With the ever-increasing cloud-native adoption, we see a lot of new concepts that help organizations to build and deliver high-quality software with speed. One such new emerging concept is GitOps, which employs DevOps best practices and enables us to interact with our production servers via simple git commands. GitOps is a new approach to managing software changes. It’s a self-service model with increased automation and transparency for developers and operators. GitOps also helps teams to be more efficient and productive by reducing the time they spend on manual tasks that can be automated or streamlined through automation via Git.
In this article, we will discuss GitOps, how it works, the difference between GitOps and DevOps in detail.
GitOps is a process of implementing continuous deployment for cloud-based applications, especially when it comes to Kubernetes deployments. GitOps emphasizes and boosts a developer-centric experience when operating environment by using the simple tools used by developers, which mainly includes Git and continuous deployment tools such as Flux CD and Argo CD, etc.
Some of the common tools of GitOps other than Git are Flux CD, Jenkins X, ArgoCD, Gitkube, Helm Operator, Quay, and ETC. GitOps is fundamentally a distributed version control system that helps developers with doing Infrastructure as Code (IaC) the right way. It maintains source code and contains text, certificates, and configuration files. Git is the tool used here to manage all these files, configurations and collaborate with various team members.
The main prerequisites of GitOps is to have,
When you deploy a new or update an existing application, you should only update the repository, and other processes will be taken care of by the automated process.
The main principles of GitOps are,
GitOps applies DevOps practices, like version control and continuous integration/continuous delivery (CI/CD), to automate the infrastructure. You can use git and CI/CD tools to replicate and roll back environments to previous versions from the repository.
The idea behind GitHub is very straightforward – use infrastructure as code for all the scripts that you need to create, update or delete your infrastructure. For this, you can use several tools such as terraform, pulumi, and even YAML, to name a few. You save everything in git – your infrastructure files, application files, state of the infrastructure; everything goes in git. Then we automate everything – deployment of apps gets automated, updating the infrastructure gets automated. We can use any of the tools that are available to us and then, we have automation that triggers all of our scripts.
Let’s see an example of how GitOps works; When you create a Kubernetes deployment file that includes a single replica that will run a container in our Kubernetes cluster. We take this resource definition and commit the deployment definition in Git, and as soon as the changes are committed to git, the automation is triggered to deploy the changes to our Kubernetes cluster. Usually, we have two choices; we can either push a change or cluster can pull the changes. In GitOps, we typically have a pull-based operator that watches the state of infrastructure and applies those changes. This executes kubectl apply, and the app is deployed in Kubernetes. An operator is where you write the logic, and it extends the Kubernetes functionality.
Push-based deployment strategy
The push-based deployment strategy is executed by the CI/CD tools like Jenkins, CircleCI, or Travis CI, etc. The source code of the application is present in the application repository along with the Kubernetes YAML required to deploy the application.
Image credits: GitOps.tech
When you update the application code, it triggers the build pipeline and builds the container images, then the environment configuration repository is updated with the new deployment descriptors. When this repository is updated, it triggers the deployment pipeline. This pipeline provides the requirements in the environment configuration repository to the organization. In this approach, you must provide credentials to the deployment environment.
When you run automated provisioning of cloud infrastructure, the push-based deployment strategy is expected. In this condition, you can use the fine-granular configurable authorization system of the cloud provider for more restrictive deployment permissions.
In the push-based GitOps strategy, when the environment repository changes, the deployment pipeline gets triggered. Thus, it requires a method to monitor, such that you can interfere if the environment does not match the environment repository.
Pull-based deployment strategy
In the pull-based GitOps strategy, there will be involvement of an external event that triggers the CI/CD pipeline. For instance, when a new code is pushed to an application repository.
Image credits: GitOps.tech
The operator is required for the pull-based deployment approach. The operator compares and analyzes the desired state in the environment repository with the actual state in the deployed infrastructure. If there are any disparities, it updates and renews the infrastructure to match the environment repository. The image registry can also be checked to see and recognize new versions of images to deploy. When there is a change in the environment repository, the pull-based deployment strategy updates the environment.
The operator must be in the same environment as the application for deployment. In this case, the credentials are not required to be known by the external services. Role-based access control (RBAC) and identity mechanisms can be used for performing deployments, giving the required access and permissions to only authorized personnel keeping security in mind.
Difference between GitOps and DevOps
|GitOps is a process of implementing continuous deployment for cloud-based applications, especially Kubernetes based deployments. GitOps emphasizes a developer-centric experience when operating environment by using tools used by developers, which includes Git and Continuous Deployment tools.||DevOps is a set of practices, tools, and a philosophy, which automates and integrates the processes between development and IT operations. DevOps focuses on team empowerment, cross-team communication and collaboration, and technology automation.|
|GitOps is a methodology, that uses Git as a single source of truth to achieve infrastructure provisioning, software deployments, and rollbacks.||DevOps is a process, which focuses on CI/CD and does not focus on any one specific tool.|
|Some of the other tools used in GitOps are Flux CD, Kubernetes, Argo CD, Jenkins X, WKSctl, Gitkube, Helm Operator, pulumi, Quay, and so on.||Some of the notable categories of tools used in DevOps are code and artifact repository tools, CI/CD tools, container management tools, infrastructure configuration tools, deployment tools, etc|
|The flexibility of GitOps is stricter and less open.||The flexibility of DevOps is less strict and more open.|
|The main focus of GitOps is on correctness and doing DevOps correctly.||The main focus of DevOps is automation and frequent deployments.|
GitOps is a new cloud-native methodology that needs to mature with more solid use cases and companies adopting it. It is still very early for us all to judge its future. Still, it is already getting good appreciation in the cloud community since it uses the tool that every developer already knows, Git. As Kubernetes-based applications and deployments increase, GitOps proves to be a go-to approach.
Get in touch and see how your business can transform today?
+1 (778) 819-6959
401 - 68 Water St, Vancouver BC, V6B 1A4
4370 Dominion St #601, Burnaby, BC V5G 4L7
32615 S Fraser Way #104 Office 1226,
Abbotsford, BC V2T 1X8