GitOps Principles: Infrastructure as Code with Git
What is GitOps?
GitOps is a way to manage infrastructure and applications using Git as the single source of truth. It extends Infrastructure as Code (IaC) by adding automated delivery: every change to the Git repository is automatically applied to the target environment (e.g., Kubernetes).
Core idea: Your Git repository contains the entire desired state of the system — configurations, manifests, policies. A software agent (like ArgoCD or Flux) continuously compares the live state with the repository and reconciles any differences.
Simple analogy: Think of Git as the “control room” for your infrastructure. Operators never touch servers directly; they only make changes via pull requests. The GitOps operator acts as an automated worker that makes the real world match the control room’s instructions.
The Four Key Principles of GitOps
1. Declarative Description
The entire system (infrastructure, apps, config) must be described declaratively. You don't write scripts that create resources step by step; instead you write a manifest that says “this is what I want”. For Kubernetes that means YAML files; for Terraform it’s HCL.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myapp:1.2.3
2. Versioned and Immutable
The desired state is stored in Git in a way that is versioned, immutable, and retains the complete history. Every change creates a new commit; you can always revert or reproduce any previous state.
Why it matters: This gives you an audit log, disaster recovery, and a clear “who changed what and when”.
3. Automatically Applied
Software agents (operators) automatically pull changes from Git and apply them to the environment. There is no manual `kubectl apply` or `terraform apply`. The operator runs continuously and ensures the live state matches the repo.
Example tools: ArgoCD, Flux CD, Jenkins X.
4. Continuous Reconciliation
The operator constantly monitors the live system. If someone (or something) manually changes the cluster, the operator will revert those changes to match Git. This self-healing property ensures that drift is automatically corrected.
Key takeaway: GitOps shifts from “push” deployments (CI server pushing to cluster) to “pull” deployments (cluster pulling from Git). This is more secure and reliable.
GitOps Workflow Example (with ArgoCD)
- Developer updates a Kubernetes manifest in Git (e.g., changes replica count from 3 to 5).
- Pull request is reviewed and merged to the main branch.
- ArgoCD (running in the cluster) detects the change in the Git repository.
- ArgoCD automatically syncs the cluster to match the new desired state (scales the deployment).
- If someone manually scales down the deployment, ArgoCD will revert it back to 5 replicas within minutes.
Infrastructure as Code (IaC) meets GitOps
IaC tools like Terraform, Pulumi, or Crossplane can also be part of a GitOps workflow. The same principles apply: store the IaC configuration in Git, and an operator applies it. For Terraform, you might use terraform-cloud-operator or Atlantis.
Example: Terraform in GitOps style
resource "aws_s3_bucket" "data" {
bucket = "my-gitops-bucket"
acl = "private"
}
With Atlantis (a GitOps tool for Terraform), when a pull request changes this file, Atlantis automatically runs terraform plan and posts the output to the PR. After merge, it runs terraform apply.
Git vs. traditional CI/CD for infrastructure
| Traditional | GitOps |
|---|---|
| Imperative scripts | Declarative manifests |
| Manual or triggered apply | Automatic reconciliation |
| Configuration drift common | Self-healing, drift correction |
| CI server needs cluster credentials | Cluster pulls from Git (more secure) |
Benefits of GitOps
- Audit trail: Every change is a commit – full history and blame.
- Faster recovery: Restore the entire cluster from Git after a disaster.
- Stronger security: No need to distribute credentials to CI servers.
- Developer experience: Use familiar Git workflows (pull requests, reviews).
- Drift prevention: The system always converges to the desired state.
Popular GitOps tools
- ArgoCD – Kubernetes native, with UI and extensive features.
- Flux CD – the original GitOps tool, now part of CNCF.
- Jenkins X – CI/CD with built-in GitOps for Kubernetes.
- Atlantis – GitOps for Terraform.
- Crossplane – control plane that can act as a GitOps operator.
Frequently Asked Questions
No, GitOps principles apply to any infrastructure that can be described declaratively. However, Kubernetes is the most common target because of its native declarative model. Tools like Terraform/Crossplane extend GitOps to cloud resources.
Secrets should never be stored plaintext in Git. Use sealed secrets (e.g., Bitnami Sealed Secrets), external secret operators (like HashiCorp Vault), or tools like SOPS to encrypt secrets before committing. The operator decrypts them at runtime.
The operator usually caches the last known desired state. If Git is unreachable, the cluster continues running with the last synced configuration. Once Git is back, the operator syncs again. For critical operations, you can run a local mirror of the Git repo.
For schema changes, tools like Liquibase or Flyway can be integrated into a GitOps pipeline. For stateful data, GitOps usually manages the infrastructure (e.g., database instance), but the data itself is not stored in Git. StatefulSets with persistent volumes can be part of GitOps.