1. What is GitOps?👨‍💻

GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.

2. Why GitOps?🤷‍♀️🤷‍♂️

GitOps takes the philosophies and approaches promised to those investing in a DevOps culture and provides a framework to start realizing the results. Organizations that practice DevOps realize significant improvements to the rate of innovation in applications and code, as well as stability.

By using the same Git-based workflows that developers are familiar with, GitOps expands upon existing processes from application development to deployment, application life cycle management, and infrastructure configuration. Every change throughout the application life cycle is traced in the Git repository and is auditable. Making changes via Git means developers can finally do what they want: code at their own pace without waiting on resources to be assigned or approved by operations teams.

For ops teams, visibility to change means the ability to trace and reproduce issues quickly, improving overall security. With an up-to-date audit trail, organizations can reduce the risk of unwanted changes and correct them before they go into production.

These changes in code from development to production make organizations more agile in responding to changes in the business and competitive landscape.

3. Overall GitOps architecture⚙

GitOps architecture works by creating a declarative model of the desired state of the application. This model is stored in a Git repository and is used to manage the entire application infrastructure.

The desired state of the application is defined using tools like Kubernetes, Helm, and Terraform. These tools are used to create a YAML file that describes the desired state of the application.

Once the YAML file is created, it’s committed to the Git repository. The Git repository is then configured to automatically deploy the changes to the production environment.

4. How to get started with GitOps 🚀

To get started with GitOps you need infrastructure that can be declaratively managed. Because of this, GitOps is often used as an operating model for Kubernetes and cloud-native application development and can enable continuous deployment for Kubernetes.

But using Kubernetes is not a requirement of GitOps. GitOps is a technique that can be applied to other infrastructure and deployment pipelines.

GitOps can be used to build development pipelines, code applications, manage configurations, provision Kubernetes clusters, and deploy on Kubernetes or container registries.

5. How does GitOps work 🔩

• Environment Configurations as Git repository

  GitOps organizes the deployment process around code repositories as the central element. There are at least two repositories: the application repository and the environment configuration repository. The application repository contains the source code of the application and the deployment manifests to deploy the application. The environment configuration repository contains all deployment manifests of the currently desired infrastructure of a deployment environment. It describes what applications and infrastructural services (message broker, service mesh, monitoring tool, …) should run with what configuration and version in the deployment environment.

• Push-based vs. Pull-based Deployments

  There are two ways to implement the deployment strategy for GitOps: Push-based and Pull-based deployments. The difference between the two deployment types is how it is ensured, that the deployment environment actually resembles the desired infrastructure. When possible, the Pull-based approach should be preferred as it is considered the more secure and thus better practice to implement GitOps.

• Push-based Deployments

  The Push-based deployment strategy is implemented by popular CI/CD tools such as Jenkins, CircleCI, or Travis CI. The source code of the application lives inside the application repository along with the Kubernetes YAMLs needed to deploy the app. Whenever the application code is updated, the build pipeline is triggered, which builds the container images and finally the environment configuration repository is updated with new deployment descriptors. Also you can just store templates of the YAMLs in the application repository. When a new version is built, the template can be used to generate the YAML in the environment configuration repository.

  

Changes to the environment configuration repository trigger the deployment pipeline. This pipeline is responsible for applying all manifests in the environment configuration repository to the infrastructure. With this approach, it is indispensable to provide credentials to the deployment environment. So the pipeline has god-mode enabled. In some use cases, a Push-based deployment is inevitable when running automated provisioning of cloud infrastructure. In such cases, it is strongly recommended to utilize the fine-granular configurable authorization system of the cloud provider for more restrictive deployment permissions.

Another important thing to keep in mind when using this approach is that the deployment pipeline only is triggered when the environment repository changes. It can not automatically notice any deviations of the environment and its desired state. This means it needs some way of monitoring in place so that one can intervene if the environment doesn’t match what is described in the environment repository.

• Pull-based Deployments

The Pull-based deployment strategy uses the same concepts as the push-based variant but differs in how the deployment pipeline works. Traditional CI/CD pipelines are triggered by an external event, for example when new code is pushed to an application repository. With the pull-based deployment approach, the operator is introduced. It takes over the role of the pipeline by continuously comparing the desired state in the environment repository with the actual state in the deployed infrastructure. Whenever differences are noticed, the operator updates the infrastructure to match the environment repository. Additionally, the image registry can be monitored to find new versions of images to deploy.

Just like the push-based deployment, this variant updates the environment whenever the environment repository changes. However, with the operator, changes can also be noticed in the other direction. Whenever the deployed infrastructure changes in any way not described in the environment repository, these changes are reverted. This ensures that all changes are made traceable in the Git log, by making all direct changes to the cluster impossible.

This change in direction solves the problem of push-based deployments, where the environment is only updated when the environment repository is updated. However, this doesn’t mean you can completely do without any monitoring in place. Most operators support sending mails or Slack notifications if it can not bring the environment to the desired state for any reason, for example, if it can not pull a container image. Additionally, you probably should set up monitoring for the operator itself, as there is no longer any automated deployment process without it.

The operator should always live in the same environment or cluster as the application to deploy. This prevents the god-mode, seen with the push-based approach, where credentials for doing deployments are known by the CI/CD pipeline. When the actual deploying instance lives inside the very same environment, no credentials need to be known by external services. The Authorization mechanism of the deployment platform in use can be utilized to restrict the permissions on performing deployments. This has a huge impact in terms of security. When using Kubernetes, RBAC configurations and service accounts can be utilized.

• Working with Multiple Applications and Environments

GitOps can also handle such a use case. You can always just set up multiple build pipelines that update the environment repository. From there on the regular automated GitOps workflow kicks in and deploys all parts of your application.

Managing multiple environments with GitOps can be done by just using separate branches in the environment repository. You can set up the operator or the deployment pipeline to react to changes on one branch by deploying to the production environment and another to deploy to staging.

6. GitOps challenges🎯

With any collaborative effort, change can be tricky and GitOps is no exception. GitOps is a process change that will require discipline from all participants and a commitment to doing things in a new way. It is vital for teams to write everything down.

GitOps allows for greater collaboration, but that is not necessarily something that comes naturally for some individuals or organizations. A GitOps approval process means that developers make changes to the code, create a merge request, an approver merges these changes, and the change is deployed. This sequence introduces a “change by committee” element to infrastructure, which can seem tedious and time-consuming to engineers used to making quick, manual changes.

It is important for everyone on the team to record what’s going on in merge requests and issues. The temptation to edit something directly in production or change something manually is going to be difficult to suppress, but the GitOps will work better.

7. Key components of a GitOps workflow🧩

• The Git repository is the source of truth for the application configuration and code.

• The CD pipeline is responsible for building, testing, and deploying the application.

• The deployment tool is used to manage the application resources in the target environment.

• The monitoring system tracks the application performance and provides feedback to the development team.

8. GitOps benefits📈

There are many benefits of GitOps, including improved efficiency and security, a better developer experience, reduced costs, and faster deployments.

With GitOps, organizations can manage their entire infrastructure and application development lifecycle using a single, unified tool. This allows for greater collaboration and coordination between teams and results in fewer errors and faster problem resolution.

In addition, GitOps can help organizations take advantage of containers and microservices and maintain consistency across all their infrastructure — from Kubernetes cluster configurations and Docker images to cloud instances and anything on-prem.

• Increased productivity

Continuous deployment automation with an integrated feedback control loop speeds up ‘Mean Time to Deployment’ (MTTD). Teams can ship 30-100 times more changes per day, increasing overall development output by 2-3 times.

• Enhanced developer experience

With GitOps, you get to push code and not containers. Developers can use familiar tools like Git to manage updates and features of Kubernetes more rapidly without having to know its internal workings. Even the newly onboarded developers can get quickly up to speed and be productive within days instead of months. All this is possible because of the platform model, and the self-service developer experience that GitOps enables.

• Improved audibility

When you use Git workflows to manage your cluster, you automatically gain a convenient audit log of all cluster changes outside of Kubernetes. An audit trail of who did what, and when to your cluster can be used to meet SOC 2 compliance and help you ensure stability.

• Higher reliability

With Git’s capability to revert and fork, you gain stable and reproducible rollbacks. Moreover, since your entire system is described in Git, you also have a single source of truth from which you can recover after a meltdown, reducing your mean time to recovery (MTTR) from hours to minutes.

• Consistency and standardization

Since GitOps gives you one model for making infrastructure, apps, and Kubernetes add-on changes, you have consistent end-to-end workflows available across your entire organization if required. Not only are your continuous integration and continuous deployment (CI/CD) pipelines all driven by pull requests, but your operations tasks are also fully reproducible through Git.

• Stronger security guardrails

Git offers strong correctness and security guardrails backed by strong cryptography used to track and manage changes. That, along with the ability to sign the changes to prove authorship and origin, is key to a secure definition of the desired state of the cluster.

• Faster development

By adopting GitOps best practices developers use familiar tools like Git to manage updates and features to Kubernetes more rapidly. By continuously pushing feature updates, businesses are more agile, can respond more quickly to customer demands, and are more competitive in the marketplace.

• Better ops

With GitOps, you have a complete end-to-end pipeline. Not only are your continuous integration and continuous deployment pipelines all driven by pull requests, but your operations tasks are also fully reproducible through Git. Policies allow for endless customization of your processes while not compromising on security and pace of operations.

• Stronger security guardrails

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 correct and secure definition of the desired state of the cluster. This along with the automated policy-based reviews of each step make GitOps a great way to secure software delivery pipelines.

If a security breach does occur, the immutable and auditable source of truth can be used to recreate a new system independently of the compromised one, reducing downtime and allowing a much better incident response.

Separation of responsibility between packaging software and releasing it to a production environment also embodies the security principle of least privilege, reducing the impact of compromise and providing a smaller attack surface.

• Easier compliance and auditing

Since changes are tracked and logged in a secure manner, compliance, and auditing are made trivial. The use of GitOps agent Flux allows you to compare a trusted definition of the state of the cluster with the actual running cluster, ensuring that the tracked and auditable changes match reality.

9. What is the difference between GitOps and DevOps?

GitOps and DevOps do share some of the same principles and goals. DevOps is about cultural change and providing a way for development teams and operations teams to work together collaboratively.

GitOps gives you tools and a framework to take DevOps practices, like collaboration, CI/CD, and version control, and apply them to infrastructure automation and application deployment. Developers can work in the code repositories they already know, while operations can put the other necessary pieces into place.

10. GitOps Tools 🛠

GitOps tools can help you with the following scenarios like

• Continuous deployment (CDep) for Kubernetes—enables you to push applications rapidly and eliminates the need for several deployment management systems.

• Continuous delivery (CDel) for Kubernetes—enables you to rapidly build, test, and deploy software via incremental updates.

• Runtime pipelines—enable you to read and write files to Git, load container images, and update container repositories.

• Continuous Monitoring–GitOps tools can continuously monitor for configuration drift and automatically reconcile any changes that differ from the Git repository. They help you gain control over application and configuration changes while helping you easily roll back to previous working versions.

• Visibility–provide insights into the status of the GitOps application, their synced status, and reconciliation processes

Some common open-source tools are as follows

• Argo CD

• 

Argo CD is a Kubernetes-native continuous deployment tool built for GitOps. It keeps all configuration logic in Git to enable developers to use existing code development, review, and approval workflow already connected to Git-based repositories.

• Flux CD

  

  Flux monitors your image repositories, detects new images, triggers deployments. It uses this data and a configurable policy to update the running configuration to the desired state

• Jenkins X

  

  Jenkins X is an opinionated open-source CI/CD and automated testing tool for cloud-native applications deployed with Kubernetes. It offers various features, including built-in GitOps, pipeline automation, and preview environments.

• Weave GitOps Core

  

Weave GitOps Core is an open-source CD tool for Kubernetes and cloud-native applications. Weave GitOps is a CD runtime for GitOps based on the CNCF Flux project.

• Werf

  

werf is an open-source command-line interface (CLI) tool written in Go. It aims to simplify and speed up the application delivery process. It facilitates GitOps by letting developers describe the configuration of an application and storing this file in a Git repository that serves as a single source of truth.

That's all for this blog, I hope you will learn something new. And feel free to share your thoughts and feedback, Thanks for reading.

Feel free to reach out to me 👀

Twitter 🖱

LinkedIn 🖱

Github 🖱