You’ve seen DevOps, and DevSecOps, and maybe even NoOps. But if you haven’t already, you’re going be hearing a whole lot more about GitOps.
As an indicator, four of the sessions at the upcoming KubeCon are about GitOps. You might not know what GitOps is, but if you’re developing software, there’s a good chance you’re already doing it.
What’s GitOps? And do we really need another software development buzzword?
Well, GitOps is really the culmination of a few different trends in software development, deployment, and operation taken to their logical conclusion. Together, they create a new way of working with new powerful synergies.
The term GitOps was coined by Alexis Richardson at Weaveworks, where it was focused on running Kubernetes-based infrastructures.
But GitOps is a much bigger idea than just Kubernetes; it’s a philosophical approach to developing and deploying software that can be applied more broadly by any company which runs its own code on its own infrastructure with its own configurations.
Single Source of Truth
The first principle of GitOps, and perhaps the one most emphasized by Alexis Richardson is that in GitOps, Git (or the version control system of your choice!) is the “single source of truth” for application code, infrastructure and configurations.
This is a term from Information Theory but essentially it means this: Git is always right. It’s the last word. You can understand the whole system by looking at Git and without looking everywhere else. It has all the ingredients right there.
Everything as Code
Those ingredients include the code of the applications, of course, and the various other code components that applications use like libraries and frameworks. But they also include other types of code. Configurations, once stored in databases, are now codified in YAML files in Git repositories. In many cases, infrastructure, too, is defined in code now, whether virtual servers, Docker images or Kubernetes clusters. Taken together, these different sorts of code are able to describe the whole system.
CI/CD Automation
That’s where the magic kicks in. Automated test, build and deployment tools take over the CI/CD process, relying on the Truth in the repository to accurately create the system, creating the infrastructure-as-code to run the application code according to the configuration-as-code.
Nick Young, Principal Engineer at Atlassian, elegantly described this process as “declaring the desired state of things and then waiting for the system to bring the world into line with the desired state.”
This is GitOps. The system is completely described and ‘declared’ in Git and is created automatically to match those declarations.
Why GitOps?
One benefit of GitOps is at the philosophical level. It’s elegant, stripping away the dross and allowing developers to worry about code and code alone.
But there are also big practical benefits too. With GitOps, you make every change to the system by changing a Git repository. Everything is done by pull request, meaning there’s an audit trail, reversibility and transparency.
There’s no weird hidden setting somewhere that someone changed by mistake and nobody knows about. If something doesn’t work, the problem is in the repo… somewhere. And it’s in the commit history,
GitOps also adds consistency. Instead of hunting through varied control panels for different settings, a developer’s workflow is all in one place. There’s no context-switching between managing application code and infrastructure.
New challenges
Every new approach brings new challenges too. GitOps is the ultimate “shift left”; if code makes it into a repository, it automatically gets pushed to production.
This means software developers have to use different tactics to catch bugs or other mistakes, ideally before they are committed. This has benefits, of course. The earlier you catch an error, the better.
GitOps also makes use of “Canary Deployments” where only a small number of users get access to the newly-deployed system to limit any possible bugs.
GitOps means that you need to be careful to ensure that you don’t merge pull requests that can do bad things. Automated CI/CD tools will often test the application code, but a single typo in a YAML Ansible template can mean a software-defined server is broken, or insecure.
Another issue is what happens when the live system changes in some unexpected way. In a GitOps system, merging a Pull Request starts the process that ultimately changes the live system.
But sometimes the system itself doesn’t do what it’s supposed to do – maybe there’s a hardware failure somewhere, for example. So you also need tools that can keep an eye on the system and, if necessary, bring it back into alignment.
If GitOps sounds like a lot, it is, both conceptually and practically. To do pure GitOps is kind of aspirational at the moment, especially if you’re not using Kubernetes.
But the chances are that you’re doing some of this already. Maybe your software organization tries to use Git as a single source of truth; perhaps you’ve moved all your configs to YAML or have some automated CI/CD pipeline from repo to production. All of these are steps on the road to GitOps.
Meanwhile, GitOps tools are coming quickly, with new options to support everything from checking Pull Requests to better, more automated CI/CD to tools for monitoring production. As these tools mature, GitOps will become less of an aspiration and more of a reality.
Source: The Next Web
To Read Our Daily News Updates, Please Visit Inventiva Or Subscribe Our Newsletter & Push.
