GitOps क्या है?

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

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

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

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

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

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

GitOps से मिलें

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

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

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

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

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

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

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

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

क्या हुआ?

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

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

गिट के बारे में कुछ शब्द

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

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

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

Kubernetes उपयोगकर्ताओं को क्या देता है?

यहां कुछ मुख्य विशेषताएं दी गई हैं:

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

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

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

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

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

GitOps कैसे काम करता है, यह समझाने के लिए हमने Kubernetes के बारे में काफी कुछ सीखा है।

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

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

1.कार्य प्रक्रिया: "जेनकींस बिल्ड - मास्टर शाखा'.
कार्य सूची:

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

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

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

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

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

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

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

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

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

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

आइए इसे दोबारा दोहराएं: सभी वांछित क्लस्टर गुण क्लस्टर में ही देखने योग्य होने चाहिए.

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

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

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

कुछ उदाहरण:

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

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

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

GitOps संपूर्ण क्लाउड नेटिव स्टैक (उदाहरण के लिए, टेराफ़ॉर्म, आदि) के लिए अभिप्रेत है।

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

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

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

कुबेरनेट्स सीआई/सीडी: GitOps की अन्य दृष्टिकोणों से तुलना करना

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

1. कुबेरनेट्स और क्लाउड नेटिव के लिए ऑपरेटिंग मॉडल ऊपर वर्णित है।
2. डेवलपर-केंद्रित एप्लिकेशन प्रबंधन वातावरण का मार्ग।

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

GitOps कुबेरनेट्स के लिए निरंतर तैनाती (सीडी) को सक्षम बनाता है

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

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

Kubectl और स्क्रिप्ट के बिना

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

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

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

सीआई और सीडी के बीच अंतर

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

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

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

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

सीआई नौकरियों के एक सेट के रूप में कुबेरनेट्स पर सीधे अपडेट व्यवस्थित करने के लिए सीआई सर्वर का उपयोग न करें। यह वह विरोधी पैटर्न है जिसके बारे में हम बात कर रहे हैं पहले ही बता दिया आपके ब्लॉग पर।

आइए ऐलिस और बॉब पर वापस जाएँ।

उन्हें किन समस्याओं का सामना करना पड़ा? बॉब का सीआई सर्वर क्लस्टर में परिवर्तन लागू करता है, लेकिन यदि यह प्रक्रिया में क्रैश हो जाता है, तो बॉब को पता नहीं चलेगा कि क्लस्टर किस स्थिति में है (या होना चाहिए) या इसे कैसे ठीक किया जाए। सफलता के मामले में भी यही सच है.

आइए मान लें कि बॉब की टीम ने एक नई छवि बनाई और फिर छवि को तैनात करने के लिए अपनी तैनाती को पैच किया (सभी सीआई पाइपलाइन से)।

यदि छवि सामान्य रूप से बनती है, लेकिन पाइपलाइन विफल हो जाती है, तो टीम को इसका पता लगाना होगा:

• क्या अपडेट जारी हो गया है?
• क्या हम एक नया निर्माण लॉन्च कर रहे हैं? क्या इससे अनावश्यक दुष्प्रभाव होंगे - एक ही अपरिवर्तनीय छवि के दो निर्माण होने की संभावना के साथ?
• क्या हमें बिल्ड चलाने से पहले अगले अपडेट की प्रतीक्षा करनी चाहिए?
• वास्तव में क्या गलत हुआ? कौन से चरण दोहराए जाने की आवश्यकता है (और कौन से चरण दोहराना सुरक्षित हैं)?

Git-आधारित वर्कफ़्लो स्थापित करने से यह गारंटी नहीं मिलती कि बॉब की टीम को इन समस्याओं का सामना नहीं करना पड़ेगा। वे अभी भी कमिट पुश, टैग या किसी अन्य पैरामीटर के साथ गलती कर सकते हैं; हालाँकि, यह दृष्टिकोण अभी भी स्पष्ट सभी-या-कुछ नहीं दृष्टिकोण के बहुत करीब है।

संक्षेप में कहें तो, यहां बताया गया है कि सीआई सर्वर को सीडी से क्यों नहीं निपटना चाहिए:

• अद्यतन स्क्रिप्ट हमेशा नियतात्मक नहीं होती हैं; उनमें ग़लतियाँ करना आसान है.
• सीआई सर्वर घोषणात्मक क्लस्टर मॉडल में परिवर्तित नहीं होते हैं।
• निष्क्रियता की गारंटी देना कठिन है। उपयोगकर्ताओं को सिस्टम के गहन शब्दार्थ को समझना चाहिए।
• आंशिक विफलता से उबरना अधिक कठिन होता है।

हेल्म के बारे में नोट: यदि आप हेल्म का उपयोग करना चाहते हैं, तो हम इसे GitOps ऑपरेटर के साथ संयोजित करने की सलाह देते हैं फ्लक्स-हेल्म. इससे अभिसरण सुनिश्चित करने में मदद मिलेगी. हेल्म स्वयं न तो नियतिवादी है और न ही परमाणु।

कुबेरनेट्स के लिए सतत वितरण को लागू करने का सबसे अच्छा तरीका GitOps है

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

कुबेरनेट्स के लिए ऑपरेटिंग मॉडल

निम्नलिखित चित्र को देखें. यह Git और कंटेनर छवि भंडार को दो व्यवस्थित जीवनचक्रों के लिए साझा संसाधनों के रूप में प्रस्तुत करता है:

• एक सतत एकीकरण पाइपलाइन जो Git में फ़ाइलों को पढ़ती और लिखती है और कंटेनर छवियों के भंडार को अद्यतन कर सकती है।
• एक रनटाइम GitOps पाइपलाइन जो प्रबंधन और अवलोकन के साथ तैनाती को जोड़ती है। यह Git में फ़ाइलें पढ़ता और लिखता है और कंटेनर छवियां डाउनलोड कर सकता है।

मुख्य निष्कर्ष क्या हैं?

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

निष्कर्ष

GitOps किसी भी आधुनिक CI/CD उपकरण के लिए आवश्यक मजबूत अद्यतन गारंटी प्रदान करता है:

• स्वचालन;
• अभिसरण;
• निष्क्रियता;
• नियतिवाद

यह महत्वपूर्ण है क्योंकि यह क्लाउड नेटिव डेवलपर्स के लिए एक परिचालन मॉडल प्रदान करता है।

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

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

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

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

• «GitOps: पुल और पुश विधियों की तुलना";
• «कुबेरनेट्स संसाधनों पर नज़र रखने के लिए एक पुस्तकालय, कुबेडॉग का परिचय";
• «कुबेरनेट्स का विस्तार और पूरक (समीक्षा और वीडियो रिपोर्ट)'.

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आप Habré पर इन दो अनुवादों के प्रदर्शित होने से पहले GitOps के बारे में जानते थे?

• हाँ, मैं सब कुछ जानता था

• केवल सतही तौर पर

• नहीं

35 उपयोगकर्ताओं ने मतदान किया। 10 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com