GitOps: another buzzword or a breakthrough in automation?
Most of us, noticing another new term in the IT blogosphere or conferences, sooner or later ask a similar question: “What is this? Another buzzword, “buzzword” or really something worth close attention, study and promises new horizons? ” The same thing happened with me with the term GitOps some time ago. Armed with many existing articles, as well as the knowledge of colleagues from the GitLab company, I tried to figure out what kind of beast it is, and how its application might look like in practice.
By the way, about the novelty of the term GitOps a survey we recently conducted also says: more than half of the respondents have not yet started working with its principles.
So, the problem of infrastructure management is not new. Many cloud providers have been available to the general public for a dozen years and, it would seem, should have made the work of the teams responsible for the infrastructure simple and unpretentious. However, when compared to the application development process (where the level of automation is reaching new and new horizons), infrastructure projects still often involve many manual tasks and require special knowledge and specialists, especially given today’s requirements for fault tolerance, flexibility, scalability and elasticity.
Cloud services met these requirements very successfully and they gave a significant impetus to the development of the approach IaC… It is understandable. After all, it was they who made it possible to configure a completely virtual data center: there are no physical servers, racks, network components, the entire infrastructure can be described using scripts and configuration files.
So what is the actual difference GitOps from IaC? It was with this question that I began my investigation. After talking with colleagues, I was able to work out the following comparison:
GitOps | IaC |
All code is stored in the git repository | Code versioning is optional |
Declarative Code Description / Idempotency | Both declarative and imperative descriptions are allowed |
Changes take effect using Merge Request / Pull Request mechanisms | Negotiation, approval and collaboration are optional |
The update rollout process is automated | The process of rolling out updates is not standardized (automatic, manual, copying files, using the command line, etc.) |
In other words GitOps was born precisely through the application of principles IaC… First, the infrastructure and configurations could now be stored just like applications. The code is easy to store, easy to share, compare, and use versioning capabilities. Versions, branches, history. And all this in a place publicly available to the entire team. Therefore, the use of version control systems has become a completely natural development. In particular, git is the most popular.
On the other hand, it became possible to automate infrastructure management processes. Now it can be done faster, more reliably and cheaper. Moreover, the principles of CI / CD were already known and popular among software developers. It was only necessary to transfer and apply already known knowledge and skills to a new area. These practices, however, went beyond the standard definition of Infrastructure as code, hence the concept GitOps…
Curiosity GitOpsof course, also in the fact that this is not a product, plugin or platform associated with any vendor. Rather, it is a paradigm and a set of principles, similar to another term familiar to us: DevOps.
At GitLab, we have developed two definitions for this new term: theoretical and practical. Let’s start with a theoretical one:
GitOps is a methodology that takes advanced DevOps principles used for application development such as version control, interoperability, reconciliation, CI / CD, and applies them to solve infrastructure management automation tasks.
All processes GitOps I work using existing tools. All infrastructure code is stored in the familiar git repository, changes go through the same approval process as any other program code, and the rollout process is automated, which minimizes human error, improves reliability and reproducibility.
From a practical point of view, we describe GitOps in the following way:
We have already discussed infrastructure as code as one of the key components of this formula. Let’s introduce the rest of the participants.
Merge Request (alternative name for Pull Request). In terms of the process, MR is a request to apply code changes and then merge branches. But in terms of the tools we use, this is rather an opportunity to get a complete picture of all the changes that are being made: not only the code diff collected from a certain number of commits, but also the context, test results, and the final expected result. If we are talking about infrastructure code, then we are interested in how exactly the infrastructure will change, how many new resources will be added or removed, changed. Preferably in some more convenient and readable format. In the case of cloud providers, it would be nice to know the financial implications of this change.
But MR is also a means of collaboration, interaction, communication. This is where the system of checks and balances comes into play. From simple comments to formal endorsements and approvals.
Well, and the last component: CI / CD, as we already know, makes it possible to automate the process of making infrastructure changes, testing (from a simple syntax check to more complex static code analysis). And also in the subsequent detection of drift: the differences between the real and the desired state of the system. For example, as a result of unauthorized manual changes or system failure.
Yes, the term GitOps does not introduce us to anything completely new, does not reinvent the wheel, but only applies the already accumulated experience in a new field. But this is his strength.
And if you suddenly become interested in how it all looks in practice, then I invite you to see our Master Class, in which I walk you through the steps using GitLab:
Implement the basic principles of GitOps
Create and make changes to the cloud infrastructure (for example, Yandex Cloud)
Automate the detection of system drift from the desired state using active monitoring
