The GitOps Way Running Operations Through Git

In the last decade, there has been a rapid growth in cloud computing. Any cloud infrastructure service provides the ability to create and update resources on the cloud through APIs. Cloud providers also have an Infrastructure as code (IaC) service to create and update resources through declarative code. This declarative code executes the API calls under the hood to create and update the resources in the cloud. Similarly, Kubernetes resources can be created and updated through declarative YAML or JSON files. Whether an application is run on a virtual machine on the cloud or a Kubernetes cluster, the application’s infrastructure can be created and updated using IaC. The application can be run as Docker containers. Now given that every resource in the cloud can be created and updated through declarative IaC, DevOps processes like continuous integration (CI) and continuous delivery (CD) can be extended from applications to the infrastructure. The cloud or Kubernetes resources can be stored as code in Git repositories and continuously integrated, tested, and deployed/delivered. The practice of adapting these DevOps processes like CI and CD for IaC is known as GitOps.

DevOps and GitOps

GitOps is particularly used in the context of development, deployment, management, and monitoring of cloud-native, containerized applications running on Kubernetes. The GitOps process entails storing the state of an environment or an application as declarative. IaC in Git repositories has a process to provision and update the live system (environment or application) in a way that is repeatable and consistent. GitOps can be applied to infrastructure or applications and is technology agnostic. 

While often linked to DevOps, the term DevOps is much broader in context and addresses how organizations can transform themselves by merging development and operations functions through continuous integration, testing, deployment and delivery with a focus on automation and monitoring. When combined with agile practices, DevOps enables organizations to achieve speed to market by eliminating waste and lead time which delay software delivery.  Agile practices play into this by implementing development in time boxed sprints and a continuous feedback loop which makes software development adaptable to change.  This results in releasing products and features faster and more frequently to customers.  

Basic GitOps process

A typical GitOps process for Kubernetes involves managing Kubernetes manifest files through Git repositories and continuously monitoring the state of these manifest files and automatically deploying the changes to various Kubernetes environments.

Basic steps in a GitOps process include: 

• The system’s desired state is stored in a revision control system such as Git
  • If the system's state as represented by the code in Git does not match the live system, then it means that some of the state changes are pending deployment.
  • In a case where the live systems config has been manually changed after the code deployment and therefore it is out of sync with the Git Repo, we call it a configuration drift.
  • Any change to the state or configuration to the system is done through standard revision control processes such as code check-ins, code reviews, pull requests, and merges to master branches.
  • Git provides audibility to every code change and commit.
  • Different branches are maintained for different environments such as test, stage, and prod, and branches are merged upwards through a gating process involving code reviews, unit, and functional testing.
• Access is controlled in such a way; the system is only changed through the code. The access to change the system configuration shall be restricted only to a few users or a group, who may need to change the system configurations outside of the GitOps workflow. In highly mature GitOps implementations, the access to change the system is only allowed through Git. Providing unconstrained access to the system may result in configuration drifts, which may result in a failed deployment.
• For any changes to applications, a new container image is published and the associated Kubernetes manifest files are changed.
• A continuous deployment tool continuously monitors and detects the differences between the state of code in Git vs the actual state of the system.
• The continuous deployment tool deploys the changes to the systems and synchronizes the actual state of the system with the state of code in Git.
• If continuous deployment tool encounters a configuration drift it marks the deployment as “out of sync” and awaits the manual synchronization of the Git code or lets you flag the CD tool to auto sync.

 In summary, GitOps can be broken down into two steps.

• Continuous Integration
  • Build and test an application.
    
  • Publish a new container image.
    
  • Update the new image and other configurations in the Kubernetes manifest file.
    
• Continuous Delivery
  • Continuously monitor state changes in the Git Repository.
    
  • Discover and detect state changes in the Git Repo compared to the live application.
    
  • Deploy changes to Kubernetes cluster.

Underlying GitOps concepts

• Idempotency:  An operation when repeated any number of times produces the same result. In the case of GitOps, a certain deployment operation when repeated produces the same result and does not produce any undesired result.
  
• Observability: The current state of the system should be observable. Observability is the ability to describe the state of the system including what resources are running and their configurations.
  
• Auditability:  Auditability provides a way to track all changes or commits to code as point-in-time snapshots; it is the ability to protect the integrity of the code and track the change history of who changed what and when.
  

These concepts form the key architecture principles in implementing GitOps CD. Any GitOps CD tool is compliant with these principles. In a follow-up blog, we’ll discuss these tools in more detail. Don’t miss it; subscribe to the DevOps blog below today.