GitOps: Not a Solution for Every Problem

GitOps: Not a Solution for Every Problem

In this article, I will share about GitOps, an emerging concept in the DevOps world, and the difficulties that can be encountered when applying it.

What is GitOps and Why You (Don't) Need It

One of the most promising trends today is Immutable Infrastructure . The main idea is to divide the infrastructure into two distinct parts: Stateless and Stateful .

• Stateless : This part does not store data or change operations based on the saved state. Stateless instances can contain basic scripts and assemblies. They are usually created from base images like alpine/jdk-temurin and are susceptible to change.
• Stateful : This part stores persistent data, which can use cloud services like RDS, object storage, or block storage.

To manage and operate effectively, coordination between engineering and DevOps teams, along with automated delivery processes, is required.

CI/CD

CI (Continuous Integration) requires integrating changes into the main branch of the project as often as possible. This requires:

• Break down work into smaller parts.
• Make sure the code is error free before merging.

CD (Continuous Delivery/Deployment):

• Continuous Delivery : Keep the main branch of the project always ready for deployment.
• Continuous Deployment : Automatically deploy all changes to the production environment.

Problems with Snowflake servers

Immutable Infrastructure still has some problems, mostly inherited from the concept of Infrastructure as Code (IaC) . One of them is Configuration Drift . This happens when changes to the system are not made through SCM (SVN, git), leading to a difference between the configuration described in SCM and the actual state.

This can lead to Snowflake Servers , where servers become so different that no one understands the internal configuration.

GitOps - The Complete Solution?

GitOps emerged as a potential solution, promising benefits such as:

• Improve consistency and standardize deployment processes.
• Enhanced security.
• Error recovery is faster and easier.
• Manage access and secrets more efficiently.
• Automatically generate documentation for deployment processes.
• Distribute knowledge in groups.

The principles of GitOps are similar to IaC, including:

• GitOps is declarative.
• GitOps applications are versioned by git and Immutable .
• GitOps applications are pulled automatically.
• GitOps applications are continuously reconciled.

GitOps uses Git as a source for code and CD tools to automatically deploy code to the infrastructure. Typically, GitOps will have at least 2 repositories:

• Application repository : Contains source code and manifest files that describe how to deploy the application.
• Infrastructure repository : Contains manifest files describing the infrastructure and deployment environment.

GitOps favors pull-oriented, as opposed to the push-based approach of tools like Ansible and Terraform.

Using Flux with Helm

Flux is a GitOps tool, consisting of controllers that operate inside the cluster:

• Source controller
• Kustomize controller
• HELM controller
• Notification controller
• Image automation controllers

Example of application deployment using Helm in Flux 2:

1. Generate Helm charts and Docker images from application repository.
2. Add them to the Helm chart repository and Docker registry.
3. Create a YAML file describing the custom resource (CR) HelmRelease and add it to the infrastructure repository.
4. Create a CR GitRepository in the Kubernetes cluster so that Flux can fetch the YAML file.
5. The Kustomize controller will take the YAML from the Source controller and deploy it to the cluster.
6. The Helm controller will get the Helm chart from the Source controller and create a release.
7. Kubernetes creates the necessary pods and downloads the Docker image.

To deploy a new version, we need to create a new image, a new HelmRelease file and possibly a new Helm chart, and then push them to the respective repositories.

Custom Resource

Flux works with custom resources (CR) like:

• GitRepository : Specifies the repository and branch to track.
• Kustomization : Apply YAML from Git repository to cluster.
• HelmRelease : Define the Helm chart name, version, and variable values to customize the release.

Checklist for GitOps

To get started with GitOps, you need to create:

• Script to build and push images to Docker registry.
• Infrastructure Git repository.
• Account for CI system to access infrastructure Git repository.
• Script to create and push HelmRelease file.
• Helm Repository.
• Account for CI system to access Helm repository.
• Script to build and publish Helm charts.
• Flux account to access infrastructure repository and Helm chart repository.

Violation of the "Single Source of Truth" principle

In the case of Helm releases, Git is not the only source of information. Helm charts and Docker images still reside outside of Git. To work around this, you can deploy Helm charts from the Git repository, but that still doesn’t solve the Docker image dependency problem.

Conclude

In the next section, I will discuss other issues related to GitOps, including:

• Problems with multiple environments
• Value from Secrets
• CI Ops vs GitOps
• Security
• Rollback Process
• Problems with multiple clusters
• Who really needs GitOps?

Hope this article is helpful to you!