GitOps क्या है?

लगभग। ट्रांस। : GitOps में पुल और पुश विधियों पर सामग्री के हाल के प्रकाशन के बाद, हमने इस मॉडल में समग्र रूप से रुचि दिखाई, हालांकि, इस विषय पर बहुत कम रूसी-भाषा के प्रकाशन थे (वे बस हब पर नहीं आते हैं)। इसलिए, हम आपके ध्यान में एक और लेख का अनुवाद लाने के लिए प्रसन्न हैं - लगभग एक साल पहले! - Weaveworks कंपनी से, जिसके प्रमुख ने "GitOps" शब्द गढ़ा था। पाठ दृष्टिकोण का सार और मौजूदा लोगों से महत्वपूर्ण अंतर की व्याख्या करता है।



एक साल पहले, हमने GitOps का एक परिचय प्रकाशित किया। तब हमने इस बारे में बात की कि वीवर्सवर्क्स की टीम ने कुबेरनेट्स-आधारित सास को कैसे लॉन्च किया, और क्लाउड नेटिव वातावरण में तैनात करने, प्रबंधन और निगरानी के लिए निर्धारित अभ्यास का एक सेट विकसित किया।

लेख लोकप्रिय हुआ। अन्य लोगों ने GitOps के बारे में बात करना शुरू कर दिया, गिट पुश , विकास , रहस्य , कार्य , निरंतर एकीकरण , आदि के लिए नए उपकरण प्रकाशित करना शुरू कर दिया। हमारी साइट पर बड़ी संख्या में प्रकाशन और GitOps के उपयोग के मामले सामने आए हैं। लेकिन कुछ लोगों के मन में अभी भी सवाल हैं। मॉडल कोड और निरंतर वितरण के रूप में पारंपरिक बुनियादी ढांचे से कैसे अलग है? क्या कुबेरनेट का उपयोग करना अनिवार्य है?

जल्द ही, हमें एहसास हुआ कि एक नए विवरण की आवश्यकता थी, भेंट:

1. उदाहरणों और कहानियों की एक बड़ी संख्या;
2. GitOps की विशिष्ट परिभाषा;
3. पारंपरिक निरंतर वितरण के साथ तुलना।

इस लेख में, हमने इन सभी विषयों को कवर करने का प्रयास किया है। इसमें आपको GitOps का अपडेटेड इंट्रोडक्शन और डेवलपर्स और CI / CD की तरफ से एक नज़र मिलेगा। हम मुख्य रूप से कुबेरनेट्स पर ध्यान केंद्रित करते हैं, हालांकि मॉडल को सामान्यीकृत किया जा सकता है।

मिलिए GitOps से

ऐलिस की कल्पना करो। वह फैमिली इंश्योरेंस चलाती है, जो लोगों के लिए हेल्थ, कार, रियल एस्टेट और ट्रैवल इंश्योरेंस पॉलिसी पेश करती है, जो अपने कॉन्ट्रैक्ट की बारीकियों को समझने में बहुत व्यस्त हैं। उसका व्यवसाय एक साइड प्रोजेक्ट के रूप में शुरू हुआ जब एलिस ने बैंक में डेटा वैज्ञानिक के रूप में काम किया। एक बार जब उसने महसूस किया कि वह उन्नत कंप्यूटर एल्गोरिदम का उपयोग डेटा का अधिक कुशलतापूर्वक विश्लेषण करने और बीमा पैकेज बनाने के लिए कर सकती है। निवेशकों ने इस परियोजना को वित्त पोषित किया, और अब उसकी कंपनी प्रति वर्ष $ 20 मिलियन से अधिक लेती है और तेजी से बढ़ रही है। वर्तमान में, इसमें विभिन्न पदों पर 180 लोग काम करते हैं। उनमें से, एक प्रौद्योगिकी टीम जो विकसित होती है, एक साइट, एक डेटाबेस को बनाए रखती है और ग्राहक आधार का विश्लेषण करती है। 60 लोगों की एक टीम का नेतृत्व कंपनी के तकनीकी निदेशक बॉब कर रहे हैं।

बॉब की टीम क्लाउड में उत्पादन प्रणाली तैनात कर रही है। Google क्लाउड पर कुबेरनेट्स का लाभ उठाते हुए, उनके मुख्य अनुप्रयोग GKE पर चलते हैं। इसके अलावा, वे अपने काम में डेटा और एनालिटिक्स के साथ काम करने के लिए विभिन्न उपकरणों का उपयोग करते हैं।

परिवार बीमा कंटेनरों का उपयोग करने वाला नहीं था, लेकिन डॉकटर के उत्साह से संक्रमित था। जल्द ही, कंपनी के विशेषज्ञों ने पता लगाया कि जीकेए नई सुविधाओं का परीक्षण करने के लिए क्लस्टर को तैनात करना आसान और आसान बनाता है। कंटेनर रजिस्ट्री को व्यवस्थित करने के लिए CI और Quay के लिए जेनकिंस को जोड़ा गया था, जेनकिंस के लिए स्क्रिप्ट में लिखा गया था कि GKE में पुश या नए कंटेनर और कॉन्फ़िगरेशन।

कुछ समय बीत चुका है। एलिस और बॉब चुने हुए दृष्टिकोण और व्यवसाय पर इसके प्रभाव के प्रदर्शन में निराश थे। कंटेनरों की शुरूआत ने उत्पादकता में वृद्धि नहीं की, जितना कि टीम को उम्मीद थी। कभी-कभी तैनाती टूट जाती थी, और यह स्पष्ट नहीं था कि क्या कोड परिवर्तन को दोष देना था। यह भी विन्यास में परिवर्तन को ट्रैक करने के लिए मुश्किल हो गया। अक्सर एक नया क्लस्टर बनाने और उसमें एप्लिकेशन स्थानांतरित करने के लिए आवश्यक था, क्योंकि यह उस गंदगी को खत्म करने का सबसे आसान तरीका था जिसमें सिस्टम बदल गया। ऐलिस को डर था कि अनुप्रयोग विकसित होने के साथ स्थिति खराब हो जाएगी (इसके अलावा, मशीन सीखने पर आधारित एक नई परियोजना पक रही थी)। बॉब ने अधिकांश काम को स्वचालित कर दिया और समझ में नहीं आया कि पाइपलाइन अभी भी अस्थिर क्यों है, अच्छी तरह से पैमाने पर नहीं है और समय-समय पर मैनुअल हस्तक्षेप की आवश्यकता है?

तब उन्होंने GitOps के बारे में जाना। यह निर्णय वास्तव में वही हुआ जो उन्हें आत्मविश्वास से आगे बढ़ने के लिए आवश्यक था।

ऐलिस और बॉब ने Git, DevOps और आधारभूत संरचना के आधार पर वर्कफ़्लोज़ के बारे में वर्षों से सुना है। GitOps की विशिष्टता यह है कि यह कुबेरनेट्स के संदर्भ में इन विचारों को लागू करने के लिए कई सर्वोत्तम प्रथाओं - श्रेणीबद्ध और प्रामाणिक - को लाता है। इस विषय को बार-बार उठाया गया है , जिसमें बुनकर ब्लॉग भी शामिल है ।

परिवार बीमा GitOps को लागू करने का निर्णय लेता है। कंपनी के पास अब कुबरनेट्स के साथ एक स्वचालित ऑपरेटिंग मॉडल है जो स्थिरता के साथ गति को जोड़ती है , जैसा कि वे:

• पाया कि टीम ने उत्पादकता दोगुनी कर दी है और कोई भी पागल नहीं हो रहा है;
• स्क्रिप्टिंग बंद कर दी। इसके बजाय, वे अब नई विशेषताओं पर ध्यान केंद्रित कर सकते हैं और इंजीनियरिंग विधियों में सुधार कर सकते हैं - उदाहरण के लिए, कैनरी रोल-आउट पेश करना और परीक्षण में सुधार करना;
• परिनियोजन प्रक्रिया में सुधार - अब यह शायद ही कभी टूट जाता है;
• मैनुअल हस्तक्षेप के बिना आंशिक विफलताओं के बाद तैनाती को पुनर्प्राप्त करने का अवसर मिला;
• आपूर्ति प्रणालियों में अधिक विश्वास प्राप्त किया। ऐलिस और बॉब ने पाया कि टीम को उन समूहों में विभाजित किया जा सकता है जो माइक्रोसेवा में काम करते हैं और समानांतर में काम करते हैं;
• प्रत्येक समूह के प्रयासों से हर दिन परियोजना में 30-50 परिवर्तन कर सकते हैं और नई तकनीकों को आजमा सकते हैं;
• वे नए डेवलपर्स द्वारा परियोजना के लिए आसानी से आकर्षित होते हैं जो कुछ ही घंटों में पुल अनुरोधों का उपयोग करके उत्पादन पर अपडेट रोल करने की क्षमता रखते हैं;
• SOC2 के भीतर आसानी से अंकेक्षित (सुरक्षित डेटा प्रबंधन के लिए आवश्यकताओं के साथ सेवा प्रदाताओं के अनुपालन के लिए; अधिक पढ़ें; उदाहरण के लिए, यहाँ - .x। अनुवाद।) ।

क्या हुआ?

GitOps दो चीजें हैं:

1. कुबेरनेट्स और क्लाउड मूल के लिए ऑपरेशन मॉडल। यह कंटेनरीकृत समूहों और अनुप्रयोगों की तैनाती, प्रबंधन और निगरानी के लिए सर्वोत्तम प्रथाओं का एक सेट प्रदान करता है। लुइस फेसिरा से एक स्लाइड में सुरुचिपूर्ण परिभाषा:
   
   
2. एप्लिकेशन के प्रबंधन के लिए डेवलपर-उन्मुख वातावरण बनाने का मार्ग। हम शोषण और विकास दोनों के लिए Git वर्कफ़्लो लागू करते हैं। कृपया ध्यान दें कि यह केवल Git पुश के बारे में नहीं है, बल्कि CI / CD और UI / UX टूल के संपूर्ण सेट को व्यवस्थित करने के बारे में है।

Git के बारे में कुछ शब्द

यदि आप संस्करण नियंत्रण प्रणालियों और गिट-आधारित वर्कफ़्लो से परिचित नहीं हैं, तो हम दृढ़ता से अनुशंसा करते हैं कि आप उनका अध्ययन करें। सबसे पहले, शाखाओं और पुल अनुरोधों के साथ काम करना काले जादू की तरह लग सकता है, लेकिन पेशेवरों के प्रयास के लायक हैं। आपको शुरू करने के लिए यहां एक अच्छा लेख है।

कुबेरनेट कैसे काम करता है

हमारी कहानी में, ऐलिस और बॉब ने कुबेरनेट्स के साथ कुछ समय तक काम करने के बाद GitOps का रुख किया। वास्तव में, GitOps Kubernetes से निकटता से जुड़ा हुआ है - यह Kubernetes पर आधारित बुनियादी ढांचे और अनुप्रयोगों के लिए एक परिचालन मॉडल है।

कुबेरनेट्स उपयोगकर्ताओं को क्या देता है?

यहाँ कुछ प्रमुख विशेषताएं हैं:

1. कुबेरनेट्स मॉडल में, सब कुछ एक घोषणात्मक रूप में वर्णित किया जा सकता है।
2. कुबेरनेट्स एपीआई सर्वर इस तरह की घोषणा को इनपुट के रूप में स्वीकार करता है, और फिर घोषणा में वर्णित राज्य में क्लस्टर लाने की लगातार कोशिश करता है।
3. घोषणाएँ कार्य-भार की एक विस्तृत विविधता का वर्णन और प्रबंधन करने के लिए पर्याप्त हैं - "अनुप्रयोग।"
4. परिणामस्वरूप, अनुप्रयोग और क्लस्टर में परिवर्तन इस कारण से होते हैं:
   
   • कंटेनर छवियों में परिवर्तन;
   • घोषणात्मक विनिर्देश में परिवर्तन;
   • पर्यावरण में त्रुटियां - उदाहरण के लिए, कंटेनर क्रैश।

कुबेरनेट्स की महान अभिसरण क्षमता

जब कोई व्यवस्थापक कॉन्फ़िगरेशन परिवर्तन करता है, तो Kubernetes ऑर्केस्ट्रेटर उन्हें क्लस्टर पर लागू करेगा, जब तक कि उसका राज्य नया कॉन्फ़िगरेशन नहीं ले लेता। यह मॉडल किसी भी कुबेरनेट संसाधन के लिए काम करता है और कस्टम संसाधन परिभाषाओं (CRDs) के साथ विस्तारित होता है। इसलिए, कुबेरनेट की तैनाती में निम्नलिखित अद्भुत गुण हैं:

• स्वचालन : कुबेरनेट्स अपडेट सही तरीके से और समय पर परिवर्तन लागू करने की प्रक्रिया को स्वचालित करने के लिए एक तंत्र प्रदान करते हैं।
• अभिसरण : कुबेरनेट्स सफलता तक अपडेट का प्रयास करते रहेंगे।
• निष्पादकता : अभिसरण के बार-बार आवेदन एक ही परिणाम उत्पन्न करते हैं।
• नियतात्मकता : पर्याप्त संसाधनों के साथ, अद्यतन क्लस्टर की स्थिति केवल वांछित स्थिति पर निर्भर करती है।

कैसे GitOps काम करता है

हमने GubOps के काम करने के तरीके के बारे में बताने के लिए Kubernetes के बारे में पर्याप्त सीखा है।

आइए माइक्रोसेर्विस से संबंधित फैमिली इंश्योरेंस टीमों पर वापस जाएं। उन्हें आमतौर पर क्या करना है? नीचे दी गई सूची देखें (यदि इसमें कोई भी बिंदु अजीब या अपरिचित लगता है - कृपया आलोचना को स्थगित करें और हमारे साथ रहें)। ये जेनकिन्स-आधारित वर्कफ़्लोज़ के उदाहरण हैं। अन्य उपकरणों के साथ काम करते समय कई अन्य प्रक्रियाएं होती हैं।

मुख्य बात यह है कि हम देखते हैं कि प्रत्येक अद्यतन कॉन्फ़िगरेशन फ़ाइलों और गिट रिपॉजिटरी में परिवर्तन के साथ समाप्त होता है। Git में ये परिवर्तन क्लस्टर को अपडेट करने के लिए "GitOps स्टेटमेंट" का कारण बनता है:

1. वर्कफ़्लो: " जेनकिंस बिल्ड - मास्टर शाखा "।
कार्यों की सूची:

• जेनकिन्स ने क्वे में टैग की गई छवियों को धक्का दिया;
• जेनकिंस पुश'ट कॉन्फिग और हेलम चार्ट्स को मास्टर स्टोरेज बकेट;
• क्लाउड फ़ंक्शन मास्टर स्टोरेज बकेट से मास्टर गिट रिपॉजिटरी में कॉन्फ़िगरेशन और चार्ट की प्रतिलिपि बनाता है;
• GitOps विवरण क्लस्टर अद्यतन करता है।

2. जेनकींस बिल्ड - रिलीज़ या हॉटफ़िक्स शाखा :

• जेनकिंस ने क्वे में अप्रकाशित छवियों को धक्का दिया;
• जेनकिंस मचान और हेल्म चार्ट को मचान भंडारण के बाल्टी में धकेलता है;
• क्लाउड फ़ंक्शन, स्टेजिंग स्टोरेज की बाल्टी से Git रिपॉजिटरी स्टेजिंग के कॉन्फिग और चार्ट्स को कॉपी करता है;
• GitOps विवरण क्लस्टर अद्यतन करता है।

3. जेनकिंस का निर्माण - विकास या सुविधा शाखा :

• जेनकिंस ने क्वे में अप्रकाशित छवियों को धक्का दिया;
• जेनकिंस भंडारण बाल्टी को विकसित करने के लिए कॉन्फ़िगर और हेलम चार्ट को धक्का देता है;
• क्लाउड फ़ंक्शन कॉन्फिगरेशन बकेट से कॉन्फिडेंट और चार्ट्स को विकसित गैट रिपॉजिटरी में कॉपी करता है;
• GitOps विवरण क्लस्टर अद्यतन करता है।

4. एक नया ग्राहक जोड़ना :

• एक प्रबंधक या प्रशासक (एलसीएम / ऑप्स) ग्रैड को नेटवर्क लोड बैलेंसरों (एनएलबी) को शुरू में तैनात करने और कॉन्फ़िगर करने के लिए कहता है;
• LCM / ops अपडेट के लिए परिनियोजन तैयार करने के लिए एक नया कॉन्फिगर करता है;
• GitOps विवरण क्लस्टर अद्यतन करता है।

GitOps का संक्षिप्त विवरण

1. प्रत्येक वातावरण के लिए घोषणात्मक विशिष्टताओं का उपयोग करके पूरे सिस्टम की वांछित स्थिति का वर्णन करें (हमारे इतिहास में, बॉब टीम पूरे सिस्टम कॉन्फ़िगरेशन को गिट में परिभाषित करता है)।
   
   
   • संपूर्ण प्रणाली की इच्छित स्थिति के बारे में सच्चाई का एकमात्र स्रोत गिट रिपॉजिटरी है।
   • इच्छित स्थिति के सभी परिवर्तन Git में कमिट के माध्यम से किए जाते हैं।
   • सभी वांछित क्लस्टर पैरामीटर भी क्लस्टर में ही देखे जा सकते हैं। इस प्रकार, हम यह निर्धारित कर सकते हैं कि वांछित और देखे गए राज्य संयोग करते हैं (अभिसरण, अभिसरण ) या भिन्न ( विचलन , विचलन )।
2. यदि वांछित और देखे गए राज्य अलग-अलग हैं, तो:
   
   
   • एक अभिसरण तंत्र है जो जितनी जल्दी या बाद में स्वचालित रूप से लक्ष्य और मनाया राज्यों को सिंक्रनाइज़ करता है। क्लस्टर के अंदर, कुबेरनेट्स ऐसा करता है।
   • प्रक्रिया तुरंत "परिवर्तन प्रतिबद्ध" अधिसूचना के साथ शुरू होती है।
   • कुछ विन्यास योग्य समय के बाद, राज्यों को अलग-अलग होने पर एक अलग चेतावनी भेजी जा सकती है।
3. इस प्रकार, सभी Git ट्रिगर क्लस्टर में verifiable और idempotent अद्यतन ट्रिगर करता है।
   
   
   • रोलबैक पहले से वांछित स्थिति का एक अभिसरण है।
4. अभिसरण अंतिम है। इसकी शुरुआत की गवाही दें:
   
   
   • एक निश्चित अवधि के लिए "भिन्न" अलर्ट का अभाव।
   • एक परिवर्तित चेतावनी (उदाहरण के लिए, webhook, Git राइटबैक ईवेंट)।

विचलन क्या है?

हम फिर से दोहराते हैं: क्लस्टर के सभी वांछित गुण क्लस्टर में ही अवलोकन करने योग्य होने चाहिए ।

विचलन के कुछ उदाहरण:

• Git में शाखाओं के विलय के कारण कॉन्फ़िगरेशन फ़ाइल में परिवर्तन।
• जीयूआई क्लाइंट द्वारा किए गए गिट में एक कमिट के कारण कॉन्फ़िगरेशन फ़ाइल में बदलाव।
• कंटेनर छवि के बाद की असेंबली के साथ गिट में पीआर के कारण वांछित स्थिति में कई बदलाव और कॉन्फ़िगरेशन में परिवर्तन।
• क्लस्टर स्थिति एक त्रुटि, "खराब व्यवहार" या मूल स्थिति से सिर्फ एक आकस्मिक विचलन के कारण संसाधन संघर्ष के कारण बदल जाती है।

अभिसरण तंत्र क्या है?

कुछ उदाहरण:

• कंटेनरों और समूहों के लिए, अभिसरण तंत्र कुबेरनेट प्रदान करता है।
• कुबेरनेट्स-आधारित अनुप्रयोगों और डिज़ाइनों (जैसे, इस्तियो और कुब्लाफ़्लो) के प्रबंधन के लिए एक ही तंत्र का उपयोग किया जा सकता है।
• कुबेरनेट्स, छवि रिपॉजिटरी और गिट के बीच कामकाजी इंटरैक्शन को प्रबंधित करने का तंत्र वीव फ्लक्स गिटोपीएस स्टेटमेंट द्वारा दिया गया है , जो वीव क्लाउड का हिस्सा है।
• आधार मशीनों के लिए, अभिसरण तंत्र को घोषणात्मक और स्वायत्त होना चाहिए। अपने स्वयं के अनुभव से, हम कह सकते हैं कि टेराफॉर्म इस परिभाषा के सबसे करीब है, लेकिन अभी भी मानव नियंत्रण की आवश्यकता है। इस अर्थ में, GitOps इन्फ्रास्ट्रक्चर की परंपरा को कोड के रूप में विस्तारित करता है।

GitOps, Git को Kubernetes के उत्कृष्ट अभिसरण इंजन के साथ जोड़ता है, जो ऑपरेशन के लिए एक मॉडल पेश करता है।

GitOps हमें यह घोषित करने की अनुमति देता है कि केवल उन्हीं प्रणालियों को वर्णित और देखा जा सकता है जिन्हें स्वचालित और नियंत्रित किया जा सकता है ।

GitOps पूरे क्लाउड देशी स्टैक (जैसे टेराफॉर्म, आदि) के लिए है।

GitOps केवल Kubernetes नहीं है। हम चाहते हैं कि संपूर्ण प्रणाली को घोषित रूप से प्रबंधित किया जाए और अभिसरण का उपयोग किया जाए। एक संपूर्ण प्रणाली से हमारा मतलब है कि कुबेरनेट्स के साथ काम करने वाले वातावरण का एक सेट - उदाहरण के लिए, "देव क्लस्टर 1", "उत्पादन", आदि। प्रत्येक पर्यावरण में मशीन, क्लस्टर, एप्लिकेशन, साथ ही बाहरी सेवाओं के लिए इंटरफेस शामिल हैं जो डेटा, निगरानी और आदि प्रदान करते हैं। एम। पी।

ध्यान दें कि बूटस्ट्रैपिंग समस्या के लिए टेराफॉर्म इस मामले में कैसे महत्वपूर्ण है। कुबेरनेट्स को कहीं तैनात करने की आवश्यकता है, और टेराफॉर्म का उपयोग करने का अर्थ है कि हम कुबेरनेट्स और अनुप्रयोगों को समझने वाली नियंत्रण परत बनाने के लिए समान GitOps वर्कफ़्लोज़ का उपयोग कर सकते हैं। यह एक अच्छा सर्वोत्तम अभ्यास है।

कुबेरनेट्स की परतों पर GitOps अवधारणाओं को लागू करने पर बहुत ध्यान दिया जाता है। वर्तमान में इस्तियो, हेल्म, कोन्सनेट, ओपनफैस और क्यूबफ्लो के लिए गिट्स-प्रकार के समाधान हैं, साथ ही, उदाहरण के लिए, पुलुमी, जो क्लाउड देशी के लिए विकासशील अनुप्रयोगों के लिए एक परत बनाते हैं।

Kubernetes CI / CD: GitOps की अन्य तरीकों से तुलना करना

जैसा कि कहा गया है, GitOps दो चीजें हैं:

1. ऊपर वर्णित कुबेरनेट्स और क्लाउड देशी के लिए परिचालन मॉडल।
2. डेवलपर-केंद्रित अनुप्रयोग प्रबंधन परिवेश को व्यवस्थित करने का पथ।

कई लोगों के लिए, GitOps मुख्य रूप से एक Git पुश-आधारित वर्कफ़्लो है। हम भी उसे पसंद करते हैं। लेकिन यह सब नहीं है: चलो अब सीआई / सीडी पाइपलाइनों को देखें।

GitOps, Kubernetes के लिए निरंतर तैनाती (CD) प्रदान करता है

GitOps एक निरंतर तैनाती तंत्र प्रदान करता है जो अलग "तैनाती प्रबंधन प्रणालियों" की आवश्यकता को समाप्त करता है। कुबेरनेट आपके लिए सभी काम करता है।

• एप्लिकेशन को अपडेट करने के लिए Git में अपडेट करना होगा। यह वांछित स्थिति में एक लेन-देन का उन्नयन है। "परिनियोजन" तब एक अद्यतन विवरण के आधार पर कुबेरनेट्स द्वारा क्लस्टर के भीतर किया जाता है।
• कुबेरनेट्स की बारीकियों के कारण, ये अपडेट अभिसरण हैं। यह निरंतर तैनाती के लिए एक तंत्र प्रदान करता है जिसमें सभी अपडेट परमाणु होते हैं।
• नोट: बुन क्लाउड एक GitOps ऑपरेटर प्रदान करता है जो Git और Kubernetes को एकीकृत करता है और आपको क्लस्टर की वांछित और वर्तमान स्थिति का मिलान करके एक सीडी चलाने की अनुमति देता है।

कुब्तेल और लिपियों के बिना

क्लस्टर को अपग्रेड करने के लिए Kubectl का उपयोग करने से बचें, और विशेष रूप से स्क्रिप्ट को kubectl कमांड के समूह में। इसके बजाय, GitOps पाइपलाइन के साथ, एक उपयोगकर्ता Git के माध्यम से अपने Kubernetes क्लस्टर को अपग्रेड कर सकता है।

लाभ में शामिल हैं:

1. शुद्धता । अद्यतनों के समूह को लागू किया जा सकता है, रूपांतरित किया जा सकता है और अंत में सत्यापन किया जा सकता है, जो हमें परमाणु परिनियोजन के लक्ष्य के करीब लाता है। इसके विपरीत, लिपियों का उपयोग अभिसरण की कोई गारंटी नहीं देता है (नीचे इस पर अधिक)।
2. सुरक्षा। केल्टी हाईटॉवर का हवाला देते हुए : "कुबेरनेट्स क्लस्टर तक स्वचालन उपकरण और प्रशासक तक पहुंच सीमित करें जो डिबगिंग या इसे बनाए रखने के लिए जिम्मेदार हैं।" सुरक्षा और अनुपालन पर मेरा प्रकाशन , साथ ही साथ लापरवाही से लिखी गई जेनकिंस लिपि से क्रेडेंशियल्स चोरी करके होमब्रे को हैक करने पर एक लेख देखें ।
3. उपयोगकर्ता अनुभव । कुबेटेल कुबेरनेट्स ऑब्जेक्ट मॉडल के यांत्रिकी को उजागर करता है, जो काफी जटिल है। आदर्श रूप में, उपयोगकर्ताओं को उच्च स्तर के अमूर्त स्तर पर सिस्टम के साथ बातचीत करनी चाहिए। यहां मैं फिर से केल्सी को संदर्भित करूंगा और इस तरह के फिर से शुरू करने की सलाह दूंगा।

CI और CD के बीच का अंतर

GitOps मौजूदा CI / CD मॉडल में सुधार करता है।

आधुनिक CI सर्वर ऑर्केस्ट्रेशन के लिए एक उपकरण है। विशेष रूप से, यह सीआई पाइपलाइनों को ऑर्केस्ट्रेट करने के लिए एक उपकरण है। इनमें बिल्ड, टेस्ट, ट्रंक में मर्ज आदि शामिल हैं। सीआई सर्वर जटिल मल्टी-स्टेप पाइपलाइनों के प्रबंधन को स्वचालित करते हैं। एक सामान्य प्रलोभन Kubernetes अद्यतन सेट के लिए एक स्क्रिप्ट बनाने और क्लस्टर में परिवर्तन को आगे बढ़ाने के लिए एक पाइपलाइन तत्व के रूप में निष्पादित करना है। वास्तव में, यह वही है जो कई विशेषज्ञ करते हैं। हालाँकि, यह इष्टतम नहीं है, और यहाँ क्यों है।

CI को ट्रंक में अपडेट करने के लिए उपयोग किया जाना चाहिए, और सीडी "आंतरिक" का प्रबंधन करने के लिए इन अपडेट के आधार पर कुबेरनेट क्लस्टर को स्वयं बदलना होगा। हम इसे सीआई पुश मॉडल के विपरीत सीडी के लिए पुल मॉडल कहते हैं। सीडी एक रनटाइम ऑर्केस्ट्रेशन का हिस्सा है।

क्यों सीआई सर्वर को कुबेरनेट में प्रत्यक्ष अपडेट के माध्यम से सीडी नहीं बनाना चाहिए

सीआई कार्यों के एक सेट के रूप में कुबेरनेट्स में सीधे अपडेट को ऑर्केस्ट्रेट करने के लिए सीआई सर्वर का उपयोग न करें। -, .

.

? CI- , , , ( ) . .

, deployment', ( CI-).

, , :

• ?
• ? — ?
• , ?
• ? ( )?

Git' , . - push' , - ; --.

, CI- CD:

• ; .
• CI- .
• . .
• .

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes

GitOps , , . , , . , , GitOps .

Kubernetes

. Git :

• , Git .
• Runtime GitOps, . Git .

?

1. : , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
2. CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
3. : Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .

निष्कर्ष

GitOps , CI/CD:

• ;
• ;
• ;
• .

, cloud native.

• , runbook' ( — . .) , deployment'.
• cloud native- , .

, . GitOps - .

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

• « werf 1.0 stable: GitOps, »;
• « GitOps: Pull Push »;
• « kubedog Kubernetes »;
• « Kubernetes ( ) ».