In this blog post we’ll take a look at the benefits of using GitOps and how it can be implemented using Kubernetes.

If you are doing infrastructure as code already, that’s great! GitOps can extend this further with improvements on workflow in terms of managing and deploying your infrastructure.

What Is GitOps?

GitOps is a method of building and improving on CI/CD deployments using the popular version control system Git and a source control repository such as GitHub. As an operating model, it can be used by cloud native technology like Kubernetes and provides a set of best practices that can help to deploy code faster and safer.

Essentially, the core of the model is to define all code in Git source control repositories like GitHub, GitLab & Bitbucket.

A typical GitOps workflow would include two separate repositories. One for application code which can be integrated into your existing CI/CD pipeline and one for infrastructure/cluster code. Engineers and developers will only commit changes to these repositories and the rest is automatically deployed out to the environment via an operator which I will explain in more detail later on.

Key Benefits of adopting GitOps

The entire system is described declaratively and in turn, the canonical desired system state is versioned. “Source control as the source of truth” I will explain why this is so important in more detail later.

Resources are never deployed manually on systems. Instead, it has to be defined as code. Approved changes to the desired state are automatically applied to the system through a typical Git pull request.

Git already has a human collaboration point in place with well known software. Most developers and ops engineers already know how to use Git with ease.

Code is treated more like data. It is checked extensively before being deployed to environments by a normal pull request.

Greater security for auditing. Everything is clearly tracked in repository through normal commit messages and notes.

If the entire infrastructure stack fails, all the application services that are defined is in one place. This significantly reduces both the risk and MTTR (Mean Time To Recovery) and is relatively straight forward process to migrate — if necessary, and recover from such major disasters.

No more writing commands, code is deployed automatically from your repository branch.

Why “Source Control as the Source of Truth” Is So Important?

When everything is defined in a source control repository you can see exactly the desired state for your infrastructure. This acts as your core source of truth, in a declarative state, for what your environment should look like. Thus anything that is not defined is considered a configuration drift from the norm and should be discarded immediately. A classic case of your Production environment vs Staging vs Dev. Using Gitops methodology, the application deployment process will reinforce this method and prevent the unwanted manual hackfix application releases, outside approved release processes of deployment.

How to Use GitOps with Kubernetes?

Kubernetes is a great example of how to implement GitOps deployments. Kubernetes resources are declarative by nature — you can define all your resources in a yaml file and deploy. This is already desired state configuration. So we can just place this in a Git repository.

If a developer writes a new Kubernetes resource file and raises a PR (pull request), once the PR is reviewed, approved, and subsequently merged, this change will be deployed and automatically rolled out to your Kubernetes cluster.

“How does this code get deployed automatically?” — you’re probably thinking.

Well this is the job of the an operator. In this case we will be using an open source tool called Weave Flux. This is created by the team at WeaveWorks, the people behind the popular Kubernetes CNI tool Weave Net.

How Does Weave Flux Work?

Weave Flux will need to be directly installed on the cluster you wish to integrate within a GitOps methodology. This can be done using kubectl command line or helm charts.

Installing Weave Flux will create a deployment on the cluster called ‘Weave Flux Agent’ — This acts as an operator for GitOps. You would then configure this deployment to sync with your chosen Git repository branch and repo this is done by passing arguments into the flux container.

--git-url=<insert your repo>

--git-branch=<insert branch to poll>

Flux will generate a deploy key which you can add to your repo for authentication. Flux will then poll the branch of the repo (default time every 5 mins) any changes it will deploy out directly to cluster by calling the Kubernetes API. Certain areas of Flux can be tweaked such as polling time and garbage collection for deleting unwanted resources. These are all set as container arguments as well.

Using Flux can help you to change the way you deploy in your environment. For example all your Kubernetes infrastructure resources can be defined in a separate config repo and deployed automatically. Your application code can be defined in a separate repo and deployed to an image registry via your normal CI/CD pipeline. Flux can monitor the image registry for any changes and deploy that automatically out to cluster when a new image is released. Automated deployments!

The diagram below shows what your deployment environment would look like using a GitOps approach.