What is GitOps?

What is GitOps?

GitOps is a term first used by Weaveworks Inc. in 2017 and is one of the practical approaches to DevOps in projects. It focuses especially on continuous deployment for cloud-native applications. As the name suggests, it means codifying every element related to application deployment and operations and managing those elements in Git.

Source: Weaveworks

GitOps is an operational framework that applies DevOps best practices used in application development, such as version control, collaboration, compliance, and CI/CD, to infrastructure automation.

The essence of GitOps is the idea and method of managing the code for the entire system, including infrastructure and applications, with Git. GitOps uses the Git version control system to manage infrastructure configuration files such as IaC (Infrastructure as Code).

Here, infrastructure generally assumes Kubernetes. Simply put, GitOps means managing Kubernetes manifest files in Git and deploying to the cluster with the manifests stored in Git.

Principles of GitOps

Every system should be declared declaratively.

• Declarative means the system is composed of facts, not a collection of commands.
• Kubernetes manifests are written declaratively. When they are managed in Git, they gain Git benefits such as versioning and provide a single source of truth (SSOT).

System state follows the version in Git.

• Because deployments use Kubernetes manifests stored in Git, you can deploy a previous system version with a command such as git revert.

Approved changes are applied to the system automatically.

• Once declared manifests are registered and managed in Git, every change, such as code modification, should be applied automatically to the system. Credentials should not be required each time deployment to a cluster is performed.

If deployment fails, users should be alerted.

• When system state is declared and kept under version control, a system should be prepared to alert users when deployment fails.

Benefits of GitOps

The benefits of GitOps can be summarized in four areas.

Productivity

• When Git changes, the repository’s IaC settings change, making it possible to update Kubernetes clusters and manage features through Git.
• Operations through deployment can be handled through Git, and the production state can be compared with IaC in Git so differences can be detected and corrected.

Stability

• Introducing a GitOps workflow makes it possible to automatically search audit logs for changes made externally to Kubernetes clusters.
• Because records remain for who did what and when, troubleshooting becomes easier.

Reliability

• In manual infrastructure management, mistakes such as incorrect kubectl apply targets can occur. GitOps avoids these mistakes. Rollbacks and other operations are managed through Git, enabling stable and reproducible operations.

Security

• Deployments with CI/CD tools often push to a cluster through kubectl, requiring credentials to be exposed outside the cluster. This may be undesirable from a security perspective because CI and CD are not separated.
• GitOps separates and manages CI and CD. Because it uses Pull to change the cluster, credentials do not need to be exposed externally, reducing security risk.

GitOps Workflow

The following is a GitOps pipeline diagram introduced in the official Weaveworks blog.

As the diagram shows, both CI and CD manage code in Git, but the CI and CD functions are separated.

GitOps Repository

When designing a GitOps pipeline, it is generally recommended to use two Git repositories: one for application code and one for infrastructure environment configuration.

Source: https://www.gitops.tech/#push-based-deployments

• Application Repository (Git Code)
  • Includes application source code and deployment manifest files, such as Kubernetes YAML.
• Repository for infrastructure environment configuration (Git Config)
  • Includes all manifests for the deployment environment, such as monitoring, services, and MQ, and defines which versions and configurations are used.

GitOps deployment strategies

GitOps has two deployment strategies: push-based pipelines and pull-based pipelines. The difference is how the manifests in the repository are matched with the state of the deployment environment. In general, pull-based deployment is considered safer from a security perspective and is preferred.

Most CI/CD tools used recently use a push-based model. A push-based pipeline starts from code in the CI system and continuously pushes changes to a Kubernetes cluster through scripted paths, often using kubectl directly.

The reason not to use deployment functions in a CI system or manual command-line deployment is that credentials may be exposed outside the cluster. Although CI/CD scripts and command lines can be secured, they operate outside the cluster’s trust domain. This is generally not a good approach, and CI systems can become an external intrusion path into production.

Push Pipeline

A push-based pipeline runs a deployment pipeline when manifest files in a Git repository change.

Source: https://www.gitops.tech/#push-based-deployments

It is not affected by the number of deployment environments, and deployment environments can be added or changed simply by adding or modifying connection information. The architecture is simple, so it is used in many places.

In general, a push pipeline has read/write permissions outside the cluster in CI, which can expose security information externally.

Source: https://www.weave.works/technologies/gitops/#a-diy-gitops-pipeline

Pull based Pipeline

This structure uses a separate operator located in the target cluster to perform deployment.
Source: https://www.gitops.tech/#pull-based-deployments

The operator continuously compares the manifests in the Git repository with the deployment environment. When a difference occurs, it keeps the cluster aligned with the manifests in the Git repository.

In a pull-based pipeline, the GitOps tool fetches images and credentials are kept inside the cluster, so security information is not exposed externally.

Image: https://www.weave.works/technologies/gitops/#a-diy-gitops-pipeline

GitOps tools

There are three commonly used tools.

Argo CD

• Argo CD provides an easy-to-understand GUI.
  • All operations, such as manual sync, can be performed from the GUI.
• Related sites
  • Source code: https://github.com/argoproj/argo-cd/
  • Documentation: https://argo-cd.readthedocs.io/en/stable/

Flux CD

• A tool from Weaveworks, which proposed GitOps. It is simple and lightweight, but does not provide a GUI.
• Related sites
  • Source code: https://github.com/fluxcd/flux2
  • Documentation: https://fluxcd.io/flux/

Jenkins X

• A tool derived from Jenkins. It can build CI/CD-capable pipelines themselves.
  • Argo CD and Flux CD handle only CD.
• It is highly flexible, but its architecture is complex, so the learning cost is also high.
• Related sites
  • Source code: https://github.com/jenkins-x/jx-cli
  • Documentation: https://jenkins-x.io/v3/about/

References

• GitOps | GitOps is Continuous Deployment for cloud native applications
• Guide To GitOps | Weaveworks