GitOps: another buzzword or a breakthrough in automation?

GitOps: another buzzword or a breakthrough in automation?

Most of us, noticing the next new term in the IT blogosphere or conference, sooner or later ask a similar question: β€œWhat is it? Another buzzword, β€œbuzzword” or is it really something worth paying close attention to, studying and promising new horizons?” The same thing happened to me with the term gitops some time ago. Armed with many existing articles, as well as the knowledge of colleagues from the company GitLab, I tried to figure out what kind of beast it is, and how its application might look in practice.

By the way, about the novelty of the term gitops also says our recent survey: more than half of those surveyed have not yet begun to work with its principles.

So, the problem of infrastructure management is not new. Many cloud providers have been available to the general public for a good decade and, it would seem, should have made the work of infrastructure teams simple and unpretentious. However, when compared to the application development process (where the level of automation reaches 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 were very successful in fulfilling these requirements and it was they who 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 fully virtual data center: there are no physical servers, racks, network components, the entire infrastructure can be described using scripts and configuration files.

So what exactly is the difference gitops from IAC? It was with this question that I began my investigation. After talking with colleagues, I managed to develop the following comparison:

gitops

IAC

All code is stored in a 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

Coordination, approval and collaboration are optional

The process of rolling out updates is automated

The process of rolling out updates is not standardized (automatic, manual, copying files, using the command line, etc.)

In other words gitops came into existence through the application of the principles IAC. First, infrastructure and configurations could now be stored just like applications. The code is easy to store, easy to share, compare, use versioning features. Versions, branches, history. And all this in a public place for the whole team. Therefore, the use of version control systems has become quite a natural development. In particular, git, as 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.

GitOps: another buzzword or a breakthrough in automation?

curiosity gitops, of course, also in the fact that this is not a product, plug-in or platform associated with any vendor. It's more of a paradigm and a set of principles, similar to another term we're familiar with: DevOps.

The company GitLab we have developed two definitions of this new term: theoretical and practical. Let's start with the theoretical:

GitOps is a methodology that takes the best DevOps principles used for application development, such as version control, interop, reconciliation, CI/CD, and applies them to automate infrastructure management tasks.

All processes gitops I work with existing tools. All infrastructure code is stored in a familiar git repository, changes go through the same check-in process as any other 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:

GitOps: another buzzword or a breakthrough in automation?

We have already discussed infrastructure as code as one of the key components of this formula. Let's introduce the rest of the members.

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 more of an opportunity to get a complete picture of all the changes being made: not only code diff collected from a certain number of commits, but also context, test results, and the final expected result. If we are talking about the 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 easy to read format. In the case of cloud providers, it would be nice to know what the financial implications of this change would be.

But MR is also a means of collaboration, interaction, communication. The place where the system of checks and balances comes into play. From simple comments to formal approvals and statements.

Well, the last component: CI / CD, as we already know, makes it possible to automate the process of making infrastructure changes, testing (from simple syntax checking to more complex static code analysis). And also in the subsequent drift detection: differences between the real and desired state of the system. For example, as a result of unauthorized manual changes or systems failure.

Yes, the term gitops does not introduce us to anything absolutely new, does not reinvent the wheel, but only applies the experience already accumulated in a new area. But therein lies its strength.

And if you suddenly become interested in how it all looks in practice, then I invite you to look at our Master Class, in which I walk you through how to use GitLab:

  • Implement the basic principles of GitOps

  • Create and make changes to the cloud infrastructure (on the example of Yandex Cloud)

  • Automate the detection of system drift from a desired state through active monitoring

GitOps: another buzzword or a breakthrough in automation?https://bit.ly/34tRpwZ

Source: habr.com

Add a comment