What is GitOps and how is it useful?

GitOps, combining "Git" with "Operations" refers to the practice of using Git as the primary tool for managing and automating the delivery and deployment of applications and infrastructure. It involves treating infrastructure and application configuration as code, which is version-controlled in Git repositories. Automation tools are then used to ensure that the state of the environment matches the state described in the Git repository. If there's a discrepancy, GitOps tooling automatically apply changes to reconcile the differences, ensuring consistency and reliability in deployments.

GitOps empowers development teams to perform tasks traditionally handled by operations teams. This includes deployment, monitoring, and management of infrastructure and applications.

The history of GitOps

GitOps was coined by Weaveworks in 2017 as a way to describe how they used Git, pull requests, and continuous deployment practices to manage Kubernetes clusters. The concept quickly gained traction in the cloud-native community, especially among Kubernetes users, due to its promise of simplifying deployment workflows, improving reliability, and enhancing security through automated, predictable, and declarative changes.

The principles of GitOps draw heavily from DevOps practices, emphasizing automation, collaboration, and continuous improvement. However, GitOps narrows the focus to Git as the cornerstone for managing operations, highlighting the benefits of using version control and collaboration tools that development teams are already familiar with.

Key components of GitOps

1. Git repository: The central element in GitOps, serving as the single source of truth for the desired state of your infrastructure and applications.

2. Declarative configuration: All resources are described in a declarative manner, specifying what the desired state should be without detailing how to achieve it.

3. Automated delivery: Automated tooling and pipelines ensure that the actual state in the environment matches the desired state described in the Git repository. As the central configuration stored in the repository is updated, these changes are automatically deployed, changing the actual state of the managed infrastructure.

4. Merge/pull requests: Changes to the infrastructure or applications are made through merge or pull requests, facilitating code review, version control, and history tracking.

GitOps in action

Let's walk through a simple example to illustrate how GitOps works in practice. Imagine you're managing a web application deployed on a Kubernetes cluster.

Initial setup

1. Create a git repository: This repository contains all the Kubernetes manifest files detailing your application, including deployments, services, and ingress resources.

2. Set up a continuous deployment pipeline: Use a tool like GitHub Actions, Argo CD, Flux, or Jenkins X that watches your Git repository for changes and applies them to your Kubernetes cluster. Here's an example of a simple GitHub action that triggers on any changes to the deployment yaml.

   When changes are detected, it will trigger a workflow to update the deployment in your Kubernetes cluster.

   1. Create a GitHub workflow file: First, create a .github/workflows directory in your repository if it doesn't already exist. Then, create a new YAML file for your workflow, for example, k8s-deploy-on-change.yml.

   2. Define the workflow: Here's a sample workflow definition that accomplishes the objectives:

   Terminal

   name: Deploy Kubernetes Manifests
   
   on:
     push:
       paths:
         - 'path/to/your/deployment.yaml'
   
   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout Repository
           uses: actions/checkout@v3
   
         - name: Set up Kubeconfig
           uses: azure/setup-kubectl@v2
           with:
             version: 'latest'
   
         - name: Deploy to Kubernetes
           run: |
             kubectl apply -f path/to/your/deployment.yaml
           env:
             KUBECONFIG: ${{ secrets.KUBECONFIG }}
   
   

   • name: Names the workflow.

   • on: Defines the trigger for the workflow. This workflow triggers on a push event, specifically for changes to the file located at 'path/to/your/deployment.yaml'.

   • jobs: Defines the jobs that the workflow will execute. This workflow has a single job called deploy.

   • runs-on: Specifies the type of machine to run the job on. This workflow uses an Ubuntu machine.

   • steps: Lists the steps that the job will execute.

     • Checkout repository: Checks out your repository under $GITHUB_WORKSPACE, so your workflow can access it.

     • Set up kubeconfig: This example uses azure/setup-kubectl@v2 for simplicity. Replace it with the appropriate action to configure kubectl for your Kubernetes cluster, like setting up KUBECONFIG or using a cloud provider's action to authenticate to the cluster.

     • Deploy to kubernetes: Applies the changes in your deployment file to the Kubernetes cluster using kubectl apply. This step uses a secret called KUBECONFIG that you need to create in your GitHub repository's settings containing your Kubernetes configuration file's content.

Making changes

Suppose you need to update your web application to a new version.

1. Update the manifest file: In your Git repository, update the Docker image tag in the deployment manifest file to the new application version.

2. Create a pull request: Submit a pull request with the change. This triggers automated tests and allows for code review.

3. Merge the pull request: Once approved, merge the pull request. The merge to the main branch triggers the continuous deployment pipeline.

Automatic deployment

1. Detect changes: The GitHub action triggers when your manifest change is merged in the main branch of your Git repository.

2. Apply changes: It automatically applies the changes to your Kubernetes cluster, rolling out the new version of your application.

3. Monitor and correct: Additional tooling continuously monitors the cluster's state. If the cluster diverges from the Git repository's state, the tool automatically applies corrections to align with the desired state.

Benefits of GitOps

• Improved reliability: By describing the desired state declaratively and tracking changes through Git, teams can quickly identify and revert problematic changes, reducing downtime.

• Enhanced security: Using Git workflows means that changes are auditable and can only be made through controlled processes, such as pull requests, enhancing security and compliance.

• Increased efficiency: Automating deployment processes reduces manual errors and frees up operations teams to focus on higher-value tasks.

• Better collaboration: Developers and operations teams can collaborate more effectively using a common toolset and processes, bridging the gap between code development and deployment.

For further reading on GitOps best practices, see the Weaveworks GitOps eBook.