🖐🏾 ⏏️ 😼 GitOps: पुल और पुश तरीकों की तुलना करना 🏈 🐧 👊

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

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

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

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

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

तैनाती के तरीके

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

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

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

खींचो और धक्का दो

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

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

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

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

पेशेवरों:

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

विपक्ष :

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

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

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

पेशेवरों :

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

विपक्ष :

क्लस्टर तक पहुँचने का डेटा बिल्ड सिस्टम के अंदर स्थित है।
खींचने की प्रक्रिया के साथ तैनाती कंटेनरों को अपडेट करना अब भी आसान है।
यह सीडी सिस्टम पर बहुत निर्भर है, क्योंकि हमें जिन पाइपलाइनों की आवश्यकता होती है, वे संभवतः गीतालाब रनर्स के लिए लिखी जाती हैं, और फिर टीम एज़्योर देवओप्स या जेनकिंस पर स्विच करने का निर्णय लेती है ... और आपको बड़ी संख्या में बिल्ड पाइपलाइनों को स्थानांतरित करना होगा।

निचला रेखा: पुश या पुल?

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

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

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

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

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

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

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

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

हमने दोनों मॉडलों का परीक्षण किया और लेख के लेखक के समान निष्कर्ष पर आए:

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

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

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

GitOps: पुल और पुश तरीकों की तुलना करना