Do you know GitOps?


Do you know what means GitOps?

The term GitOps was first publicized by Weaveworks in 2017 and originally is a way to do Kubernetes cluster management and application delivery using Git as a single source of truth for declarative infrastructure and applications. Weaveworks describes GitOps as:

Concept GitOps
An operating model for Kubernetes and other cloud-native technologies, providing a set of best practices that unify deployment, management, and monitoring for containerized clusters and applications. A path toward a developer experience for managing applications, where end-to-end CI/CD pipelines and Git workflows are applied to both operations and development.

The main of GitOps  is use software agents to alert when occurs divergence between Git with what’s running in a cluster, and if there’s a difference, Kubernetes reconcilers automatically update or rollback the cluster depending on the case.

In GitOps, Git and is the center of your delivery pipelines and end-to-end CI/CD pipeline workflows are applied to both operations and development teams.

Why Use GitOps?

This paradigm is focused on the developer’s experience. It’s based on a single source for its state file and is based on a pull pipeline approach instead of the regular push pipeline. Also cluster state is inside a Git repository. Using Git commit history, engineers can view current deployment and change history. You can roll back by using git commands. Git access control policies also apply to deployments. For example, there’s an option in Git for only a few users to have permission to push to the master branch. With this access control, a few people are given access to deployment, and others can request a change using a pull request.

Principle of GitOps

1. The entire system described declaratively.

Declarative means that configuration is guaranteed by a set of facts instead of by a set of instructions. With your application’s declarations versioned in Git, you have a single source of truth. We can deploy and roll back our app and when disaster strikes, your cluster’s infrastructure can also be reliability and quickly reproduced.

2. The canonical desired system state versioned in Git.

With the declaration of your system stored in a version control system, and serving as your canonical source of truth, you have a single place from which everything is derived and driven. You can also improve the security using your SSH key to sign commits that enforce strong security guarantees about the authorship and provenance of your code.  

3. Approved changes that can be automatically applied to the system.  

With GitOps, there is a segregated environment of which the state definition lives outside. This allows you to separate what you do and how you’re going to do it.

4. Software agents to ensure correctness and alert on divergence.

Once the state of your system is declared and kept under version control, software agents can inform you whenever reality doesn’t match your expectations.  The use of agents also ensures that your entire system is self-healing, not only when nodes or pods fail.

Benefits of GitOps

The Key benefits of GitOps are automated delivery pipelines roll out changes to your infrastructure when changes are made to Git and provision tools to compare the actual production state of your whole application with what’s under source control and then it tells you when your cluster doesn’t match the real world. By applying GitOps best practices, there is a ‘source of truth’ for both your infrastructure and application code, allowing development teams to increase velocity and improve system reliability.

There are Many benefits when applying GitOps practices, such as:

Increased Productivity through  continuous deployment automation with an integrated feedback bringing more changes per day.

Enhanced Developer Experience through push code. Developers can work tools which they have familiar to manage updates and features without having to know infra technologies in depth. Its complete end to end pipeline, not only are your continuous integrations and continuous deployment pipelines all driven by pull request, but your operations tasks are also fully reproducible through Git. 

Improved Stability using Git workflows to manage your cluster and audit trail of who did what, and when to your cluster.

Higher Reliability with Git’s capability to revert/rollback and fork, you gain stable and reproducible rollbacks.

Consistency and Standardization Not only are your continuous integration and continuous deployment pipelines all driven by pull request, but your operations tasks are also fully reproducible through Git.  

Stronger Security Guarantees Git’s strong correctness and security guarantees, backed by the strong cryptography used to track and manage changes, as well as the ability to sign changes to prove authorship and origin is key to a secure definition of the desired state of the cluster. 

So, the reader can do some questions about relations between GitOps and Infra as Code because the IaC too use declarative tools and files to entire set of configuration files, versioned, backed up and reproducible from source control.  GitOps through Kubernetes brought completely declarative, combined with the immutable container, it is possible to extend some of these concepts to managing applications and their operating system as well. The ability to manage and compare the current state of both your infrastructure and your applications so that you can test, deploy, rollback with a complete audit trail all from Git is what encompasses the GitOps philosophy and its best practices.  This is possible because Kubernetes is managed almost entirely through declarative config and because containers are immutable. The important thing to mention here is to use always declarative language instead imperative on Kubernetes to accomplish GitOps, otherwise you cannot track these changes.

GitOps takes full advantage of the move towards immutable infrastructure and declarative container orchestration for immutability as well as different cloud native tools like Terraform and Ansible to automate and manage our configuration. These tools together with containers and declarative nature of Kubernetes provide what we need for a complete recovery in the case of an entire meltdown.  

GitOps Workflow

Imagine the following scenario

One team desire to development and deploy a simple application and they want that whenever a new commit hits the master branch a new pipeline is executed. The application is deployed on two environments (stage and production). In order to accomplish the GitOps model, the team should have one repository with three branches:

  • Configuration: should have common files to all environments
  • Stage: should have files for deploying the application into the stage environment
  • Production: should have files for deploying the application into the production environment

The basic pipeline should attend for:

  • Download the new code
  • Run tests
  • Build the app on a container image
  • Push the container image to container image repository

In view of the previous requirements the GitOps Workflow should look like this:

  1. Developers push new changes to the application repository
  2. The changes are tested and a new image is built automatically
  3. Developers request the deployment of the new image by sending a Pull Request to the stage branch on the repository
  4. The Pull Request is reviewed and merged
  5. The new image version is deployed automatically on stage environment
  6. After testing the application on the stage environment a Pull Request is sent to the production branch to deploy the application on production environment
  7. The Pull Request is reviewed and merged
  8. The new image version is deployed automatically on production

Whenever a new commit hits stage or production branches one trigger is started. In this case, you can use webhook in git repository to build your app, for stage deployment and production deployment.

Is GitOps for me?

If you would like to build a developer-centric experience that lets DevOps worry about the state of the cluster, and developers control the state of their application and want provide infrastructure stability and application reliability you can think in GitOps.

  • History and rollback to any application configuration in the target Git repository

  • Automatic deployment of an application to a Kubernetes cluster

  • Management and deployment to multiple clusters

  • A version control system (to house all information, documentation, and code)

  • Operational workflow management

  • An easy way to revert to your previous application state

  • An audit trail

  • A single source of truth


The tools for GitOps is growing continuously but now it is possible to use the following tools:

  • Argo CD that is a GitOps continuous delivery tool for Kubernetes.

  • FLux that is a tool that automatically ensures that the state of your Kubernetes cluster matches the configuration you’ve supplied in Git

  • Jenkins X that has capabilities to promote the environment via GitOps, and it implements CI/CD pipelines.

In the next posts, we will setup an pratical example using GitOps or any set of tools mentioned here.