GitOps: पुल आणि पुश पद्धतींची तुलना

नोंद. अनुवाद: Kubernetes समुदायामध्ये, GitOps नावाचा ट्रेंड स्पष्टपणे लोकप्रिय होत आहे, जसे की आपण वैयक्तिकरित्या पाहिले आहे, भेट देऊन KubeCon Europe 2019. ही संज्ञा तुलनेने अलीकडील होती शोध लावला Weaveworks च्या प्रमुखाद्वारे - अॅलेक्सिस रिचर्डसन - आणि याचा अर्थ विकासकांना परिचित असलेल्या साधनांचा वापर (प्रामुख्याने Git, म्हणून नाव) ऑपरेशनल समस्या सोडवण्यासाठी. विशेषतः, आम्ही Git मध्ये त्याचे कॉन्फिगरेशन संचयित करून आणि क्लस्टरमधील बदल स्वयंचलितपणे रोलआउट करून कुबरनेटच्या ऑपरेशनबद्दल बोलत आहोत. मॅथियास जेजी या लेखात या रोलआउटच्या दोन दृष्टिकोनांबद्दल बोलतो.

मागील वर्षी (खरं तर, औपचारिकपणे हे ऑगस्ट 2017 मध्ये घडले - अंदाजे भाषांतर.) Kubernetes मध्ये अनुप्रयोग तैनात करण्यासाठी एक नवीन दृष्टीकोन आहे. याला GitOps म्हणतात, आणि ते Git भांडाराच्या सुरक्षित वातावरणात उपयोजन आवृत्त्या ट्रॅक केल्या जातात या मूळ कल्पनेवर आधारित आहे.

या पद्धतीचे मुख्य फायदे खालीलप्रमाणे आहेत::

1. उपयोजन आवृत्ती आणि बदल इतिहास. संपूर्ण क्लस्टरची स्थिती Git रेपॉजिटरीमध्ये संग्रहित केली जाते आणि उपयोजन केवळ कमिटद्वारे अद्यतनित केले जातात. याव्यतिरिक्त, कमिट इतिहास वापरून सर्व बदलांचा मागोवा घेतला जाऊ शकतो.
2. परिचित Git आदेश वापरून रोलबॅक. सोपे git reset तुम्हाला उपयोजनांमधील बदल रीसेट करण्याची परवानगी देते; भूतकाळातील स्थिती नेहमी उपलब्ध असतात.
3. तयार प्रवेश नियंत्रण. सामान्यतः, Git सिस्टममध्ये खूप संवेदनशील डेटा असतो, म्हणून बहुतेक कंपन्या त्याचे संरक्षण करण्यासाठी विशेष लक्ष देतात. त्यानुसार, हे संरक्षण तैनातीसह ऑपरेशन्सवर देखील लागू होते.
4. तैनातीसाठी धोरणे. बर्‍याच Git सिस्टीम मुळात शाखा-दर-शाखा धोरणांना समर्थन देतात-उदाहरणार्थ, फक्त पुल विनंत्या मास्टर अपडेट करू शकतात आणि बदलांचे पुनरावलोकन करणे आणि दुसर्‍या कार्यसंघ सदस्याने स्वीकारले पाहिजे. प्रवेश नियंत्रणाप्रमाणे, समान धोरणे उपयोजन अद्यतनांवर लागू होतात.

तुम्ही बघू शकता, GitOps पद्धतीचे बरेच फायदे आहेत. गेल्या वर्षभरात, दोन पद्धतींनी विशेष लोकप्रियता मिळवली आहे. एक पुश आधारित आहे, दुसरा पुल आधारित आहे. आपण ते पाहण्याआधी, प्रथम कुबर्नेट्स उपयोजन कशा दिसतात ते पाहू.

उपयोजन पद्धती

अलिकडच्या वर्षांत, कुबर्नेट्समध्ये उपयोजनासाठी विविध पद्धती आणि साधने स्थापित झाली आहेत:

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

आमच्या कामात, आम्ही महत्त्वाच्या साधनांसाठी हेल्म चार्ट वापरतो (कारण त्यांच्याकडे बर्‍याच गोष्टी आधीच तयार आहेत, ज्यामुळे जीवन खूप सोपे होते) आणि आमचे स्वतःचे अनुप्रयोग उपयोजित करण्यासाठी "शुद्ध" Kubernetes YAML फाइल्स.

ओढा ढकला

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

एनबी! GitOps वापरण्याचे सर्व फायदे दोन्ही पद्धतींसाठी सारखेच राहतात.

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

पुलाचा दृष्टिकोन या वस्तुस्थितीवर आधारित आहे की सर्व बदल क्लस्टरमधून लागू केले जातात. क्लस्टरमध्ये एक ऑपरेटर आहे जो संबंधित गिट आणि डॉकर रेजिस्ट्री रेपॉजिटरीज नियमितपणे तपासतो. त्यांच्यामध्ये कोणतेही बदल आढळल्यास, क्लस्टरची स्थिती अंतर्गत अद्यतनित केली जाते. ही प्रक्रिया सामान्यतः अतिशय सुरक्षित मानली जाते, कारण कोणत्याही बाह्य क्लायंटला क्लस्टर प्रशासक अधिकारांमध्ये प्रवेश नाही.

साधक:

1. कोणत्याही बाह्य क्लायंटला क्लस्टरमध्ये बदल करण्याचे अधिकार नाहीत; सर्व अद्यतने आतून आणली जातात.
2. काही टूल्स तुम्हाला हेल्म चार्ट अपडेट्स सिंक्रोनाइझ करण्याची आणि त्यांना क्लस्टरशी लिंक करण्याची परवानगी देतात.
3. डॉकर रेजिस्ट्री नवीन आवृत्त्यांसाठी स्कॅन केली जाऊ शकते. नवीन प्रतिमा उपलब्ध असल्यास, Git रेपॉजिटरी आणि उपयोजन नवीन आवृत्तीमध्ये अद्यतनित केले जातात.
4. पुल टूल्स वेगवेगळ्या नेमस्पेसमध्ये वेगवेगळ्या Git रिपॉझिटरीज आणि परवानग्यांसह वितरित केले जाऊ शकतात. याबद्दल धन्यवाद, मल्टीटेनंट मॉडेल वापरले जाऊ शकते. उदाहरणार्थ, टीम ए नेमस्पेस A वापरू शकते, टीम बी नेमस्पेस बी वापरू शकते आणि इन्फ्रास्ट्रक्चर टीम ग्लोबल स्पेस वापरू शकते.
5. एक नियम म्हणून, साधने खूप हलके आहेत.
6. ऑपरेटर सारख्या साधनांसह एकत्रित बिटनामी सीलबंद रहस्ये, गुपिते Git रिपॉजिटरीमध्ये एनक्रिप्टेड संग्रहित केली जाऊ शकतात आणि क्लस्टरमध्ये पुनर्प्राप्त केली जाऊ शकतात.
7. क्लस्टरमध्ये उपयोजन होत असल्याने सीडी पाइपलाइनशी कोणतेही कनेक्शन नाही.

मिनिन्स:

1. हेल्म चार्ट्समधून डिप्लॉयमेंट सिक्रेट्स व्यवस्थापित करणे नेहमीच्या पेक्षा अधिक कठीण आहे, कारण ते आधी सीलबंद सिक्रेट्सच्या स्वरूपात तयार केले जावे, नंतर अंतर्गत ऑपरेटरद्वारे डिक्रिप्ट केले जावे आणि त्यानंतरच ते पुल टूलसाठी उपलब्ध होतील. मग तुम्ही हेल्ममध्ये आधीच तैनात केलेल्या रहस्यांमधील मूल्यांसह रिलीझ चालवू शकता. सर्वात सोपा मार्ग म्हणजे उपयोजनासाठी वापरल्या जाणार्‍या सर्व हेल्म मूल्यांसह एक रहस्य तयार करणे, ते डिक्रिप्ट करणे आणि ते गिटमध्ये कमिट करणे.
2. जेव्हा तुम्ही पुलाचा दृष्टीकोन घेता तेव्हा तुम्ही खेचण्याच्या साधनांशी बांधले असता. हे क्लस्टरमध्ये उपयोजन प्रक्रिया सानुकूलित करण्याची क्षमता मर्यादित करते. उदाहरणार्थ, Kustomize हे क्लिष्ट आहे की अंतिम टेम्पलेट्स Git ला वचनबद्ध होण्यापूर्वी ते चालणे आवश्यक आहे. मी असे म्हणत नाही की तुम्ही स्वतंत्र साधने वापरू शकत नाही, परंतु ते तुमच्या उपयोजन प्रक्रियेत समाकलित करणे अधिक कठीण आहे.

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

पुश अप्रोचमध्ये, बाह्य प्रणाली (मुख्यतः CD पाइपलाइन) Git रिपॉझिटरीशी कमिट केल्यानंतर किंवा मागील CI पाइपलाइन यशस्वी झाल्यास क्लस्टरमध्ये तैनाती सुरू करते. या दृष्टिकोनामध्ये, सिस्टमला क्लस्टरमध्ये प्रवेश आहे.

Плюсы:

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

मिनिन्स:

1. क्लस्टर ऍक्सेस डेटा बिल्ड सिस्टममध्ये आहे.
2. उपयोजन कंटेनर अद्यतनित करणे पुल प्रक्रियेसह अद्याप सोपे आहे.
3. सीडी सिस्टीमवर खूप अवलंबित्व, कारण आम्हाला आवश्यक असलेल्या पाइपलाइन कदाचित गिटलॅब रनर्ससाठी लिहिल्या गेल्या असतील आणि त्यानंतर टीमने Azure DevOps किंवा Jenkins वर जाण्याचा निर्णय घेतला... आणि मोठ्या प्रमाणात बिल्ड पाइपलाइन स्थलांतरित कराव्या लागतील.

परिणाम: पुश किंवा पुल?

सामान्यतः प्रमाणेच, प्रत्येक दृष्टिकोनाचे त्याचे फायदे आणि तोटे आहेत. काही कार्ये एकाने पूर्ण करणे सोपे आणि दुसर्‍याने अधिक कठीण असते. सुरुवातीला मी स्वतः उपयोजने करत होतो, परंतु मी वीव्ह फ्लक्सबद्दल काही लेख पाहिल्यानंतर, मी सर्व प्रकल्पांसाठी GitOps प्रक्रिया लागू करण्याचा निर्णय घेतला. मूलभूत टेम्पलेट्ससाठी हे सोपे होते, परंतु नंतर मला हेल्म चार्टसह अडचणी येऊ लागल्या. त्या वेळी, विव्ह फ्लक्सने हेल्म चार्ट ऑपरेटरची केवळ एक प्राथमिक आवृत्ती ऑफर केली होती, परंतु आताही काही कार्ये व्यक्तिचलितपणे रहस्ये तयार करणे आणि ते लागू करणे आवश्यक असल्याने अधिक कठीण आहे. तुम्ही असा युक्तिवाद करू शकता की पुल दृष्टीकोन अधिक सुरक्षित आहे कारण क्लस्टरचे क्रेडेन्शियल्स क्लस्टरच्या बाहेर प्रवेश करण्यायोग्य नाहीत, ते इतके अधिक सुरक्षित बनवते की अतिरिक्त प्रयत्न करणे योग्य आहे.

थोडा विचार केल्यावर, मी अनपेक्षित निष्कर्षावर आलो की हे तसे नाही. जर आम्ही अशा घटकांबद्दल बोललो ज्यांना जास्तीत जास्त संरक्षण आवश्यक आहे, तर या सूचीमध्ये गुप्त स्टोरेज, CI/CD सिस्टम आणि Git रेपॉजिटरीज समाविष्ट असतील. त्यांच्यातील माहिती अतिशय असुरक्षित आहे आणि जास्तीत जास्त संरक्षणाची आवश्यकता आहे. याव्यतिरिक्त, जर कोणी तुमच्या Git रेपॉजिटरीमध्ये आला आणि तेथे कोड पुश करू शकतो, तर ते त्यांना हवे ते उपयोजित करू शकतात (मग ते पुल किंवा पुश) आणि क्लस्टरच्या सिस्टममध्ये घुसखोरी करू शकतात. अशा प्रकारे, सर्वात महत्वाचे घटक ज्यांना संरक्षित करणे आवश्यक आहे ते म्हणजे गिट रेपॉजिटरी आणि सीआय/सीडी सिस्टम, क्लस्टर क्रेडेन्शियल्स नव्हे. जर तुमच्याकडे या प्रकारच्या सिस्टीमसाठी धोरणे आणि सुरक्षा नियंत्रणे चांगल्या प्रकारे कॉन्फिगर केली असतील आणि क्लस्टर क्रेडेन्शियल्स केवळ गुपिते म्हणून पाइपलाइनमध्ये काढली गेली असतील, तर पुल दृष्टिकोनाची अतिरिक्त सुरक्षा मूळ विचार केल्याप्रमाणे मूल्यवान असू शकत नाही.

तर, जर पुलाचा दृष्टीकोन अधिक श्रम-केंद्रित असेल आणि सुरक्षितता लाभ देत नसेल, तर केवळ पुश दृष्टिकोन वापरणे तर्कसंगत नाही का? परंतु कोणीतरी असा युक्तिवाद करू शकतो की पुश पध्दतीमध्ये आपण सीडी सिस्टमशी खूप बांधलेले आहात आणि कदाचित, असे न करणे चांगले आहे जेणेकरून भविष्यात स्थलांतर करणे सोपे होईल.

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

मला आशा आहे की या विषयावरील माझा अनुभव तुम्हाला तुमच्या उपयोजन प्रकारासाठी कोणती पद्धत अधिक योग्य आहे हे ठरविण्यात मदत करेल आणि तुमचे मत ऐकून मला आनंद होईल.

अनुवादकाकडून पीएस टीप

पुल मॉडेलची नकारात्मक बाजू म्हणजे Git मध्ये रेंडर केलेले मॅनिफेस्ट ठेवणे कठीण आहे, परंतु पुल मॉडेलमधील सीडी पाइपलाइन रोलआउटपासून वेगळी राहते आणि मूलत: श्रेणी पाइपलाइन बनते असा कोणताही दोष नाही. सतत लागू करा. त्यामुळे, सर्व उपयोजनांमधून त्यांची स्थिती संकलित करण्यासाठी आणखी प्रयत्न करावे लागतील आणि शक्यतो सीडी प्रणालीच्या संदर्भात, लॉग/स्टेटसमध्ये प्रवेश प्रदान करा.

या अर्थाने, पुश मॉडेल आम्हाला रोलआउटची किमान काही हमी प्रदान करण्यास अनुमती देते, कारण पाइपलाइनचे आयुष्य रोलआउटच्या आयुष्याप्रमाणे केले जाऊ शकते.

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

1. पुल मॉडेल आमच्यासाठी मोठ्या संख्येने क्लस्टर्सवर सिस्टम घटकांचे अद्यतने आयोजित करण्यासाठी योग्य आहे (पहा. ऍडऑन-ऑपरेटर बद्दल लेख).
2. GitLab CI वर आधारित पुश मॉडेल हेल्म चार्ट वापरून ऍप्लिकेशन्स रोल आउट करण्यासाठी योग्य आहे. त्याच वेळी, टूल वापरून पाइपलाइनमधील उपयोजनांच्या रोलआउटचे परीक्षण केले जाते werf. तसे, आमच्या या प्रकल्पाच्या संदर्भात, जेव्हा आम्ही KubeCon Europe'19 येथे आमच्या स्टँडवर DevOps अभियंत्यांच्या गंभीर समस्यांबद्दल चर्चा केली तेव्हा आम्ही सतत “GitOps” ऐकले.

अनुवादकाकडून PPS

आमच्या ब्लॉगवर देखील वाचा:

• «Kubernetes टिपा आणि युक्त्या: हेल्म 2 व्यवस्थापनामध्ये क्लस्टरमध्ये चालू असलेली संसाधने हस्तांतरित करणे";
• «कुबेडॉग सादर करत आहे, कुबर्नेट्स संसाधनांचा मागोवा घेण्यासाठी एक लायब्ररी";
• «कुबर्नेट्सचा विस्तार आणि पूरक (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «GitLab CI मध्ये सानुकूल वर्कफ्लो तयार करण्यासाठी टिपा».

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुम्ही GitOps वापरत आहात?

• होय, पुल दृष्टिकोन

• होय, ढकलणे

• होय, पुल + पुश

• होय, दुसरे काहीतरी

• कोणत्याही

30 वापरकर्त्यांनी मतदान केले. 10 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com