The GitOps Principle¶
The entire Contain Platform is built on a foundational principle: GitOps. Rather than making manual changes or running imperative scripts, the desired state of your applications and infrastructure is declared as code and stored in a Git repository. This repository acts as the single source of truth.
GitOps is a declarative approach to infrastructure and application management. Software agents, known as controllers, automatically ensure that the live environment always matches the state defined in your repository. This creates a more reliable, secure, and auditable system.
For our GitOps capabilities, we use the CNCF project FluxCD, a powerful and extensible set of controllers that automate the reconciliation process.
Core Concepts of GitOps¶
Adopting a GitOps-driven model is an architectural choice that provides several key benefits, which stem from its core concepts.
- Declarative State as the Source of Truth: The entire state of your system is described declaratively in Git. You define what you want, not how to achieve it. This makes the system state transparent and easy to understand.
- Version Controlled and Auditable: Every change to your infrastructure is a
git commit. This gives you a complete, immutable history of who changed what, when, and why. Rolling back to a previous known-good state can be as simple as agit revert. - Automated Reconciliation: A GitOps controller, like Flux, runs inside your cluster. It continuously compares the desired state in the Git repository with the actual state of the cluster. If it detects any drift, it automatically takes action to correct it.
- Pull-Based Model for Enhanced Security: The controller pulls changes from the repository, rather than having an external system push changes to the cluster. This is more secure because you don't need to expose the Kubernetes API or grant credentials to external CI/CD systems.
The GitOps Workflow¶
The GitOps workflow creates a continuous reconciliation loop that automates deployments and ensures consistency.
The process is straightforward:
- A developer pushes a declarative change (e.g., updating a container image tag in a YAML file) to the designated Git repository.
- The GitOps controller, running in the cluster, detects the change in the repository.
- The controller applies the new state to the cluster, updating the necessary resources.
This workflow is illustrated in more technical detail in our Git and Artifacts Flow architecture diagram.
Get Started¶
To start deploying your applications, follow our GitOps Getting Started Guide.