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

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. या कोर्समधील प्रत्येक मोठ्या कल्पनेसाठी: ती येण्याआधी जीवन कसे होते, तिचे प्रामाणिक फायदे ✅ आणि तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🍱 कंटेनर (Docker) — धडे 01–04

⏮️ कंटेनरच्या आधी

सर्व्हर-रूमचा काळ: प्रत्येक भौतिक मशीनवर एक ॲप, wiki पानावरून हाताने install केलेले — प्रत्येक सर्व्हर एक अनोखा "snowflake" ज्याला हात लावायची कोणाची हिंमत नसे. मग virtual machines (~2000 चे दशक): चांगली गर्दी, पण प्रत्येक VM संपूर्ण OS घेऊन येते — डिस्कवर गिगाबाइट, boot ला मिनिटे, आणि आतले तरीही बदलत राही ("माझ्या VM वर चालते"). सॉफ्टवेअर पाठवणे म्हणजे install डॉक्स, dependency याद्या, आणि प्रार्थना. Docker ने (2013) डबा स्वस्त केला: संपूर्ण OS शिवाय isolation.

✅ फायदे

  • प्रत्येक मशीनवर सुसंगत environment — dev ≈ prod
  • मिलिसेकंदांत सुरू, GB नव्हे MB चे वजन
  • एका मशीनवर अनेक (घनता = स्वस्त)
  • इमेज = आवृत्ती असलेली, पाठवता येणारी वस्तू

❌ तोटे

  • host चा kernel वाटून घेते → VM पेक्षा कमकुवत isolation
  • Linux-प्रथम (Mac/Windows गुपचूप VM चालवतात)
  • शिकायला आणि debug करायला आणखी एक थर
  • base layers पुन्हा न बांधल्या/patch न केल्यास इमेज सडतात

👍 वापरा जेव्हा

  • web services, API, workers — सर्व्हर बाजूचे काहीही
  • CI ला स्वच्छ, पुनरावृत्ती करता येणारे environment हवे
  • तुम्ही Kubernetes/ECS कडे निघालात (कंटेनर आवश्यक)

👎 दोनदा विचार करा जेव्हा

  • desktop/GUI ॲप्स — पूर्णपणे चुकीचे साधन
  • अविश्वसनीय tenant कोड चालवणे → VM/microVM वापरा
  • kernel modules किंवा खास drivers लागतात
  • static साइट — object storage होस्टिंग सोपे

आकृती ↗

🏬 इमेज & रजिस्ट्री — धडे 02, 09

⏮️ इमेज रजिस्ट्रीच्या आधी

Deploy म्हणजे फाइल हस्तांतरण: प्रत्येक सर्व्हरवर rsync/FTP ने कोड, किंवा "golden" VM snapshots/AMI बनवणे — बांधायला हळू, diff करणे अशक्य, audit करणे गूढ. "सर्व्हर 7 वर कोणती आवृत्ती आहे?" ला चांगले उत्तर नव्हते. रजिस्ट्रींनी deployment वस्तूंचे आवृत्ती असलेल्या, fingerprint केलेल्या, कुठूनही ओढता येणाऱ्या वस्तूंमध्ये रूपांतर केले.

✅ फायदे

  • अपरिवर्तनीय, आवृत्ती असलेल्या वस्तू (tags + digests)
  • layer dedup → push/pull फक्त बदललेले हलवतात
  • एक स्रोत, कितीही ओढणारे
  • digests म्हणजे बदलता न येणारे fingerprint

❌ तोटे

  • रजिस्ट्री बंद = deploy बंद (हे critical infra आहे)
  • साठा गुपचूप वाढतो — सफाई कामगार लागतो (धडा 11)
  • tag बदलता येत असेल तर खोटे बोलू शकतो, बंदी नसेल तर

👍 वापरा जेव्हा

  • एकापेक्षा जास्त मशीन कधीही ॲप चालवतात
  • कोणतीही CI/CD pipeline आहे
  • Kubernetes (वाटाघाटी नाही — तो फक्त pull करतो)

👎 दोनदा विचार करा जेव्हा

  • शुद्ध serverless zip (Lambda zip → इमेज लागत नाही)
  • एका-लॅपटॉपवरचे प्रयोग — स्थानिक इमेज पुरतात

आकृती ↗

🍽️ Docker Compose — धडा 06

⏮️ Compose च्या आधी

बारा "आता हे चालवा" commands असलेली README, प्रत्येक डेव्हलपरच्या shell स्क्रिप्ट, आणि प्रत्येकी थोडे वेगळे चालणारे लॅपटॉप. किंवा Vagrant VMs: चांगले, पण जड आणि हळू. Compose ने संपूर्ण dev stack ला एक review करता येणारी फाइल आणि एक command बनवले.

✅ फायदे

  • संपूर्ण stack = git मधील एक फाइल, review करता येणारी
  • एक command वर, एक command खाली
  • प्रत्येक सहकाऱ्याच्या लॅपटॉपवर एकसारखे
  • Kubernetes संकल्पनांकडे सौम्य चढ

❌ तोटे

  • फक्त एक मशीन — multi-node नाही, HA नाही
  • स्व-उपचार किंवा autoscaling नाही
  • depends_on = सुरू होण्याचा क्रम, readiness नाही

👍 वापरा जेव्हा

  • स्थानिक development (त्याचे खरे घर)
  • डेमो, CI मधील integration tests
  • एका सर्व्हरवरची छोटी ॲप्स जिथे downtime चालतो

👎 दोनदा विचार करा जेव्हा

  • खऱ्या uptime गरजांसह production → k8s/ECS
  • multi-node किंवा auto-scaling काहीही
  • "स्वस्त k8s" म्हणून — नंतर ते दात दाखवेल

आकृती ↗

👨‍🍳 Multi-stage builds — धडा 07

⏮️ multi-stage च्या आधी (2017 मध्ये Docker मध्ये आले)

एकतर तुम्ही host वर build करून वस्तू COPY करत होतात (host drift — कंटेनर ज्या रोगावर उपाय आहेत तोच), किंवा दोन Dockerfiles + एक glue स्क्रिप्ट ठेवत होतात (जुना "builder pattern"), किंवा तुम्ही सरळ स्वयंपाकघरच पाठवत होतात: compiler, package manager आणि source code असलेल्या 1GB+ production इमेज.

✅ फायदे

  • छोट्या अंतिम इमेज (10–20× लहान सामान्य)
  • prod मध्ये build साधने नाहीत → खूप कमी CVE
  • एक फाइल, पूर्णपणे पुनरुत्पादित करता येणारी

❌ तोटे

  • मधल्या stages debug करायला सराव लागतो
  • CI cache ला काळजी लागते (--cache-from) नाहीतर build हळू होतात

👍 वापरा जेव्हा

  • build step असलेले काहीही: npm build, Go, Java, Rust
  • इमेजचा आकार किंवा scan reports त्रास देतात

👎 दोनदा विचार करा जेव्हा

  • build करायला काहीच नाही — आपले शून्य-dep server.js आनंदाने single-stage आहे; दिखाव्यासाठी stages कोणालाच मदत करत नाहीत

आकृती ↗

🏦 AWS ECR — धडे 10–12

⏮️ ECR च्या आधी (2015)

एकतर सगळ्यासाठी Docker Hub (मुळात सार्वजनिक, rate-limited, प्रत्येक node वर पासवर्ड), किंवा स्वतः registry:2 होस्ट करणे — म्हणजे तुम्ही patch करा, वाढवा, साठवा, backup घ्या आणि सुरक्षित ठेवा. AWS वर, आधीच चालवत असलेल्या compute शेजारी हा भरपूर निरर्थक त्रास होता.

✅ फायदे

  • IAM auth — EKS nodes role ने pull करतात, शून्य पासवर्ड
  • scan-on-push, immutable tags, lifecycle सफाई कामगार अंगभूत
  • त्याच region मधून pull: जलद + egress चा धक्का नाही
  • छोट्या प्रमाणावर काही पैसे, चालवायला शून्य सर्व्हर

❌ तोटे

  • फक्त AWS; पत्ते account आणि region ला बांधलेले
  • माणसांसाठी 12-तासांच्या token चा नाच (CI साठी ठीक)
  • cross-account शेअरिंगला policy चे काम लागते

👍 वापरा जेव्हा

  • तुमचे workloads AWS वर चालतात (EKS, ECS, Lambda containers)
  • अतिरिक्त साधनांशिवाय scan + सफाई हवी

👎 दोनदा विचार करा जेव्हा

  • सार्वजनिक/ओपन-सोर्स इमेज प्रकाशित करणे → Docker Hub किंवा GHCR
  • मुद्दाम multi-cloud → GHCR किंवा स्वतः होस्ट केलेले Harbor

आकृती ↗