GitOps and Kubernetes: CI/CD for Cloud Native applications

GitOps is a paradigm aimed at implementing Continuous Deployment and/or Continuous Delivery for Cloud Native applications. Through the use of tools that the developer is already familiar with, it focuses on an experience that also sees the developer involved in infrastructure-related activities.

We can think of GitOps as a collection of best practices for managing the delivery of containerized applications, together with the infrastructure on which they run.

GitOps is based on 3 key principles:

• First principle: the end-to-end system must be described declaratively – precisely why the declarative nature of Kubernetes and the Controller model are ideal for the adoption of GitOps.
• Second principle: the desired state of the system must be versioned in a Git repository. If a Git repository contains files which declaratively describe the desired state of the system, then Git becomes both the single source of truth for the state of our system, as well as the single place where all environments run.
• Third principle: all changes that have been approved and committed in a repository can automatically be applied to our system. This does not mean that automation is a requirement for GitOps, but that if the context allows it, it is recommended to automate the procedure.

So a new actor is needed in order to implement GitOps in Kubernetes: the GitOps Operator.

THIS MAY INTEREST YOU: 3 mistakes to avoid when adopting Kubernetes

So what do I need to adopt GitOps?

As we already mentioned, a new actor is needed: the GitOps operator. In other words, a Kubernetes operator which follows the loop control pattern of the Kubernetes controller and handles the automation aspect of delivery and monitoring. Several GitOps operators are currently available on the market, the main ones being Flux CD, Argo CD and Jenkins-X.

• Developed by Weave Works (who coined the term GitOps), Flux CD is an application written in Go that installs an operator in the target cluster, a command-line utility, presumably facilitating its automation. A new version of Flux is currently under development, a complete rewrite based on the GitOps Toolkit project. This new version will introduce interesting new features, including support for multiple repositories.
• Argo CD is part of Argo Project, a set of native Kubernetes tools for deploying and executing jobs and applications developed by Inuit, a US enterprise working in the financial software sector. Argo offers an excellent graphical interface and includes a command-line tool. It is also quite flexible as, thanks to features such as Single Sign On and multi-cluster multi-project centralized management, it can be used on any type of project, from the smallest to enterprise projects.
• Jenkins-X is a CI/CD solution for Kubernetes-based Cloud Native applications. It is not a single product but rather a package of preconfigured tools, which can be installed automatically or based on the options selected by the user. The installation is managed from the command line (jx), which allows you to have a complete platform at your disposal in a relatively short time through a wizard. Jenkins-X, therefore, positions itself as an all-in-one solution that can be used for the entire CI/CD process.

Jenkins-X is an open-source project with enterprise support offered by CloudBees, and is part of the Continuous Delivery Foundation (CDF).

• Moreover, those who already use GitLab EE, the premium version of GitLab, will have available – starting from release 13.4 – the integration of a Kubernetes Agent, a native tool that will allow you to implement GitOps without having to rely on other products. The project is the result of a collaboration between Argo with Flux and Amazon AWS. 

So why are we telling you this? It is not uncommon that, after a few releases, some premium features switch over to the free version. So it’s definitely worth keeping an eye on this GitLab feature and on how the tool will evolve in its free version.

The GitOps CI/CD pipeline

Before looking at the GitOps CI/CD pipeline, let’s take a look at a typical Kubernetes CI/CD pipeline, also known as the Push Model.

Credits: GitOps, Push-Based Deployments

This model follows a pipeline which, as you can see, we can defined as unilinear and unidirectional: it starts from the developer, follows all the steps of the CI and, finally, it is the same CI tool that also handles the Continuous Deployment of the application in its target environment. 

Although not inherently wrong, this process can present some weaknesses: first of all, the need to provide the target environment credentials to the CI/CD tool. Second, we see a CI tool that is unable to detect/alert us of discrepancies between the desired state and the current one and forces us to install a second tool that is in charge of monitoring the state of the application.

Credits: GitOps, Pull-Based Deployments

In the Pull-Based Model, and likewise in the CI/CD GitOps pipeline model, we see a first main difference, namely the presence of two repositories located at the beginning and end of the CI process. In this model, in fact, the CI tool no longer takes care of the deployment. Instead, this task will fall on an operator like those seen previously, installed in the target environment. Listening for any changes made in the registry docker and in the repository environment, the tool will ensure that the current state of the environment coincides with that of the repository environment, in other words, the desired state. 

So let’s take a look and see how in this model the unidirectional and unilinear nature of the Push-Based model are circumvented, thus enhancing its security and efficiency.

GitOps: benefits and challenges (and how to deal with them)

No doubt, GitOps can offer many benefits. First, it makes the system fully observable, both by you and by an automated tool. It assures you that what you see in the repository environment is perfectly in line with the Kubernetes cluster, independently making the necessary implementations to match the current state of the system with the desired state (consequently also increasing the verifiability of the system!).

Moreover, GitOps shares an essential benefit with Kubernetes: the declarative model on which the work of the operators is based, thanks to which you can see an increase in productivity. Finally, the Pull model enhances system security by simplifying the problem of having to expose the Kubernetes APIs to your Continuous Integration.

To be absolutely sure that you can take full advantage of these benefits, however, attention must be paid to aspects that can lead to problems if not properly managed. Indeed, it is important to leverage the repository environment and pipelines to prevent, as much as possible, the simultaneous push to the same repository. If Git found that the remote repository was no longer aligned because, in the meantime, another pipeline pushed on the same repository and on the same branch, it would no longer be able to push the changes.

So what are our recommendations to avoid these problems? 

First, if possible, we recommend that you always use two repositories, one for your application code and the other as storage for your manifests. Moreover, always remember that you should never store sensitive data in the repository environment. It is true that GitHub helps make your system more secure, but it is still a good idea to take this precaution.

By following these two simple tips and best practices, you can create modern and Cloud Native applications, enjoying all the various benefits that the GitOps paradigm has to offer and will continue to offer with its ever-growing development.