Establish GitOps principles

DevOps aims to reunite development and operations teams and automate the process of bringing new software versions into the production environment. To achieve that, automation frameworks support a way to describe what and how a software component should be deployed. This could be achieved either in an imperative or declarative manner. In DevOps, these ways are called paradigms.

With imperative practise (e.g. kubectl create deployment nginx --image=nginx, kubectl expose deployment nginx --port=80 --target-port=8000, ... ), the order of the commands is relevant. In case a previous step has not been executed, the command fails.

The declarative way does not rely on previous configuration steps and is lesser error-prone. A file contains the desired state and e.g. Kubernetes ensures that the actual state is adjusted to the desired state. This is also why it is best practice to store the manifests files for Kubernetes resources to deploy or redeploy them. This way it is guaranteed whenever and wherever the same manifest files are applied that the same resources are created and the application is running as the last time.

The big question is: where to store these Kubernetes manifest files?

Typically these Kubernetes manifest files could change based on the functionality of the application which will be deployed. For example, if the application is extended with probes endpoints, the corresponding Kubernetes manifest file should be adjusted to use them. Since the manifest files are bound tight to the software it does make sense to store them in the same version control system. Nowadays, this is usually Git.

GitOps is an operational framework that takes DevOps best practices for application development such as version control, collaboration, compliance and CI/CD tooling, and applies them to infrastructure automation.

While the software development life cycle has been automated, infrastructure has remained a largely manual process that requires specialized teams. With the target to have more frequent and smaller releases, it has become a demand in today's infrastructure to automate the deployment task as well.

• Developer friendly experience

It helps developers to use the tool they are familiar with to maintain resources within Kubernetes.

• Reliable

Because the software version and the Kubernetes manifest files which also contain the configuration are bundled together, it is easily possible to roll back to a stable version without headache.

• Rapid deployment

New software versions can be deployed rapidly into other stages (e.g. Integration, Production, ...)

• Self declarative documentation

Since the Kubernetes manifest files describe in a declarative manner what should be deployed, a certain version can be checked out from Git and analyzed which software version is used with which configuration.

• Security and Compliance

GitOps helps companies to stay secure and compliant. Access can be restricted and the manifest files are under version control. This makes auditing much easier.

This way the security control mechanism of Airlock Microgateway is also under version control and can be audited.

A GitOps pipeline looks like this:

1. A user changes the application code and pushes it to the Git repository.
2. A new container is built and tested and pushed into a container registry in a CI/CD pipeline.
3. A Pull request is created for the Git repository containing the Kubernetes manifest files.
4. Someone verifies the Pull request. In case everything is fine, the Pull request is merged.
5. A GitOps tool detects the changes and ensures that the new desired is deployed.

Most important, GitOps is all about making sure that Git is the source of truth at least for the desired state.

There exist many GitOps tools to implement the mentioned GitOps pipeline.

• Some of the most common are:
• ArgoCD
• Flux
• Jenkins X

As illustrated in the GitOps pipeline graphic, GitOps requires Git and Kubernetes.