The concept of GitOps was first proposed by Weaveworks, a Kubernetes management company, in 2017. It has been 5 years now. Everyone must have heard of this concept, but you may not know what it is. What is it and DevOps? What is the relationship, this article is here to help you understand one by one.
Infrastructure as Code
Before understanding GitOps, we need to understand what infrastructure as code is .
Infrastructure as Code ( IaC ), as the name suggests, means using code (rather than manual processes) to define infrastructure, and developers can treat infrastructure like application software, for example:
- You can create declarative configuration files that contain infrastructure specifications, making it easy to edit and distribute configurations.
- You can ensure that the environment you configure is exactly the same every time.
- Version control can be performed, and all changes will be recorded for easy traceability.
- The infrastructure can be divided into several modular components and combined in different ways through automation.
Of course, IaC in a broad sense is not only about infrastructure, but also includes network , security , configuration , etc., so IaC in a broad sense is also called X as Code .
For example, if you want to create servers, configure networks, deploy Kubernetes clusters and various workloads in AWS, you only need to define the declarative configuration of Terraform or Ansible, as well as the configuration list of Kubernetes, without all the complicated manual operations.
What is GitOps
GitOps = IaC + Git + CI/CD, which is versioned CI/CD based on IaC. Its core is to use the Git repository to manage the configuration of infrastructure and applications, and to use the Git repository as the single source of truth for infrastructure and applications , you will not be allowed to modify the configuration from other places (such as manually changing the online configuration).
The declarative configuration in the Git repository describes the desired state of the infrastructure currently required by the target environment. With GitOps, if the actual state of the cluster does not match the desired state defined in the Git repository, Kubernetes reconcilers will adjust the current state according to the desired state. state, and finally make the actual state match the desired state.
On the other hand, the development of modern applications is more about iterative speed and scale. Organizations with a mature DevOps culture can deploy code to production environments hundreds of times a day. DevOps teams can use version control, code reviews, and automated testing and Best practices like a deployed CI/CD pipeline to achieve this, which is what GitOps does.
GitOps vs DevOps
In a broad sense, GitOps does not conflict with DevOps, GitOps is a technology, and DevOps is a culture . GitOps is a tool and framework for Continuous Delivery, Continuous Deployment, and Infrastructure as Code (IaC) that supports the DevOps culture.
In a narrow sense, GitOps and DevOps have the following differences:
First, GitOps is goal-oriented . It uses Git to maintain the desired state, and constantly adjusts the actual state to eventually match the desired state. DevOps, on the other hand, focuses more on best practices that can be applied universally to every process in an enterprise.
Second, GitOps takes a declarative approach to operations, while DevOps accepts both declarative and imperative approaches , so DevOps is applicable to virtual machines and bare metal environments in addition to container environments.
Finally, GitOps redefines CI/CD in cloud-native scenarios with Git-centric immutable state declarations to speed up continuous deployment.
The Design Philosophy of GitOps
To use GitOps to manage your infrastructure and applications, you need to practice the following principles:
1. Declarative
The desired state of the system must be described declaratively. For example, Kubernetes is just one of many modern cloud-native tools that are declarative.
2. Versioning / Immutability
Because all state declarations are stored in the Git repository, and the Git repository is used as the single source of truth, all operations are driven from the Git repository, and the full version history is preserved for easy rollbacks. With Git’s excellent security guarantees, SSH keys can also be used to sign commits, implementing strong security guarantees about the authorship and provenance of code.
3. Automatically apply changes
Any changes to the desired state declared in the Git repository can be applied to the system immediately, and there is no need to install and configure additional tools (such as kubectl), nor to configure Kubernetes authentication and authorization.
4. Continuous Reconciliation
Reconciliation is actually a concept in Kubernetes at first, which represents the process of ensuring that the actual state of the system is consistent with the expected state . The specific implementation is to install an agent in the target environment. Once the actual state does not match the expected state, the agent will automatically repair it. The repair here is more advanced than Kubernetes’ self-healing, even if the cluster’s orchestration manifest is manually modified, the cluster will be restored to the state described by the manifest in the Git repository.
Given these design philosophies above, let’s take a look at the GitOps workflow:
- First, any member of the team can Fork the repository to make changes to the configuration, and then submit a Pull Request.
- Next, the CI pipeline is run, which generally does several things: verifying configuration files, executing automated tests, detecting code complexity, building OCI images, pushing images to image repositories, and so on.
- After the CI pipeline runs, someone on the team with permission to merge the code will merge the Pull Request into the master branch. Generally, those who have this authority are R&D personnel, security experts or senior operation and maintenance engineers.
- Finally, the CD pipeline runs to apply the changes to the target system (such as a Kubernetes cluster or AWS).
The entire process is fully automated and transparent, ensuring the robustness of the declarative configuration of the infrastructure through multi-person collaboration and automated testing. The traditional model is that one of the engineers operates it all on his own computer, and the others don’t know what’s going on and can’t review their operations.
Push vs Pull
The CD pipeline has two modes: Push and Pull.
Push mode
Most of the current CI/CD tools use Push-based deployment mode, such as Jenkins, CircleCI, etc. This mode generally executes a command (such as kubectl) to deploy the application to the target environment after the CI pipeline is completed.
The flaws of this CD mode are obvious:
- Need to install and configure additional tools (such as kubectl);
- Requires Kubernetes to authorize it;
- Cloud platform authorization is required;
- Unable to sense deployment status. It is impossible to perceive the deviation between the expected state and the actual state, and additional solutions are needed to ensure consistency.
The authorization credentials of the Kubernetes cluster or cloud platform to the CI system are outside the trust domain of the cluster or cloud platform and are not protected by the security policy of the cluster or cloud platform. Therefore, the CI system can easily be used as a carrier of illegal attacks.
Pull mode
Pull mode will install an Agent in the target environment. For example, in the Kubernetes cluster, the Operator will act as the Agent. The Operator periodically monitors the actual state of the target environment and compares it with the desired state in the Git repository. If the actual state does not match the desired state, the Operator updates the actual state of the infrastructure to match the desired state.
Only Git’s changes can be used as the only source of the desired state. In addition, no one can make any changes to the cluster. Even if you modify it, it will be restored to the desired state by the operator, which is the legendary immutability . infrastructure .
The current CD tools based on Pull mode are:
Argo CD ,
Flux CD and
Advantages of GitOps
Generally, GitOps prefers the Pull-based deployment mode, because this mode has many irreplaceable advantages.
stronger security
As mentioned above, using GitOps does not require any Kubernetes or cloud platform credentials to perform deployment. Argo CD or Flux CD in the Kubernetes cluster only needs to access the Git repository and update it through Pull mode.
Git, on the other hand, is backed by strong cryptography for tracking and managing code changes, and the ability to sign changes to prove authorship and origin is key to keeping your cluster safe.
Git as the single source of truth for facts
Because all the declarative configuration of the application, including the infrastructure, is stored in Git, and Git is the single source of truth for the application system, it is possible to use the power of Git to operate everything, such as version control, history, auditing and rollbacks And so on, no need to use a tool like kubectl to do it.
increase productivity
Git is also a tool that developers are very familiar with. Continuous iteration through Git can improve productivity, speed up development and deployment, and launch new products faster, while improving the stability and reliability of the system.
Easier compliance audits
Infrastructure using GitOps can be managed using Git like any software project, so it can also be audited for quality. When someone needs to make a change to the infrastructure, a Pull Request is created, and the change can be applied to the system after the relevant person has code-reviewed it.
Summarize
GitOps complements the existing DevOps culture and uses a version control system like Git to automate the deployment of infrastructure, with visibility of the deployment process, visibility and tracking of any changes made to the system, improved productivity, security and compliance . And GitOps provides more elegant observability, observing deployment status in real time and taking action to align the actual state with the desired state.
Moreover, in GitOps, the entire system is described by declarative, which is naturally suitable for cloud-native environments, because Kubernetes is also designed in this way.
References
This article is reprinted from https://icloudnative.io/posts/what-is-gitops/
This site is for inclusion only, and the copyright belongs to the original author.