What Is GitOps?

GitOps extends the functionality of IaC by allowing developers to declare every resource in Git and automatically maintain the desired state across the infrastructure.

What is GitOps? Well, GitOps is a software development framework that enables organizations to continuously deliver software applications while efficiently managing IT infrastructure using Git as a single source of truth. GitOps, a subset of DevOps, combines Infrastructure-as-Code (IaC) and DevOps best practices to create an operating model for managing architecture and instantly reproducing the system’s cloud infrastructure based on the state of Git repos.

While there are several tools and solutions for software development, infrastructure management has always been a complex task. It requires expert knowledge to build and maintain infrastructure. DevOps revolutionized the software development landscape and empowered infrastructure management with the “Infrastructure-as-Code (IaC)” approach.

While IaC enables developers to declare configuration as code and automate system infrastructure, maintaining live sync between the code, testing, staging, and production environments remains a challenge. GitOps extends the functionality of IaC by allowing developers to declare every resource in Git and automatically maintain the desired state across the infrastructure. Continue reading to learn more about GitOps!

1. GitOps: Is It a Version Control Method?

Version control systems play a crucial role in DevOps environments. A VCS is a software tool that enables organizations to track and manage changes to code. It stores every change made to the code in a unique database. Version control systems allow teams to collaborate on code development seamlessly, bringing faster time to market while minimizing outages. When a mistake is made, teams can quickly revert to the earlier version without disrupting the rest’s work. GitOps leverages the Git VCS to improve the efficiency of CI/CD pipelines.

Git is the most popular version control system among developer circles. As most developers are familiar with Git, it becomes easy to work with GitOps projects. In a GitOps environment, Git serves as a single source of truth. Every resource in the environment is descriptively declared in the Git repository. When a Git “pull request” is made, and the changes are approved, the live infrastructure is automatically reconfigured to sync with the desired state declared in the Git repository. A flux operator is used to monitor Git pull requests and converge production clusters to the desired state of the Git repo.

2. Principles of GitOps

Here are four key principles of GitOps.

Declarative Description

As Git acts as a single source of truth for all DevOps operations, the entire system is described declaratively in Git using .yaml files. Changes made to applications, infrastructure, deployment, and environment are all managed via Git. For instance, Kubernetes configuration and environment configuration can be managed with Helm via reusable charts. The application code can be declared in a Dockerfile, and Terraform can declare the infrastructure. Not only can you quickly deploy containers and rollback, but you can also reproduce the entire cluster infrastructure at the time of a disaster.

Versioning

As the version control system acts as a central repository for declaring and managing the infrastructure’s desired state, you can experiment with new features and quickly rollback/revert when required. When a commit is made, details such as the committer information, commit timestamp and the commit ID are stored. As such, you can fully trace all the changes made to the state of the infrastructure at any given point in time.

The ability to view the entire audit trail of changes brings transparency across teams in the organization. When the infrastructure and applications are available as versioned artifacts, auditing becomes easy too.

Automation

The advantage of the declarative description is that you can declare the system’s desired state in the Git code and then automate the system to apply all the approved changes to the system. By implementing a feedback control loop integrated into your continuous deployment pipeline, you can automate deployments. While it significantly increases the number of changes you make per day, it also reduces mean time to deployment.

Assurance

When the desired state doesn’t match with the system’s actual state, software agents instantly alert you about the configuration change. With this self-healing approach, you can be assured of a quality software development environment.

3. The Need for GitOps

Innovation is a continuous process in the technology world. The advent of cloud computing technology has revolutionized the IT industry, bringing speed and scale to software development environments. DevOps enabled organizations to efficiently manage this agility and seamlessly deliver code faster and better using CI/CD pipelines, version control systems, code review systems, and infrastructure management solutions. However, automation was more developer-focused.

All the DevOps practices facilitated easy automation of development processes. However, Infrastructure automation remained a complex process, requiring certified professionals and expert knowledge of infrastructure management.

The modern infrastructure should be flexible and robust enough to scale up and manage continuous deployments. While configuration management tools such as Puppet, Chef, and Ansible help you to maintain the infrastructure at the desired state, they don’t combine apps and IaC into a cohesive unit. Moreover, they are not efficient enough to manage the entire cloud stack. GitOps rightly suits this purpose.

GitOps is an innovative framework that allows developers to declare infrastructure as code in the Git repository and centrally manage infrastructure automation with ease. GitOps extends the functionality of IaC tools by integrating applications and Infrastructure-as-Code as a cohesive unit such that Dev and Ops teams share a single Git repository code to manage infrastructure and applications running on it.

Now that you’re aware of GitOps, it is important to understand that it’s not just about deployment automation and configuration management. It enables developers to handle complex infrastructure operations easily and increase productivity. With rollback/revert features and actionable alerting features, it reduces time to recovery and time to market. With GitOps, managing CI/CD operations in the cloud is easy and cost-effective.

4. How Does GitOps Work?

GitOps architecture enables developers to manage infrastructure operations using Git as the only source of truth. In a typical DevOps development environment, the CI component stands at the forefront of the pipeline. The CI component considers the VCS as a service that provides input to build operations and the CD as a service to deploy the code. It takes the code, runs automated tests, and pushes the approved code to production using CD automation.

Here is a typical DevOps CI/CD pipeline:

1. Developers write the code and commit it to the version control system.

2. The CI server takes the code and runs automated tests on it.

3. When errors/bugs are found, the code is sent for corrections.

4. Approved code is automatically pushed to the container image repository.

5. The automation deployment tool pushes the containers to production.

6. A container orchestration tool is used to manage containers.

Here, the CI component is central to the CI/CD pipeline. However, GitOps pushes the version control system Git to the center. In this architecture, Git seamlessly manages deployments and operations. As developers are most familiar with Git and pull requests, it becomes easy to use GitOps. A pull request is a review request wherein a developer who pushes code to the repository requests the code’s approval to be merged with the repository.

Here is a typical workflow in the GitOps environment:

1. A developer makes a pull request to the Git repository.

2. The code is reviewed and approved by the relevant people.

3. The code is then merged into the Git repository.

4. When a change is detected, the CI build pipeline gets triggered. The CI tool automatically runs tests. Once the code passes all tests, it builds the image and pushes it to the image container.

5. The deployment Automator detects changes to the image repository, pulls it from the registry, and updates the Config repository YAML file.

6. The deployment synchronizer detects the change in the cluster. It pulls the changes from the config repository and updates the outdated cluster with the new feature.

Consider a GitOps environment that uses Kubernetes clusters and Flux CD for managing Kubernetes. The state of the Kubernetes cluster is first declared in the Git repository. Without a prior declaration, no workload enters the Kubernetes cluster. Workload descriptions are declared and pushed to a Git repository. The deployed cluster state should always be in sync with the declared state in the Git. Flux operates as a deployment synchronizer. It is deployed within Kubernetes and uses a control loop to pull the git repository and check if any new commits are pushed. When a new commit is applied, it immediately converges the cluster state to the newly declared state.

Moreover, Flux also checks the container image registry for updates. When a new image is found, Flux will update the cluster manifest files on Git with the latest container image tags and then re-sync the cluster state with the latest commit. This means container instances are always running with the latest container images. It also ensures that the cluster state is always in perfect sync with the declarations made in the Git repository. If you need to roll back a feature, you can simply revert to the earlier version with Git repo, and Flux will automatically sync the cluster state to that version. Similarly, during a disaster, you can simply redeploy the most recent commit in the Git repo to get back the last working cluster state.

With GitOps, you don’t need to provide write access to developers. Instead, Flux will update, delete or create resources within the cluster as per Git repo declarations. By implementing role-based-access controls (RBAC), you can configure a Flux service account with the required privileges and perform desired operations without exposing cluster credentials outside.

5. Advantages of GitOps

Here are some of the key advantages offered by GitOps.

Faster Time to Market

In a DevOps environment, faster deployments are a default requirement. However, GitOps takes it to the next level as deployments happen right within the source code. As code is developed and pushed to Git, it is automatically deployed using the same deployment tools. The fact that you don’t have to switch tools makes this process faster and better.

Reliability

GitOps allows you to revert/rollback changes with a click of a button. You can experiment with new features quickly and undo them in case of your code’s unexpected behavior. It also increases productivity levels while being reliable and secure.

Improved Developer Experience

GitOps is more developer-focused. With the luxury of working with developer-side tools such as Git, developers get good command over deployment infrastructure and can easily manage and monitor deployments. The continuous feedback loops help them to identify errors, make changes and push code to production more frequently. They can use a single set of tools across the infrastructure.

Easy Auditing

In a GitOps environment, every change is made via the repository. As such, you can check the branch history at any given point in time to see the complete deployment history and the history of each change made to the code. The free audit trail feature essentially simplifies auditing tasks. Moreover, every team member can check the Git repo and be updated with what’s happening across the development lifecycle. It also makes your auditing tasks easy.

Standardized Operations Across the Infrastructure

GitOps enables you to create a standard model for change management across the apps, deployments, and add-ons. It means you have Git-centered end-to-end workflows that are consistent across the infrastructure. It also provides greater visibility into CI/CD pipelines.

6. GitOps Best Practices

While GitOps offers speed and scale to development environments, using the right strategies is the key to leveraging this framework.

Managing Repos

Firstly, traditional development teams use multiple repositories to gain clear ownership of the services they are working on. However, it gets complicated when the project scales up. Each team can only monitor its repositories, and gaining visibility into the entire project becomes daunting. So, minimizing repositories is a good idea. For a small company, a single repo is enough. A mid-size company can use one repo for each team, while large enterprises can use a repo for each service. Each team can use one repository and then add multiple branches to it if needed. This means teams can seamlessly collaborate on the project.

Another good idea about repositories is to use two — one for app code and the other for the deployment configuration. It means every commit will not be deployed, and everyone cannot release. It also means you can control who can have a better release management process.

Managing Manifests

When you commit changes to manifests without testing them, you’ll most likely encounter several issues in the pre-production phase. A good idea is to locally run the CLI command to generate manifests before committing changes. You should also ensure that external modifications don’t change Git manifests. So, pin remote bases or dependencies to specific commits.

Managing Stateful Apps and Services

Managing stateful apps and services in Kubernetes is a cumbersome task. Instead of using manual scripting, it is recommended to use Kubernetes operators wherever possible. Using pull requests over push is also highly recommended. It will also avoid exposing cluster credentials outside the cluster. You can automate repetitive processes across the environment using Git webhooks.

7. Continuous Delivery Using GitOps

Continuous delivery is a software development approach wherein code is continuously built, tested, and deployed to production. Cross-functional teams collaborate on application development using a version control system. Every change is merged with the branch frequently. For every change, a build is created on which automated tests are performed. Successful builds will automatically be deployed to the production environment.

At the outset, GitOps seems to give an edge to continuous deployment over continuous integration. However, GitOps makes CD easy and efficient, which empowers CI to deliver faster and better. In the traditional CI/CD pipeline, CI stands at the center and manages build and deployments. While CI frequently releases code to production, synching the configuration with it is a challenge. The presence of hybrid multi-facet infrastructure adds up to this challenge.

GitOps descriptively declares the state of every resource in the repository. As such, changes to app code and manifests are instantly reflecting in the production clusters. It gives the visibility and insights to ensure consistency across all production environments. With guaranteed predictability and consistency of the state of production clusters, developers can quickly build apps and deploy them to multi-clustered infrastructure while gaining traceability and visibility into every change made to the code that moves to production. With GitOps, CI becomes faster, more comfortable, and better.

8. Infrastructure-as-Code Using GitOps

Infrastructure-as-Code is an innovative idea of using configuration files for IT infrastructure management. GitOps is an excellent example of IaC, but it differs in implementation. It extends the functionality of IaC tools. In GitOps, the desired state of the IT infrastructure is stored and controlled by the source control. Here, immutable containers are used as deployable artifacts, and an orchestration tool is used to converge them to the state declared in the Git manifests. Git acts as a central source of truth, while other IaC frameworks use multiple repositories or a combination of git and a database to manage the infrastructure.

While IaC tools enable you to manage IT infrastructure, they are not enough for controlling the entire cloud-native stack. However, GitOps is enough to handle the whole cloud-native stack. You can use an IaC tool and extend its functionality to perform infrastructure updates using Git. When a manifest is updated, the Kubernetes operator triggers the convergence mechanism wherein changes are applied to the cluster until the state is converged to the one declared in Git. When divergence is detected, it will automatically send an alert. You can configure the operator to trigger the convergence mechanism automatically.

9. GitOps Tools

Here are some of the tools that enable you to build a result-driven GitOps environment.

Git

Git is the heart of the GitOps environment. It hosts the code, configuration, and documentation to deploy and manage clusters across the infrastructure. The entire process is automated, wherein “automators” read Git repositories, detect changes to code and configuration in Git, and apply them to the corresponding clusters in the infrastructure.

Helm

Helm is a popular Kubernetes package manager. It enables organizations to define and install complete Kubernetes apps using Helm Charts. With custom hooks and in-place upgrades, you can easily update Kubernetes apps as well. Helm charts contain YAML template files that are arranged into a specific directory structure. Using Helm, you can optimize CI/CD environments for Kubernetes.

Flux

Flux is another key operator in GitOps that ensures that the Git repository configurations are automatically enforced on production clusters. It continually reads Git Repos and detects changes to code and config files, and converges Kubernetes production clusters to the desired state declared in Git. Flux helps you to deploy container images to production clusters seamlessly. Changes to clusters can be easily reverted to previous versions.

Flagger

Flagger is a popular progressive delivery operator for Kubernetes. Using Flagger progressive delivery techniques such as canary releases, A/B testing, and blue/green, developers can confidently push code to production. A canary release allows developers to test new features in the production environment and safely rollback if required. With slow ramping of load, developers can monitor key performance metrics and assess the new feature’s impact on the production environment. Using Flagger and FluxCD, you can easily build automated GitOps pipelines for canary deployments.

10. Summary

After reviewing what is GitOps, we can conclude that with the influx of multiple technologies, tools, and frameworks, modern cloud infrastructure is getting complex day by day. GitOps offers a powerful operating workflow to manage this complex cloud system infrastructure. With an assurance that live production clusters are always running in the desired state, organizations get the luxury of incorporating new features to deliver a great customer experience, increase productivity and reduce outages.

GitOps is, however, still in a nascent stage. While GitOps supports Kubernetes and non-Kubernetes clusters, the majority of GitOps operators are designed to manage Kubernetes clusters. Going forward, you can expect GitOps operators to manage all types of clusters across the infrastructure.

We ZippyOPS, Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, and Security

Services offered by us: https://www.zippyops.com/services

Our Products: https://www.zippyops.com/products

Our Solutions: https://www.zippyops.com/solutions

For Demo, videos check out YouTube Playlist: https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro

Relevant Blogs:

A Deep Dive Into Distributed Tracing

Lessons Learned Moving From On-Prem to Cloud Native

Reducing Kubernetes Costs With Autoscaling