GitOps: Controlling infrastructure from Git

In short: The desired state of applications and infrastructure is stored in a Git repository, and a tool automatically reconciles the running systems with it.

In more detail: With GitOps, Git is the single source of truth. Changes are not made by manual commands on the server but as a commit or pull request. An agent in the cluster (for example Argo CD or Flux) constantly compares the desired state in the repository with the actual state and corrects deviations.

In Depth

Principles

• Declarative: the files describe what should run (YAML for Kubernetes), not the steps to get there.
• Versioned: every change has an author, a time and a reason, and can be undone (git revert).
• Applied automatically: an agent adopts approved changes.
• Self-healing: if something is changed by hand, the agent resets it (drift detection).

Pull instead of push

Classic pipelines push changes into the cluster with their own credentials. With GitOps the agent in the cluster pulls the changes from the repository. The cluster does not need to hand out credentials to the pipeline, which increases security, and the state is traceable at all times.

Typical flow

1. Developers change the manifest file (e.g. a new image tag) in a branch.
2. Pull request with review and automatic checks.
3. After the merge the agent detects the change.
4. The agent applies it and reports the status. Rolling back means: undo the commit.

Stumbling blocks

Secrets (passwords) must not go into the repository in plain text; tools such as Sealed Secrets or SOPS exist for that. Separate application code and environment configuration, otherwise every code change triggers a configuration build. GitOps is most effective together with infrastructure as code.

See also: Infrastructure as code, Kubernetes basics, Git, CI/CD pipeline