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

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

ArgoCD शिवाय deployment (लाल, धडे 1–4) आणि ArgoCD सह (हिरवे, धडे 5–12) — प्रत्येक एका क्रमांकित बॉक्स-आणि-बाण चित्रात. वर्तुळातील क्रमांक 1 → 2 → 3 अनुसरा.

🗺️ संपूर्ण चित्र — एक आकृती, दोन्ही जगे

संपूर्ण कोर्स एका कॅनव्हासवर: PUSH जग (लाल, धडे 1–4) त्याच्या चार त्रुटींसह, आणि PULL जग (हिरवे, धडे 5–12) त्याच्या सहा विजयांसह. 4K आवृत्तीसाठी क्लिक करा — wallpaper-आकाराच्या संदर्भासाठी उत्तम.

The big picture: deploying without ArgoCD (push model, with its gaps) vs with ArgoCD (GitOps pull model, with its wins)

1 🎒 हाताने deploy — तुम्हीच deploy प्रणाली आहात

तुमच्या लॅपटॉपवरून kubectl apply चालते… आणि गुपचूप तुम्हाला single point of failure बनवते.

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

कल्पना करा, शाळेच्या सूचना-फलकाची किल्ली फक्त तुमच्याकडे आहे आणि तुम्ही कोणतीही नोंद न ठेवता आठवणीने सूचना लावता. आज ते चालते, पण तुम्ही सुट्टीवर गेलात की फलकावर काय आहे किंवा ते कसे परत करायचे हे कोणालाच कळत नाही. Laptop वरून kubectl apply चालवणे तसेच आहे: live काय आहे याची एकमेव नोंद तुमची terminal history, आणि production च्या keys तुमच्या laptop वर.

📖 नवे शब्दdeploy — ॲपचे नवे version खऱ्या servers वर टाकणेkubectl apply — YAML files cluster ला पाठवते: "असे दिसू दे"kubeconfig — तुमच्या laptop वरची cluster चा पत्ता आणि keys असलेली filesingle point of failure — एकच व्यक्ती किंवा गोष्ट, जी नसेल तर सगळे थांबते
1🎒 लॅपटॉपवरून kubectl apply — चालते, आजतुमचा लॅपटॉपk8s/*.yaml~/.kube/config 🔑kubectl apply -f k8s/🏫 cluster🪑 pod🪑 podचालते! 🎉 … आजकाय live आहे त्याची एकमेव नोंदम्हणजे तुमची terminal historyतुमच्या लॅपटॉपकडे production च्याकिल्ल्या आहेत2📅 एका आठवड्याने — फक्त तुमची आठवण उत्तर देऊ शकते असे प्रश्न❓ कोणती आवृत्ती live आहे?❓ कोणी बदलले, आणि का?❓ सहकाऱ्यानेही deploy केले का?❓ मंगळवारच्या स्थितीत परत कसे जायचे?😱 deploy system तुम्हीच आहात — आणि तुम्ही सुट्टीवर जाता
⏪ आधी

कोणत्याही automation आधी तुम्ही स्वतःच्या laptop वरून kubectl apply -f k8s/ चालवायचा आणि ते आज तरी चालायचे.

💡 काय

हाताने deploy करणे म्हणजे तुम्हीच deploy system आहात: production च्या keys तुमच्या laptop कडे असतात.

⚙️ कसे

kubectl ~/.kube/config वाचतो आणि YAML apply करतो; काय live आहे याची एकमेव नोंद म्हणजे तुमची terminal history.

🎯 का

आठवड्यानंतर कोणीच सांगू शकत नाही की कोणते version live आहे, ते कोणी बदलले, किंवा मंगळवारच्या स्थितीत परत कसे जायचे.

🚀 पुढे

पुढे यातून निर्माण होणारा छुपा धोका पाहाल: drift, जेव्हा cluster git मधील files शी जुळणे थांबवतो.

🧪 Try it here — आठवडाभर हाताने deploy करा, मग प्रश्नांची उत्तरे देऊन पहा

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

2 🪑 Drift — जेव्हा वास्तव फाइल्सशी जुळेनासे होते

git मध्ये परत न जाणारा प्रत्येक हाताने केलेला बदल एक मूक, धोकादायक दरी रुंदावतो.

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

बैठक-वहीत खोलीत 2 खुर्च्या असे लिहिले आहे, पण शुक्रवारी कोणीतरी आणखी 3 आणल्या आणि वही कधी बदलली नाही. आता वही आणि खोली जुळत नाहीत, आणि मंगळवारी कोणी वहीप्रमाणे खोली लावली की जास्तीच्या खुर्च्या नाहीशा होतात. ही तफावत म्हणजे drift: git म्हणते replicas: 2, cluster मध्ये 5 चालतात, कारण हाताने केलेला बदल git मध्ये परत लिहिलाच नाही.

📖 नवे शब्दdrift — git जे सांगते आणि खरोखर जे चालू आहे त्यातली तफावतdesired state — तुम्हाला काय हवे आहे ते git मधल्या YAML मध्ये लिहिलेलेhotfix — घाईत केलेली तातडीची दुरुस्ती, बहुतेक हातानेkubectl diff — cluster तुमच्या files पेक्षा कसा वेगळा आहे ते ओळ-ओळ दाखवते
1🪑 drift — पुस्तक एक सांगते, खोल्या दुसरे📄 git मधले YAML म्हणतेreplicas: 2image: hello-school:v1resources.limits.memory: 64Mi🏫 cluster खरे तर हे चालवतोreplicas: 5 ← शुक्रवारची घाईimage: v2-hotfix-final-REALlimits.memory: 512Mi ← kubectl edit≠≠≠DRIFTशुक्रवार 18:00हाताने hotfix, "फक्त याच वेळी"शुक्रवार 18:05… आणि कोणीच ते git मध्ये परत लिहीत नाहीमंगळवारgit मधून "स्वच्छ" deploy hotfix गुपचूप पुसतो 💥2🔍 स्वतः पहा$ kubectl diff -f k8s/- replicas: 5+ replicas: 2- image: hello-school:v2-hotfix-final-REALgit मध्ये परत न आलेला प्रत्येकहाताने केलेला बदल दरी वाढवतो —शांतपणे, पुढच्या deploy पर्यंत
⏪ आधी

शुक्रवारी 18:00 वाजता कोणी "फक्त एकदाच" हाताने hotfix करतो, आणि कोणीच ते परत git मध्ये लिहीत नाही.

💡 काय

Drift म्हणजे पुस्तक आणि वर्गखोल्या यांतील फरक: git म्हणते replicas: 2, cluster प्रत्यक्षात 5 चालवतो.

⚙️ कसे

kubectl diff -f k8s/ हा फरक ओळीओळीने दाखवतो, जसे replicas 5 विरुद्ध 2 आणि hotfix image tag.

🎯 का

मंगळवारी git मधून केलेला "clean" deploy शांतपणे hotfix पुसून टाकतो, कारण प्रत्येक हाताने केलेला बदल फरक वाढवतो.

🚀 पुढे

लोक आधी जो उपाय वापरतात तो म्हणजे प्रत्येक push वर तुमच्यासाठी deploy करणारा CI/CD robot; तो पुढे आहे.

🧪 Try it here — cluster हाताने बदला, मग git शी तुलना करा

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

3 📮 CI/CD push — कुरिअर रोबोट तुमच्यासाठी deploy करतो

प्रत्येक push तपासला, बांधला आणि पोहोचवला जातो — माणूस लूपच्या बाहेर (बहुतेक).

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

तुम्ही स्वतः फलकाकडे जाण्याऐवजी, प्रत्येक नवी सूचना लिहिली की courier robot फेरी मारतो: तो ती तपासतो, copy करतो आणि फलकावर लावतो. हे आहे CI/CD push: प्रत्येक git push test होतो, build होतो आणि kubectl apply ने deploy होतो, दर वेळी त्याच पद्धतीने. आता कोणत्याही laptop वर keys नाहीत, पण त्या robot कडे आहेत, आणि तो शाळेबाहेर राहतो.

📖 नवे शब्दCI/CD — प्रत्येक push वर तुमचा कोड test, build आणि deliver करणारा robotpush model — robot बाहेरून cluster मध्ये पोहोचून deploy करतोcredentials — cluster बदलू देणाऱ्या keys किंवा passespipeline — robot दर वेळी चालवतो ती पायऱ्यांची ठरलेली यादी
1📮 CI/CD push — कुरिअर रोबोट तुमच्यासाठी deploy करतोdevgit push📮 CI/CD — कुरिअर रोबोट (cluster च्या बाहेर)✅ test🍱 build🗄️ push image🚚 kubectl apply🔑 cluster ची credentials सोबत नेतोबाहेरून🏫 cluster🪑 pod🪑 podप्रत्येक वेळी त्याच पायऱ्या — "अरे, tests विसरलो" नाही · हेच CI/CD शाळेचे deploy.yml — PUSH पद्धत2✅ काय सुधारले · ❓ काय नाही✅ प्रत्येक deploy तपासलेला आणि पुन्हा करता येणारा✅ कोणता commit deploy झाला ते git सांगते✅ कोणत्याच लॅपटॉपकडे किल्ल्या नाहीत❓ दोन push मध्ये cluster वर लक्ष कोण ठेवतो?❓ pipeline कडे production च्या किल्ल्या❓ दहा clusters = दहा keys सह दहा pipelines
⏪ आधी

हाताने deploy करताना चुका सहज व्हायच्या: कोणी tests विसरतो, किंवा laptop वरील जुन्या copy मधून deploy करतो.

💡 काय

CI/CD push म्हणजे cluster बाहेरचा courier robot, जो test, build, image push आणि deploy करतो.

⚙️ कसे

git push वर तो test, build, push image आणि kubectl apply चालवतो, cluster credentials घेऊन आत जातो.

🎯 का

प्रत्येक deploy तपासलेला आणि पुन्हा करता येणारा असतो, कोणता commit deploy झाला ते git सांगते, आणि laptop कडे keys नसतात.

🚀 पुढे

तरीही प्रश्न उरतात: दोन push च्या मध्ये कोण लक्ष ठेवते, आणि pipeline कडे production keys का असाव्यात?

🧪 Try it here — कुरिअरमधून commit push करा; मग cluster हाताने बदला

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

4 🚪 push च्या मर्यादा — कुरिअर पोहोचवतो आणि निघून जातो

push pipeline क्षण deploy करते; मधल्या काळात स्थितीवर कोणी पहारा देत नाही.

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

Courier सूचना लावतो आणि निघून जातो. दोन फेऱ्यांमध्ये फलकावर कोणाचेच लक्ष नसते, म्हणून शुक्रवारी कोणी हाताने सूचना बदलली तर ती पुढच्या delivery पर्यंत चुकीचीच राहते. आणि courier कडे प्रत्येक शाळेच्या keys असल्याने courier कडून चोरी करणे मोठे बक्षीस ठरते. दहा शाळा म्हणजे दहा keys घेतलेले दहा couriers. उपाय: शाळेतच राहणारा पहारेकरी.

📖 नवे शब्दdrift — cluster हळूहळू git शी जुळेनासा होतो, आणि कोणाच्या लक्षात येत नाहीattack surface — हल्लेखोर घुसू शकेल अशा जागा; prod keys असलेले CI त्यातली एकcluster — Kubernetes ज्या मशीनच्या गटावर तुमची ॲप्स चालवतो तो गट
1🚪 कुरिअर पोहोचवतो — आणि निघून जातो14:03शुक्र 18:00सोमपुढचा push📮 deploy ✓मग बाहेर पडतोअसुरक्षित: cluster ची git शी तुलना कोणीच करत नाही😈 kubectl edit🪑 drift वाढतो📮 deployतो पुसून टाकतोpush pipeline क्षणापुरता deploy करतो; मधली स्थिती शेवटी हात लावणाऱ्याची2🔑 बाहेरच्या किल्ल्या📮 CI🏫 prod🪑 podCI production बदलू शकते — म्हणूनCI स्वतःच हल्लेखोरांना हवी गोष्ट बनते3🏫🏫🏫 दहा clusters🏫 c1🏫 c2🏫 c3🏫 c4🏫 c5🔑 + yml🔑 + yml🔑 + yml🔑 + yml🔑 + ymlउपाय चांगला कुरिअर नाही — शाळेतच राहणारा पहारेकरी → भाग 2
⏪ आधी

Courier ने 14:03 ला deploy केले आणि निघून गेला; शुक्रवारपर्यंत kubectl edit ने cluster बदलला आणि कोणाच्या लक्षात आले नाही.

💡 काय

Push ची मर्यादा: pipeline फक्त क्षणी deploy करते, आणि मधल्या काळात स्थितीवर कोणीच पहारा देत नाही.

⚙️ कसे

CI बाहेरून keys घेऊन आत पोहोचते, आणि दहा clusters साठी दहा pipelines लागतात, प्रत्येकीची स्वतःची key आणि YAML.

🎯 का

CI production बदलू शकते म्हणून CI स्वतःच attackers चे लक्ष्य बनते, आणि drift न दिसता वाढत राहतो.

🚀 पुढे

उपाय चांगला courier नाही, तर शाळेच्या आतच राहणारा पहारेकरी आहे, आणि इथून Part 2 सुरू होतो.

🧪 Try it here — clusters वाढवा आणि push पद्धतीला काय लागते ते मोजा
3

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

5 📖 GitOps ची कल्पना — वास्तव वहीशी जुळलेच पाहिजे

इच्छित स्थिती git मध्ये जाहीर करा; cluster च्या आतला एजंट वास्तव तिच्याकडे नेतो, कायम.

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

शाळेत एक अधिकृत वही असते जी प्रत्येक खुर्ची कुठे हवी ते सांगते, आणि शाळेतच राहणारा काळजीवाहक दर काही मिनिटांनी खोल्या तपासून जागा सोडलेले सगळे परत लावतो. हे आहे GitOps: git म्हणजे तुम्हाला काय हवे त्याची वही, आणि cluster मधला agent खरा cluster त्याच्याशी जुळवत राहतो, कायम. तो आतून git वाचायला बाहेर जातो, म्हणून cluster च्या keys कधीच बाहेर जात नाहीत.

📖 नवे शब्दGitOps — काय चालायला हवे ते git मध्ये असते, आणि cluster मधला मदतनीस तसे घडवतोreconcile loop — वही वाचा, खोल्या पाहा, फरक दुरुस्त करा, थांबा, पुन्हा कराpull model — cluster मधला agent स्वतःच git मधून बदल आणतोdesired vs actual state — git नुसार काय चालायला हवे विरुद्ध आत्ता खरोखर काय चालू आहे
1📖 GitOps — पुस्तक हेच सत्य; आतला पहारेकरी खोल्यांना त्याच्याशी कायम जुळवतो📖 git — अपेक्षित स्थितीk8s/deployment.yaml replicas: 2 image: v1k8s/service.yamlफक्त review केलेले PRs🏫 cluster — प्रत्यक्ष स्थिती🪑 pod🪑 podpods · services · configs🔄 एजंटcluster च्या आत1 पुस्तक वाचा2 खोल्या पहा3 फरक दुरुस्त करा4 ~3 मिनिटे थांबाKubernetes सारखाच reconcile loop (k8s धडा 03) — एक पातळी वर: ज्याची अपेक्षित स्थिती git मध्ये आहे असा controller2🔁 push विरुद्ध pull — किल्ल्या कोणाकडेpush: CI credentials घेऊन आत पोहोचते, प्रत्येक commit ला एकदाpull: आतला agent git कडे बाहेर पोहोचतो, कायम — cluster च्या किल्ल्या बाहेर जात नाहीत
⏪ आधी

Push मध्ये cluster फक्त deploy च्या क्षणी git शी जुळायचा, आणि keys CI कडे बाहेर द्याव्या लागायच्या.

💡 काय

GitOps म्हणजे git हे अपेक्षित स्थितीचे पुस्तक आहे, आणि cluster मधील agent वास्तव त्याच्याशी जुळवतो.

⚙️ कसे

Agent सतत फिरत राहतो: पुस्तक वाचा, खोल्या पाहा, कोणताही फरक दुरुस्त करा, सुमारे 3 min थांबा, कायम.

🎯 का

तो आतूनच git मधून pull करतो, म्हणून cluster keys बाहेर जात नाहीत, आणि फक्त review झालेले PRs चालणारे बदलतात.

🚀 पुढे

हा Kubernetes सारखाच reconcile loop आहे, एक पातळी वर; पुढे तो चालवण्यासाठी ArgoCD install कराल.

🧪 Try it here — reconcile loop हाताने चालवा: git बदला किंवा cluster बदला

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

6 🤖 ArgoCD install करा — रोबोट शाळेत राहायला येतो

एक kubectl apply संपूर्ण रोबोट install करते; UI म्हणजे त्याच्या डोक्यात डोकावण्याची खिडकी.

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

काळजीवाहक काम सुरू करण्याआधी त्याला शाळेत एक खोली हवी. एका kubectl apply ने ArgoCD त्याच्या स्वतःच्या namespace मध्ये, argocd मध्ये, install होतो: git वाचणारा भाग, तपासणीचा loop चालवणारा भाग, आणि web page असलेला server. Port-forward ने ते web page उघडता आणि admin म्हणून login करून robot च्या डोक्यात डोकावता.

📖 नवे शब्दArgoCD — तुमच्या cluster मध्ये राहून तो git शी जुळता ठेवणारा robotnamespace — cluster मधली वेगळी खोली; ArgoCD argocd नावाच्या खोलीत राहतोapplication-controller — ArgoCD चा तपासा-आणि-दुरुस्त-करा loop चालवणारा भागport-forward — तुमच्या laptop पासून cluster मधल्या service पर्यंत तात्पुरता बोगदा
1🤖 ArgoCD install — एक kubectl apply, आणि रोबोट राहायला येतोतुम्हीkubectl apply-n argocd-f install.yaml🏫 तुमचा cluster🚪 namespace argocd — रोबोटची खोली🖥️ argocd-serverAPI + web UI📖 repo-servergit clone करतो, YAML render करतो🔄 application-controllerreconcile लूपredis (cache) · dex (SSO) · notifications🚪 तुमची ॲप्सरोबोट सांभाळतोते namespaces2🖥️ त्याच्या डोक्यात डोकावण्याची खिडकी$ kubectl -n argocd port-forward svc/argocd-server 8080:443$ kubectl -n argocd get secret argocd-initial-admin-secret \ -o jsonpath="{.data.password}" | base64 -dhttps://localhost:8080 · login adminरोबोट पहिल्या योजना-पानाची वाट पाहतो(पुढचा धडा: Application)
⏪ आधी

GitOps कल्पनेला cluster मध्ये राहणारा खरा agent लागतो, आणि आतापर्यंत तसा कोणी नव्हता.

💡 काय

ArgoCD हाच robot आहे: तो स्वतःच्या खोलीत, argocd namespace मध्ये राहायला येतो आणि तुमच्या apps वर लक्ष ठेवतो.

⚙️ कसे

kubectl apply -n argocd -f install.yaml argocd-server, repo-server आणि application-controller सुरू करते.

🎯 का

port-forward svc/argocd-server 8080:443 करून admin म्हणून login करा आणि UI मध्ये robot च्या डोक्यात पाहा.

🚀 पुढे

Install झालेला robot plan book च्या पहिल्या पानाची वाट पाहतो: Application, जे पुढे आहे.

🧪 Try it here — ArgoCD install करा आणि त्याचे pods वर येताना पहा

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

7 📄 पहिले Application — प्लॅन-वहीचे एक पान

Application सांगते: हा रेपो, हा फोल्डर, हे लक्ष्य. बाकी रोबोट करतो.

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

काळजीवाहकाला सूचनांचे पान हवे: कोणती वही, कोणता धडा, कोणती खोली. Application हे तेच पान आहे: हा git repo, हा folder (k8s/), हा namespace. ArgoCD तो folder वाचून लागू करतो. तेव्हापासून तुम्ही ॲपसाठी कधीच kubectl apply चालवत नाही; तुम्ही pull request merge करता, आणि बाकी robot करतो. Cluster git शी जुळला की UI मध्ये Synced दिसते.

📖 नवे शब्दApplication — कोणता repo, कोणता folder आणि कुठे deploy करायचे हे सांगणारे ArgoCD चे पानtargetRevision — git ची कोणती branch किंवा version पाळायची, उदा. mainSynced / OutOfSync — Synced = cluster git शी जुळतो; OutOfSync = ते वेगळे आहेतHealthy — ॲप फक्त लागू झालेले नाही, तर खरोखर नीट चालू आहे
1📄 Application — हे repo, हा folder, हे ठिकाणapiVersion: argoproj.io/v1alpha1kind: Applicationmetadata: { name: hello-school }spec: source: repoURL: …/learn-argocd-school path: k8s/ targetRevision: main destination: namespace: gitops-school syncPolicy: automated: {}reads📖 git: k8s/k8s/namespace.yamlk8s/deployment.yamlk8s/service.yaml🤖 ArgoCDrender + apply🚪 gitops-school🪑 pod🪑 podhello-school live ✓आतापासून तुम्ही ॲप कधीच kubectl-apply करत नाही:तुम्ही PR merge करता, आणि रोबोट ते लावतो2🟢 UI दाखवते ती स्थितीSyncedcluster git शी जुळतोOutOfSyncgit बदलले, किंवा कोणी cluster बदललाHealthypods तयार, service ला endpointsDegradedcrash-loop, probes नापास
⏪ आधी

ArgoCD install असूनही ॲप cluster मध्ये टाकण्यासाठी तुम्ही अजून स्वतः kubectl apply चालवत होता.

💡 काय

Application म्हणजे plan book चे एक पान: हीच repo, हाच folder, हेच destination.

⚙️ कसे

repoURL, path: k8s/ आणि targetRevision: main source सांगतात; ArgoCD ते render करून gitops-school namespace मध्ये लावतो.

🎯 का

आतापासून तुम्ही PR merge करता आणि robot तो apply करतो, तर UI Synced किंवा OutOfSync आणि Healthy दाखवते.

🚀 पुढे

पुढे robot पुस्तक किती काटेकोरपणे पाळतो ते ठरवाल: manual, automated, prune आणि selfHeal.

🧪 Try it here — Application भरा आणि रोबोट काय करतो ते पहा

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

8 📏 Sync policies — रोबोट वही किती काटेकोर पाळतो

Manual = आधी विचारतो. Automated = कृती करतो. Prune आणि selfHeal काटेकोरपणा वाढवतात.

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

काही काळजीवाहक काहीही हलवण्याआधी विचारतात; काही थेट दुरुस्त करतात. Sync policy ArgoCD किती कडक असावा ते ठरवते. Manual: तो OutOfSync दाखवतो आणि तुम्ही Sync click करेपर्यंत थांबतो. Automated: तो git मधले बदल स्वतः लागू करतो. selfHeal हाताने केलेले बदलही उलटवतो, आणि prune git मधून काढलेल्या गोष्टीही delete करतो. Prune default ला बंद असतो, कारण तो कोणी हाताने बनवलेल्या गोष्टीही delete करेल.

📖 नवे शब्दsync — git जे सांगते तसा cluster करणेautomated — ArgoCD click ची वाट न पाहता git मधले बदल स्वतः लागू करतोselfHeal — cluster मधले हाताने केलेले बदल git नुसार परत उलटवले जातातprune — git मधून delete केलेल्या गोष्टी cluster मधूनही delete होतात
1📏 रोबोट पुस्तक किती काटेकोरपणे पाळतो?📖 बदल येतोreplicas: 2 → 3🟡 OutOfSync✋ manual syncरोबोट विचारतो — तुम्ही Sync दाबता⚡ automated syncरोबोट स्वतः करतो🗑️ prune: truegit मधून हटवले → live मधून हटवले↩️ selfHeal: trueहाताने केलेले बदल उलटवले जातातकाटेकोरपणाचे बटण: manual → automated → + selfHeal → + pruneशिकताना manual ने सुरू करा; production मध्ये जाणीवपूर्वक, सुरक्षा उपायांसह वाढवा2🗑️ prune default ने बंद का📖 gitk8s/old-cronjob.yaml ✗ deleted🏫 clusterold-cronjob अजून चालूprune: false → तसेच ठेवलेprune: true ते काढते — बरोबर,आणि रोबोट सांभाळतो असे हातानेबनवलेलेही काढते— git मधली एक typo database पुसू शकते
⏪ आधी

Policy शिवाय robot आधी विचारेल की थेट करेल, किंवा delete केलेल्या गोष्टी कशा हाताळेल हे निवडता येत नव्हते.

💡 काय

Sync policy म्हणजे काटेकोरपणाचा dial: manual, मग automated, मग selfHeal, मग prune.

⚙️ कसे

Manual तुम्ही Sync click करेपर्यंत थांबते; automated स्वतः करते; prune git मधून गेलेले delete करते; selfHeal हाताचे बदल उलटवते.

🎯 का

Prune default ने बंद असते कारण ते कोणी हाताने बनवलेल्या गोष्टीही काढते, म्हणून ते विचारपूर्वक चालू करा.

🚀 पुढे

शिकताना manual ने सुरुवात करा; पुढे कोणी खोली बदलली की selfHeal खुर्च्या परत कशा लावतो ते पाहाल.

🧪 Try it here — sync policy निवडा आणि बदल करा

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

9 🪑↩️ Self-heal — खुर्च्या वही सांगते तिथे परत जातात

हाताने केलेला drift सेकंद टिकतो, महिने नाही. खोली नव्हे, वही बदला.

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

एखाद्या विद्यार्थ्याने खोलीत जास्तीच्या खुर्च्या आणल्या, तर काळजीवाहकाला काही सेकंदांत कळते आणि तो त्या वहीत लिहिल्याप्रमाणे परत लावतो. selfHeal सोबत ArgoCD तेच करतो: कोणी हाताने 5 पर्यंत scale केले, तर सुमारे 25 सेकंदांत ते परत 2 होते. खरोखर 5 हवे असतील, तर वही बदला: YAML edit करा, review घ्या, merge करा, आणि robot आनंदाने scale up करतो.

📖 नवे शब्दself-heal — हाताने बदललेले सगळे ArgoCD git शी जुळेल असे परत लावतोreplicas — ॲपच्या किती copies (pods) चालायला हव्यातpull request — git मधला प्रस्तावित बदल, merge होण्याआधी इतर तो review करतात
1🪑↩️ self-heal — खुर्च्या पुस्तकात सांगितलेल्या जागी परत10:00📖 पुस्तक: 2 · खोल्या: 2 ✓10:01😈 kubectl scale --replicas=510:01:20🟡 OutOfSync — drift लक्षात आला10:01:25🤖 पुस्तक पुन्हा लावले ✓हाताने केलेला drift महिने नव्हे, सेकंद टिकतो2📖 खरेच 5 replicas हवे? खोली नव्हे, पुस्तक बदलाedit k8s/deployment.yamlpull request + reviewमिळवणे🤖 आनंदाने वाढवतोबदल review केलेला, नोंदवलेला, आणि उलटवता येणारा — kubectl edit नसलेल्या तीन गोष्टी
⏪ आधी

हाताने केलेला kubectl scale --replicas=5 cluster मध्ये महिनोन्महिने कोणाच्या लक्षात न येता राहू शकायचा.

💡 काय

Self-heal म्हणजे कोणी खुर्च्या हलवल्या की robot त्या पुस्तकात लिहिल्याप्रमाणे परत लावतो.

⚙️ कसे

10:01 ला कोणी 5 पर्यंत scale करतो, 10:01:20 ला ArgoCD OutOfSync दाखवतो, आणि 10:01:25 ला पुस्तक पुन्हा apply करतो.

🎯 का

हाताने केलेला drift महिने नाही, काही सेकंदच टिकतो, आणि खरा बदल git मधून जातो: reviewed, recorded, reversible.

🚀 पुढे

खरोखर 5 replicas हवे? PR मधून पुस्तक बदला; पुढे पाहाल की git वाईट deploys ही उलटवते.

🧪 Try it here — हाताने scale करा आणि रोबोट खुर्च्या परत लावताना पहा

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

10 ⏪ Rollback — वही कालच्या पानावर उलटा

GitOps मध्ये git इतिहास हाच deploy इतिहास — म्हणून commit मागे घेणे म्हणजे deploy मागे घेणे.

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

आजच्या सूचनेत चूक असेल, तर वहीचे पान कालच्या पानावर उलटवा. GitOps मध्ये git history म्हणजेच deploy history: वाईट version एका commit मधून आले, म्हणून git revert ते उलटवणारा नवा commit बनवतो. तुम्ही push करता, ArgoCD सुमारे 3 मिनिटांत, किंवा Sync click केल्यास लगेच, sync करतो, आणि cluster परत जुन्या version वर येतो.

📖 नवे शब्दrollback — शेवटच्या चालणाऱ्या version कडे परत जाणेgit revert — आधीचा commit उलटवणारा नवा commit बनवतो, history तशीच ठेवूनgit history — प्रत्येक commit ची यादी: कोणी काय आणि केव्हा बदललेsource of truth — सगळे बरोबर मानतात ती एकच जागा; इथे git
1⏪ rollback — पुस्तक कालच्या पानावर उलटाAcommit Aimage: v1 ✅Bcommit Bimage: v2 💥Ccommit C = B चा revertimage: v1 ✅$ git revert B && git push[main 7c1d] Revert "bump to v2" (10 seconds)🤖 syncs C~3 मिनिटे, किंवा Sync दाबा🏫 पुन्हा v1 वर🪑 pod🪑 podGitOps मध्ये git history हीच deploy history: वाईट आवृत्ती commit मधून गेली, म्हणून commit उलटवला की deploy उलटतोArgoCD स्वतःचीही sync history ठेवते — UI जुन्या sync वर परत जाऊ शकते, पण सत्याचा स्रोत git च2🧾 दोन इतिहास, एक गोष्टकधीgit logArgoCD historyMon 10:00A image v1synced A ✓Tue 14:00B image v2synced B · Degraded 💥Tue 14:03C revert Bsynced C ✓
⏪ आधी

Rollback म्हणजे जुना pipeline run शोधणे किंवा आधी कोणते version live होते ते आठवणे असायचे.

💡 काय

GitOps मध्ये git history हीच deploy history आहे, म्हणून rollback म्हणजे पुस्तक कालच्या पानावर उलटवणे.

⚙️ कसे

git revert B && git push image v1 सह commit C बनवते; ArgoCD ते सुमारे 3 min मध्ये sync करतो, किंवा Sync click करा.

🎯 का

वाईट version commit मधून आले, म्हणून commit उलटवला की deploy उलटतो, आणि git हेच सत्य राहते.

🚀 पुढे

पुढे हे एका app वरून अनेक खोल्यांपर्यंत वाढवाल: Helm किंवा Kustomize ने एकाच recipe मधून dev, staging आणि prod.

🧪 Try it here — वाईट आवृत्ती पाठवा, मग GitOps पद्धतीने उलटवा

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

11 📚 Helm, Kustomize & environments — एक पाककृती, अनेक वर्ग

Templates + प्रत्येक environment ची values; प्रत्येक खोलीसाठी एक Application, आणि सगळ्यांची यादी करणारे एक मुख्य पान.

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

शिक्षक एकच पाठ-योजना लिहितात आणि प्रत्येक वर्गासाठी फक्त आकडे बदलतात: इथे 20 बाक, तिथे 40. Helm आणि Kustomize तसेच चालतात: ॲपसाठी एकच recipe, आणि प्रत्येक environment साठी छोट्या value files, उदा. dev मध्ये 1 replica, staging मध्ये 2, prod मध्ये 5. प्रत्येक खोलीला स्वतःचे Application मिळते, आणि एक root Application, म्हणजे app of apps, त्या सगळ्यांची यादी ठेवते.

📖 नवे शब्दHelm — YAML template मध्ये values भरणारे tool, रिकाम्या जागांच्या फॉर्मसारखेKustomize — base YAML घेऊन प्रत्येक environment साठी छोटे बदल जोडणारे toolvalues file — एका environment साठी आकड्यांची छोटी file, उदा. replicas: 5app of apps — एक Application ज्याच्या folder मध्ये बाकी सगळ्या Applications ची यादी असते
1📚 एक कृती, अनेक वर्ग — प्रत्येक environment चे values📚 एक पाककृतीHelm chart / Kustomize basereplicas: {{ .replicas }}image: {{ .image }}values-dev.yamlreplicas: 1🚪 dev🪑values-staging.yamlreplicas: 2🚪 staging🪑🪑values-prod.yamlreplicas: 5 + HPA🚪 prod🪑🪑🪑🪑🪑कृती एकदाच लिहिली; फक्त values वेगळे — म्हणून dev, staging आणि prod आकाराने कधीच वेगळे होत नाहीत2📖 app of apps — एक पान सगळी पाने सांगते📖 root Applicationpath: apps/📄 hello-dev📄 hello-staging📄 hello-prod
⏪ आधी

dev, staging आणि prod साठी YAML copy केल्याने प्रत्येक copy हळूहळू आकारात वेगळी होत जायची.

💡 काय

Helm किंवा Kustomize म्हणजे प्रत्येक environment च्या values सह एक recipe, आणि app of apps प्रत्येक Application ची यादी करते.

⚙️ कसे

values-dev.yaml replicas: 1 ठेवते, staging 2, prod 5 + HPA; path: apps/ वरचे root Application तिन्ही सूचीबद्ध करते.

🎯 का

Recipe एकदाच लिहिली जाते आणि फक्त values वेगळ्या असतात, म्हणून environments आकारात कधीच वेगळ्या होत नाहीत.

🚀 पुढे

एक गोष्ट अजूनही git मध्ये plain text म्हणून ठेवता येत नाही: secrets, ज्यांचा उपाय शेवटच्या धड्यात आहे.

🧪 Try it here — सामाईक कृती किंवा एका environment चे values बदला

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

12 🔑 GitOps मधील Secrets + अंतिम गुणपत्रक

सगळे git मध्ये राहते… plaintext secrets सोडून. ते encrypt करून आत ठेवा, किंवा बाहेरचा संदर्भ द्या.

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

Locker चा combination तुम्ही वर्गाच्या हजेरी-पटात कधीच लिहिणार नाही, कारण तो पट उघडणाऱ्या प्रत्येकाला तो कायमचा दिसतो. Git तसेच आहे: git मधला साधा password त्याच्या history मध्ये कायमचा उघड राहतो. म्हणून एकतर आत टाकण्याआधी तो बंद करा (Sealed Secrets: फक्त cluster तो उघडू शकतो), किंवा फक्त तो कुठे ठेवला आहे ते लिहा (External Secrets: vault कडे निर्देश).

📖 नवे शब्दsecret — खाजगीच राहायला हवा असा password किंवा keyplaintext — साध्या स्वरूपात लिहिलेले, म्हणजे पाहणारा कोणीही वाचू शकतोSealed Secrets — secret git मध्ये जाण्याआधी बंद केला जातो; key फक्त cluster कडेExternal Secrets — git मध्ये फक्त निर्देश असतो; खरी value AWS SM सारख्या vault मध्ये
1🔑 सगळे git मध्ये — साध्या मजकुरातली गुपिते सोडून❌ वहीत पासवर्डDB_PASSWORD: hunter2git मध्ये साधा मजकूर = कायमचे गळले (history)🔐 Sealed SecretsencryptedData: AgBy3i…git मध्ये encrypted — फक्त cluster ची key उघडू शकते🗝️ External SecretsremoteRef: school/db-passwordgit मध्ये फक्त POINTER; मूल्य vault / AWS SM मध्ये2🏁 गुणपत्रक — push विरुद्ध pull📮 push (CI deploy करते)🤖 pull (GitOps)drift वर नजर?❌ फक्त deploy वेळी✅ दर ~3 मिनिटांनीcluster च्या किल्ल्या❌ बाहेर, CI मध्ये✅ cluster च्या आतचइतिहास⚠️ pipeline logs✅ git log = deploy logrollbackजुनी pipeline पुन्हा चालवाgit revert10 clusters10 pipelines + 10 keys10 agents, एक repo
⏪ आधी

DB_PASSWORD: hunter2 git मध्ये टाकले म्हणजे ते कायमचे leak झाले, कारण git history ते जपून ठेवते.

💡 काय

Plaintext secrets सोडून सगळे git मध्ये राहते: त्यांना encrypt करून आत ठेवा, किंवा बाहेरून reference करा.

⚙️ कसे

Sealed Secrets फक्त cluster उघडू शकेल असा encryptedData ठेवतात; External Secrets AWS SM कडे remoteRef ठेवतात.

🎯 का

Scorecard: pull दर ~3 मिनिटांनी drift तपासतो, keys आतच ठेवतो, आणि git log लाच deploy log बनवतो.

🚀 पुढे

परिपक्व setup दोन्ही robots वापरतो: CI image build करून ठेवते, आणि ArgoCD cluster ला git शी जुळलेला ठेवतो.

🧪 Try it here — database password तीन प्रकारे साठवा आणि git मध्ये काय आहे ते पहा

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