शाळेच्या त्रयीतील कोर्स 1 पैकी 3 — Kubernetes तुमचे ॲप चालवण्याआधी आणि ArgoCD ते deploy करण्याआधी, कोणीतरी ते पॅक करून पाठवायला हवे. तोच हा कोर्स: तुमच्या लॅपटॉपवर इमेज, Dockerfiles, compose आणि multi-stage builds, मग क्लाउडमध्ये रजिस्ट्री आणि AWS ECR.
सफाईचे नियम, scans, आणि CI ते सगळे तुमच्यासाठी करते
🎯 या कोर्सनंतर तुम्हाला जमले पाहिजे: इमेज विरुद्ध कंटेनर विरुद्ध रजिस्ट्री समजावणे · Dockerfile लिहिणे आणि सुधारणे · कंटेनर build, tag, run, inspect आणि debug करणे · ports, environment variables, volumes आणि networks वापरणे · Compose ने बहु-कंटेनर ॲप चालवणे · multi-stage builds ने छोट्या production इमेज बनवणे · मूलभूत कंटेनर सुरक्षा आणि इमेज स्वच्छता पाळणे · AWS ECR वर push/pull करणे · ECR tags आणि अपरिवर्तनीय digests यातला फरक ओळखणे · ECR lifecycle policy लिहिणे · CI इमेज कशी बांधते आणि push करते ते समजावणे · Kubernetes ती नंतर कशी pull करते ते समजावणे. मानसिक मॉडेल:source code → Dockerfile → इमेज → रजिस्ट्री/ECR → Kubernetes.
🗺️ संपूर्ण चित्र — एक आकृती, संपूर्ण प्रवास
संपूर्ण कोर्स एका कॅनव्हासवर: पॅक करा (निळा, धडे 1–8) आणि पाठवा (नारिंगी, धडे 9–12). 4K आवृत्तीसाठी क्लिक करा — एकाच संदर्भासाठी उत्तम.
स्वयंपाकघरात शिजवा, फक्त अन्न पॅक करा — छोट्या इमेज.lesson-07-multi-stageधडा वाचा →आकृती पहा ↗
8
🏷️ इमेजची स्वच्छता
सुरक्षेचा धडा: डब्यांवर लेबल लावा; किल्ल्या कधीच पॅक करू नका. 🔗 IAMlesson-08-image-hygieneधडा वाचा →आकृती पहा ↗
☁️ भाग 2 — पाठवा: रजिस्ट्री & AWS ECR (धडे 9–12)
लॅपटॉपपासून क्लाउडपर्यंतचा पूल: clusters ना pull करता याव्यात म्हणून इमेज कुठे राहतात. खरे AWS खाते वापरते (काही पैसे; सफाई दाखवली आहे).
9
🏬 रजिस्ट्री
गोठवलेल्या डब्यांचे गोदाम — एकदा push, कुठूनही pull.lesson-09-registriesधडा वाचा →आकृती पहा ↗
10
🏦 ECR setup
बँक लॉकर भाड्याने घ्या; 12 तासांचा दिवसाचा पास मिळवा. 🔗 IAM → ECRlesson-10-ecr-setupधडा वाचा →आकृती पहा ↗
11
🧹 Push, pull & lifecycle
डबे लावा; tags विरुद्ध digests; तुम्ही लिहिलेली lifecycle policy (उदाहरण: नवे दहा ठेवा).lesson-11-push-pull-lifecycleधडा वाचा →आकृती पहा ↗
12
📮 CI ते क्लाउड
कळस: कुरिअर प्रती लावतो — आणि k8s & ArgoCD कडे सोपवतो. 🔗 पुढे: Kuberneteslesson-12-ci-to-cloudधडा वाचा →आकृती पहा ↗
# take the course locally (just Docker Desktop for Part 1):
git clone https://github.com/BaluRaut/learn-docker-school.git
cd learn-docker-school
git checkout lesson-01-why-containers # then open lessons/01-why-containers/README.md
प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत, एकामागून एक — इथेच वाचता येईल (निळा = Docker, नारिंगी = ECR). स्वतंत्र पानावरही, उडी-मारण्याच्या दुव्यांसह.
1 🍱 कंटेनर का — "माझ्या मशीनवर चालते" चा शेवट
ॲप त्याला लागणाऱ्या सगळ्यासह पॅक करा; तीच इमेज प्रत्येक मशीनवर सुसंगत application environment देते.
🧒 सोप्या शब्दांत
घरी केलेला पदार्थ छान होतो, पण मित्राच्या घरी शेगडी आणि मसाले वेगळे असल्याने तो बिघडतो. ॲपचेही तसेच आहे: ते तुमच्या laptop वर node 20 सोबत चालले, पण node 14 असलेल्या laptop वर crash झाले. Container म्हणजे डबा: ॲप आणि त्याला लागणारे सगळे एकत्र पॅक केलेले, म्हणून Docker असलेल्या प्रत्येक मशीनवर ते सारखेच चालते.
📖 नवे शब्दcontainer — चालू असलेला डबा: तुमचे ॲप आणि त्याला लागणारे सगळे, एकत्र बंद केलेलेimage — पॅक करून ठेवलेला डबा; प्रत्येक container एका image मधून सुरू होतोkernel — संगणकाच्या operating system चा गाभा; containers मशीनचा एकच kernel वाटून घेतातVM — स्वतःचे OS असलेला पूर्ण नकली संगणक: खूप मोठा (~2 GB) आणि सुरू व्हायला हळू
⏪ आधी
Unpacked ॲप तुमच्या laptop वर चालायचे, पण सहकाऱ्याच्या laptop वर crash व्हायचे: node 14, libs नाहीत, PATH चुकीचा.
💡 काय
कंटेनर म्हणजे डबा: तुमचे ॲप node 20, libs, config आणि छोट्या Linux सोबत एकत्र पॅक केलेले.
⚙️ कसे
एका image मध्ये ॲपला लागणारे सगळे असते आणि ते host चा kernel वाटून घेते, म्हणून ते ~50 MB असते आणि 1 s च्या आत सुरू होते.
🎯 का
तीच image Docker असलेल्या प्रत्येक मशीनवर सारखीच चालते, म्हणून "माझ्या मशीनवर चालते" ही सबब संपते.
🚀 पुढे
पुढे आपण पाहू की image कशापासून बनते: Dockerfile मधून बनलेले थर, जे cache मधून पुन्हा वापरले जातात.
🧪 Try it here — न बांधलेले ॲप, मग डबा, तीन मशीनवर पाठवा
Dockerfile ची प्रत्येक ओळ एक लेयर बनवते; न बदललेले लेयर cache मधून पुन्हा वापरले जातात.
🧒 सोप्या शब्दांत
केक खालून वर, एक-एक थर करून बनतो. Docker image सुद्धा तशीच बनते: Dockerfile ची प्रत्येक ओळ एक थर जोडते. पुन्हा build करताना Docker न बदललेले थर तसेच वापरतो आणि फक्त बदललेला थर व त्यावरचे थर पुन्हा बनवतो, म्हणून कोडमधला छोटा बदल मिनिटांत नाही, सेकंदांत होतो.
📖 नवे शब्दlayer — image चा एक थर, ज्यात फक्त Dockerfile च्या एका ओळीने केलेला बदल असतोcache — मागच्या वेळचे जपून ठेवलेले थर, म्हणजे Docker ला ते पुन्हा बनवावे लागत नाहीतbase image — ज्यापासून सुरुवात करता तो सर्वात खालचा थर, उदा. node:20-alpine (~50 MB)
⏪ आधी
थर नसते तर कोडमधील प्रत्येक छोट्या बदलासाठी संपूर्ण image पुन्हा सुरुवातीपासून बांधावी आणि साठवावी लागली असती.
💡 काय
Image म्हणजे थरांचा केक: Dockerfile ची प्रत्येक ओळ एक थर बनवते, जो फक्त स्वतःचा बदल साठवतो.
⚙️ कसे
पुन्हा build करताना न बदललेले थर cache मधून येतात; बदललेला थर आणि त्यावरचा प्रत्येक थर पुन्हा बांधला जातो.
🎯 का
ओळी क्वचित बदलणाऱ्यापासून वारंवार बदलणाऱ्याकडे लावल्या की rebuild मिनिटांऐवजी काही सेकंदांत होतो.
🚀 पुढे
वाटलेले थर पुढे push आणि pull ही जलद करतात: node:20-alpine वरच्या दहा images ते 50 MB एकदाच साठवतात.
🧪 Try it here — एक ओळ बदला आणि पुन्हा build करा — कोणते थर cache मधून येतात ते पहा
या सूचना तुम्हाला भेटणाऱ्या बहुतेक Dockerfiles व्यापतात — RUN build वेळी घडते, CMD सुरू होताना, आणि EXPOSE काहीही publish करत नाही.
🧒 सोप्या शब्दांत
कृती-पत्रिकेवर पायऱ्या क्रमाने असतात: भांडे घ्या, तांदूळ घाला, शिजवा. Dockerfile ही image बनवण्यासाठी Docker ची कृती-पत्रिका आहे. काही ओळी स्वयंपाक करतानाच घडतात (build वेळी, उदा. COPY), तर काही डबा उघडल्यावरच (run वेळी, उदा. CMD). EXPOSE ही फक्त "ॲप 3000 वर ऐकते" अशी नोंद आहे; ती काहीच उघडत नाही.
📖 नवे शब्दDockerfile — image बनवण्यासाठी Docker ज्या पायऱ्या पाळतो त्यांची text fileFROM — ज्या तयार डब्यापासून सुरुवात करता तो, उदा. आत Node असलेले छोटे LinuxCMD — container सुरू झाल्यावर चालणारी commandEXPOSE — ॲप कोणता port वापरते याची नोंद; तो port ही ओळ उघडत नाहीUSER — ॲप कोणत्या user म्हणून चालते; USER node म्हणजे सर्वशक्तिमान root नाही
⏪ आधी
लिखित recipe नसताना ॲप सेट करणे म्हणजे हाताने केलेल्या पायऱ्या, ज्या कोणीही अगदी तशाच पुन्हा करू शकत नव्हते.
💡 काय
Dockerfile म्हणजे recipe card: FROM, WORKDIR, COPY, ENV, USER आणि CMD सारख्या काही सूचना.
⚙️ कसे
FROM, COPY आणि RUN build वेळी काम करतात; ENV, USER आणि CMD image मध्ये नोंदले जातात आणि start वेळी लागू होतात; EXPOSE फक्त नोंद करते.
🎯 का
काय build वेळी आणि काय start वेळी चालते हे कळले की नेहमीच्या चुका टळतात, जसे EXPOSE ने port उघडेल अशी अपेक्षा.
🚀 पुढे
पुढे तुम्ही image चालवाल: docker run डबा उघडतो, आणि खरोखर port publish करतो तो -p.
🧪 Try it here — Dockerfile ची ओळ निवडा आणि ती कधी चालते, काय करते ते शिका
docker run डबा उघडते; ports म्हणजे वाढायची खिडकी; logs आणि exec म्हणजे तुमचे डोळे आणि हात.
🧒 सोप्या शब्दांत
फ्रिजमधला डबा उघडेपर्यंत कोणाचेच पोट भरत नाही. docker run image ची नवी copy उघडतो आणि आतले ॲप सुरू करतो; ती चालू copy म्हणजे container. बाहेरच्यांना ते मिळावे म्हणून -p 3000:3000 ने वाढण्याची खिडकी उघडा; ती नसेल तर ॲप चालते पण बाहेरून कोणीच पोहोचू शकत नाही. docker logs ॲपने काय छापले ते दाखवतो, docker exec ने तुम्ही आत जाऊ शकता.
📖 नवे शब्दdocker run — image मधून नवा container बनवून तो सुरू करतोcontainer — image ची चालू copy; दहा वेळा run केले तर दहा containers-p (publish) — खिडकी उघडते: तुमच्या laptop चा port 3000 डब्याच्या port 3000 कडे जातोdocker logs — ॲपने छापलेले सगळे दाखवतोdocker exec — चालू container च्या आत command चालवतो, जसे तिथे shell उघडणे
⏪ आधी
Image स्वतः गोठलेली असते; ती चालवल्याशिवाय requests serve करता येत नाहीत किंवा ॲप काय करते ते दिसत नाही.
💡 काय
कंटेनर म्हणजे image ची चालणारी प्रत, स्वतःच्या filesystem आणि network सह; image कधीच बदलत नाही.
⚙️ कसे
docker run -p 3000:3000 laptop:3000 ते box:3000 अशी खिडकी उघडतो; docker logs आणि exec ने आत पाहता येते.
🎯 का
दहा वेळा run केल्यास एका image मधून दहा नवीन कंटेनर मिळतात, आणि -p नसेल तर बाहेरून कोणीही ॲपपर्यंत पोहोचू शकत नाही.
🚀 पुढे
कंटेनर फेकून देण्यासारखे असतात, म्हणून पुढे data टिकवण्यासाठी volumes आणि डबे बोलण्यासाठी networks शिकाल.
🧪 Try it here — docker run ची command बनवा आणि browser ॲपपर्यंत पोहोचतो का ते पहा
5 🧊📞 Volumes & networks — सामायिक फ्रीज आणि इंटरकॉम
कंटेनर टाकाऊ आहेत; volumes डेटा टिकवतात. Networks कंटेनरना एकमेकांना नावाने कॉल करू देतात.
🧒 सोप्या शब्दांत
डबा फेकला की आतले अन्नही जाते, पण शेअर केलेल्या फ्रिजमधले दूध उद्याही असते. Containers वारंवार फेकले जातात, म्हणून टिकून राहायला हवा असा data, उदा. database, डब्याबाहेर volume मध्ये ठेवतात. आणि सतत बदलणाऱ्या खोली-क्रमांकांऐवजी एका network वरचे containers intercom सारखे एकमेकांना नावाने बोलावतात: "web", 172.18.0.2 नाही.
📖 नवे शब्दvolume — container बाहेरची साठवण, त्यामुळे डबा delete झाला तरी data टिकतोbind mount — तुमच्या laptop वरचा folder container च्या आत दिसतोnetwork — containers ना एकमेकांशी बोलता यावे म्हणून खाजगी लाईनDocker DNS — "web" सारख्या नावाचा container चा पत्ता (IP) शोधून देणारी phone book
⏪ आधी
कंटेनर delete केला की त्याचा data जायचा; कंटेनरना बदलणाऱ्या IPs वरून एकमेकांना शोधावे लागायचे.
💡 काय
Volume म्हणजे डब्याबाहेरचा सामायिक fridge; network म्हणजे intercom, जिथे कंटेनर एकमेकांना नावाने बोलावतात.
⚙️ कसे
-v pgdata:/var/lib/postgresql/data data टिकवतो; "school" network वर Docker DNS "web" नावाचे IP मध्ये रूपांतर करतो.
🎯 का
नवीन db कंटेनरला जुना data सापडतो, आणि restart नंतर IPs बदलले तरी http://web:3000 चालत राहते.
🚀 पुढे
पुढे Kubernetes Services हीच नावाची युक्ती करतात; आता पुढे Compose तुमच्यासाठी volumes आणि networks जोडून देते.
🧪 Try it here — grade लिहा, कंटेनर delete करा, नवा सुरू करा — volume सह आणि त्याशिवाय
6 🍽️🍽️ Docker Compose — एका command ने संपूर्ण टेबल लावा
एक YAML फाइल प्रत्येक service वर्णन करते; docker compose up त्या सगळ्या बांधून सुरू करते, एकमेकांशी जोडून.
🧒 सोप्या शब्दांत
एक-एक ताट करून टेबल लावायला अनेक फेऱ्या लागतात; लिहिलेला टेबल-प्लॅन असेल तर सगळे एकदम लागते. compose.yml तोच प्लॅन आहे: त्यात प्रत्येक service ची यादी असते, आणि docker compose up त्या सगळ्या एका shared network वर एकत्र सुरू करतो. फक्त proxy ला तुमच्या laptop कडे दार (8080) मिळते. web कोणताही port publish करत नाही, म्हणून तुम्ही त्याच्याकडे थेट पोहोचू शकत नाही, पण proxy आतून नावाने पोहोचतो: web:3000.
📖 नवे शब्दDocker Compose — एका YAML file वरून अनेक containers एकत्र सुरू करणारे toolservice — file मधला एक प्रकारचा container, उदा. web किंवा proxyports — तुमच्या laptop कडून service मध्ये दार उघडते, उदा. laptop चा 8080 ते proxy चा 80depends_on — ही service त्या service नंतर सुरू करा; ती तयार होईपर्यंत थांबत नाहीdocker compose down — file ने सुरू केलेले सगळे थांबवून काढून टाकतो
⏪ आधी
अनेक कंटेनर चालवायचे म्हणजे लांब docker run आणि network commands हाताने, योग्य क्रमाने टाइप करणे.
💡 काय
Docker Compose संपूर्ण टेबल मांडते: एक compose.yml प्रत्येक service वर्णन करते, आणि एक command ती सगळी सुरू करते.
⚙️ कसे
docker compose up --build network school_default बनवते; web कोणताही port publish करत नाही; फक्त proxy :8080 वर publish होतो.
🎯 का
Host वरून web पर्यंत थेट पोहोचता येत नाही, पण proxy service नावाने web:3000 वर पोहोचतो; depends_on फक्त सुरू होण्याचा क्रम आहे.
🚀 पुढे
तीच file प्रत्येक सहकाऱ्याच्या laptop वर चालते; पुढे multi-stage builds या images खूप लहान करतात.
🧪 Try it here — टेबल वर आणि खाली करा, आणि प्रत्येक service पर्यंत पोहोचून पहा
7 👨🍳 Multi-stage builds — स्वयंपाकघरात शिजवा, फक्त अन्न पॅक करा
build साधने टाकाऊ stage मध्ये राहतात; फक्त निकाल पाठवला जातो. इमेज प्रचंड लहान होतात.
🧒 सोप्या शब्दांत
हॉटेल सुऱ्या, भांडी आणि उरलेल्या सालींनी भरलेल्या स्वयंपाकघरात शिजवते, पण तुम्हाला फक्त तयार अन्न डब्यात मिळते. Multi-stage build तेच करतो: पहिल्या stage मध्ये (स्वयंपाकघर) Node आणि build tools असतात आणि ते index.html बनवतात; दुसरी stage फक्त ती एक file छोट्या nginx image मध्ये copy करते. स्वयंपाकघर फेकून दिले जाते, म्हणून image ~180 MB वरून ~50 MB होते.
📖 नवे शब्दstage — Dockerfile मधला एक FROM भाग; नंतरची stage आधीच्या stage मधून copy करू शकतेbuilder — स्वयंपाकघर stage ला दिलेले नाव, जिथे बनवण्याचे काम होतेCOPY --from — आधीच्या stage मधून फक्त तयार file घेतोCVE — package मधला जाहीर माहीत असलेला सुरक्षा-दोष; कमी packages, कमी CVEs
⏪ आधी
Single-stage image सोबत node, npm, build tools आणि source code पण जायचे: एका index.html साठी सुमारे 180 MB.
💡 काय
Multi-stage build फेकून देण्याच्या kitchen stage मध्ये स्वयंपाक करते आणि फक्त तयार अन्न डब्यात भरते.
⚙️ कसे
FROM node:20-alpine AS builder index.html बनवते; मग FROM nginx:alpine आणि COPY --from=builder फक्त तेच घेते.
🎯 का
Image 180 MB वरून 50 MB होते: जलद push आणि pull, कमी CVEs, आणि पाठवलेल्या थरांत source उरत नाही.
🚀 पुढे
लहान images ही पुढच्या धड्यातील production-ready images च्या चार सवयींपैकी एक आहे.
🧪 Try it here — single-stage विरुद्ध multi-stage build करा आणि काय पाठवले जाते त्याची तुलना करा
हौशी इमेज आणि production इमेज यांना वेगळ्या करणाऱ्या चार सवयी.
🧒 सोप्या शब्दांत
वर्गातल्या प्रत्येक डब्यावर फक्त "जेवण" असे लिहिले असेल, तर तो कोणाचा आणि कोणत्या दिवसाचा हे कळत नाही. चांगल्या images चार सवयी पाळतात: स्पष्ट label (v1, v2 किंवा git commit; production मध्ये :latest कधीच नाही), आत खाजगी files नाहीत (उदा. passwords असलेली .env), सर्वशक्तिमान root ऐवजी साधा user म्हणून चालणे, आणि छोटा base.
📖 नवे शब्दtag — image वरचे label, उदा. :v1; :latest शांतपणे सर्वात नव्या image कडे सरकते.dockerignore — Docker ने image मध्ये कधीच copy करू नयेत अशा files ची यादी, उदा. .env secretsroot — सर्वशक्तिमान user; ॲप root म्हणून चालत असेल तर घुसखोरालाही ती शक्ती मिळतेbase image — ज्या image FROM सुरुवात करता ती; छोटी म्हणजे बिघडणाऱ्या किंवा हल्ला होणाऱ्या गोष्टी कमी
⏪ आधी
:latest म्हणजे सोमवारी v1 आणि मंगळवारी v2, COPY सोबत secrets आत जायचे, आणि ॲप्स root म्हणून चालायची.
💡 काय
Image hygiene म्हणजे चार सवयी: खरे tags, खाजगी files साठी .dockerignore, USER node, आणि लहान base images.
⚙️ कसे
:v1 किंवा git sha ने tag करा, .env आणि .git .dockerignore मध्ये टाका, आणि ॲप root नसावे म्हणून USER node जोडा.
🎯 का
Pinned tags मुळे rollback ला अर्थ येतो, COPY जे पाहू शकत नाही ते leak करू शकत नाही, आणि break-in लहानच राहतो.
🚀 पुढे
स्वच्छ, नीट tag केलेल्या images laptop सोडायला तयार आहेत: पुढे registry त्या इतर मशीनसाठी साठवते.
रजिस्ट्री इमेज साठवते जेणेकरून इतर मशीन त्या pull करू शकतील — लॅपटॉपपासून क्लाउडपर्यंतचा पूल.
🧒 सोप्या शब्दांत
घरी पॅक केलेले अन्न शहराच्या दुसऱ्या टोकाला असलेल्या मित्राला उपयोगाचे नाही, जोपर्यंत ते उचलायला एखादी जागा नसते. Registry हे images साठी तसे गोदाम आहे: तुम्ही laptop वरून docker push करता, आणि सहकारी किंवा cloud cluster docker pull करतो. Docker Hub हे कोणालाही pull करता येणारे सार्वजनिक गोदाम; ECR आणि GHCR ही कंपनीसाठी खाजगी गोदामे.
📖 नवे शब्दregistry — इतर मशीनना download करता याव्यात म्हणून images साठवणारे online गोदामpush / pull — image registry वर upload करणे / तिथून download करणेrepository — registry मधला एका ॲपचा कप्पा, ज्यात त्याची सगळी versions असतातdigest — image च्या नेमक्या मजकुराचा ठसा (sha256); तो कधीच हलवता येत नाही
⏪ आधी
तुमच्या laptop वर बनलेली image तिथेच राहायची; सहकारी आणि servers ना तोच डबा मिळवण्याचा मार्ग नव्हता.
💡 काय
Registry म्हणजे गोठलेल्या डब्यांचे गोदाम: docker push image ठेवतो, आणि इतर मशीन docker pull ने ती घेतात.
⚙️ कसे
Repository hello-school मध्ये :v1 आणि :v2 सारखे tags असतात; प्रत्येक tag sha256:9c1e सारख्या digest कडे निर्देश करतो.
🎯 का
Tag हे हलवता येणारे लेबल आहे, पण digest हा छेडछाड न होणारा fingerprint आहे, म्हणून नक्की काय चालते ते कळते.
🚀 पुढे
Docker Hub सार्वजनिक आहे; पुढे तुम्ही ECR सेट कराल, कंपनीचे खाजगी गोदाम, जिथे कोण आत येईल ते IAM ठरवते.
🧪 Try it here — push करा, मग tag हलवा, आणि digest काय निश्चित करतो ते पहा
खाजगी repository एकदा बनवा; प्रत्येक भेटीला नवा 12 तासांचा पास घ्या.
🧒 सोप्या शब्दांत
बँकेत locker एकदाच भाड्याने घेता, पण प्रत्येक भेटीत ओळखपत्र दाखवून त्या दिवसाचा pass मिळवता. ECR तसेच चालते: Terraform किंवा एका AWS command ने private repository एकदाच बनवता, आणि प्रत्येक वेळी push करायचे असेल तेव्हा 12 तासांत संपणारा login मिळवता. IAM तुम्ही कोण आहात ते तपासते आणि कोण push करू शकतो व कोण फक्त pull हे ठरवते.
📖 नवे शब्दECR — Amazon ची खाजगी image registry, तुमच्या कंपनीचा lockerget-login-password — 12 तासांनी संपणारा ECR साठीचा Docker login pass मिळवतोIAM — AWS ची ओळख-तपासणी: तुम्ही कोण आणि तुम्हाला काय करण्याची परवानगी आहेTerraform — तुम्ही लिहिलेल्या files वरून cloud मधल्या गोष्टी बनवणारे tool
⏪ आधी
कंपनीच्या images सार्वजनिक गोदामात असत्या तर कोणालाही दिसल्या असत्या, आणि कोण push करते यावर नियंत्रण नसते.
💡 काय
ECR म्हणजे भाड्याचा bank locker: AWS मधील खाजगी repository, एकदाच बनवलेली, scan on push आणि immutable tags सह.
11 🧹 Push, pull & lifecycle — डबे लावणे आणि सफाई कामगार
tag म्हणजे पत्ता, digest म्हणजे ओळख; push डबा लावतो, EKS तो घेतो, आणि तुम्ही लिहिलेली lifecycle policy लॉकर नीट ठेवते.
🧒 सोप्या शब्दांत
पत्र पोहोचायला पूर्ण पत्ता लागतो. Image चा पूर्ण पत्ता म्हणजे registry + repository + tag, उदा. …/hello-school:v3; push तिथे ती ठेवतो आणि cluster त्याच पत्त्याने pull करतो. Locker मध्ये आधी नसलेलेच थर push upload करतो, म्हणून कोड बदलल्यावर काही KB च जातात. Locker भरतो, म्हणून तुम्ही lifecycle policy लिहिता: "नवीन 10 ठेवा, बाकीच्या expire करा" असा सफाई-नियम.
📖 नवे शब्दtag — v3 सारखे माणसांसाठीचे label; ते दुसऱ्या image कडे हलवता येतेdigest — image चा ठसा; त्याचा अर्थ नेहमी अगदी तोच मजकूरlifecycle policy — ECR ने जुन्या images आपोआप delete कराव्यात म्हणून तुम्ही लिहिलेला नियमexpire — ECR ती image locker मधून काढून टाकते
⏪ आधी
पूर्ण पत्त्याशिवाय योग्य locker मध्ये push करता येत नव्हते, आणि जुन्या images कायम साचत राहायच्या.
💡 काय
Push डबा ठेवतो, EKS तो त्याच नावाने pull करते, आणि तुम्ही लिहिलेली lifecycle policy म्हणजे सफाई कर्मचारी.
⚙️ कसे
Registry + repo + tag ने tag करा, docker push करा, आणि imageCountMoreThan 10 असलेला नियम जुन्या images expire करतो.
🎯 का
Push फक्त locker मध्ये नसलेले थर upload करतो, म्हणून कोड बदलाला काही KB लागतात, आणि locker नीटनेटका राहतो.
🚀 पुढे
हे सगळे हाताने करणे लवकरच कंटाळवाणे होते; पुढे CI courier robot प्रत्येक push वर धडे 1 ते 11 करतो.
🧪 Try it here — बारा आवृत्त्या push करा आणि झाडूवाल्याला चालू द्या
खऱ्या जगात एक रोबोट प्रत्येक push वर धडे 1–11 करतो — आणि पुढच्या दोन कोर्सकडे काठी सोपवतो.
🧒 सोप्या शब्दांत
प्रत्येक बदलावर धडे 1–11 हाताने करणे म्हणजे प्रत्येक पत्र स्वतः चालत post office ला नेण्यासारखे आहे. प्रत्यक्षात प्रत्येक git push वर courier robot (GitHub Actions) हे करतो: test, build, commit SHA चा tag, login, ECR वर push. कोणतीही पायरी लाल झाली तर robot थांबतो, म्हणून बिघडलेले काहीच locker पर्यंत पोहोचत नाही. मग Kubernetes ती image cluster वर चालवतो.
📖 नवे शब्दCI — प्रत्येक push वर तुमचा कोड आपोआप test आणि build करणारा robotcommit SHA — एका git commit चा अनोखा ID; image चा tag म्हणून वापरतात म्हणजे माग काढता येतोOIDC — password साठवून न ठेवता robot ला थोड्या वेळाचा pass मिळण्याची पद्धतscan on push — ECR प्रत्येक नव्या image मध्ये माहीत असलेले सुरक्षा-दोष (CVEs) तपासते
⏪ आधी
प्रत्येक बदलावर हाताने build, tag, login आणि push करणे हळू होते आणि चुका सहज व्हायच्या.
💡 काय
CI म्हणजे courier robot, इथे GitHub Actions, जो प्रत्येक push वर test, build, tag, login आणि push करतो.
⚙️ कसे
npm test, docker build, tag = commit SHA, 12 h चा OIDC login, ECR ला push; कोणतीही लाल पायरी courier थांबवते.
🎯 का
तुटलेले काहीही locker पर्यंत पोहोचत नाही, आणि SHA tag मुळे चालणारा प्रत्येक कंटेनर त्याला बनवणाऱ्या कोडपर्यंत शोधता येतो.
🚀 पुढे
Baton पुढे जाते: Kubernetes या images cluster वर चालवते, आणि ArgoCD त्या git मधून deploy करते.
🧪 Try it here — commit push करा आणि कुरिअर पहा; एक पायरी मोडा
एक डेव्हलपर Git वर कोड push करतो. CI Docker इमेज बांधते, scan करते आणि ECR वर push करते. Kubernetes नंतर ती इमेज pull करून चालवते. ArgoCD Kubernetes configuration Git शी जुळते याची खात्री करते. Docker वस्तू बांधते · ECR वस्तू साठवते · Kubernetes वस्तू चालवते · ArgoCD deployment सांभाळते. आता उत्तर द्या, प्रत्येकी एका वाक्यात:
