You've seen DevOps and DevSecOps and possibly even NoOps. If you have not already done so, you will learn much more about GitOps.
As an indicator, four of the sessions will be at the upcoming KubeCon GitOps. You may not know what GitOps is, but if you develop software, there is a good chance that you will already be doing it.
What is GitOps? And do we really need another buzzword for software development?
Well, GitOps is truly the culmination of several different trends in software development, deployment, and operation that lead 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 he focused on operating infrastructures based on Kubernetes.
But GitOps is a much bigger idea than just Kubernetes. It is a philosophical approach to developing and delivering software that can be more widely used by any company that 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 Git (or the version control system of your choice!) Is the only source of GitOps (1
This is a term from information theory, but essentially it means: Git is always right, it's the last word, you can understand the entire system by looking at Git and without looking any other way around, it has all the ingredients right there.
Everything as Code
Of course this includes the code of the applications and the various other code components that use applications like libraries and frameworks, but they also contain other types of Code Once stored in databases, configurations are now codified into YAML files in Git repositories, and in many cases the I infrastructure is now defined in code, whether virtual servers, docker images, or Kubernetes clusters (19459012). Taken together, these different types of code can describe the entire system.
CI / CD automation
This is where the magic begins. Automated testing, build, and deployment tools adopt the CI / CD process and rely on the truth in the repository to accurately build the system and build the infrastructure code to run the application code as code, as configured.
Nick Young, chief engineer at Atlassian, elegantly described this process as " declaring the desired state of affairs and waiting for the system to reconcile the world with the desired state ]]. "
This is GitOps. The system is fully described and "declared" in Git and is automatically created to conform to these declarations.
An advantage of GitOps is on a philosophical level. It's elegant by removing the garbage and allowing developers to just take care of code and code.
But there are also great practical advantages. With GitOps, you make any change to the system by modifying a git repository. Everything is done by pull request, which means there is an audit trail, reversibility and transparency.
There are no strange, hidden settings that someone has mistakenly changed and nobody knows. If something does not work, the problem is in the repo … somewhere. And it's in the commit history
. GitOps also adds consistency. Instead of searching for different settings through different panels, a developer's workflow is in one place. There is no context switching between application code management and infrastructure.
Each new approach brings with it new challenges. GitOps is the ultimate "left shift"; When code is added to a repository, it is automatically moved to production.
This means that software developers must use different tactics to catch errors or other errors, preferably before they are committed. Of course, this has advantages. The sooner you detect a mistake, the better.
GitOps also uses "Canary Deployments", where only a few users gain access to the newly deployed system to limit potential errors.
GitOps means you have to be careful to make sure that you do not merge pull requests that can cause bad things. Automated CI / CD tools often test the application code. However, a single typo in a YAML ansible template may mean that a server defined by the software is broken or unsafe.
Another problem is what happens when the live system changes in an unexpected way. In a GitOps system, merging a pull request starts the process that ultimately changes the live system.
Sometimes the system itself does not do what it is supposed to do – there may be a hardware failure, for example. Therefore, you also need tools that can keep track of the system and, if necessary, realign it.
When Gi tOps sounds like a lot it's both conceptual and practical. Doing pure GitOps is a bit challenging at the moment, especially if you do not use Kubernetes.
But chances are you're already doing some of that. Your software organization may be trying to use Git as the only source of truth. You may have moved all of your configurations to YAML or have an automated CI / CD pipeline from repo to production. All these are steps on the way to GitOps.
Meanwhile, GitOps tools come with new options that support everything, from reviewing pull requests, to better, more automated CI / CD, to production monitoring tools. As these tools mature, GitOps becomes less of an aspiration and more of a reality.