G
GuideDevOps
Lesson 1 of 10

Introduction to GitOps

Part of the GitOps tutorial series.

The Pre-GitOps Nightmare

To understand why GitOps is revolutionary, you must understand how painful Kubernetes deployments used to be.

Historically, a CI/CD deployment looked like this:

  1. A developer writes code and pushes it to GitHub.
  2. A Jenkins CI server tests the code and builds a Docker image.
  3. Jenkins runs kubectl apply -f deployment.yaml to push the new version to the production Kubernetes cluster.

What is wrong with this?

This is known as a "CIOps" (Continuous Integration Ops) model, and it has massive flaws:

  • God-Mode Jenkins: To run kubectl apply, you must give the Jenkins server the master administrative credentials to your production Kubernetes cluster. If a hacker breaches Jenkins, they instantly own your entire production environment.
  • Drift: Jenkins pushes v1.0 to the cluster. Later that day, a developer named Tim logs directly into the Kubernetes cluster and manually runs kubectl edit deployment to desperately fix a bug. The cluster is now running v1.1, but Git still says v1.0. Your codebase and your cluster have "drifted" apart.
  • Disaster Recovery is Impossible: If the cluster burns down, you cannot just look at Git to restore it, because Tim's manual changes were never committed to Git.

Enter GitOps

Coined by Weaveworks in 2017, GitOps is an operating model for Cloud Native applications.

GitOps is founded on a very simple premise: Git is the single source of truth for your entire system.

If your infrastructure isn't written in a Git repository, it doesn't exist. If you want to change the number of replicas on a web server from 3 to 5, you do not log into the cluster and type a command. You create a Git commit changing the number 3 to 5 in a YAML file, and you merge it.

The Pull Model

The absolute key to GitOps is the Pull Model.

Instead of Jenkins aggressively pushing configurations into the cluster, you install a GitOps software agent (like ArgoCD or Flux) inside the Kubernetes cluster itself.

This internal agent reaches out to GitHub every 3 minutes.

  1. It looks at the GitHub repository (the Desired State).
  2. It looks at the Kubernetes cluster it lives inside (the Actual State).
  3. If they don't match, the agent fixes the cluster to perfectly mirror GitHub.
graph LR
    A[Developer Git Push] --> B[GitHub Repo (Desired State)]
    B -.-> |Agent Pulls| C[Kubernetes Cluster (Actual State)]
    D[Hacker Manual Change] --> C
    C -.-> |Agent Reverts Hacker!| C

The Magic of Auto-Healing

Because of the Pull Model, if Tim manually types kubectl delete deployment on the live cluster, the GitOps agent instantly notices. It looks at GitHub, sees that the deployment is supposed to exist, and immediately recreates it, undoing Tim's manual destruction within 5 seconds.

This ensures incredible system stability.

In the next tutorial, we will explore the four foundational principles that officially define a GitOps architecture.