← कोर्सच्या मुख्य पानाकडे परत

📐 12 धडे आकृत्यांमध्ये

भाग 1: तुमच्या लॅपटॉपवर Docker (निळा, धडे 1–8) · भाग 2: रजिस्ट्री & ECR (नारिंगी, धडे 9–12). प्रत्येक चित्रात वर्तुळातील क्रमांक 1 → 2 → 3 अनुसरा.

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) आणि सुरू व्हायला हळू
1💥 न बांधलेले ॲप — मशीनवर अवलंबूनतुमचा लॅपटॉपचालते ✓आहेnode20 ✓libsसगळे ✓PATHबरोबर ✓सहकाऱ्याचा लॅपटॉपcrash 💥आहेnode14 ✗libsनाहीत ✗PATHचुकीचा ✗कोड तोच आहे —मशीन वेगळे आहे"माझ्या मशीनवर चालते"हे मशीनबद्दलचे सत्य आहे,कोडबद्दलचे नाही2🍱 कंटेनर — लागणाऱ्या सगळ्यासह पॅक केलेले🍱 डबा (image)server.js — तुमचे ॲपnode 20libs: express …config: PORT=3000छोटे Linux (alpine)host चा kernel वाटून घेतो —आत अख्खे OS नाही:containerVMआकार~50 MB~2 GBसुरू होतो< 1 s~1 minkernelवाटलेलास्वतःचा3✅ तोच डबा सगळीकडे सारखाच चालतोhello-school:v1एक image💻 laptop Anode 20 · तेच libs ✓💻 laptop Bnode 20 · तेच libs ✓⚙️ CI runnernode 20 · तेच libs ✓☁️ AWS सर्व्हरnode 20 · तेच libs ✓docker run hello-school:v1 — Docker असलेल्या प्रत्येक मशीनवर सारखेच, कारण ॲपला लागणारे सगळे डब्याच्या आतून प्रवास करते
⏪ आधी

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 — न बांधलेले ॲप, मग डबा, तीन मशीनवर पाठवा

संपूर्ण धडा 01 वाचा →

2 🎂 इमेज & लेयर — केक आणि cache

Dockerfile ची प्रत्येक ओळ एक लेयर बनवते; न बदललेले लेयर cache मधून पुन्हा वापरले जातात.

🧒 सोप्या शब्दांत

केक खालून वर, एक-एक थर करून बनतो. Docker image सुद्धा तशीच बनते: Dockerfile ची प्रत्येक ओळ एक थर जोडते. पुन्हा build करताना Docker न बदललेले थर तसेच वापरतो आणि फक्त बदललेला थर व त्यावरचे थर पुन्हा बनवतो, म्हणून कोडमधला छोटा बदल मिनिटांत नाही, सेकंदांत होतो.

📖 नवे शब्दlayer — image चा एक थर, ज्यात फक्त Dockerfile च्या एका ओळीने केलेला बदल असतोcache — मागच्या वेळचे जपून ठेवलेले थर, म्हणजे Docker ला ते पुन्हा बनवावे लागत नाहीतbase image — ज्यापासून सुरुवात करता तो सर्वात खालचा थर, उदा. node:20-alpine (~50 MB)
1🎂 image म्हणजे थरांचा केक — Dockerfile च्या प्रत्येक ओळीला एक थरCMD ["node","server.js"]0 B · metadataCOPY server.js .2 KB · तुमचा कोडWORKDIR /app0 BFROM node:20-alpine~50 MB · आधीच तयारवर — वारंवार बदलतेखाली — क्वचित बदलतेप्रत्येक थर फक्त स्वतःचा बदल साठवतो, git commit सारखाथर वाटले जातात: node:20-alpine वरच्या दहा imagesते 50 MB एकदाच साठवतातdocker history hello-school:v1 केक वरून खाली दाखवते2🔁 पुन्हा build — cache काय पुन्हा वापरतेकाहीच बदलले नाही:FROM ✓ cacheWORKDIR ✓ cacheCOPY ✓ cacheCMD ✓ cacheserver.js बदलले:FROM ✓ cacheWORKDIR ✓ cacheCOPY 🔨 rebuildCMD 🔨 rebuildबदललेला थर स्वतः आणि त्यावरचा प्रत्येक थर पुन्हा बांधला जातोकाहीच बदलले नाही तर ~1 s · फक्त वरचा बदलला तर काही सेकंद3💡 ओळी क्वचित-बदलणाऱ्या पासून वारंवार-बदलणाऱ्या पर्यंत लावा✗ हळू: प्रत्येक बदलावर packages पुन्हा installCOPY . .RUN npm install✓ जलद: packages cache मध्येCOPY package*.json .RUN npm installCOPY . .dependencies आठवड्याला बदलतात, तुमचा कोड तासाला — म्हणूनआधी package यादी copy करा, install करा, मग कोड copy करा
⏪ आधी

थर नसते तर कोडमधील प्रत्येक छोट्या बदलासाठी संपूर्ण image पुन्हा सुरुवातीपासून बांधावी आणि साठवावी लागली असती.

💡 काय

Image म्हणजे थरांचा केक: Dockerfile ची प्रत्येक ओळ एक थर बनवते, जो फक्त स्वतःचा बदल साठवतो.

⚙️ कसे

पुन्हा build करताना न बदललेले थर cache मधून येतात; बदललेला थर आणि त्यावरचा प्रत्येक थर पुन्हा बांधला जातो.

🎯 का

ओळी क्वचित बदलणाऱ्यापासून वारंवार बदलणाऱ्याकडे लावल्या की rebuild मिनिटांऐवजी काही सेकंदांत होतो.

🚀 पुढे

वाटलेले थर पुढे push आणि pull ही जलद करतात: node:20-alpine वरच्या दहा images ते 50 MB एकदाच साठवतात.

🧪 Try it here — एक ओळ बदला आणि पुन्हा build करा — कोणते थर cache मधून येतात ते पहा

संपूर्ण धडा 02 वाचा →

3 📝 Dockerfile — पाककृतीचे कार्ड ओळीने वाचणे

या सूचना तुम्हाला भेटणाऱ्या बहुतेक 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 नाही
1📝 कृती-पत्रिका — app/Dockerfile, ओळ-ओळFROM node:20-alpineWORKDIR /appCOPY server.js .ENV PORT=3000EXPOSE 3000USER nodeCMD ["node","server.js"]buildआधीच तयार डब्यापासून सुरुवात: छोटे Linux + Node — Node तुम्ही कधीच स्वतः install करत नाहीbuildडब्याच्या आत /app मध्ये जा (नसेल तर बनते)buildतुमचा कोड आत ठेवा — आत काय येईल ते .dockerignore ठरवतेचालवाdefault setting; docker run -e PORT=… ते बदलतेdocsफक्त दस्तऐवज: "3000 वर ऐकते" — काहीच publish करत नाहीचालवाroot सोडा: घुसखोरी छोटीच राहते (धडा 08)चालवाडबा उघडल्यावर काय चालते — एक प्रोसेस, foreground मध्ये⏱️ प्रत्येक ओळ कधी घडते?FROM · WORKDIR · COPY · RUN → docker build वेळी (थरांत भाजलेले) ENV · USER · CMD → नोंदवले, docker run वेळी वापरलेEXPOSE → कधीच नाही: port फक्त docker run -p publish करते (धडा 04)2🔨 docker build — पत्रिकेची image होतेDockerfile+ server.jsbuild$ docker build -t hello-school:v1 app/[1/3] FROM node:20-alpine CACHED[2/3] COPY server.js . 0.1snaming to hello-school:v1 ✓hello-school:v1एक imagetag = नाव:आवृत्ती-t नाव देते
⏪ आधी

लिखित 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 ची ओळ निवडा आणि ती कधी चालते, काय करते ते शिका

संपूर्ण धडा 03 वाचा →

4 🍽️ कंटेनर चालवणे — जेवणाची वेळ

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 उघडणे
1🍽️ docker run — डबा उघडतो आणि ॲप सेवा देऊ लागतेhello-school:v1image (गोठलेली)docker run🏃 कंटेनर — चालणारी प्रतnode server.js (PID 1)स्वतःची filesystem · स्वतःचे network-e APP_VERSION=v2 → settingport 3000डब्याच्या आततुमचा लॅपटॉप:3000-p 3000:3000लॅपटॉप:3000 → डबा:3000-p नाही = खिडकी नाही:ॲप चालते, बाहेरूनकोणीच पोहोचू शकत नाहीimage कधीच बदलत नाही; प्रत्येक docker run त्यातून नवा कंटेनर बनवतो — दहा runs, दहा कंटेनर, एक image2👀 चालणाऱ्या डब्यावर तुमचे डोळे आणि हातdocker psकोणते डबे चालू आहेतdocker logs -f webॲपने काय छापले (stdout + stderr)docker exec -it web shचालणाऱ्या डब्याच्या आत एक shelldocker stop webSIGTERM → ॲप संपवते → exit (10 s, मग KILL)docker rm webडबा फेकून द्या — image राहते$ docker psCONTAINER IMAGE PORTS3f2a… hello-school:v1 0.0.0.0:3000->3000$ docker logs weblistening on 3000 (v2)
⏪ आधी

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 ॲपपर्यंत पोहोचतो का ते पहा
:

संपूर्ण धडा 04 वाचा →

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
1📞 network — कंटेनर एकमेकांना नावाने बोलावतातdocker network "school" — इंटरकॉमwebॲप :3000proxynginxhttp://web:3000Docker DNS: "web" → 172.18.0.2IP नव्हे, नाव — IPs प्रत्येक restart ला बदलतात, नावे नाहीKubernetes Services नेमके हेच करतात (k8s L04)2🧊 volumes — डबा गेल्यावरही टिकणारा datadb containerv1docker rm 🗑️db containerv2 (नवा)volume pgdataकंटेनरच्या बाहेर राहतोनव्या डब्याला जुना data सापडतो ✓3📂 कंटेनरला storage देण्याचे तीन मार्गnamed volume-v pgdata:/var/lib/postgresql/dataDocker सांभाळते — databasesbind mount-v $(pwd)/app:/appलॅपटॉपचा folder आत जोडलेला — कोड थेट बदलाकाहीच नाही (tmpfs)(default)डब्यासोबत जाते — caches, कच्चे कामनियम: जे हरवल्यावर तुम्ही रडाल ते volume मध्ये — कंटेनर स्वतः फेकण्याजोगा
⏪ आधी

कंटेनर 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 सह आणि त्याशिवाय

संपूर्ण धडा 05 वाचा →

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 ने सुरू केलेले सगळे थांबवून काढून टाकतो
1📄 compose.yml — अख्खे टेबल एका फाइलमध्येservices: web: build: ./app environment: APP_VERSION: v2 proxy: image: nginx:alpine volumes: - ./proxy/nginx.conf:/etc/… ports: - "8080:80" depends_on: [web]$ docker compose up --build✔ Network school_default Created✔ Container school-web-1 Started✔ Container school-proxy-1 Started$ docker compose down # all gone2🍽️ ते काय बांधते — एक network, एक दारटेबल — network school_defaultwebॲप :3000 · उघडे नाहीproxynginx :80web:3000web = Compose service चे नाव →Docker DNS ते web container कडे पोहोचवतोbrowser → localhost:8080 → proxy:80 → web:3000:8080एकमेव दारbrowser → localhost:8080web चे ports publish नाहीत → host वरूनथेट पोहोचता येत नाही, पण Compose network मध्येservice नावाने पोहोचता येतेएक command वर, एक खाली, तीचफाइल प्रत्येक सहकाऱ्याच्या लॅपटॉपवरdepends_on = सुरू होण्याचा क्रम, तयारी नव्हे
⏪ आधी

अनेक कंटेनर चालवायचे म्हणजे लांब 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 पर्यंत पोहोचून पहा

संपूर्ण धडा 06 वाचा →

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
1👨‍🍳 multi-stage — स्वयंपाकघरात शिजवा, फक्त डबा पाठवाstage 1 — स्वयंपाकघर (AS builder)FROM node:20-alpine AS buildernode + npm + build साधनेsource कोड + node_modulesRUN node generate.js → index.html~180 MB🗑️ build नंतर टाकून दिलेstage 2 — डबा (जे पाठवले जाते)FROM nginx:alpineCOPY --from=builder /app/index.html .~50 MB · node नाही, साधने नाहीत, source नाहीफक्त निकाल. हेच पाठवले जाते. 🚀फक्त index.htmlपलीकडे जाते2📏 का महत्त्वाचेsingle stage180 MBmulti-stage50 MBलहान image → जलद push आणि pull (धडा 11)कमी packages → patch करायला कमी CVEs (धडा 08)पाठवलेल्या थरांत source किंवा गुपिते उरत नाहीत
⏪ आधी

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 करा आणि काय पाठवले जाते त्याची तुलना करा

संपूर्ण धडा 07 वाचा →

8 🏷️ इमेजची स्वच्छता — डब्यांवर लेबल लावा, किल्ल्या पॅक करू नका

हौशी इमेज आणि 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 सुरुवात करता ती; छोटी म्हणजे बिघडणाऱ्या किंवा हल्ला होणाऱ्या गोष्टी कमी
1🏷️ छंदाच्या images ना production images पासून वेगळ्या करणाऱ्या चार सवयी1 · खरे tags, prod मध्ये :latest कधीच नाही2 · खासगी सगळे .dockerignore करा3 · USER node — root कधीच नाही4 · छोट्या base images:latestसोमवार = v1:latestमंगळवार = v2तेच लेबल, दोन वेगळे डबे —"latest वर rollback" ला अर्थ नाही:v1 · :v2:3f2a9c1 (git sha)निश्चित, मागोवा घेता येणारे ✓.git/.env ← गुपितेnode_modules/*.logDockerfileCOPY . . ला फक्त तेच दिसते जे.dockerignore लपवत नाहीCOPY जे पाहू शकत नाहीते गळू देऊ शकत नाही ✓डब्यात rootॲपमध्ये घुसखोरी= मशीनवरच्या पोहोचता येणाऱ्याफाइल्सवर root💥USER nodeॲप एकासामान्य user म्हणून चालते— चोरायला थोडेचnode:201100 MBnode:20-slim240 MBnode:20-alpine140 MBdistroless120 MBओढायला कमी · patch करायला कमी · हल्ल्याला कमी
⏪ आधी

: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 त्या इतर मशीनसाठी साठवते.

🧪 Try it here — reviewer करतो तसे image तपासा

संपूर्ण धडा 08 वाचा →

9 🏬 रजिस्ट्री — गोठवलेल्या डब्यांचे गोदाम

रजिस्ट्री इमेज साठवते जेणेकरून इतर मशीन त्या 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); तो कधीच हलवता येत नाही
1🏬 registry — इतर मशीन्स जिथून ओढतात ते गोदामतुमचा लॅपटॉपimage इथे बांधलीdocker push🏬 registry📚 repository hello-school — एका ॲपचे कपाट:v1→ digest sha256:9c1e…:v2→ digest sha256:3f2a…:3f2a9c1→ digest sha256:3f2a…tag म्हणजे हलवता येणारे लेबल · digest म्हणजे बदलता न येणारा ठसाdocker pull☸️ EKS clusterdeploy च्या वेळी pull करतोसहकारी2🌍 सार्वजनिक विरुद्ध खाजगी गोदामेDocker Hub — सार्वजनिक गोदामnode:20-alpine, nginx, postgres … कोणीही ओढू शकतोECR / GHCR — तुमच्या कंपनीचे खाजगीकोण push आणि pull करू शकते ते IAM ठरवते (पुढचा धडा)
⏪ आधी

तुमच्या 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 काय निश्चित करतो ते पहा

संपूर्ण धडा 09 वाचा →

10 🏦 ECR setup — बँक लॉकर भाड्याने घेणे

खाजगी 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
1🏦 ECR — लॉकर एकदा भाड्याने घ्या, प्रत्येक भेटीला 12 तासांचा पास1 लॉकर भाड्याने (एकदा)$ terraform apply ecr/ecr.tfaws_ecr_repository ✓किंवा: aws ecr create-repository--repository-name hello-school☁️ AWS — ECRhello-school (खाजगी)push वर scan ✓ · न बदलणारे tagsपत्ता:123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-school2 12 तासांचा दिवसाचा पास$ aws ecr get-login-password \ | docker login --username AWS \ --password-stdin 1234…ecr…Login Succeeded12 तासांनी संपतो —CI प्रत्येक run ला login करते2🔑 आत कोण येऊ शकते = IAM — बँक आधी ओळखपत्र तपासतेओळखकरू शकतेकसेतुम्ही (developer)push + pullया repo वर ecr:* असलेला IAM user/roleCI (GitHub Actions)pushOIDC role — साठवलेल्या keys नाहीत (CI/CD शाळा)EKS nodesफक्त pullnode role: ecr:BatchGetImage, GetDownloadUrl…IAM परवानगी नाही → "no basic auth credentials" किंवा 403 · पास तुम्ही कोण ते सिद्ध करतो; तुम्ही काय करू शकता ते IAM ठरवते (AWS शाळा L03)
⏪ आधी

कंपनीच्या images सार्वजनिक गोदामात असत्या तर कोणालाही दिसल्या असत्या, आणि कोण push करते यावर नियंत्रण नसते.

💡 काय

ECR म्हणजे भाड्याचा bank locker: AWS मधील खाजगी repository, एकदाच बनवलेली, scan on push आणि immutable tags सह.

⚙️ कसे

terraform apply repo बनवते; aws ecr get-login-password | docker login 12 h टिकणारा pass देतो.

🎯 का

Pass तुम्ही कोण ते सिद्ध करतो आणि IAM तुम्ही काय करू शकता ते ठरवते, म्हणून developers, CI आणि EKS nodes ना फक्त त्यांचा भाग मिळतो.

🚀 पुढे

Pass 12 h नंतर संपतो म्हणून CI प्रत्येक run वर login करतो; पुढे तुम्ही locker मध्ये push, pull आणि साफसफाई कराल.

🧪 Try it here — पासशिवाय, संपलेल्या पासने, आणि IAM नाकारल्यावर push करून पहा

संपूर्ण धडा 10 वाचा →

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 मधून काढून टाकते
1🏷️ push — डब्याला पत्ता द्या, दाखल करा, त्याच नावाने ओढाhello-school:v3tag1234….dkr.ecr…/hello-school:v3पूर्ण पत्ता = registry + repo + tagpush🏦 ECR लॉकर📦 v3 (सर्वात नवा)📦 v2📦 v1📦 जुने … कालबाह्य 🧹pull☸️ EKS deploymentimage: 1234…/hello-school:v3push फक्त लॉकरकडे नसलेले थर पाठवते —कोड बदलला तर काही KB जातात, 50 MB नाही2🧹 lifecycle policy — तुम्ही लिहिलेला झाडूवाला{ "rules": [{ "selection": {"tagStatus": "any", "countType": "imageCountMoreThan", "countNumber": 10}, "action": {"type": "expire"} }] }ecr/lifecycle-policy.jsonv1v2v3v4v5v6v7v8v9v10v11v12नवे 10 राहतात🧹 कालबाह्यत्याशिवाय लॉकर कायम भरत जातो आणि प्रत्येक push ला बिल वाढते
⏪ आधी

पूर्ण पत्त्याशिवाय योग्य 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 करा आणि झाडूवाल्याला चालू द्या

संपूर्ण धडा 11 वाचा →

12 📮 CI ते क्लाउड — कुरिअर प्रती लावतो

खऱ्या जगात एक रोबोट प्रत्येक 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) तपासते
1📮 CI ते cloud — कुरिअर रोबोट प्रत्येक push ला धडे 1–11 करतोdevgit push📮 CI — कुरिअर रोबोट (GitHub Actions)✅ testnpm test🍱 builddocker build🏷️ tag= commit SHA🔑 login12 h पास (OIDC)📤 pushECR कडेकोणतीही लाल पायरी कुरिअर थांबवते — मोडलेले काहीच लॉकरपर्यंत पोहोचत नाही🏦 ECR🛡️ push वर scanज्ञात CVEs दाखवल्याhello-school:3f2a9c1image tag म्हणजे commit SHA, म्हणून प्रत्येक चालणारा कंटेनर तो बांधणाऱ्या कोडच्या नेमक्या ओळीपर्यंत मागे नेता येतो2🏃 दंडुका — पुढचे दोन कोर्स तो उचलतात🐳 Docker (इथे)डबा पॅक करतो आणि दाखल करतो☸️ Kubernetesया images cluster भर चालवतो🤖 ArgoCDत्यांना git मधून deploy करतो, आपोआप, कायम
⏪ आधी

प्रत्येक बदलावर हाताने 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 करा आणि कुरिअर पहा; एक पायरी मोडा

संपूर्ण धडा 12 वाचा →