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

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

📮 धडा 12 — CI ते cloud: courier प्रती ठेवतो

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 — शेवटचा धडा! · मागे: lesson-11-push-pull-lifecycle

🔗 पुढे: Kubernetes ही image ECR वरून pull करते — Kubernetes शाळेचा धडा 01 नेमका इथून सुरू होतो जिथे हा संपतो.

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

सगळे 12 धडे — संपूर्ण कोर्स. शेवटचा भाग: धडे 1–11 प्रत्येक push वर करणाऱ्या robot कडे सोपवणे, सोबत scan report, आणि उरलेल्या trilogy कडे baton देणे.

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

काल तुम्ही हाताने काय केले ते पाहा: build 🍱 → पूर्ण पत्त्याचे लेबल 🏷️ → दिवसाचा पास 🎫 → push 📦. चार commands, प्रत्येक deploy ला, कायम? नाही. हे काम courier robot 📮 (CI) चे आहे:

प्रत्येक git push वर robot:

गृहपाठ तपासतो ✅ — tests चालवतो. खराब कोड कधीच डब्यात जात नाही.
डबा भाजतो 🍱 — docker build, धडा 02 मुळे cache-जलद.
त्यावर commit च्या ठशाचे लेबल लावतो 🏷️ — tag म्हणजेच git SHA (hello-school:abc123), म्हणजे कप्प्यावरचा प्रत्येक डबा "हा कोणता कोड आहे?" याचे उत्तर नावानेच देतो. (आणि IMMUTABLE tags मुळे त्याबद्दल कोणीही कधीच खोटे बोलू शकत नाही.)
स्वतःचा दिवसाचा पास घेऊन डबा ठेवतो 🎫📦 — प्रत्येक run ला ताजा ECR login, push, झाले.
बँक डब्याचा X-ray काढते 🛡️ — scan-on-push तुमच्या थरांतल्या माहीत असलेल्या vulnerabilities (CVEs) ची यादी करते. लहान alpine images (धडा 07/08) हा report आनंददायकपणे छोटा ठेवतात.

k8s कोर्सची CircleCI pipeline तिच्या दोन services साठी नेमके हेच करते — ती file तुम्ही आता सहज वाचू शकता. 🎓

🗺️ आकृती

flowchart LR
    dev["🧑‍💻 git push"]
    subgraph ci["📮 CI - the courier robot"]
        t["✅ test"] --> b["🍱 build"] --> tag["🏷️ tag = commit SHA"] --> p["🎫 login + push"]
    end
    subgraph ecr["🏦 ECR"]
        box["📦 hello-school:abc123"]
        scan["🛡️ scan on push"]
    end
    k8s["☸️ k8s course:<br/>Deployments RUN it"]
    argo["🤖 ArgoCD course:<br/>git deploys it, forever"]
    dev -->|"1"| ci -->|"2"| ecr
    ecr -->|"3 pulled by cluster"| k8s
    ecr -.->|"4 address committed to git"| argo

❓ काय (GitHub Actions चे खरे उदाहरण)

# .github/workflows/ship.yml — illustrative; store AWS creds as CI secrets
on: { push: { branches: [main] } }
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app app/                     # 🍱 (tests would run first)
      - uses: aws-actions/configure-aws-credentials@v4
        with: { aws-region: ap-south-1,
                role-to-assume: arn:aws:iam::ACCOUNT:role/ci-ecr-push }  # 🪪 no long-lived keys
      - run: |
          REPO=ACCOUNT.dkr.ecr.ap-south-1.amazonaws.com/hello-school
          aws ecr get-login-password | docker login --username AWS --password-stdin "$REPO"  # 🎫
          docker tag app "$REPO:${GITHUB_SHA::7}"          # 🏷️ tag = commit
          docker push "$REPO:${GITHUB_SHA::7}"             # 📦

Tag = commit SHA हा सगळा भार पेलणारा संकेत आहे: त्यामुळे deploys traceable होतात (k8s कोर्स) आणि GitOps commits ना अर्थ येतो (ArgoCD कोर्स).
OIDC role assumption (role-to-assume) CI मध्ये AWS keys साठवण्यापेक्षा सरस आहे — दिवसाच्या पासाचे आधुनिक रूप.

🧠 कळसाध्याय — संपूर्ण pipeline एका चित्रात

Developer
    │  git push
    ▼
CI  ── test ── docker build ── scan ── tag (commit SHA) ── push
                                                            │
                                                            ▼
                                                          ECR
                                                            │  image pull (IAM role)
                                                            ▼
                                                      Kubernetes
                                                            │  desired state from git
                                                            ▼
                                                        ArgoCD

Docker artifact बनवते. ECR artifact साठवते. Kubernetes artifact चालवते. ArgoCD deployment सांभाळते.

🎓 पदवी परीक्षा — हे समजावता येते का?

एक developer कोड Git वर push करते. CI Docker image build करते, ती scan करते आणि ECR वर push करते. नंतर Kubernetes ती image pull करून चालवते. ArgoCD Kubernetes ची configuration Git शी जुळते याची खात्री करते.

Source code कुठे आहे?
Image कोण बनवते?
Image च्या आत काय आहे?
Image कुठे साठवली जाते?
नेमकी image कशाने ओळखली जाते?
ECR वर push करण्याची परवानगी कोणाला आहे?
ECR वरून pull करण्याची परवानगी कोणाला आहे?
Container प्रत्यक्षात कोण चालवते?
Image tag बदलला तर काय होते?
ArgoCD कुठे बसते?

प्रत्येक उत्तर एका वाक्यात देता आले, तर तुमची ही शाळा पूर्ण झाली.

🤔 का

हाताने पाठवण्याला हाताने deploy करण्यासारखाच आजार आहे (ArgoCD कोर्स, धडा 01): ते माणसाच्या लक्षात राहण्यावर अवलंबून असते. Robot प्रत्येक image tested, labeled, scanned आणि जागेवर ठेवलेली करतो — अगदी तशीच, कायम. तुमचे काम फक्त कोड लिहिणे आणि scan reports वाचणे एवढेच उरते.

🧪 करून पाहा

# read a real scan report from your lesson-11 push:
aws ecr describe-image-scan-findings --repository-name hello-school \
  --image-id imageTag=v1 --query 'imageScanFindings.findingSeverityCounts'
# alpine base → usually a very short list 🪶

# cleanup when done playing (stop the pennies):
# terraform -chdir=ecr destroy     # or:
# aws ecr delete-repository --repository-name hello-school --force

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

CI images ना commit SHA ऐवजी latest tag देणे — deploys पुन्हा तसेच करता येत नाहीत
CI ने दीर्घकाळ टिकणाऱ्या AWS keys ने push करणे — त्याऐवजी OIDC → role
"वेगासाठी" scan ची पायरी वगळणे — काही सेकंद घेणारी आणि incidents वाचवणारी हीच ती एक पायरी

🎓 Trilogy — तुम्ही आता कुठे आहात

तुम्ही 3 पैकी कोर्स 1 पूर्ण केला: तुमचा कोड आपोआप tested, छोटी, labeled, scanned image बनून खाजगी registry मध्ये बसतो. पुढे:

☸️ Learn Kubernetes School — cluster तुमच्या images चालवतो: pods, services, autoscaling, rollouts.
🤖 Learn ArgoCD School — git त्या deploy करते: काळजी घेणारा robot, self-heal, 10 सेकंदांचे rollbacks.

पॅक करा. चालवा. कायम पाठवत राहा. 🍱☸️🤖

git checkout main

📮 Lesson 12 — CI to cloud: the courier files the copies

📍 You are here: Lesson 12 of 12 — the final lesson! · Previous: lesson-11-push-pull-lifecycle

🔗 Next: Kubernetes pulls this image from ECR — the Kubernetes school's lesson 01 starts exactly where this one ends.

📦 What's in this branch

All 12 lessons — the complete course. The finale: handing lessons 1–11 to a robot that does them on every push, plus the scan report, plus the baton pass to the rest of the trilogy.

🧒 Explain like I'm 5

Look at what you did by hand yesterday: build 🍱 → label with the full address 🏷️ → get the day pass 🎫 → push 📦. Four commands, every deploy, forever? No. That's a job for the courier robot 📮 (CI):

On every git push, the robot:

Checks the homework ✅ — runs the tests. Bad code never gets boxed.
Bakes the box 🍱 — docker build, cache-fast thanks to lesson 02.
Labels it with the commit's fingerprint 🏷️ — the tag IS the git SHA (hello-school:abc123), so every box on the shelf answers "which code is this?" by name. (And IMMUTABLE tags mean nobody can ever lie about it.)
Gets its own day pass and files the box 🎫📦 — fresh ECR login each run, push, done.
The bank X-rays the box 🛡️ — scan-on-push lists known vulnerabilities (CVEs) in your layers. Small alpine images (lesson 07/08) keep this report blissfully short.

This is exactly what the k8s course's CircleCI pipeline does for its two services — you can now read that file fluently. 🎓

🗺️ Diagram

flowchart LR
    dev["🧑‍💻 git push"]
    subgraph ci["📮 CI - the courier robot"]
        t["✅ test"] --> b["🍱 build"] --> tag["🏷️ tag = commit SHA"] --> p["🎫 login + push"]
    end
    subgraph ecr["🏦 ECR"]
        box["📦 hello-school:abc123"]
        scan["🛡️ scan on push"]
    end
    k8s["☸️ k8s course:<br/>Deployments RUN it"]
    argo["🤖 ArgoCD course:<br/>git deploys it, forever"]
    dev -->|"1"| ci -->|"2"| ecr
    ecr -->|"3 pulled by cluster"| k8s
    ecr -.->|"4 address committed to git"| argo

❓ What (a real GitHub Actions example)

# .github/workflows/ship.yml — illustrative; store AWS creds as CI secrets
on: { push: { branches: [main] } }
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app app/                     # 🍱 (tests would run first)
      - uses: aws-actions/configure-aws-credentials@v4
        with: { aws-region: ap-south-1,
                role-to-assume: arn:aws:iam::ACCOUNT:role/ci-ecr-push }  # 🪪 no long-lived keys
      - run: |
          REPO=ACCOUNT.dkr.ecr.ap-south-1.amazonaws.com/hello-school
          aws ecr get-login-password | docker login --username AWS --password-stdin "$REPO"  # 🎫
          docker tag app "$REPO:${GITHUB_SHA::7}"          # 🏷️ tag = commit
          docker push "$REPO:${GITHUB_SHA::7}"             # 📦

Tag = commit SHA is the load-bearing convention: it makes deploys traceable (k8s course) and GitOps commits meaningful (ArgoCD course).
OIDC role assumption (role-to-assume) beats storing AWS keys in CI — the modern version of the day pass.

🧠 The capstone — the whole pipeline in one picture

Developer
    │  git push
    ▼
CI  ── test ── docker build ── scan ── tag (commit SHA) ── push
                                                            │
                                                            ▼
                                                          ECR
                                                            │  image pull (IAM role)
                                                            ▼
                                                      Kubernetes
                                                            │  desired state from git
                                                            ▼
                                                        ArgoCD

Docker builds the artifact. ECR stores the artifact. Kubernetes runs the artifact. ArgoCD manages the deployment.

🎓 Graduation test — can you explain this?

A developer pushes code to Git. CI builds a Docker image, scans it and pushes it to ECR. Kubernetes later pulls that image and runs it. ArgoCD makes sure the Kubernetes configuration matches Git.

Where is the source code?
What creates the image?
What is inside the image?
Where is the image stored?
What identifies an exact image?
Who is allowed to push to ECR?
Who is allowed to pull from ECR?
Who actually runs the container?
What happens if the image tag changes?
Where does ArgoCD fit?

If every answer comes out in one sentence, you are done with this school.

🤔 Why

Manual shipping has the same disease as manual deploying (ArgoCD course, lesson 01): it depends on a human remembering. The robot makes every image tested, labeled, scanned, and filed — identically, forever. Your job shrinks to writing code and reading scan reports.

🧪 Try it

# read a real scan report from your lesson-11 push:
aws ecr describe-image-scan-findings --repository-name hello-school \
  --image-id imageTag=v1 --query 'imageScanFindings.findingSeverityCounts'
# alpine base → usually a very short list 🪶

# cleanup when done playing (stop the pennies):
# terraform -chdir=ecr destroy     # or:
# aws ecr delete-repository --repository-name hello-school --force

⚠️ Common mistakes

tagging CI images latest instead of the commit SHA — deploys become unreproducible
CI pushing with long-lived AWS keys — OIDC → role instead
skipping the scan step "for speed" — the one step that costs seconds and saves incidents

🎓 The trilogy — where you are now

You've completed course 1 of 3: your code becomes a tested, tiny, labeled, scanned image sitting in a private registry, automatically. Next:

☸️ Learn Kubernetes School — a cluster RUNS your images: pods, services, autoscaling, rollouts.
🤖 Learn ArgoCD School — git DEPLOYS them: the caretaker robot, self-heal, 10-second rollbacks.

Pack it. Run it. Ship it forever. 🍱☸️🤖

git checkout main

← Previouspush pull lifecycle Finished! Take the quiz →check what stuck

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