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

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

🤖 धडा 14 — Deploy: CI/CD आणि ArgoCD सह GitOps (एक ओळख)

📍 तुम्ही इथे आहात: 26 पैकी धडा 14 — भाग 2 (पाठवणे आणि वाढवणे) सुरू · मागचा: lesson-13-under-the-hood · पुढचा: lesson-15-multi-az-scaling

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

गाभ्याचे सर्व 13 धडे, आणि शेवटचा भाग: कोणत्याही माणसाने kubectl न टाइप करता code प्रत्यक्ष cluster पर्यंत कसा पोहोचतो — robots च्या दोन पद्धती: CI/CD (push) आणि ArgoCD सह GitOps (pull). खऱ्या files:

.circleci/config.yml — हा repo ज्यासोबत येतो ती पूर्ण push-पद्धतीची pipeline
argocd-app.yaml — pull पद्धतीसाठी लगेच apply करता येणारी ArgoCD Application

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

Robot #1 — गृहपाठाचा robot (CI/CD, push पद्धत). 📮 तुम्ही तुमचा गृहपाठ शाळेच्या पत्रपेटीत टाकता (git push). एक robot तो उचलतो:

तो तपासतो — शुद्धलेखन, गणित, सगळे (tests चालवतो). वाईट गृहपाठ कधीच पुढे जात नाही.
त्याची झेरॉक्स काढतो — अधिकृत प्रत बनवतो (Docker image बनवतो 🍱).
ती प्रत शाळेच्या कपाटात ठेवतो (ECR registry वर push करतो).
मुख्याध्यापिकांच्या सहीची वाट पाहतो ✍️ (manual approval चे फाटक).
स्वतः प्रत्येक वर्गात पोहोचवतो (cluster मध्ये kubectl apply).

हा robot एका मुख्य चावीने (CI मध्ये ठेवलेली AWS credentials) शाळेत घुसतो (push). जलद आणि सोपे — पण चावी शाळेच्या बाहेर राहते. 🔑😬

Robot #2 — काळजीवाहू robot (GitOps, pull पद्धत). 🤖 हा robot शाळेच्या आतच राहतो आणि त्याच्याकडे बाहेरची कोणतीही चावी नसते. भिंतीवर मुख्य प्लॅन-वही टांगलेली असते (तुमचा git repo — k8s/ folder). दर काही मिनिटांनी काळजीवाहू:

वही वाचतो 📖,
व्हरांड्यांतून फिरून आराखडा आणि वास्तव यांची तुलना करतो,
कोणताही फरक दुरुस्त करतो — वहीत नवे पान? खोली पुन्हा बांधा. एखाद्या मुलाने हाताने खुर्च्या इकडे-तिकडे केल्या? त्या वहीत लिहिल्याप्रमाणेच परत ठेवा.

Deploy करायचे आहे? तुम्ही शाळेला अजिबात हात लावत नाही — तुम्ही वही edit करता. Roll back करायचे आहे? कालचे पान उलटा (git revert). काय चालू आहे ते जाणून घ्यायचे आहे? वही वाचा — ती नेहमीच सत्य असते.

🗺️ आकृती

flowchart TB
    dev["🧑‍💻 git push"]
    subgraph ci["📮 Robot 1 - CI/CD pipeline"]
        t["✅ test"]
        b["🍱 build image"]
        reg["🗄️ push to registry ECR"]
        hold["✍️ manual approval"]
        t --> b --> reg --> hold
    end
    subgraph cluster["🏫 Kubernetes cluster"]
        argo["🤖 Robot 2 - ArgoCD<br/>lives INSIDE"]
        app["🪑 school-api pods"]
        argo -->|"sync + self-heal"| app
    end
    book["📖 git repo = master plan<br/>k8s/ manifests"]
    dev --> ci
    hold -->|"PUSH style:<br/>kubectl apply from outside"| app
    ci -.->|"GitOps style: CI only<br/>updates the image tag in git"| book
    argo -->|"pulls & compares<br/>every 3 min"| book

❓ काय

CI (Continuous Integration) — प्रत्येक push आपोआप test आणि build होतो. CD (Continuous Delivery/Deployment) — build झालेली गोष्ट आपोआप release होते. आपली CircleCI pipeline दोन्ही आहे.
GitOps — deployment चे तत्त्वज्ञान जिथे git हाच सत्याचा एकमेव स्रोत आहे: cluster सतत commit केलेल्या स्थितीकडे सरकत राहतो. कोणीही हाताने kubectl चालवत नाही; बदल = pull requests. ArgoCD आणि Flux ही दोन मोठी tools आहेत; ArgoCD मध्ये उत्तम UI आहे.
मुख्य फरक: push = CI कडे cluster credentials असतात आणि तो बदल आत ढकलतो. Pull = cluster आतला agent git मधून आणतो; cluster credentials कधीच cluster बाहेर जात नाहीत.
ही पद्धत ओळखली? ArgoCD म्हणजे धडा 03 मधला वर्ग-प्रमुख, पण संपूर्ण cluster साठी, git हीच desired state. तोच reconcile loop, एक पातळी वर. drift दुरुस्त करणे (self-heal) सुद्धा अगदी वर्ग-प्रमुखाने जादा मूल परत पाठवण्यासारखेच.

🤔 का

हाताने चालवलेले kubectl apply चालते... शुक्रवारी संध्याकाळी 6 वाजेपर्यंत: काय deploy झाले आहे? ते कोणी बदलले? prod YAML पेक्षा वेगळा का आहे? कोणालाच माहीत नसते. 🔥

CI/CD "माझ्या machine वर चालते" आणि "tests चालवायला विसरलो" संपवते — प्रत्येक deploy tested असतो, commit SHA ने tag केलेला असतो, आणि त्याचा माग काढता येतो.
GitOps configuration drift संपवते — तुमच्या YAML files आणि वास्तव यांच्यातली शांत दरी. Self-heal चालू असताना drift ~3 मिनिटे टिकतो, मग काळजीवाहू तो दुरुस्त करतो. तुमचा git log हाच तुमचा deploy log बनतो — audit मोफत.
खऱ्या teams सहसा दोन्ही वापरतात: CI image test आणि build करतो, मग नवा image tag manifest repo मध्ये commit करतो — आणि प्रत्यक्ष deploy चे सगळे काम ArgoCD करतो. Pipeline कधीच cluster ला हात लावत नाही.

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

Push पद्धत — आधीच जोडलेली: .circleci/config.yml test-node + test-python एकाच वेळी चालवते → build-and-push (दोन्ही images → ECR, git SHA ने tag केलेल्या) → hold-for-approval → deploy-to-eks (kubectl apply + rollout status, धडा 11 चे फाटक). least-privilege चा तपशील लक्षात घ्या: test jobs ना AWS credentials अजिबात मिळत नाहीत; फक्त AWS ला स्पर्श करणाऱ्या jobs नाच सामायिक credentials context मिळतो.

Pull पद्धत — हा धडा ती जोडतो: argocd-app.yaml ArgoCD ला सांगते: "या repo च्या main branch मधला k8s/ folder पाहत राहा, namespace school त्याच्याशी जुळता ठेव, delete केलेल्या गोष्टी काढून टाक (prune), आणि drift self-heal कर."

spec:
  source:
    repoURL: https://github.com/BaluRaut/learn-kubernetes-school.git
    targetRevision: main
    path: k8s                    # 📖 the master plan pages
  syncPolicy:
    automated:
      prune: true                # deleted from git → deleted from cluster
      selfHeal: true             # hand-edits get reverted. The book wins.

🧪 करून पाहा (सगळे local, ~15 min)

# 1) Install the caretaker robot into your local cluster:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2) Open its UI:
kubectl -n argocd port-forward svc/argocd-server 8080:443 &
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d; echo   # login: admin + this password
# browse https://localhost:8080

# 3) Fork this repo on GitHub, then edit argocd-app.yaml's repoURL to YOUR fork,
#    and in k8s/deployment.yaml replace IMAGE_PLACEHOLDER with a real image
#    (e.g. nginxdemos/hello:plain-text) — commit & push to your fork.

# 4) Hand ArgoCD the plan book:
kubectl apply -f lessons/14-deploy-gitops/argocd-app.yaml
# watch the UI: it clones your repo, shows a diff, and syncs the school into being 🎉

# 5) Feel GitOps — deploy WITHOUT kubectl:
#    edit k8s/deployment.yaml in your fork: replicas: 2 → 3, push...
#    ...and watch a third pod appear on its own within ~3 minutes.

# 6) Feel self-heal — try to cause drift by hand:
kubectl -n school scale deployment school-api --replicas=5
kubectl -n school get pods -w    # the caretaker puts it back to 3. The book wins. 🤖

🔧 या धड्यासाठी kubectl

kubectl get applications -n argocd · argocd app sync

🔗 यावर आधारित: 🍱 Docker L12 (CI build आणि push करतो) · 🤖 ArgoCD शाळा (सर्व 12 धडे)

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

manifest मधला बदल push करा → ArgoCD आधी OutOfSync आणि मग Synced दाखवतो; हाताने kubectl scale करा → ते लगेच पूर्वीसारखे होते.

🧹 साफसफाई

local काम झाल्यावर kubectl delete namespace argocd

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

हा धडा संपूर्ण ArgoCD शिकवेल अशी अपेक्षा — तो मुद्दाम फक्त ओळख करून देणारा आहे; ArgoCD शाळा सखोल जाते
CI ने manifests apply करणे आणि त्याच वेळी ArgoCD ने ते sync करणे — दोन robots भांडतात

🎓 शेवट — या वेळी खरोखरचा

Push pipelines, pull reconcilers, आणि जेवणाच्या डब्यांपासून control plane पर्यंत मधले सगळे. आता तुम्हाला फक्त तुमचे app काय चालवते हेच नाही, तर ते कोण deploy करते आणि प्रामाणिक ठेवते हेही समजते. एक शेवटचा बोनस: इमारतीतली आग आणि परीक्षेच्या निकालाचा दिवस यातून ते टिकवणे.

git checkout lesson-15-multi-az-scaling   # multi-AZ + the scaling ladder 🏫🏫

🤖 Lesson 14 — Deploy: CI/CD & GitOps with ArgoCD (an introduction)

📍 You are here: Lesson 14 of 26 — Part 2 (shipping & scaling) begins · Previous: lesson-13-under-the-hood · Next: lesson-15-multi-az-scaling

📦 What's in this branch

All 13 core lessons, plus the finale: how code actually reaches the cluster without a human typing kubectl — two robot styles: CI/CD (push) and GitOps with ArgoCD (pull). Real files:

.circleci/config.yml — the full push-style pipeline this repo ships with
argocd-app.yaml — a ready-to-apply ArgoCD Application for the pull style

🧒 Explain like I'm 5

Robot #1 — the homework robot (CI/CD, push style). 📮 You drop your homework in the school letterbox (git push). A robot picks it up:

Checks it — spelling, math, everything (runs the tests). Bad homework never goes further.
Photocopies it — makes the official copy (builds the Docker image 🍱).
Files the copy in the school cabinet (pushes to the ECR registry).
Waits for the headteacher's signature ✍️ (the manual approval gate).
Delivers it to every classroom itself (kubectl apply into the cluster).

The robot pushes its way into the school with a master key (AWS credentials stored in CI). Fast and simple — but the key lives outside the school. 🔑😬

Robot #2 — the caretaker robot (GitOps, pull style). 🤖 This robot lives inside the school and holds no outside key. On the wall hangs the master plan book (your git repo — the k8s/ folder). Every few minutes the caretaker:

reads the book 📖,
walks the halls comparing plan vs reality,
fixes any difference — new page in the book? Rebuild the room. A kid moved the chairs around by hand? Put them back exactly as the book says.

Want to deploy? You don't touch the school at all — you edit the book. Want to roll back? Flip to yesterday's page (git revert). Want to know what's running? Read the book — it's always the truth.

🗺️ Diagram

flowchart TB
    dev["🧑‍💻 git push"]
    subgraph ci["📮 Robot 1 - CI/CD pipeline"]
        t["✅ test"]
        b["🍱 build image"]
        reg["🗄️ push to registry ECR"]
        hold["✍️ manual approval"]
        t --> b --> reg --> hold
    end
    subgraph cluster["🏫 Kubernetes cluster"]
        argo["🤖 Robot 2 - ArgoCD<br/>lives INSIDE"]
        app["🪑 school-api pods"]
        argo -->|"sync + self-heal"| app
    end
    book["📖 git repo = master plan<br/>k8s/ manifests"]
    dev --> ci
    hold -->|"PUSH style:<br/>kubectl apply from outside"| app
    ci -.->|"GitOps style: CI only<br/>updates the image tag in git"| book
    argo -->|"pulls & compares<br/>every 3 min"| book

❓ What

CI (Continuous Integration) — every push is automatically tested and built. CD (Continuous Delivery/Deployment) — the built thing is automatically released. Our CircleCI pipeline is both.
GitOps — the deployment philosophy where git is the single source of truth: the cluster continuously converges to what's committed. Nobody runs kubectl by hand; changes = pull requests. ArgoCD and Flux are the two big tools; ArgoCD adds a great UI.
The key difference: push = CI holds cluster credentials and shoves changes in. Pull = an in-cluster agent fetches from git; cluster credentials never leave the cluster.
Recognize the pattern? ArgoCD is lesson 03's class monitor, but for the whole cluster, with git as the desired state. Same reconcile loop, one level up. Even drift-fixing (self-heal) is exactly the monitor sending the extra kid back.

🤔 Why

Hand-run kubectl apply works... until Friday 6 PM: what's deployed? who changed it? why is prod different from the YAML? Nobody knows. 🔥

CI/CD kills "works on my machine" and "forgot to run tests" — every deploy is tested, tagged with a commit SHA, and traceable.
GitOps kills configuration drift — the silent gap between your YAML files and reality. With self-heal on, drift survives ~3 minutes, then the caretaker fixes it. Your git log becomes your deploy log — audit for free.
Real teams typically use both: CI tests & builds the image, then commits the new image tag into the manifest repo — and ArgoCD does all the actual deploying. The pipeline never touches the cluster.

🔧 How (in this repo)

Push style — already wired: .circleci/config.yml runs test-node + test-python in parallel → build-and-push (both images → ECR, tagged with the git SHA) → hold-for-approval → deploy-to-eks (kubectl apply + rollout status, lesson 11's gate). Note the least-privilege detail: test jobs get no AWS credentials; only the AWS-touching jobs receive the shared credentials context.

Pull style — this lesson adds it: argocd-app.yaml tells ArgoCD: "watch the k8s/ folder of this repo's main branch, keep namespace school matching it, prune deleted things, and self-heal drift."

spec:
  source:
    repoURL: https://github.com/BaluRaut/learn-kubernetes-school.git
    targetRevision: main
    path: k8s                    # 📖 the master plan pages
  syncPolicy:
    automated:
      prune: true                # deleted from git → deleted from cluster
      selfHeal: true             # hand-edits get reverted. The book wins.

🧪 Try it (all local, ~15 min)

# 1) Install the caretaker robot into your local cluster:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2) Open its UI:
kubectl -n argocd port-forward svc/argocd-server 8080:443 &
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d; echo   # login: admin + this password
# browse https://localhost:8080

# 3) Fork this repo on GitHub, then edit argocd-app.yaml's repoURL to YOUR fork,
#    and in k8s/deployment.yaml replace IMAGE_PLACEHOLDER with a real image
#    (e.g. nginxdemos/hello:plain-text) — commit & push to your fork.

# 4) Hand ArgoCD the plan book:
kubectl apply -f lessons/14-deploy-gitops/argocd-app.yaml
# watch the UI: it clones your repo, shows a diff, and syncs the school into being 🎉

# 5) Feel GitOps — deploy WITHOUT kubectl:
#    edit k8s/deployment.yaml in your fork: replicas: 2 → 3, push...
#    ...and watch a third pod appear on its own within ~3 minutes.

# 6) Feel self-heal — try to cause drift by hand:
kubectl -n school scale deployment school-api --replicas=5
kubectl -n school get pods -w    # the caretaker puts it back to 3. The book wins. 🤖

🔧 kubectl for this lesson

kubectl get applications -n argocd · argocd app sync

🔗 Builds on: 🍱 Docker L12 (CI builds & pushes) · 🤖 ArgoCD school (all 12 lessons)

✅ Verify — what you should see

push a manifest change → ArgoCD shows OutOfSync then Synced; kubectl scale by hand → it snaps back.

🧹 Clean up

kubectl delete namespace argocd when done locally

⚠️ Common mistakes

expecting this lesson to teach all of ArgoCD — it is intentionally introductory; the ArgoCD school goes deep
CI applying manifests AND ArgoCD syncing them — two robots fighting

🎓 The end — for real this time

Push pipelines, pull reconcilers, and everything from lunchboxes to the control plane in between. You now understand not just what runs your app, but what deploys it and keeps it honest. One last bonus: making it survive a building fire and exam-results day.

git checkout lesson-15-multi-az-scaling   # multi-AZ + the scaling ladder 🏫🏫

← Previousunder the hood Next →multi az scaling

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