GitOps: पुल और पुश विधियों की तुलना

टिप्पणी। अनुवाद।: कुबेरनेट्स समुदाय में, GitOps नामक एक प्रवृत्ति स्पष्ट लोकप्रियता प्राप्त कर रही है, जैसा कि हमने व्यक्तिगत रूप से देखा है, दौरा KubeCon यूरोप 2019. यह शब्द अपेक्षाकृत नया था गढ़ा वीववर्क्स के प्रमुख - एलेक्सिस रिचर्डसन द्वारा - और इसका अर्थ परिचालन समस्याओं को हल करने के लिए डेवलपर्स (मुख्य रूप से गिट, इसलिए नाम) से परिचित उपकरणों का उपयोग है। विशेष रूप से, हम कुबेरनेट्स के कॉन्फ़िगरेशन को Git में संग्रहीत करके और क्लस्टर में परिवर्तनों को स्वचालित रूप से रोल आउट करके संचालित करने के बारे में बात कर रहे हैं। मैथियास जेजी इस लेख में इस रोलआउट के दो दृष्टिकोणों के बारे में बात करते हैं।

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

इस दृष्टिकोण के मुख्य लाभ इस प्रकार हैं::

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

जैसा कि आप देख सकते हैं, GitOps पद्धति के कई लाभ हैं। पिछले वर्ष में, दो दृष्टिकोणों ने विशेष लोकप्रियता हासिल की है। एक पुश आधारित है, दूसरा पुल आधारित है। इससे पहले कि हम उन पर नज़र डालें, आइए देखें कि विशिष्ट कुबेरनेट्स तैनाती कैसी दिखती है।

परिनियोजन के तरीके

हाल के वर्षों में, कुबेरनेट्स ने तैनाती के लिए विभिन्न तरीके और उपकरण स्थापित किए हैं:

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

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

खींचे धक्का दें

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

नायब! GitOps का उपयोग करने के सभी लाभ दोनों दृष्टिकोणों के लिए समान हैं।

खींच आधारित दृष्टिकोण

पुल दृष्टिकोण इस तथ्य पर आधारित है कि सभी परिवर्तन क्लस्टर के भीतर से लागू होते हैं। क्लस्टर के अंदर एक ऑपरेटर होता है जो नियमित रूप से संबंधित Git और Docker रजिस्ट्री रिपॉजिटरी की जाँच करता है। यदि उनमें कोई परिवर्तन होता है, तो क्लस्टर की स्थिति आंतरिक रूप से अद्यतन की जाती है। इस प्रक्रिया को आम तौर पर बहुत सुरक्षित माना जाता है, क्योंकि किसी भी बाहरी क्लाइंट के पास क्लस्टर व्यवस्थापक अधिकारों तक पहुंच नहीं होती है।

पेशेवरों:

1. किसी भी बाहरी क्लाइंट के पास क्लस्टर में परिवर्तन करने का अधिकार नहीं है; सभी अपडेट भीतर से ही जारी किए जाते हैं।
2. कुछ उपकरण आपको हेल्म चार्ट अपडेट को सिंक्रनाइज़ करने और उन्हें क्लस्टर से लिंक करने की भी अनुमति देते हैं।
3. नए संस्करणों के लिए डॉकर रजिस्ट्री को स्कैन किया जा सकता है। यदि कोई नई छवि उपलब्ध है, तो Git रिपॉजिटरी और परिनियोजन को नए संस्करण में अपडेट किया जाता है।
4. पुल टूल को विभिन्न Git रिपॉजिटरी और अनुमतियों के साथ विभिन्न नामस्थानों में वितरित किया जा सकता है। इसके लिए धन्यवाद, एक मल्टीटेनेंट मॉडल का उपयोग किया जा सकता है। उदाहरण के लिए, टीम ए नेमस्पेस ए का उपयोग कर सकती है, टीम बी नेमस्पेस बी का उपयोग कर सकती है, और इंफ्रास्ट्रक्चर टीम ग्लोबल स्पेस का उपयोग कर सकती है।
5. एक नियम के रूप में, उपकरण बहुत हल्के होते हैं।
6. ऑपरेटर जैसे उपकरणों के साथ संयुक्त बिटनामी सीलबंद रहस्य, रहस्यों को Git रिपॉजिटरी में एन्क्रिप्टेड संग्रहीत किया जा सकता है और क्लस्टर के भीतर पुनर्प्राप्त किया जा सकता है।
7. सीडी पाइपलाइनों से कोई संबंध नहीं है क्योंकि तैनाती क्लस्टर के भीतर होती है।

विपक्ष:

1. हेल्म चार्ट से परिनियोजन रहस्यों को प्रबंधित करना नियमित चार्टों की तुलना में अधिक कठिन है, क्योंकि उन्हें पहले सीलबंद रहस्यों के रूप में उत्पन्न करना होता है, फिर एक आंतरिक ऑपरेटर द्वारा डिक्रिप्ट किया जाता है, और उसके बाद ही वे पुल टूल के लिए उपलब्ध होते हैं। फिर आप पहले से ही तैनात रहस्यों में मूल्यों के साथ हेल्म में रिलीज चला सकते हैं। सबसे आसान तरीका यह है कि तैनाती के लिए उपयोग किए जाने वाले सभी हेल्म मूल्यों के साथ एक रहस्य बनाएं, इसे डिक्रिप्ट करें और इसे गिट में प्रतिबद्ध करें।
2. जब आप खींचने का तरीका अपनाते हैं, तो आप खींचने वाले औजारों से बंध जाते हैं। यह क्लस्टर में परिनियोजन प्रक्रिया को अनुकूलित करने की क्षमता को सीमित करता है। उदाहरण के लिए, कस्टमाइज़ इस तथ्य से जटिल है कि इसे अंतिम टेम्प्लेट Git के लिए प्रतिबद्ध होने से पहले चलना होगा। मैं यह नहीं कह रहा हूं कि आप स्टैंडअलोन टूल का उपयोग नहीं कर सकते, लेकिन उन्हें आपकी तैनाती प्रक्रिया में एकीकृत करना अधिक कठिन है।

पुश आधारित दृष्टिकोण

पुश दृष्टिकोण में, एक बाहरी सिस्टम (मुख्य रूप से सीडी पाइपलाइन) गिट रिपॉजिटरी के लिए प्रतिबद्ध होने के बाद या पिछली सीआई पाइपलाइन सफल होने पर क्लस्टर में तैनाती शुरू करता है। इस दृष्टिकोण में, सिस्टम की क्लस्टर तक पहुंच होती है।

पेशेवरों:

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

विपक्ष:

1. क्लस्टर एक्सेस डेटा बिल्ड सिस्टम के अंदर है।
2. पुल प्रक्रिया के साथ परिनियोजन कंटेनरों को अद्यतन करना अभी भी आसान है।
3. सीडी सिस्टम पर भारी निर्भरता, क्योंकि हमें जिन पाइपलाइनों की आवश्यकता है, वे मूल रूप से गिटलैब रनर के लिए लिखी गई होंगी, और फिर टीम Azure DevOps या जेनकिंस में जाने का फैसला करती है... और बड़ी संख्या में बिल्ड पाइपलाइनों को स्थानांतरित करना होगा।

परिणाम: धक्का दें या खींचें?

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

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

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

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

मुझे आशा है कि इस विषय पर मेरा अनुभव आपको यह निर्णय लेने में मदद करेगा कि आपके प्रकार की तैनाती के लिए कौन सी विधि अधिक उपयुक्त है, और मुझे आपकी राय सुनकर खुशी होगी।

अनुवादक से पुनश्च नोट

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

इस अर्थ में, पुश मॉडल हमें रोलआउट की कम से कम कुछ गारंटी प्रदान करने की अनुमति देता है, क्योंकि पाइपलाइन का जीवनकाल रोलआउट के जीवनकाल के बराबर बनाया जा सकता है।

हमने दोनों मॉडलों को आज़माया और लेख के लेखक के समान निष्कर्ष पर पहुंचे:

1. बड़ी संख्या में क्लस्टर पर सिस्टम घटकों के अपडेट को व्यवस्थित करने के लिए पुल मॉडल हमारे लिए उपयुक्त है (देखें)। ऐडऑन-ऑपरेटर के बारे में लेख).
2. GitLab CI पर आधारित पुश मॉडल हेल्म चार्ट का उपयोग करके एप्लिकेशन को रोल आउट करने के लिए उपयुक्त है। साथ ही, टूल का उपयोग करके पाइपलाइनों के भीतर तैनाती के रोलआउट की निगरानी की जाती है Werf. वैसे, हमारे इस प्रोजेक्ट के संदर्भ में, जब हमने KubeCon यूरोप'19 में अपने स्टैंड पर DevOps इंजीनियरों की गंभीर समस्याओं पर चर्चा की, तो हमने लगातार "GitOps" सुना।

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

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

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

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

क्या आप GitOps का उपयोग कर रहे हैं?

• हाँ, दृष्टिकोण खींचो

• हाँ, धक्का

• हाँ, खींचो + धक्का दो

• हाँ, कुछ और

• नहीं

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

स्रोत: www.habr.com