↓Skip to main content

GitOps Fundamentals

·854 words·5 mins
Gitops
Vinay V
Author
Vinay V
Passionate about building scalable, reliable platforms through automation and best practices.
Table of Contents

In this blog, lets understand some basics about GitOps, how it is different from traditional DevOps CI/CD and some practical use cases around it.

Overview
#

GitOps Methodology is a set of principles, practices and workflows for managing and operating infrastructure and applications in a declarative way.

One of the fundamental concept of GitOps is the usage of git as a single source of truth for all the application configurations, deployment manifests, and infrastructure code.

GitOps Principles

  1. Declarative Description
  2. Versioned and Immutable
  3. Automated Deployments
  4. Continuous Reconciliation

Declarative Description

GitOps follows a declarative approach which defines the desired operating state of the systems (ex. YAML files). This principle emphasis more on “what” the system should look like instead of specifying the procedures for “how” to achieve it.

Versioned and Immutable

GitOps uses git for storing the desired state of a system via declarations that is versioned and are immutable. This further helps in access control and auditing on the changes to the desired state.

Automated Deployments

GitOps focus on continuous delivery model, where changes are deployed to the environment upon approval. Any changes committed to a git repository via (PR or MR), GitOps agents would deploy the changes to the target system.

Continuous Reconciliation

This is one of the key feature of GitOps — The process of ensuring the actual state of the system matches its desired state. In a traditional CI/CD automation is generally driven by pre-set triggers, where as in GitOps reconciliation is triggered whenever there is a drift detected.

GitOps follows control-theory , which operates in a closed feedback loop to keep the desired and actual states in sync, either by doing an automated sync or waits for manual intervention (more on this later..)

DevOps CI/CD vs GitOps
#

alt text

DevOps CI/CD Approach

The above flow represents the traditional CI/CD process with basic steps.

  1. Developers commits source code of the application to a version control system.
  2. CI system builds the application along with other additional actions such as unit tests, security scans, lint, static code analysis etc.
  3. As part of build step [2] a container image would be produced and that’s pushed to a container registry.
  4. Post the build step the CD platform in this case it could be a continuous deployment or a continuous delivery model would interact with the cluster creates or updates the deployment using commands like kubectl apply or helm install.

Cons:

Two main disadvantages of the above approach are :

  1. The cluster state is decided by a set of commands or API’s — So this means the state can easily be changed in the future and its hard to keep track of the changes (depending on the release cadence followed).
  2. Access control and policies to the CD agents that deploys to the cluster needs to be managed efficiently if that’s not taken care of then your CD agents would have unrestricted access to the cluster. GitOps Approach

alt text

The above flow represents the GitOps CI/CD process.

  1. As we can see above workflow, both the application code and its respective configurations are stored in git and the version changes are applied via a pull request — A declarative approach.
  2. Once the PR is merged the GitOps agents in the cluster would automatically pick those changes and sync the actual state with the desired state (as per git changes)

Pros:

Some of the key advantages of this approach:

  1. The state of the application is always described and stored in Git. Here Git not only holds application code but also the configurations related to it.
  2. There is no external deployment (CD) system with full access to cluster, instead the cluster pulls the changes as an when required. There is no additional access control required.
  3. The GitOps controller or agents runs in a closed feedback loop and does continuous reconciliation to keep the desired and actual states in sync.

Use case of GitOps Methodology
#

Below are some of the important use-cases of GitOps over traditional DevOps systems.

Continuous Deployment:

  1. GitOps can be used in continuous deployment approach which fosters automated releases — useful for such environments with microservices and requires frequent and faster deployments without any manual intervention.

  2. Rollbacks and Rolling updates are made easy and simple with git commits — With states stored in git which becomes a single source of truth for application and its configurations.

Self Healing Systems:

  1. With continuous reconciliation feature, where system constantly ensures the actual state matches with the desired state and automatically corrects if any drifts are found.
  2. This reduces operational overhead and removes manual changes in the system thus streamlining the process of change management w.r.t application configurations.

Multi-Environment Management:

  1. With git being the single source of truth for configurations, different environment manifests can be managed in different branches or different directories thus streamlining environment management.
  2. Changes to a specific environment folder will sync respective environment in an automated fashion.
  3. This ensures consistency between environments and reduces configuration drifts between them, and promotion of changes from one environment to another would be handled through pull requests and merges.

GitOps agents.

Some of the popular GitOps tools out there.

  • ArgoCD
  • Flux
  • Jenkins X
  • Weave GitOps