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

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

📮 धडा 03 — CI/CD push: courier robot तुमच्यासाठी deploy करतो

📍 तुम्ही इथे आहात: 12 पैकी धडा 03 · मागे: lesson-02-drift-problem · पुढे: lesson-04-limits-of-push

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

धडे 01–02, आणि त्यासोबत पहिला खरा उपाय: प्रत्येक push वर test, build आणि deploy करणारी CI/CD pipeline — म्हणजे push model, ज्यात बाहेरची एखादी system बदल जोराने cluster मध्ये ढकलते.

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

मुले हाताने गृहपाठ पोहोचवतात याला शाळा कंटाळली, म्हणून तिने एक courier robot 📮 कामावर ठेवला. आता तुम्ही फक्त तुमचा गृहपाठ टपालपेटीत टाकता (git push) आणि robot दर वेळी अगदी त्याच पायऱ्या करतो:

तपासतो ✅ — शुद्धलेखन आणि गणित (tests चालवतो). वाईट गृहपाठ कधीच टपालखोलीतून बाहेर पडत नाही.
झेरॉक्स काढतो 🍱 — अधिकृत प्रत (container image build करतो).
प्रत जपून ठेवतो 🗄️ — कपाटात (registry ला push करतो).
पोहोचवतो 🚚 — गाडी चालवत शाळेत जातो, स्वतःकडच्या deployment credentials 🔑 ने दार उघडतो (सगळ्यात वाईट म्हणजे साठवलेले kubeconfig, सगळ्यात चांगले म्हणजे थोड्या काळासाठीचा OIDC badge), आणि सगळे जागेवर लावतो (kubectl apply).

खूप मोठी सुधारणा! आता विसरलेल्या पायऱ्या नाहीत, "माझ्या machine वर चालते" नाही, आणि टपालखोलीत पोहोचवण्याची नोंदवही आहे. पण त्या credentials वर लक्ष ठेवा — आणि robot निघून गेल्यावर नंतर काय होते त्यावरही… (धडा 04 😈)

🗺️ आकृती

flowchart LR
    dev["🧑‍💻 dev<br/>git push"]
    subgraph ci["📮 the courier robot - CI/CD"]
        t["✅ test"] --> b["🍱 build image"] --> r["🗄️ registry"]
    end
    cluster["🏫 cluster<br/>kubectl apply from OUTSIDE<br/>with deployment credentials 🔑"]
    dev -->|"1"| ci
    r -->|"3 PUSH deploy"| cluster
    t -.->|"2 bad code stops here"| dev

❓ काय

CI (Continuous Integration): प्रत्येक push आपोआप test आणि build होतो.
CD (Continuous Delivery/Deployment): build झालेले artifact आपोआप release होते. दोन्ही मिळून: आता कोणीच हाताने deploy करत नाही.
Push model: बाहेरून cluster पर्यंत पोहोचण्यासाठी pipeline ला deployment credentials लागतात — सगळ्यात साध्या setup मध्ये CI secret म्हणून साठवलेले kubeconfig, किंवा OIDC द्वारे मिळवलेले थोड्या काळाचे credentials (CI/CD शाळा कोणत्याही साठवलेल्या keys शिवाय OIDC शिकवते; Docker शाळेचा धडा 12 ते ECR साठी दाखवतो, आणि हीच कल्पना EKS साठीही चालते). कसेही असले तरी, बाहेरची system बदल आत ढकलते.
नेमके हेच Kubernetes कोर्सची CircleCI pipeline करते: test → build → ECR ला push → manual approval → kubectl apply.

🤔 का

Pipeline धडा 01 मधल्या माणसांच्या समस्या सोडवते: विसरलेल्या पायऱ्या, वगळलेल्या tests, एकाच व्यक्तीकडचे ज्ञान, पोहोचवण्याची नोंद नसणे. प्रत्येक deploy आता एखाद्या commit पर्यंत मागोवा घेता येतो आणि पुन्हा करता येतो. एवढेच ही एक प्रचंड, खरी सुधारणा आहे — बहुतेक teams नी ArgoCD चा विचार करण्याआधी इथपर्यंत पोहोचायला हवे.

🔧 कसे (एक छोटे उदाहरण)

GitHub Actions मधला push-style deploy job असा दिसतो (फक्त उदाहरणासाठी — खरे cluster credentials commit करू नका, CI secrets वापरा):

# .github/workflows/deploy.yml (example — the k8s course uses CircleCI, same idea)
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "$KUBECONFIG_DATA" | base64 -d > kubeconfig   # 🔑 deployment credentials — here a stored kubeconfig; see the OIDC note
        env: { KUBECONFIG_DATA: ${{ secrets.KUBECONFIG_DATA }} }
      - run: KUBECONFIG=kubeconfig kubectl apply -f k8s/        # push it in
      - run: KUBECONFIG=kubeconfig kubectl -n gitops-school rollout status deploy/hello-school

आत्ता काय झाले ते लक्षात घ्या: cluster ची key आता cluster च्या बाहेर राहते, CI system च्या secret store मध्ये. हे लक्षात ठेवा.

🪪 साठवलेली key विरुद्ध OIDC. हे उदाहरण kubeconfig CI secret म्हणून साठवते — सगळ्यात सोपा आणि सगळ्यात कमी सुरक्षित प्रकार. अधिक चांगला प्रकार म्हणजे CI/CD शाळा जे शिकवते — आणि Docker शाळेचा धडा 12 ECR साठी जे करतो: job OIDC द्वारे आपली ओळख सिद्ध करतो आणि त्याला थोड्या काळाचे credential मिळते (EKS साठी: role-to-assume नंतर aws eks update-kubeconfig). CI मध्ये दीर्घकाळ टिकणारी key बसून राहत नाही — पण pipeline ला बाहेरून आत येण्याचा कोणता तरी मार्ग लागतोच, आणि त्याचा अर्थ काय हा धडा 04 चा विषय आहे.

🧪 करून पाहा (robot चे local simulation)

# play courier robot yourself — the exact steps a pipeline runs:
kubectl diff -f k8s/ || true                          # 1. what would change?
kubectl apply -f k8s/                                 # 2. deliver
kubectl -n gitops-school rollout status deploy/hello-school   # 3. confirm it landed

# the pipeline's superpower is that it NEVER does it differently.
# your superpower is that you now know each step it automates.

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

Robot चे local simulation करताना, शेवटची command — kubectl -n gitops-school rollout status deploy/hello-school — successfully rolled out छापते. खऱ्या pipeline मध्ये: हिरवा job, आणि kubectl -n gitops-school get deploy hello-school -o jsonpath='{.spec.template.spec.containers[0].image}' नेमका त्या job ने build केलेला tag दाखवते.

🧹 साफसफाई

काहीच install झाले नाही. तुम्ही fork वर खरा workflow बनवला असेल, तर काम झाल्यावर साठवलेले kubeconfig secret delete करा — ते तुमच्या cluster चे credential आहे, अगदी local cluster असले तरी.

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

cluster-admin kubeconfig CI secrets मध्ये चिकटवणे आणि काम झाले असे मानणे — त्याची व्याप्ती मर्यादित करा, किंवा अजून चांगले, OIDC द्वारे थोड्या काळाचे credentials मिळवा (CI/CD शाळा, Docker शाळा L12)
tests fail झाल्या तरी deploy step चालू देणे (job ordering / needs:)
:latest deploy करणे — मग प्रत्यक्षात काय ship झाले ते pipeline सांगू शकत नाही

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: खऱ्या deployments पैकी बहुतेक push pipelines असतात आणि त्या हाताने deploy करण्यापेक्षा खरी सुधारणा आहेत. ArgoCD कडे वळण्याआधी त्या नीट करा — थोड्या काळाचे credentials, tag = commit SHA, फाटक म्हणून rollout status. GitOps एक reconcile loop जोडते; ते CI ची जागा घेत नाही.

⏭️ पुढे

Courier छान आहे — मग या कोर्सचा भाग 2 का आहे? कारण courier जे करू शकत नाही त्यामुळे. धडा 04 त्या त्रुटी मोजतो.

git checkout lesson-04-limits-of-push

📮 Lesson 03 — CI/CD push: the courier robot deploys for you

📍 You are here: Lesson 03 of 12 · Previous: lesson-02-drift-problem · Next: lesson-04-limits-of-push

📦 What's in this branch

Lessons 01–02, plus the first real fix: a CI/CD pipeline that tests, builds and deploys on every push — the push model, where an outside system shoves changes into the cluster.

🧒 Explain like I'm 5

The school got tired of kids hand-delivering homework, so it hired a courier robot 📮. Now you just drop your homework in the mailbox (git push) and the robot does the same steps, every single time:

Checks it ✅ — spelling and math (runs the tests). Bad homework never leaves the mailroom.
Photocopies it 🍱 — the official copy (builds the container image).
Files the copy 🗄️ — into the cabinet (pushes to the registry).
Delivers it 🚚 — drives to school, unlocks the door with the deployment credentials it carries 🔑 (a stored kubeconfig at worst, a short-lived OIDC badge at best), and puts everything in place (kubectl apply).

Huge upgrade! No more forgotten steps, no more "works on my machine", and there's a delivery log in the mailroom. But keep an eye on those credentials — and on what happens after the robot drives away… (lesson 04 😈)

🗺️ Diagram

flowchart LR
    dev["🧑‍💻 dev<br/>git push"]
    subgraph ci["📮 the courier robot - CI/CD"]
        t["✅ test"] --> b["🍱 build image"] --> r["🗄️ registry"]
    end
    cluster["🏫 cluster<br/>kubectl apply from OUTSIDE<br/>with deployment credentials 🔑"]
    dev -->|"1"| ci
    r -->|"3 PUSH deploy"| cluster
    t -.->|"2 bad code stops here"| dev

❓ What

CI (Continuous Integration): every push is automatically tested & built.
CD (Continuous Delivery/Deployment): the built artifact is automatically released. Together: nobody deploys by hand anymore.
Push model: the pipeline needs deployment credentials to reach the cluster from outside — a kubeconfig stored as a CI secret in the simplest setups, or short-lived credentials obtained via OIDC (the CI/CD school teaches OIDC with no stored keys; the Docker school's lesson 12 shows it for ECR, and the same idea works for EKS). Either way, an outside system pushes changes in.
This is exactly what the Kubernetes course's CircleCI pipeline does: test → build → push to ECR → manual approval → kubectl apply.

🤔 Why

The pipeline fixes the human problems from lesson 01: forgotten steps, skipped tests, single-person knowledge, no delivery record. Every deploy is now traceable to a commit and repeatable. This alone is a massive, genuine upgrade — most teams should get here before even thinking about ArgoCD.

🔧 How (a minimal example)

A push-style deploy job in GitHub Actions looks like this (illustrative — don't commit real cluster credentials, use CI secrets):

# .github/workflows/deploy.yml (example — the k8s course uses CircleCI, same idea)
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "$KUBECONFIG_DATA" | base64 -d > kubeconfig   # 🔑 deployment credentials — here a stored kubeconfig; see the OIDC note
        env: { KUBECONFIG_DATA: ${{ secrets.KUBECONFIG_DATA }} }
      - run: KUBECONFIG=kubeconfig kubectl apply -f k8s/        # push it in
      - run: KUBECONFIG=kubeconfig kubectl -n gitops-school rollout status deploy/hello-school

Note what just happened: the cluster's key now lives outside the cluster, in the CI system's secret store. Remember that.

🪪 Stored key vs OIDC. This example stores a kubeconfig as a CI secret — the simplest and least safe shape. The better shape is what the CI/CD school teaches — and the Docker school's lesson 12 does for ECR: the job proves who it is via OIDC and receives a short-lived credential (for EKS: aws eks update-kubeconfig after role-to-assume). No long-lived key sits in CI — but the pipeline still needs some way in from outside, and lesson 04 is about what that means.

🧪 Try it (simulate the robot locally)

# play courier robot yourself — the exact steps a pipeline runs:
kubectl diff -f k8s/ || true                          # 1. what would change?
kubectl apply -f k8s/                                 # 2. deliver
kubectl -n gitops-school rollout status deploy/hello-school   # 3. confirm it landed

# the pipeline's superpower is that it NEVER does it differently.
# your superpower is that you now know each step it automates.

✅ Verify — what you should see

Simulating the robot locally, the last command — kubectl -n gitops-school rollout status deploy/hello-school — prints successfully rolled out. In a real pipeline: a green job, and kubectl -n gitops-school get deploy hello-school -o jsonpath='{.spec.template.spec.containers[0].image}' shows exactly the tag that job built.

🧹 Clean up

Nothing was installed. If you created a real workflow on a fork, delete the stored kubeconfig secret when you are done — it is a credential to your cluster, even a local one.

⚠️ Common mistakes

pasting a cluster-admin kubeconfig into CI secrets and calling it done — scope it, or better, obtain short-lived credentials via OIDC (CI/CD school, Docker school L12)
letting the deploy step run even when tests fail (job ordering / needs:)
deploying :latest — the pipeline can no longer tell you what actually shipped

🏭 Why this matters in production: push pipelines are the majority of real deployments and a genuine upgrade over hand deploys. Do them well — short-lived credentials, tag = commit SHA, rollout status as the gate — before reaching for ArgoCD. GitOps adds a reconcile loop; it does not replace CI.

⏭️ Next

The courier is great — so why does Part 2 of this course exist? Because of what the courier can't do. Lesson 04 counts the gaps.

git checkout lesson-04-limits-of-push

← Previousdrift problem Next →limits of push

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