What is GitOps?: OS tools for GitOps Deployment

A Decisive Victory for Progressive Policies

Share this article:

GitOps is a software delivery philosophy to treats source code management systems like Git as the source of truth for applications, application configuration, and infrastructure as code. The idea is that all the changes to an application or infrastructure are stored in Git and synchronized with the target environment in real time through frequent reconciliation.

Difference between GitOps and DevOps?

Very often IT folks get confused about the two terminologies and assume GitOps is perhaps an advanced version of DevOps. However, there are differences between the two and we will see how the industry needs both GitOps and DevOps to succeed in their software delivery.

DevOps methodology is applied to bring more collaboration between software development and operations teams with an ultimate goal to reduce the time and cost of the software delivery life cycle (SDLC) process. The central idea of DevOps existed in the 1990s but the name was coined and industry started using it from the late 2000s.

On the other hand, GitOps was coined in 2017 by Weaveworks with the emergence of Docker containers, Kubernetes and the concept of Infrastructure as code (IAC). The goal of the GitOps philosophy is to reduce configuration drift and practice continuous deployments into multiple environments with less human intervention. ‍

In a nutshell, DevOps aims to improve the whole SDLC process which would involve a lot of tools and software along with inculcating the culture through frequent training to developers and Ops team, while GitOps aims to fasten the deployment activity (a sub-process of SDLC) using a one or two tools.

Six golden principles to practice GitOps

If you want to start implementing the GitOps process for your Kubernetes application delivery then you need to follow the six major principles of GitOps and its best practices. Note, that we have extended four principles by Weaveworks to six principles based on our experience with large-scale implementation.

1. Everything Declarative- Apps, Configurations and Infrastructure

Every object in the tech stack i.e. apps and infrastructure should be described declaratively. Storing infrastructure configuration in a declarative state (using YAML or JSON format) will help trace the list of items changed and its related impact on the production or customer experience. One can store deployments, load balancers, API gateway configurations, traffic management rules, and security policies in Git and maintain them. The benefit of using declarative configuration instead of scripts or commands is Ops team can avoid configuration drifts in their environments.

2. Everything Version Control

The second feature is to store all the declarative configurations in a version control management system such as Git or Bitbucket. Apart from having a single source of truth for application and infrastructure configuration changes, using version control is also helpful for maintaining the version history of configuration changes of all resources across environments and projects. Another great benefit of keeping everything in a version control system is reverting your changes to previous versions, in case of issues, with a single click of a button.

3. Continuous Deployments

It is essential to ensure that all the configuration changes that are merged with the master branch in your version control system- Git, are immediately automatically picked up and deployed into the target Kubernetes cluster. Tools such as Devtron, and Argo CD frequently monitor repositories at frequent intervals of time, and in case of any new change configurations (declared state) are deployed and automatically to the target environment (desired state). This process deployment without any human intervention is also called continuous deployment.

4. Continuous Reconciliation

One of the most important functions of deploying applications using GitOps is that the state of the cluster will always match the state of the Git repository. If the state of the cluster does not match the state of the manifests present in the Git repository, the GitOps tool will automatically reconcile the differences and ensure that both states match. Different GitOps tools such as ArgoCD and FluxCD have different mechanisms for reconciliation.

5. Integration of GitOps with CI/CD process

GitOps cannot work in silo or as a disjointed functionality, but rather it has to be made a part of the overall CI/CD process. GitOps tool should be integrated with the CI/CD toolchain and should be customized to ensure security, safety, and speed of deployments are not compromised.

6. Visibility and Control

Finally, GitOps is like any other paradigm shift to help enterprises release more applications into the market quickly and frequently. To adopt and scale GitOps style delivery, a single plane for visibility and control is essential to visualize the deployment changes across the Kubernetes cluster, and also practice safety in the release process. A central control plane will help in configuring rollout and rollback strategies easily.

Why is GitOps very popular?

Kubernetes has become, by far, the most accepted and widely used container orchestration platform. Although Kubernetes provides a lot of benefits, users need learning and training before complete adoption. There are many organizations where developers and testers don’t care to learn Kubernetes as it is not their core activity. Secondly, there are many flavors of managed Kubernetes offered by cloud providers and independent companies such as AWS EKS, Google Kubernetes, Azure Kubernetes, Rancher Kubernetes, Red Hat OpenShift, Mirantis Kubernetes, etc.

This aversion of developers to learning Kubernetes and commands, and writing deployment configurations made the Kubernetes deployments very slow. That’s where the idea of GitOps was born to continuously check off new and approved app or infra changes and constantly deploy into the target cluster with less human intervention.

Who should use GitOps?

Any organization using Kubernetes as their infrastructure for their applications can and should use GitOps. Since GitOps is about just deployment, it can be used by small, mid, and large enterprises. When it comes to the software department, then developers DevOps engineers (or release engineers), and SREs are the ones who will benefit the most from GitOps implementation.

Before GitOps a DevOps engineer would take the new image and create configuration (manifest files or HELM Charts) for deployment. Even though deployment was done using a pipeline using tools such as Spinnaker, there was a manual intervention.

After GitOps, an agent would monitor the change in the Docker Hub repository and automatically update the manifest file. The manifest file will be updated in the environment repository (say in Git or Bitbucket). The GitOps agent would take the updated manifest files or HELM charts and apply them to the target cluster. This is a very simple explanation of the integration of the GitOps method with the CI/CD process. The actual implementation may be very complicated based on the SDLC policies and stages. For e.g. the deployment may happen to test, pre-prod, and finally production cluster using GitOps tools. And GitOps methods can be invoked in the CI/CD pipeline

Key Benefits of GitOps

There are several benefits of using GitOps methodology when used for deploying Kubernetes applications.

More time for innovation: Developers and Engineers are relieved from updating changes to Kubernetes configuration every time, they will have to deal with less context switching and more time to focus on their core activities.
Faster time to market: With less manual intervention in deployment with GitOps methodology, developers can release more features to the market quickly and frequently.
Zero downtime with instant rollback: Since all the configurations are stored and versioned in Git, the application can be rolled back to the previous version instantaneously without causing unnecessary service unavailability.
Single source of truth for almost all the changes: By storing applications, infrastructure, deployments, network, and security policies in a single place, the manageability increases by many folds
Audit trail to identify breaches: When GitOps style deployment is practiced using Git to store environment configuration and manage the Kubernetes cluster, the DevOps team will get a complete audit trail of every change- who, what, how, and when of every change. The audit is particularly beneficial to analyze what went wrong and optimize the deployment process further.

More visibility into software deployment: By using Git for environment configuration and GitOps software for deployment, there will be more data and insights available w.r.t application, deployments, Kubernetes clusters, namespaces, etc.

Open source tools for GitOps deployment

Devtron

Comparatively, the youngest Kubernetes-native open-source platform was founded in 2020 to implement GitOps, but Devtron is gradually becoming famous. It offers an intuitive UI and is the one-stop-shop solution for deploying Kubernetes apps using CI/CD pipelines and GitOps. Devtron also provides its own Dashboard for visibility into Kubernetes resources, deployment, HELM charts, and take any action such as Rollback or configure rollout strategies such as canary and blue/green.

ArgoCD

Argo CD was started in 2018 and is perhaps the most popular GitOps tool now. The Argo project of which the Argo CD is a part, has other applications to offer- Argo Workflow, Argo Notification, Argo Rollouts, and Argo Events- to transform the Kubernetes delivery. Argo is a CNCF graduate project.

Flux CD

Flux CD was initially created by Weaveworks and has since become a Cloud Native Computing Foundation (CNCF) project with an Apache 2.0 license on GitHub. It is an open-source Continuous Delivery tool for automated Git-based Kubernetes deployments. It uses a declarative approach to manage Kubernetes deployments using Git repositories to store application configurations. Check out how ArgoCD and FluxCD differ from each other.

JenkinsX

Jenkins X was introduced around 2018 as an extension of Jenkins. Jenkins provides GitOps functionalities and also natively supports integration with Tekton CI/CD pipelines for deployment. Of late, the project has seen very less contributions from the community.