🧹 धडा 11 — Push, pull आणि lifecycle: डबे ठेवणे आणि सफाई कर्मचारी

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागे: lesson-10-ecr-setup · पुढे: lesson-12-ci-to-cloud

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

धडे 01–10, आणि त्याशिवाय: ECR चा रोजचा workflow — पूर्ण पत्त्याने tag करा, push करा, pull करा — आणि तुमचा locker जुन्या पुराण्या जेवणाने भरू न देणारी lifecycle policy. खरी file:

ecr/lifecycle-policy.json — "सर्वात नवे 10 ठेवा, बाकीचे फेकून द्या"

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

बँकेत डबा ठेवण्याचा एक नियम आहे ज्यावर लोक नेहमी अडखळतात: लेबलवर पूर्ण पत्ता असायलाच हवा 🏷️. फक्त hello-school:v1 लेबल असलेला डबा बँक स्वीकारत नाही — कोणती बँक? कोणती शाखा? कोणता locker? लेबलवर असे लिहिलेले हवे:

123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-school:v1 (बँक · शाखा · locker · डब्याचे नाव)

docker tag नेमके हेच करते — ते काहीही copy करत नाही, फक्त त्याच डब्यावर दुसरे, पूर्ण पत्ता असलेले लेबल लिहिते. मग docker push ते लेबल वाचतो आणि नेमके कुठे पोहोचवायचे ते त्याला कळते.

आणि सफाई कर्मचारी 🧹: प्रत्येक push एक डबा जोडतो, कायमचा. वर्षभर रोज deploys = बहुतेक ममी झालेल्या जेवणाचे 365 डबे, आणि बँक कप्प्याच्या प्रत्येक सेंटीमीटरचे पैसे घेते. lifecycle policy म्हणजे सफाई कर्मचाऱ्याला दिलेल्या कायमच्या सूचना: "सर्वात नवे 10 डबे ठेवा; बाकीचे शांतपणे expire करा." एकदा सेट करा, कायम नीटनेटके.

🗺️ आकृती

flowchart LR
    tag["🏷️ full-address label<br/>docker tag hello-school:v1<br/>ACCOUNT.dkr.ecr.REGION…/hello-school:v1"]
    subgraph ecr["🏦 ECR locker"]
        v3["📦 v3 - newest"]
        v2["📦 v2"]
        old["📦 v-old… expired 🧹"]
    end
    eks["☸️ EKS deployment<br/>image: ACCOUNT.dkr…/hello-school:v3"]
    jan["🧹 lifecycle policy<br/>keep newest 10"]
    tag -->|"1 docker push"| ecr
    ecr -->|"2 pulled at deploy"| eks
    jan -.->|"3 tidies automatically"| old

❓ काय

docker tag SOURCE FULL_ADDRESS:TAG — तोच image ID, नवे पूर्ण नाव. Push कुठे करायचा ते नावातच लिहिलेले असते — हीच सगळी युक्ती.
Pushes थरांबाबत हुशार असतात: ECR कडे नसलेले थरच जातात (धडा 02 आणि धडा 07 चे फळ मिळते: लहान थर = 2 सेकंदांचे pushes).
EKS मधून pull करणे: k8s कोर्सच्या deployment.yaml मधला IMAGE_PLACEHOLDER नेमक्या याच पत्त्याने बदलला जातो — nodes आपल्या IAM role ने pull करतात, cluster वर docker login ची गरज नाही.
Lifecycle rules संख्येनुसार किंवा वयानुसार जुळतात, आणि tag prefixes सुरक्षित ठेवू शकतात (उदा. release-* नेहमी ठेवा). Git मधले JSON → ecr/ecr.tf ने लागू — सफाई कर्मचाऱ्याच्या कराराचा code-review होतो.

🧠 Tag विरुद्ध digest — आणि lifecycle policy चे एक उदाहरण

tag     =  human-friendly name        my-app:v42        (mutable — can be re-pointed)
digest  =  content identity           sha256:abc123…    (immutable — the exact bytes)

my-app:v42  ──resolves today to──▶  sha256:abc123…

Production deployments अनेकदा digest pin करतात (किंवा immutable tags वापरतात) कारण तुम्ही test केल्यानंतर tag वेगळ्या content कडे हलवला जाऊ शकतो; digest नाही. म्हणूनच Kubernetes image: repo@sha256:… स्वीकारते.

ECR मध्ये default सफाई कर्मचारी नाही. Lifecycle policy तुम्ही लिहायची असते — उदाहरणार्थ: "सर्वात नव्या 10 tagged images ठेवा; untagged images 7 दिवसांनंतर expire करा." तुमच्या rollback च्या गरजांना जुळणारे आकडे निवडा.

🤔 का

हा धडा म्हणजेच deploy चा मार्ग: भाग 1 ने बांधलेले सगळे इथे cluster ला उपलब्ध होते. आणि सफाई कर्मचारी दिसतो त्यापेक्षा जास्त महत्त्वाचा आहे: मर्यादा नसलेल्या registries ला खरे पैसे लागतात, scans हळू होतात, आणि कोणत्या images खरोखर महत्त्वाच्या आहेत ते लपते. "सर्वात नवे 10 + सुरक्षित releases" हा कंटाळवाणा, पण योग्य default आहे.

🧪 करून पाहा

REPO=$(aws ecr describe-repositories --repository-names hello-school \
  --query 'repositories[0].repositoryUri' --output text)     # your locker address

# 1) file a box: full-address label → push
docker tag hello-school:v1 "$REPO:v1"
docker push "$REPO:v1"                       # watch layers upload (then re-push: instant)

# 2) prove it's really there — pull it back as a stranger would:
docker rmi "$REPO:v1"
docker pull "$REPO:v1" && echo "round trip complete 🎉"

# 3) test IMMUTABLE tags (lesson 10's promise):
docker push "$REPO:v1" 2>&1 | tail -1        # rejected? no — identical bytes are fine.
# now change the app, rebuild, and try to REUSE v1:
echo "// changed" >> app/server.js && docker build -t "$REPO:v1" app/ && git checkout app/server.js
docker push "$REPO:v1" 2>&1 | tail -1        # ❌ "tag invalid: The image tag 'v1' already exists"

# 4) read the janitor's contract:
aws ecr get-lifecycle-policy --repository-name hello-school --query lifecyclePolicyText --output text

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

tag ला हमी समजणे — फक्त digest नेमका content ओळखतो
ECR आपोआप साफसफाई करते असे गृहीत धरणे — lifecycle policy लिहा (आणि बिल वाचा)
production सध्या ज्यावर चालू आहे ती image expire करणारी आक्रमक policy

⏭️ पुढे

तुम्ही आत्ता tag → login → push हाताने केले. शेवटचा धडा हे संपूर्ण काम एका robot कडे सोपवतो — आणि पुढच्या दोन कोर्सकडे baton देतो.

git checkout lesson-12-ci-to-cloud

🧹 Lesson 11 — Push, pull & lifecycle: filing boxes and the janitor

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-ecr-setup · Next: lesson-12-ci-to-cloud

📦 What's in this branch

Lessons 01–10, plus: the daily ECR workflow — tag with the full address, push, pull — and the lifecycle policy that stops your locker from filling up with ancient lunches. Real file:

ecr/lifecycle-policy.json — "keep the newest 10, toss the rest"

🧒 Explain like I'm 5

Filing a box at the bank has one rule people always trip on: the label must carry the FULL address 🏷️. The bank won't accept a box labeled just hello-school:v1 — which bank? which branch? which locker? The label must say:

123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-school:v1 (bank · branch · locker · box name)

That's what docker tag does — it doesn't copy anything, it just writes a second, fully-addressed label on the same box. Then docker push reads the label and knows exactly where to deliver.

And the janitor 🧹: every push adds a box, forever. A year of daily deploys = 365 boxes of mostly-mummified lunch, and the bank charges by the shelf-centimeter. The lifecycle policy is standing instructions to the janitor: "keep the newest 10 boxes; quietly expire the rest." Set once, tidy forever.

🗺️ Diagram

flowchart LR
    tag["🏷️ full-address label<br/>docker tag hello-school:v1<br/>ACCOUNT.dkr.ecr.REGION…/hello-school:v1"]
    subgraph ecr["🏦 ECR locker"]
        v3["📦 v3 - newest"]
        v2["📦 v2"]
        old["📦 v-old… expired 🧹"]
    end
    eks["☸️ EKS deployment<br/>image: ACCOUNT.dkr…/hello-school:v3"]
    jan["🧹 lifecycle policy<br/>keep newest 10"]
    tag -->|"1 docker push"| ecr
    ecr -->|"2 pulled at deploy"| eks
    jan -.->|"3 tidies automatically"| old

❓ What

docker tag SOURCE FULL_ADDRESS:TAG — same image ID, new fully-qualified name. Push destination is encoded in the name — that's the whole trick.
Pushes are layer-smart: only layers ECR doesn't have travel (lesson 02 and lesson 07 pay off: small layers = 2-second pushes).
Pulling from EKS: the k8s course's deployment.yaml gets its IMAGE_PLACEHOLDER replaced with exactly this address — nodes pull with their IAM role, no docker login needed on the cluster.
Lifecycle rules match by count or age, and can protect tag prefixes (e.g. always keep release-*). JSON in git → applied by ecr/ecr.tf — the janitor's contract is code-reviewed.

🧠 Tag vs digest — and an example lifecycle policy

tag     =  human-friendly name        my-app:v42        (mutable — can be re-pointed)
digest  =  content identity           sha256:abc123…    (immutable — the exact bytes)

my-app:v42  ──resolves today to──▶  sha256:abc123…

Production deployments often pin the digest (or use immutable tags) because a tag can be moved to different content after you tested it; a digest cannot. Kubernetes accepts image: repo@sha256:… for exactly this.

ECR has no default janitor. A lifecycle policy is something you write — for example: "keep the newest 10 tagged images; expire untagged images after 7 days." Pick numbers that match your rollback needs.

🤔 Why

This lesson IS the deploy path: everything Part 1 built becomes available to the cluster here. And the janitor matters more than it looks: unbounded registries cost real money, slow scans, and hide which images actually matter. "Newest 10 + protected releases" is the boring, correct default.

🧪 Try it

REPO=$(aws ecr describe-repositories --repository-names hello-school \
  --query 'repositories[0].repositoryUri' --output text)     # your locker address

# 1) file a box: full-address label → push
docker tag hello-school:v1 "$REPO:v1"
docker push "$REPO:v1"                       # watch layers upload (then re-push: instant)

# 2) prove it's really there — pull it back as a stranger would:
docker rmi "$REPO:v1"
docker pull "$REPO:v1" && echo "round trip complete 🎉"

# 3) test IMMUTABLE tags (lesson 10's promise):
docker push "$REPO:v1" 2>&1 | tail -1        # rejected? no — identical bytes are fine.
# now change the app, rebuild, and try to REUSE v1:
echo "// changed" >> app/server.js && docker build -t "$REPO:v1" app/ && git checkout app/server.js
docker push "$REPO:v1" 2>&1 | tail -1        # ❌ "tag invalid: The image tag 'v1' already exists"

# 4) read the janitor's contract:
aws ecr get-lifecycle-policy --repository-name hello-school --query lifecyclePolicyText --output text

⚠️ Common mistakes

treating a tag as a guarantee — only a digest identifies exact content
assuming ECR cleans up by itself — write the lifecycle policy (and read the bill)
an aggressive policy that expires the image production is currently running on

⏭️ Next

You just did tag → login → push by hand. The final lesson hands the whole routine to a robot — and passes the baton to the next two courses.

git checkout lesson-12-ci-to-cloud

← Previousecr setup Next →ci to cloud

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