Most of us, noticing yet another new term in the IT blogosphere or at a conference, sooner or later ask ourselves a question like: “What is it? Just another buzzword or something truly worthy of attention, study, and that promises new horizons?” I encountered this very question with the term GitOps some time ago. Armed with numerous existing articles and the knowledge of colleagues from the company , I tried to figure out what this creature is and how its application might look in practice.
By the way, the novelty of the term GitOps is also reflected in a recent survey we conducted: more than half of the respondents had not yet begun working with its principles.
So, the problem of infrastructure management is not new. Many cloud providers have been available to the public for a good decade, and it would seem that they should have made the work of infrastructure teams straightforward and uncomplicated. However, compared to the application development process (where the level of automation reaches new heights), infrastructure projects still often involve many manual tasks and require specialized knowledge and professionals, especially considering modern demands for fault tolerance, flexibility, scalability, and elasticity.
Cloud services successfully met these demands and they gave a significant boost to the development of the approach IaC. This is understandable. After all, they allowed for the configuration of a fully virtual data center: no physical servers, racks, or networking components; the entire infrastructure can be described using scripts and configuration files.
So what is the actual difference GitOps from IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
All code is stored in a Git repository
Versioning of code is not mandatory
Declarative code description / Idempotence
Both declarative and imperative descriptions are acceptable
Changes take effect using Merge Request / Pull Request mechanisms
Approval, endorsement, and collaboration are not required
The process of deploying updates is automated
The update deployment process is not standardized (automatic, manual, file copying, using command line, etc.)
In other words GitOps it came into existence specifically due to the application of principles IaCFirstly, the infrastructure and configurations can now be stored just like applications. Code is easy to store, share, compare, and take advantage of versioning capabilities. Versions, branches, history. And all this in a space accessible to the entire team. Therefore, it was a natural evolution to utilize version control systems, particularly git, as the most popular one.
On the other hand, it became possible to automate infrastructure management processes. Now this can be done faster, more reliably, and at a lower cost. Moreover, the principles of CI/CD were already well-known and popular among software developers. It was merely necessary to transfer and apply the existing knowledge and skills to the new domain. However, these practices extended beyond the standard definition of Infrastructure as Code, thus giving rise to the concept. GitOps.
Curiosity GitOps, of course, also lies in the fact that this is not a product, plugin, or platform associated with any vendor. It is more of a paradigm and a set of principles, similar to another term we are familiar with: DevOps.
In the company We have developed two definitions of this new term: theoretical and practical. Let's start with the theoretical:
GitOps is a methodology that uses advanced DevOps principles applied in application development, such as version control, collaboration, agreement, CI/CD, and applies them to solve infrastructure management automation challenges.
All processes GitOps work with existing tools. All infrastructure code is stored in the familiar git repository, changes go through the same approval process as any other software code, and the deployment process is automated, which minimizes human error, increases reliability, and reproducibility.
From a practical perspective, we describe GitOps as follows:
Infrastructure as Code we have already discussed as one of the key components of this formula. Let's consider the other participants.
Merge Request (alternative name for Pull Request). In terms of the MR process, it is a request to apply code changes and later merge branches. But regarding the tools we use, it is more about getting a complete picture of all the changes being made: not just a code diff collected from a number of commits, but also the context, test results, and the expected final outcome. When it comes to infrastructure code, we are interested in how exactly the infrastructure will change, how many new resources will be added or removed, and what will be modified. Ideally, this should be presented in a more convenient and easily readable format. In the case of cloud providers, it would be good to know what financial consequences this change will entail.
But MR is also a means of collaboration, interaction, and communication. It is the place where the system of checks and balances comes into play. From simple comments to formal approvals and agreements.
And the last component: CI/CD, as we already know, allows us to automate the process of making infrastructure changes, testing (from simple syntax checks to more complex static code analysis). And also subsequently detecting drift: differences between the actual and desired state of the system. For example, as a result of unauthorized manual changes or system failures.
Yes, the term GitOps does not introduce us to anything absolutely new, does not reinvent the wheel, but merely applies the accumulated experience in a new area. But this is where its strength lies.
And if you suddenly become interested in how this all looks in practice, I invite you to watch our , where I explain step by step how to use GitLab to:
Implement the core principles of GitOps
Create and modify cloud infrastructure (using Yandex Cloud as an example)
Automate the detection of system drift from the desired state through active monitoring
https://bit.ly/34tRpwZ
Source: habr.com
