Skip to main content

Gitops Intro

Once the deployment manifests are ready, there must be a deployment automation process that takes care of the deployment process in a repeatable, trackable way. Continuous Integration (CI) systems are generally used for this task.

The very last step of the CI pipeline is typically a deployment step. The pipelines either run on push or tag events on certain branches, or you can trigger a deployment pipeline on demand.

A typical CI pipeline

Rollbacks also need automation because companies usually have ways to deploy to throwaway environments to preview a feature or to deploy a preview of a Pull Request.

Gitops​

Gitops means many things to many people.

What they all agree on is that gitops is a form of Infrastructure as Code, where the infrastructure configuration is stored in a git repository - being the single source of truth - and some automation delivers it to the target system.

The term was coined in 2017 by the CEO of Weave Works. His definition enumerates the benefits of this approach, and it is rather permissive, allowing many existing tools to be called gitops tools, including Terraform, Ansible, and their gitops controller, FluxCD.

But this permissive definition doesn't help us in our day-to-day communication. It is not clear what others mean when they talk about gitops, plus, we can come to a disturbing realization: we already had a handful of terms defining something similar many years prior.

Therefore, this book uses a more restrictive definition.

Gitops, a restrictive definiton​

Gitops is a continuous delivery technique that delivers Kubernetes yamls on the cluster.

Essentially meaning tools like FluxCD or ArgoCD.

This book focuses on FluxCD and its concepts to explain gitops in depth.

Gitops, a high-level overview​

Gitops overview

  • FluxCD, the gitops controller, runs in the cluster
  • It pulls the latest changes from a configured gitops repository (1)
  • Then it applies them on the cluster (2)
  • The gitops repository is a completely normal git repository. We store Kubernetes resource definitions in it.

How gitops differs from any other automation​

Whether you deploy today from your laptop or from CI, you have a set of commands - or plugin - to install Kubernetes manifests, and you have to have Kubernetes access to be able to perform these commands.

With gitops, your deployment step is simplified. You only interact with git by writing your manifests to it, then the gitops controller will apply these changes on the cluster in a separate workflow.

This split allows for a more declarative software delivery flow - you record in git what state the cluster needs to be in, and leave the rollout to standardized tooling.

Pull semantics​

The presented flow is the exact opposite of what you find in CI based automation.

CI pushes changes to a target system, while FluxCD pulls changes from git and applies them on the environment it is running in.

While this may look odd at first, it allows for

  • a fine-grained access management. No central component knows the credentials of all target systems
  • more robust error handling. Since the controller is a long-running process in the target environment, it allows for more versatile state reconciliation (the process when the controller tries to get the target system into the desired state) and it is better equipped to solve complex failure modes.
  • flexible configuration. The environment controls what identity it wants to assume. You can easily replicate environments or control flavors of environments.

Building on the core properties of git​

  • Git is a well-known toolchain for developers
    Making and reading changes is a skill all developers possess

  • You get an audit log of all changes
    This log that was previously scattered in the CI build history

  • Rolling back based on git history
    Since every version is stored, rolling back to exact revisions is a core property of git

Bootstrapping gitops automation​

On the next page, you will use GimletCLI to bootstrap the GitOps workflow, then write application manifests to the GitOps repository, and see them deploy.

Alternatively, you can use the Flux CLI to bootstrap gitops automation.

Let's turn the page, shall we?