एक नई एयरलाइन पर. एक परिचारिका यात्री केबिन में प्रवेश करती है: "आप हमारी नई एयरलाइन पर हैं। विमान की नाक में, हमारे पास एक सिनेमा हॉल है। पिछले भाग में - स्लॉट मशीनों का एक हॉल। निचले डेक पर - एक स्विमिंग पूल। पर ऊपरी डेक - एक सौना। अब, सज्जनों, अपनी सीट बेल्ट बांध लें, और इन सभी अनावश्यक चीजों के साथ, हम उड़ान भरने की कोशिश करेंगे। नमस्ते, मेरा नाम एंड्री है। मैं अपने जीवन के अधिकांश समय आईटी उद्योग में काम करता रहा हूँ। मुझे इंफ्रास्ट्रक्चर कॉन्फ़िगरेशन प्रबंधन इंजीनियरिंग के विकास में बहुत दिलचस्पी है। पिछले 8 वर्षों से, मैं से जुड़ा हुआ हूँ। DevOps ताजा लोकप्रिय रुझानों में से एक की अवधारणा है, जिसे 2017 में वीववर्क्स के सीईओ एलेक्सिस रिचर्डसन द्वारा पेश किया गया था। वीववर्क्स एक बड़ी वयस्क कंपनी है, जिसने 2020 में अपने GitOps को विकसित करने के लिए 36 मिलियन से अधिक का निवेश जुटाया। GitOps मेरे पिछले लेख में अब, मैं उन गैर-स्पष्ट चुनौतियों के बारे में बात करने का प्रयास करने जा रहा हूँ जो इस अवधारणा को अपनाते समय आपके सामने आ सकती हैं। संक्षेप में, GitOps कोई "सिल्वर बुलेट" नहीं है। आप संभवतः कई जटिल समाधानों के साथ पुनर्गठन करेंगे। मैं स्वयं इस रास्ते पर चल चुका हूं और आपको सबसे निराशाजनक समस्याएं दिखाना चाहता हूं जो आप GitOps के बारे में अन्य लेख पढ़ते समय नहीं देख सकते। लागत में कटौती की सफलता की कहानी पर चर्चा की गई थी कि कैसे हमने इलास्टिक स्टैक से ग्राफाना पर स्विच किया। सामग्री अवलोकन GitOps क्या है और आपको इसकी आवश्यकता क्यों नहीं है स्नोफ्लेक सर्वर समस्या GitOps - आपकी सभी समस्याओं का रामबाण इलाज (या नहीं) हेल्म के साथ फ्लक्स का उपयोग करने का तर्क कस्टम फ़्लक्स संसाधन GitOps के लिए चेकलिस्ट सत्य अवधारणा के एकल स्रोत का उल्लंघन छोटा निष्कर्ष GitOps क्या है और आपको इसकी आवश्यकता क्यों नहीं है आइए सीधे गोता लगाएँ! स्टेटलेस और स्टेटफुल आज बुनियादी ढाँचे के निर्माण की सबसे आशाजनक अवधारणा अपरिवर्तनीय बुनियादी ढाँचा है। इसका मुख्य विचार बुनियादी ढांचे को दो मूलभूत रूप से अलग-अलग भागों में विभाजित करना है: स्टेटलेस और स्टेटफुल। बुनियादी ढांचे का राज्यविहीन हिस्सा अपरिवर्तनीय और निष्क्रिय है। यह स्थिति को संचित नहीं करता है (डेटा को संग्रहीत नहीं करता है) या संचित स्थिति के आधार पर इसके संचालन को नहीं बदलता है। स्टेटलेस भाग के उदाहरणों में कुछ बुनियादी कलाकृतियाँ, स्क्रिप्ट और असेंबली शामिल हो सकती हैं। एक नियम के रूप में, मैं उन्हें क्लाउड/वर्चुअलाइज्ड वातावरण में आधार छवियों से बनाता हूं। वे नाजुक और अल्पकालिक हैं: मैं नई आधार छवियों से उदाहरणों को फिर से बनाकर अनुप्रयोगों के नए संस्करण वितरित करता हूं। लगातार डेटा को स्टेटफुल भाग में संग्रहीत किया जाता है। इसे शास्त्रीय योजना द्वारा समर्पित सर्वर या कुछ क्लाउड तंत्र (DBaaS, ऑब्जेक्ट, या ब्लॉक स्टोरेज) द्वारा महसूस किया जा सकता है। इस "चिड़ियाघर" को प्रबंधनीय बनाने और सही ढंग से काम करने के लिए, हमें इंजीनियरिंग और DevOps टीमों के साथ-साथ पूरी तरह से स्वचालित डिलीवरी पाइपलाइनों के बीच सहयोग की आवश्यकता है। सीआई भाग एक्सट्रीम प्रोग्रामिंग त्वरित विकास पद्धतियों में से एक है। इसमें कई फीडबैक लूप हैं, जो आपको क्लाइंट की जरूरतों के साथ तालमेल बनाए रखने की अनुमति देते हैं। हम सीआई/सीडी सिस्टम का उपयोग करके डिलीवरी पाइपलाइनों के स्वचालन को लागू करते हैं। CI (सतत एकीकरण) शब्द 1994 में ग्रैडी बूच द्वारा प्रस्तुत किया गया था, और 1997 में केंट बेक और रॉन जेफ़्रीज़ ने इसे चरम प्रोग्रामिंग के अनुशासन में पेश किया। सीआई में, हमें अपने परिवर्तनों को जितनी बार संभव हो अपनी परियोजना की मुख्य कार्य शाखा में एकीकृत करने की आवश्यकता है। इसके लिए, सबसे पहले, कार्यों के अधिक विस्तृत अपघटन की आवश्यकता होती है: छोटे परिवर्तन अधिक परमाणु होते हैं और उन्हें ट्रैक करना, समझना और एकीकृत करना आसान होता है। दूसरा, हम केवल ताज़ा लिखे गए कोड को मर्ज नहीं कर सकते। शाखाओं के विलय से पहले, हमें यह सुनिश्चित करना चाहिए कि पहले काम करने वाली कोई भी चीज़ तोड़ी नहीं गई है। ऐसा करने के लिए, एप्लिकेशन कम से कम बनाया जाना चाहिए. कोड को परीक्षणों के साथ कवर करना भी एक अच्छा विचार है। और यह कार्य सीआई प्रणालियों द्वारा किया जाता है, जो विकास में एक लंबा सफर तय कर चुके हैं और, इस पथ के बीच में कहीं, सीआई/सीडी सिस्टम में बदल गए हैं। सीडी भाग सीडी क्या है? : मार्टिन फाउलर ने सीडी की 2 परिभाषाएँ बताईं सतत वितरण. यह तब होता है, जब सतत एकीकरण प्रथाओं और DevOps संस्कृति की मदद से, आप अपने प्रोजेक्ट की मुख्य शाखा को उत्पादन में तैनात करने के लिए लगातार तैयार रखते हैं। सतत तैनाती. यह सतत वितरण है जहां मुख्य शाखा में जाने वाली हर चीज आपके क्लस्टर में, आपके उत्पादन में डंप हो जाती है। चलिए आगे बढ़ते हैं. स्नोफ्लेक सर्वर समस्या दुर्भाग्य से, अपरिवर्तनीय बुनियादी ढांचे में कई समस्याएं हैं। उनमें से बड़ा हिस्सा इंफ्रास्ट्रक्चर एज़ कोड (IaC) की अवधारणा से विरासत में मिला है। सबसे पहले, यह कॉन्फ़िगरेशन बहाव है। यह शब्द पपेट लैब्स (प्रसिद्ध पपेट एससीएम के लेखक) में पैदा हुआ था और बताता है कि लक्ष्य प्रणालियों पर सभी परिवर्तन सिस्टम कॉन्फ़िगरेशन प्रबंधन (एससीएम) की मदद से नहीं किए जाते हैं। कुछ को दरकिनार करते हुए मैन्युअल रूप से किया जाता है। ऐसे कई परिवर्तनों की प्रक्रिया में, कॉन्फ़िगरेशन बहाव प्रकट होता है - एससीएम में वर्णित कॉन्फ़िगरेशन और मामलों की वास्तविक स्थिति के बीच अंतर। इससे स्वचालन भय का माहौल पैदा होता है। जितने अधिक मैन्युअल परिवर्तन किए जाएंगे, उतनी ही अधिक संभावना होगी कि SCM स्क्रिप्ट चलाने से अनरिकॉर्ड किए गए परिवर्तन टूट जाएंगे। इसे चलाना जितना डरावना होगा, नए मैन्युअल संपादन किए जाने की संभावना उतनी ही अधिक होगी। अंततः, इस शातिर सकारात्मक प्रतिक्रिया से स्नोफ्लेक सर्वर का निर्माण होता है, जो इतने असंगत हो गए हैं कि अब कोई नहीं समझता कि अंदर क्या है। मैन्युअल संपादन के बाद, नोड बर्फबारी में प्रत्येक व्यक्तिगत बर्फ के टुकड़े के समान अद्वितीय हो जाता है। यह बहाव सर्वर को अपरिवर्तनीय बुनियादी ढांचे के भीतर उच्च स्तर पर छोड़ देता है: अब हम जीसीपी प्रोजेक्ट/एडब्ल्यूएस वीपीसी/कुबेरनेट्स-क्लस्टर-स्नोफ्लेक्स के बारे में बात कर सकते हैं। ऐसा इसलिए होता है क्योंकि परिवर्तन के कार्यान्वयन को अपरिवर्तनीय बुनियादी ढांचे पर विनियमित नहीं किया जाता है। इसके अलावा, कोई नहीं जानता कि इसे ठीक से कैसे किया जाए। GitOps - आपकी सभी समस्याओं के लिए रामबाण इलाज (या नहीं) और फिर वीववर्क्स आता है और कहता है, "दोस्तों, हमारे पास वह है जो आपको चाहिए - GitOps"। GitOps को बढ़ावा देने के लिए, वे केल्सी हाईटॉवर जैसे दिग्गज को लाए, जिन्होंने बनाया। अपने पीआर के दौरान, उन्होंने बड़े पैमाने पर संदेश प्रसारित किया, "एक आदमी बनो, बी...! स्क्रिप्टिंग बंद करो और शिपिंग शुरू करो।" और वह कहते हैं कि एक निश्चित मात्रा में मार्केटिंग बकवास बिंगो है। "कुबेरनेट्स द हार्ड वे" गाइड मेरी राय में, सबसे रोमांचक लाभ थे: तैनाती की बेहतर स्थिरता और मानकीकरण बेहतर सुरक्षा आश्वासन त्रुटियों से आसान और तेज़ पुनर्प्राप्ति पहुंच और रहस्यों का आसान प्रबंधन स्व-दस्तावेजीकरण तैनात करता है टीम के भीतर ज्ञान वितरण और जो कोई भी यह जानने की कोशिश कर रहा है कि GitOps क्या है, उसकी नजर इस पाठ्यपुस्तक स्लाइड पर पड़ती है। इसके बाद, हमें GitOps सिद्धांत मिलते हैं, जो थोड़े संवर्धित IaC सिद्धांतों से मिलते जुलते हैं: GitOps घोषणात्मक है GitOps ऐप्स संस्करणबद्ध और अपरिवर्तनीय हैं GitOps ऐप्स स्वचालित रूप से खींचे जाते हैं GitOps ऐप्स का लगातार समाधान किया जाता है फिर भी, यह शून्य में एक गोलाकार वर्णन है, इसलिए हम अपना शोध जारी रखते हैं। हमें GitOps.tech वेबसाइट और उस पर कई महत्वपूर्ण स्पष्टीकरण मिले। सबसे पहले, हम सीखते हैं कि GitOps, CD टूलींग के साथ Git में एक बुनियादी ढांचा जैसा कोड है जो स्वचालित रूप से इसे बुनियादी ढांचे पर लागू करता है। GitOps में हमारे पास कम से कम 2 रिपॉजिटरी होनी चाहिए: अनुप्रयोग भंडार. यह एप्लिकेशन स्रोत कोड और मैनिफ़ेस्ट का वर्णन करता है जो उस एप्लिकेशन की तैनाती का वर्णन करता है। अवसंरचना भंडार. यह बुनियादी ढांचे के प्रकटन और परिनियोजन वातावरण का वर्णन करता है। इसके अलावा, GitOps विचारधारा में, पुश-ओरिएंटेड दृष्टिकोण की तुलना में पुल-ओरिएंटेड दृष्टिकोण को प्राथमिकता दी जाती है। यह हेवीवेट पुल मॉन्स्टर्स पपेट और शेफ से लेकर हल्के पुश-आधारित एन्सिबल और टेराफॉर्म तक एससीएम सिस्टम के विकास के कुछ हद तक विपरीत है। और यदि GitOps मुख्य रूप से एक टूलकिट कहानी है, तो Weaveworks से ही फ्लक्स-आधारित अवधारणा लेना और इसे विखंडित करना समझ में आता है। विचार के लेखकों ने एक संदर्भ कार्यान्वयन किया होगा। फ्लक्स अब संस्करण 2 तक है और वास्तुशिल्प रूप से इसमें नियंत्रक शामिल हैं जो क्लस्टर के भीतर काम करते हैं: स्रोत नियंत्रक नियंत्रक को अनुकूलित करें हेल्म नियंत्रक अधिसूचना नियंत्रक छवि स्वचालन नियंत्रक इसके बाद, आइए फ्लक्स और हेल्म के साथ काम पर चर्चा करें। हेल्म के साथ फ्लक्स का उपयोग करने का तर्क मैं फ्लक्स 2 में हेल्म पैकेज मैनेजर का उपयोग करके एक एप्लिकेशन को तैनात करने के उदाहरण का वर्णन करने जा रहा हूं। क्यों? के अनुसार, एचईएलएम पैकेज मैनेजर 50% से अधिक की हिस्सेदारी के साथ सबसे लोकप्रिय पैकेजिंग एप्लिकेशन था। सीएनसीएफ सर्वेक्षण 2021 दुर्भाग्य से, मुझे अधिक अद्यतन डेटा नहीं मिल सका, लेकिन मुझे नहीं लगता कि तब से कुछ भी बहुत कुछ बदला है। तो, आइए बुनियादी तर्क पर चलें कि फ़्लक्स 2 हेल्म के साथ कैसे काम करता है। हमारे पास 2 रिपॉजिटरी हैं: एप्लिकेशन और इंफ्रास्ट्रक्चर। हम एप्लिकेशन रिपॉजिटरी से एक हेल्म चार्ट और डॉकर छवि बनाते हैं और उन्हें क्रमशः हेल्म चार्ट रिपॉजिटरी और डॉकर रजिस्ट्री में जोड़ते हैं। इसके बाद, हमारे पास फ्लक्स नियंत्रकों को चलाने वाला कुबेरनेट्स क्लस्टर है। अपने एप्लिकेशन को रोल आउट करने के लिए, हम कस्टम संसाधन (सीआर) हेल्मरिलीज़ का वर्णन करते हुए एक YAML तैयार करते हैं और इसे बुनियादी ढांचे के भंडार में जोड़ते हैं। फ्लक्स को प्राप्त करने में सहायता के लिए, हम कुबेरनेट्स क्लस्टर में एक सीआर गिटरिपोजिटरी बनाते हैं। स्रोत नियंत्रक इसे देखता है, गिट पर जाता है, और इसे डाउनलोड करता है। इस YAML को क्लस्टर में तैनात करने के लिए, हम एक अनुकूलन संसाधन का वर्णन करते हैं। कस्टमाइज़ नियंत्रक इसे देखता है, स्रोत नियंत्रक के पास जाता है, YAML प्राप्त करता है, और इसे क्लस्टर में तैनात करता है। हेल्म नियंत्रक देखता है कि एक सीआर हेल्मरिलीज़ क्लस्टर में दिखाई दिया है और वर्णित हेल्म चार्ट प्राप्त करने के लिए स्रोत नियंत्रक के पास जाता है। स्रोत नियंत्रक के लिए HELM नियंत्रक को अनुरोधित चार्ट देने के लिए, हमें CR क्लस्टर में एक HelmRepository बनाना होगा। हेल्म-नियंत्रक स्रोत-नियंत्रक से एक चार्ट प्राप्त करता है, एक रिलीज़ बनाता है, और इसे क्लस्टर में तैनात करता है। फिर कुबेरनेट्स आवश्यक पॉड्स बनाता है, डॉकर रजिस्ट्री में जाता है, और संबंधित छवियों को डाउनलोड करता है। तदनुसार, हमारे एप्लिकेशन के एक नए संस्करण को रोल आउट करने के लिए, हमें एक नई छवि, एक नई हेल्मरिलीज़ फ़ाइल और संभवतः एक नया हेल्म चार्ट बनाना होगा। फिर हमें उन्हें उपयुक्त रिपॉजिटरी में रखना होगा और फ्लक्स नियंत्रकों द्वारा ऊपर वर्णित श्रृंखला में कार्य को दोहराने की प्रतीक्षा करनी होगी। और, अपना काम समाप्त करने के लिए, हम कहीं एक अधिसूचना नियंत्रक लगाते हैं जो हमें सूचित करता है कि क्या गलत हो सकता है। कस्टम फ़्लक्स संसाधन अब आइए उन कस्टम संसाधनों पर चर्चा करें जिनके साथ फ्लक्स संचालित होता है। पहला Git रिपॉजिटरी है। यहां हम Git रिपॉजिटरी (पंक्ति 14) और जिस शाखा को यह देखता है (पंक्ति 10) का पता निर्दिष्ट कर सकते हैं। इस प्रकार, हम केवल एक शाखा डाउनलोड करते हैं, संपूर्ण रिपॉजिटरी नहीं। लेकिन! चूँकि हम जिम्मेदार इंजीनियर हैं और जीरो ट्रस्ट अवधारणा का पालन करने का प्रयास करते हैं, हम रिपॉजिटरी तक पहुंच को लॉक कर देते हैं, कुबेरनेट्स क्लस्टर में एक कुंजी के साथ एक रहस्य बनाते हैं और इसे फ्लक्स को दे देते हैं ताकि यह वहां जा सके (पंक्ति 12)। अगला है अनुकूलन. यहां मैं आपका ध्यान इस तथ्य की ओर आकर्षित करना चाहता हूं कि फ्लक्स से कस्टमाइज कंट्रोलर और कुबेरनेट्स के लेखकों से कस्टमाइज दो अलग-अलग चीजें हैं। मुझे नहीं पता कि इस तरह का भ्रमित करने वाला नामकरण क्यों चुना गया, लेकिन यह महत्वपूर्ण है कि उन्हें भ्रमित न किया जाए। अनुकूलन YAML (किसी भी) को Git रिपॉजिटरी से क्लस्टर में तैनात करने का एक तरीका है। यहां हमें उस स्रोत को निर्दिष्ट करना होगा जहां से हमने इसे रखा है (पंक्ति 12 - ऊपर वर्णित सीआर गिटरिपोजिटरी का नाम), वह निर्देशिका जहां से हम YAMLs लेते हैं (पंक्ति 8), और हम लक्ष्य नाम स्थान निर्दिष्ट कर सकते हैं जहां उन्हें जमा करना है (पंक्ति 13). अगली हेल्म रिलीज़ है। यहां हम नाम और चार्ट संस्करण (पंक्तियाँ 10,11) निर्दिष्ट कर सकते हैं। यहां आप परिवर्तनीय मान निर्दिष्ट करते हैं ताकि हेल्म एक परिवेश से दूसरे परिवेश में रिलीज़ को अनुकूलित कर सके (पंक्तियाँ 15-19)। यह एक अत्यंत महत्वपूर्ण और आवश्यक सुविधा है, क्योंकि आपका परिवेश काफी भिन्न हो सकता है। आप हेल्म चार्ट (पंक्तियाँ 12, 13, 14) लेने के लिए स्रोत भी निर्दिष्ट करते हैं। इस मामले में, यह हेल्म रिपॉजिटरी है। लेकिन! चूँकि हम अभी भी जिम्मेदार इंजीनियर हैं, हमारे पास हेल्म रिपॉजिटरी तक भी करीबी पहुंच है और हम फ्लक्स को वहां पहुंचने का एक रहस्य देते हैं (पंक्तियाँ 7, 8)। GitOps के लिए चेकलिस्ट तो, आइए एक छोटी सी चेकलिस्ट बनाएं और देखें कि हमने अभी क्या देखा। GitOps करना शुरू करने के लिए, हमें अचानक स्क्रिप्ट का एक समूह लिखना होगा (हमें याद है कि अपरिवर्तनीय बुनियादी ढांचा पूरी तरह से स्वचालित डिलीवरी पाइपलाइनों के बारे में है)। तो सबसे पहले, हमें बनाना होगा: छवियों को डॉकर रजिस्ट्री में बनाने और पुश करने के लिए स्क्रिप्ट इन्फ्रास्ट्रक्चर गिट रिपॉजिटरी बुनियादी ढांचे जीआईटी भंडार तक सीआई प्रणाली की पहुंच के लिए खाता हेल्मरिलीज़ फ़ाइल को जनरेट करने और पुश करने के लिए स्क्रिप्ट हेल्म रिपॉजिटरी हेल्म रिपॉजिटरी तक सीआई सिस्टम पहुंच के लिए खाता हेल्म चार्ट बनाने और प्रकाशित करने के लिए स्क्रिप्ट बुनियादी ढांचे के भंडार के लिए फ्लक्स खाता हेल्म चार्ट भंडार के लिए फ्लक्स खाता बढ़िया, अब आपके पास GitOps के लिए एक चेकलिस्ट है। आगे बढ़ो। सत्य अवधारणा के एकल स्रोत का उल्लंघन आइए देखें कि सामान्य तौर पर हेल्म रिलीज से हमें क्या मिलता है। यह बिल्कुल स्पष्ट है कि Git इस विशेष मामले में सत्य का एकमात्र स्रोत नहीं हो सकता है। हमारे पास कम से कम 2 संसाधन, git के बाहर 2 कलाकृतियाँ हैं, जिन पर यह हेल्म रिलीज़ निर्भर करती है: हेल्म चार्ट (पंक्तियाँ 8-14) डॉकर छवि (पंक्ति 19) और हम चीजों को और अधिक जटिल बना सकते हैं और हेल्म चार्ट संस्करणों की सीमा निर्दिष्ट कर सकते हैं। इस मामले में, फ्लक्स इस सीमा के भीतर दिखाई देने वाले नए हेल्म चार्ट की निगरानी और सेट करेगा। इसके अलावा, हमारे पास जो सोर्स कंट्रोलर है, वह S3 बंडलों सहित YAML को एक स्रोत के रूप में उपयोग कर सकता है। वहां से, हम YAML और हेल्म दोनों चार्ट रख सकते हैं। इसके अलावा, हमारे पास इमेज ऑटोमेशन कंट्रोलर हैं जो डॉकर रजिस्ट्री में नई छवियों पर नज़र रख सकते हैं और इंफ्रास्ट्रक्चर रिपॉजिटरी को संपादित कर सकते हैं। लेकिन हम हेल्म चार्ट रेपो-ऑप्स या डॉकर रजिस्ट्री-ऑप्स नहीं चाहते हैं। हम यथासंभव GitOps बनना चाहते हैं। इसलिए हम दस्तावेज़ीकरण को देखते हैं और जीआईटी रिपॉजिटरी से अपने हेल्म चार्ट को तैनात करने के लिए प्रक्रियाओं को सही करते हैं (हम इसे स्टोर करने के लिए एप्लिकेशन रिपॉजिटरी चुनते हैं)। यह हमें एप्लिकेशन रिपॉजिटरी के लिए एक और सीआर गिट रिपोजिटरी बनाने, फ्लक्स तक पहुंचने के लिए एक खाता बनाने और कुंजियों के साथ एक रहस्य बनाने के लिए मजबूर करता है। साथ ही, हम किसी भी तरह से डॉकर छवि पर जटिल निर्भरता की समस्या का समाधान नहीं करते हैं। छोटा निष्कर्ष मुझे लगता है कि आज के लिए इतना ही काफी है। दूसरे भाग में मैं आपको बताऊंगा कि इस अच्छाई की क्या-क्या समस्याएं हैं। में चर्चा करूंगा: एकाधिक वातावरण की समस्या से मान रहस्य समस्या सीआई ऑप्स बनाम गिटऑप्स सुरक्षा रोलबैक प्रक्रिया एकाधिक क्लस्टर समस्या वास्तव में GitOps की आवश्यकता किसे है? मुझे आशा है कि यह लेख आपके लिए उपयोगी था!
