.svg)
.svg)
.svg)
🚀 Download our latest eBook - Adopt Kubernetes in Weeks 🚀
GitOps is a software delivery philosophy to treat 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. Note, 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 declarative state (using YAML or JSON format) will help tracing list of items changed and its related impact to the production or customer experience. One can store deployments, load balancers, API gateway configurations, traffic management rules, 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 configuration 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 version history of configuration changes of all 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 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, Argo CD frequently monitor repositories at frequent intervals of time, and incase 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
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, Argo CD frequently monitor repositories at frequent intervals of time, and incase 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.
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 tool chain and should be customized to ensure security, safety and speed of deployments is 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 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, writing deployment configuration made the Kubernetes deployments very slow. And 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.
Kubernetes Dashboard is an external service developed on top of Kubernetes architecture. Under the hood, the Dashboard uses APIs to read all cluster-wide information for visibility into a single pane. It also uses the APIs to deploy resources and applications into a cluster. Both CLI and Kubernetes Dashboards depend on the kube-API-server to process the requests. To get started with the CLI, the Ops team must deploy the Kubernetes Dashboard in the same cluster (similar to Kubectl deployment).
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 and DevOps engineers (or release engineers), and SREs are the ones who will benefit the most from GitOps implementation.
GitOps implementation with CI/CD process
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 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 to the environment repository (say in Git or Bitbucket). And the GitOps agent would take the update manifest files or HELM charts and apply them into the target cluster. This is a very simple explanation of the integration of the GitOps method with 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 testing, 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 the Git, 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 application, 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 Kubernetes cluster, DevOps team will get a complete audit trail of every change- who, what, how and when of every change. Audit is particularly beneficial to analyze what went wrong and optimize 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
There are several software available with which one can get started with GitOps style deployments for Kubernetes. The famous and widely-accepted GitOps tools are:
Devtron
Comparatively the youngest Kubernetes-native open source platform founded in 2020 for implementing 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 roll out strategies such as canary and blue/green.
Argo CD
Argo CD was started in 2018 and perhaps the most popular GitOps tool now. The Argo project of which the Argo CD is a part of, 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
Open source dashboard started by VMware but is archived now- no community support, and you are on your own. Initially, the project was targeted for developers to use the UI to ship code faster into clusters. Octane has limited functionalities w.r.t cluster visualization and management. Read more about Devtron vs Octant.
Jenkins X
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.
Resources to get started with GitOps
GitOps with your choice of Git provider
Talk to an expert
Do you need any help to set up GitOps deployment along with multi-cluster and multi-cloud visibility and controls with Kubernetes dashboard?