Introduction to CI/CD
To understand and comprehend the ideas behind GitOps, you need to familiarize yourself with the concept of CI/CD, which is an integral part of the methodology.
CI/CD is a combination of modern DevOps principles and Agile software development practices – Continuous Integration and Continuous Delivery.
Continuous Integration (CI) is an approach to programming that involves continuously checking and merging code changes into a common branch of a central repository.
Before merging changes into the main branch, the project code is checked on a server, which knows how to build and test it.
Continuous Delivery (CD) – an approach where the program is focused on improved development, fast iterations, and high frequency of updating the work of the central repository.
The advantage of CD is simple: the more often developers submit changes to the central repository, the easier it is to maintain the project. So if users start reporting the latest update, you can roll back the previous one without affecting working features.
With CI/CD, you can automate Git processes, deploy applications, and focus on security and business logic.
Introduction to the GitOps Philosophy
What is GitOps
GitOps is a methodology that takes best development practices and transfers them to infrastructure. Thus, the latter can be considered as code (according to the IaC Infrastructure as Code model) and described declaratively using JSON or YAML files. Based on these, special software automatically implements the infrastructure, including CI/CD processes.
GitOps and Git
The GitOps framework uses Git as its primary management system. The remote repository stores and tests clusters, their update history and other information. So, if developers used to 'push' only code from repositories before, now they can do the same with full-fledged images, cluster descriptions, and Helm charts.
GitOps and DevOps
Atlassian developers believe that the idea of infrastructure as code itself comes from DevOps. The GitOps methodology simply implements DevOps methods, thus bridging the gap between system administration and distributed cloud application development.
Principles and advantages of GitOps
Let's summarize and highlight the main principles that apply when working with GitOps.
Declarative system. According to GitOps, all infrastructure is declaratively described in YAML or JSON files. Although hidden IaC can also be described using a procedural approach. The most important thing is that it should be transparent and comprehensive.
IaC is not just about servers, it's about policy, it's about everything a cloud provider has to offer.
Version Control System. It's a solid foundation and the main advantage to GitOps. And since Git is the most popular DVCS system, the methodology is aptly named GitOps.
Each infrastructure update is done through the Git repository and installed after a request for merging in the master branch (pull-requests). A group of experts tests the update and either accepts it or rejects it. This is an important advantage of the Git system.
In addition, using the Git permissions system, you can differentiate access to different parts of the project. For example, normal participants cannot accept merge requests or discreetly change the infrastructure configuration.
Automate changes. Once the experts approve the merge, the changes are automatically implemented in the application.
The system itself highlights and cleans up differences between content in the Git repository and content on the servers. For example, if the configuration file specifies that an additional web server is required, the system should automatically install it and configure the environment.
GitOps using Kubernetes as an example
GitOps is typically used in the development of cloud applications based on orchestrators like Kubernetes. Therefore, GitOps tools - which we will discuss below - contain methods that unify deployment, monitoring, cluster management, and application management. With their help, containers can be automatically updated in accordance with the latest version of the main branch.
The operator here acts as an intermediary between system orchestration and the pipeline, which checks and automatically synchronizes the repository's state with the cloud application. Here's how it works:
Developer has changed the container configuration and sends a pull request to release the pending change.
Specialists test the code and reject/accept the merge.
The merge activates the CI/CD pipeline, which automatically tests and adds the code to the registry.
Operator registers and downloads the update, then submits it to the connected local repository.
It is a declarative GitOps tool for continuous delivery (CD) and deployment of K8s applications. An important feature is 'multiplexed' management: the ArgoCD operator can work with multiple clusters simultaneously. Moreover, the tool provides not only efficient CD but also a user-friendly UI/UX.
Do not confuse this tool with Flux React architecture. It is the second most popular solution after ArgoCD. GitOps Flux also targets Kubernetes CD applications, but can only manage the cluster and repository. Otherwise, the functionality is identical.
This is an open source operator (GitOps extension) for Kubernetes for declarative management of HelmRelease and Helm charts. It can be used as a Flux extension to automate the publishing of Helm charts.
We have covered only a small part of the GitOps tools. You can also use Jenkins X, Quay, Gitkube, WKSctl and other solutions - the choice depends on the task.