GitOps Principles Visualized

GitOps is a modern practice to managing infrastructure and application deployments using Git as the single source of truth. The four core principles of GitOps were introduced by OpenGitOps CNCF Sandbox organization, that maintains a set of open-source standards, best practices, and community-focused education to adopt GitOps approach.

The latest version of the principles can be found at opengitops.dev.

Below is an explanation of each principles, according to the v1.0.0 of the document.

---

Principle #1. Declarative

A system managed by GitOps must have its desired state expressed declaratively.

• Meaning: The desired state of the system (e.g., infrastructure, applications, configurations) is described in a declarative manner, meaning you specify what the system should look like, not how to achieve it. This is typically done using configuration files (e.g., YAML, JSON) stored in a Git repository.

• Implication: Instead of writing step-by-step scripts (imperative approach), you define the end state (e.g., "I want 3 replicas of this application running with this configuration"). The system figures out how to make it happen.

• Example: A Kubernetes manifest file declaring a deployment with specific settings (replicas, container images, etc.) is declarative because it describes the desired outcome without specifying the steps to achieve it.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-app
      labels:
        app: my-app
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - name: my-container
            image: nginx:1.25
            ports:
            - containerPort: 80
  

  The provided sample Kubernetes deployment YAML file does not tell Kubernetes how to create or maintain these pods - Kubernetes takes care of the "how" behind the scenes.

• Why it matters: Declarative systems are easier to reason about, reproduce, and audit since the configuration explicitly states the intent.

---

Principle #2. Versioned and Immutable

Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.

• Meaning: The desired state of the system is stored in a Git repository (or similar version control system) where changes are tracked, versioned, and immutable. Once a change is committed, it cannot be altered without creating a new version, and the entire history of changes is preserved.

• Implication: Every change to the system’s configuration is recorded as a Git commit, providing a clear audit trail. Immutability ensures that past states can be reliably reproduced or rolled back if needed.

• Example: A configuration file in a Git repository is updated via a pull request, committed, and tagged. If a problem occurs, you can revert to a previous commit to restore the earlier state.

• Why it matters: Versioning enables traceability, collaboration, and rollback capabilities, while immutability ensures configurations are tamper-proof and consistent.

---

Principle #3. Pulled Automatically

Software agents automatically pull the desired state declarations from the source.

• Meaning: Software agents (e.g., GitOps operators like ArgoCD or Flux) automatically retrieve the desired state declarations from the Git repository without manual intervention. These agents "pull" the configuration rather than having it "pushed" to them.

• Implication: The system is self-managing to an extent, as the agents continuously monitor the Git repository for changes and apply them to the system. This eliminates the need for manual deployment commands or external orchestration tools pushing changes.

• Example: An ArgoCD agent monitors a Git repository, detects a new commit with updated Kubernetes manifests, and applies them to the cluster automatically.

• Why it matters: Automated pulling reduces human error, ensures consistency, and enables rapid deployment of changes as soon as they’re committed to Git.

---

Principle #4. Continuously Reconciled

Software agents continuously observe actual system state and attempt to apply the desired state.

• Meaning: Software agents continuously compare the actual state of the system (e.g., what’s running in production) with the desired state defined in the Git repository. If there’s a discrepancy (drift), the agents automatically take action to reconcile the system back to the desired state.

• Implication: The system is self-healing, as the agents enforce the declared configuration. For example, if a pod is manually deleted, the agent will recreate it to match the desired state.

• Example: If a Kubernetes cluster’s actual state diverges from the Git-defined state (e.g., due to a manual change or failure), the GitOps agent (like Flux) will detect the drift and reapply the correct configuration.

• Why it matters: Continuous reconciliation ensures the system remains consistent with the declared intent, improving reliability and reducing manual maintenance.

---

Together, these principles make GitOps a powerful paradigm for managing infrastructure and applications:

• Declarative ensures clarity and simplicity in defining system states.

• Versioned and immutable provides auditability, reproducibility, and rollback capabilities.

• Pulled automatically enables automation and reduces manual intervention.

• Continuously reconciled ensures the system is always aligned with the desired state, enhancing reliability and self-healing.

By leveraging Git as the source of truth and automating the application of changes, GitOps streamlines operations, improves collaboration, and aligns with DevOps practices like CI/CD and infrastructure-as-code.

References

• The NewStack Blog: 4 Core Principles of GitOps

• github.com/Brain2life/gitops-cookbook