🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📖 धडा 05 — GitOps कल्पना: वास्तव पुस्तकाशी जुळलेच पाहिजे

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 — भाग 2 सुरू! · मागे: lesson-04-limits-of-push · पुढे: lesson-06-install-argocd

📦 या ब्रँचमध्ये काय आहे

धडे 01–04, आणि त्यासोबत चारही खड्डे एकाच वेळी बुजवणारी मोठी कल्पना: GitOps — git हे एकमेव source of truth, आणि cluster च्या आत राहणारा agent ते अंमलात आणतो.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळा एकच मुख्य प्लॅन-वही 📖 लिहिते आणि ती ग्रंथालयात ठेवते (git). प्रत्येक खोली नेमकी कशी दिसायला हवी ते वही सांगते: खुर्च्या, पोस्टर्स, झाडांना पाणी घालणारे, projector च्या जागा.

आणि इथे युक्ती आहे — शाळा एक केअरटेकर 🤖 कामावर ठेवते जो इमारतीतच राहतो आणि ज्याचे एकच काम आहे, कायम पुन्हा पुन्हा:

वही वाचा. व्हरांड्यातून फिरा. खोल्या वहीशी जुळवा. पुन्हा करा.

आता सगळ्याचेच स्वरूप बदलते:

खोली वेगळी हवी? खोलीला हात लावू नका — वही बदला. केअरटेकर ते प्रत्यक्षात आणेल.
एखाद्या मुलाने खुर्च्या हलवल्या? केअरटेकर काही मिनिटांत त्या परत लावतो. खोलीत drift होऊच शकत नाही, कारण कोणीतरी दिवसभर तिची वहीशी तुलना करत असते.
"खोली 3B कशी दिसते?" — वही वाचा. ती नेहमी खरी असते.
कालची मांडणी जास्त चांगली होती? एक पान मागे उलटा. केअरटेकर ऐकतो.
आणि शाळेच्या चाव्या? त्या कधीच इमारतीबाहेर जात नाहीत — केअरटेकर आतूनच काम करतो. 🔑🏫

धडा 04 मधले चार खड्डे. चार उपाय. एक कल्पना.

🗺️ आकृती

flowchart LR
    book["📖 git repo<br/>DESIRED state - the book<br/>reviewed PRs, full history"]
    agent(("🔄 agent<br/>compare and converge"))
    cluster["🏫 cluster<br/>ACTUAL state - the rooms"]
    book -->|"1 reads the book"| agent
    cluster -->|"2 looks at the rooms"| agent
    agent -->|"3 fixes any difference"| cluster
    agent -.->|"4 repeat every ~3 min, forever"| agent

❓ काय

GitOps = चार नियम (OpenGitOps project ने ठरवल्याप्रमाणे):

Declarative — संपूर्ण system files च्या रूपात वर्णन केलेली असते (हे तुमच्याकडे धडा 01 पासूनच आहे — तुमचा k8s/ folder).
Versioned & immutable — त्या files git मध्ये राहतात: history, blame, review, revert.
Pulled automatically — cluster च्या आतला agent इच्छित स्थिती स्वतःच आणतो. बाहेरची कोणतीही system key घेऊन push करत नाही.
Continuously reconciled — agent कायम तुलना करतो आणि जुळवतो, फक्त deploy च्या क्षणी नाही.

नियम 1–2 तुमच्याकडे आधीपासूनच होते. नियम 3–4 या नव्या महाशक्ती आहेत — आणि त्या ओळखीच्या वाटत असतील तर: Deployment "replicas: 2" ला अगदी असेच वागवते (k8s कोर्स, धडा 03). GitOps हाच reconcile loop तुमच्या संपूर्ण cluster ला लागू करते, git ला इच्छित स्थिती मानून.

🤔 का

कारण ते push model चे चारही खड्डे समस्याच उरू देत नाही: drift → सतत उलटवला जातो · बाहेरून येणारे deployment credentials → agent आतून pull करतो · दहा clusters → दहा agents, प्रत्येक एकाच repo मधून pull करतो · "काय चालू आहे?" → वही, आणि agent ची स्वतःची sync history. Deploys आता कोणीतरी करायच्या घटना राहत नाहीत, तर कोणीतरी commit केलेली तथ्ये बनतात.

🔧 कसे (या repo मध्ये)

अजून काहीच install करायचे नाही — हा धडा म्हणजे मनातले model. पण लक्षात घ्या की repo आधीच GitOps च्या आकारात आहे: k8s/ हे app चे संपूर्ण declarative वर्णन आहे (नियम 1), git मध्ये versioned (नियम 2). धडे 06–07 agent जोडतात (नियम 3–4): ArgoCD + एक Application file.

🧪 करून पाहा (कागदावरचा सराव, 2 मिनिटे)

# GitOps quiz — answer each with "edit the book" or "touch the room":
#   Q1: you want 3 replicas instead of 2            → ?
#   Q2: prod is on fire, revert last night's change → ?
#   Q3: auditor asks who changed the memory limit   → ?
# answers: book (git commit), book (git revert), book (git log -p k8s/)
git log --oneline -- k8s/    # ← the book's history: your future desired-state history

✅ तपासा — तुम्हाला काय दिसायला हवे

कागदावरचा सराव: तिन्ही उत्तरे "वही" आहेत. git log --oneline -- k8s/ manifests ना स्पर्श केलेले commits छापते — ती यादी म्हणजे तुमच्या भविष्यातल्या इच्छित-स्थिती history चा आकार.

🧹 साफसफाई

काहीच साफ करायचे नाही — या धड्यात cluster मध्ये कोणताही बदल नाही.

⚠️ नेहमीच्या चुका

GitOps म्हणजे "आम्ही YAML git मध्ये ठेवतो" असे समजणे — फक्त नियम 1–2 म्हणजे version control; खड्डे बुजवतो तो agent (नियम 3–4)
प्रत्यक्षात काय घडले ते वहीला माहीत असेल अशी अपेक्षा ठेवणे — ती हेतू नोंदवते; agent ची sync history कृती नोंदवते (धडा 10)
"सगळे git मध्येच हवे" म्हणून secrets वहीत ठेवणे (धडा 12)

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: GitOps on-call चा प्रश्न "कोणी काय deploy केले?" वरून "git काय सांगते, आणि app Synced आहे का?" असा बदलते — पण फक्त प्रत्येक बदल वहीमधूनच गेला तरच. Prod मध्ये एक kubectl edit केला की तुम्ही पुन्हा धडा 02 मध्ये पोहोचता, जोपर्यंत selfHeal वेगळे ठरवत नाही.

⏭️ पुढे

केअरटेकरला कामावर ठेवण्याची वेळ. ArgoCD एका command ने तुमच्या cluster मध्ये install होतो.

git checkout lesson-06-install-argocd

📖 Lesson 05 — The GitOps idea: reality must match the book

📍 You are here: Lesson 05 of 12 — Part 2 begins! · Previous: lesson-04-limits-of-push · Next: lesson-06-install-argocd

📦 What's in this branch

Lessons 01–04, plus the big idea that fixes all four gaps at once: GitOps — git as the single source of truth, enforced by an agent that lives inside the cluster.

🧒 Explain like I'm 5

The school writes ONE master plan book 📖 and keeps it in the library (git). The book says exactly how every room should look: chairs, posters, plant-waterers, projector positions.

And here's the trick — the school hires a caretaker 🤖 who lives in the building and has one job, repeated forever:

Read the book. Walk the halls. Make the rooms match the book. Repeat.

Now everything changes shape:

Want a different room? Don't touch the room — edit the book. The caretaker will make it real.
A kid rearranges chairs? Caretaker puts them back within minutes. The room can't drift, because someone compares it to the book all day.
"What does Room 3B look like?" — read the book. It's always true.
Yesterday's layout was better? Flip back one page. Caretaker obliges.
And the school's keys? They never leave the building — the caretaker works from inside. 🔑🏫

Four gaps from lesson 04. Four fixes. One idea.

🗺️ Diagram

flowchart LR
    book["📖 git repo<br/>DESIRED state - the book<br/>reviewed PRs, full history"]
    agent(("🔄 agent<br/>compare and converge"))
    cluster["🏫 cluster<br/>ACTUAL state - the rooms"]
    book -->|"1 reads the book"| agent
    cluster -->|"2 looks at the rooms"| agent
    agent -->|"3 fixes any difference"| cluster
    agent -.->|"4 repeat every ~3 min, forever"| agent

❓ What

GitOps = four rules (as codified by the OpenGitOps project):

Declarative — the whole system is described as files (you've had this since lesson 01 — your k8s/ folder).
Versioned & immutable — those files live in git: history, blame, review, revert.
Pulled automatically — an agent inside the cluster fetches the desired state itself. No outside system pushes with a key.
Continuously reconciled — the agent compares & converges forever, not just at deploy moments.

Rules 1–2 you already had. Rules 3–4 are the new superpowers — and if they sound familiar: it's exactly how a Deployment treats "replicas: 2" (k8s course, lesson 03). GitOps applies the same reconcile loop to your entire cluster, with git as the desired state.

🤔 Why

Because it converts the four push-model gaps into non-problems: drift → reverted continuously · deployment credentials from outside → the agent pulls from inside · ten clusters → ten agents, each pulling the same repo · "what's running?" → the book, plus the agent's own sync history. Deploys stop being events somebody performs and become facts somebody committed.

🔧 How (in this repo)

Nothing to install yet — this lesson is the mental model. But notice the repo is already GitOps-shaped: k8s/ is a complete declarative description of the app (rule 1), versioned in git (rule 2). Lessons 06–07 add the agent (rules 3–4): ArgoCD + one Application file.

🧪 Try it (a paper exercise, 2 minutes)

# GitOps quiz — answer each with "edit the book" or "touch the room":
#   Q1: you want 3 replicas instead of 2            → ?
#   Q2: prod is on fire, revert last night's change → ?
#   Q3: auditor asks who changed the memory limit   → ?
# answers: book (git commit), book (git revert), book (git log -p k8s/)
git log --oneline -- k8s/    # ← the book's history: your future desired-state history

✅ Verify — what you should see

Paper exercise: all three answers are "the book". git log --oneline -- k8s/ prints the commits that touched the manifests — that list is the shape of your future desired-state history.

🧹 Clean up

Nothing to clean — no cluster changes in this lesson.

⚠️ Common mistakes

equating GitOps with "we keep YAML in git" — rules 1–2 alone are version control; the agent (rules 3–4) is what closes the gaps
expecting the book to know what actually happened — it records intent; the agent's sync history records action (lesson 10)
putting secrets in the book because "everything must be in git" (lesson 12)

🏭 Why this matters in production: GitOps changes the on-call question from "who deployed what?" to "what does git say, and is the app Synced?" — but only if every change goes through the book. One kubectl edit in prod and you are back in lesson 02, until selfHeal says otherwise.

⏭️ Next

Time to hire the caretaker. ArgoCD installs into your cluster with one command.

git checkout lesson-06-install-argocd

← Previouslimits of push Next →install argocd

This page is the lesson's README from the lesson-05-gitops-idea branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.