GitOps म्हणजे काय?

नोंद. अनुवाद: अलीकडील प्रकाशनानंतर सामग्री GitOps मधील पुल आणि पुश पद्धतींबद्दल, आम्हाला सर्वसाधारणपणे या मॉडेलमध्ये स्वारस्य दिसले, परंतु या विषयावर रशियन भाषेतील फारच कमी प्रकाशने होती (हॅब्रेवर काहीही नाही). म्हणून, आम्हाला दुसर्‍या लेखाचे भाषांतर ऑफर करताना आम्हाला आनंद होत आहे - जरी जवळजवळ एक वर्षापूर्वी! - Weaveworks पासून, ज्याच्या प्रमुखाने "GitOps" हा शब्द तयार केला. मजकूर दृष्टिकोनाचे सार आणि अस्तित्वातील मुख्य फरक स्पष्ट करतो.

एक वर्षापूर्वी आम्ही प्रकाशित केले GitOps चा परिचय. तेव्हा मागे, आम्ही सामायिक केले की Weaveworks टीमने SaaS पूर्णपणे Kubernetes वर आधारित कसा लाँच केला आणि क्लाउड नेटिव्ह वातावरणात उपयोजित, व्यवस्थापित आणि देखरेख करण्यासाठी सर्वोत्कृष्ट पद्धतींचा संच विकसित केला.

लेख लोकप्रिय झाला. इतर लोक GitOps बद्दल बोलू लागले आणि नवीन साधने प्रकाशित करू लागले गिट पुश, विकास, गुपिते, कार्ये, सतत एकीकरण आणि असेच. आमच्या वेबसाइटवर दिसू लागले मोठी संख्या प्रकाशने आणि GitOps वापर प्रकरणे. पण तरीही काही लोकांचे प्रश्न आहेत. मॉडेल पारंपारिक मॉडेलपेक्षा वेगळे कसे आहे? कोड म्हणून पायाभूत सुविधा आणि सतत वितरण (सतत वितरण)? कुबर्नेट्स वापरणे आवश्यक आहे का?

आम्हाला लवकरच समजले की नवीन वर्णन आवश्यक आहे, ऑफर:

1. उदाहरणे आणि कथा मोठ्या संख्येने;
2. GitOps ची विशिष्ट व्याख्या;
3. पारंपारिक सतत वितरणाशी तुलना.

या लेखात आम्ही हे सर्व विषय मांडण्याचा प्रयत्न केला आहे. हे GitOps आणि विकासक आणि CI/CD दृष्टीकोन एक अद्यतनित परिचय प्रदान करते. आम्ही प्रामुख्याने कुबर्नेट्सवर लक्ष केंद्रित करतो, जरी मॉडेल सामान्यीकृत केले जाऊ शकते.

GitOps ला भेटा

अॅलिसची कल्पना करा. ती कौटुंबिक विमा चालवते, जी अशा लोकांना आरोग्य, वाहन, घर आणि प्रवास विमा देते जे स्वत: कराराचे इन्स आणि आउट्स शोधण्यात व्यस्त आहेत. अॅलिस डेटा सायंटिस्ट म्हणून बँकेत काम करत असताना तिचा व्यवसाय साइड प्रोजेक्ट म्हणून सुरू झाला. एके दिवशी तिला समजले की ती डेटाचे अधिक प्रभावीपणे विश्लेषण करण्यासाठी आणि विमा पॅकेज तयार करण्यासाठी प्रगत संगणक अल्गोरिदम वापरू शकते. गुंतवणूकदारांनी प्रकल्पासाठी वित्तपुरवठा केला आणि आता तिची कंपनी वर्षाला $20 दशलक्ष पेक्षा जास्त उत्पन्न आणते आणि वेगाने वाढत आहे. सध्या, विविध पदांवर 180 लोकांना रोजगार आहे. यामध्ये एक तंत्रज्ञान कार्यसंघ समाविष्ट आहे जो वेबसाइट, डेटाबेस विकसित करतो, देखरेख करतो आणि ग्राहक बेसचे विश्लेषण करतो. 60 लोकांच्या टीमचे नेतृत्व कंपनीचे तांत्रिक संचालक बॉब करत आहेत.

बॉबची टीम क्लाउडमध्ये उत्पादन प्रणाली तैनात करते. गुगल क्लाउडवरील कुबर्नेट्सचा फायदा घेऊन त्यांचे मूळ अनुप्रयोग GKE वर चालतात. याव्यतिरिक्त, ते त्यांच्या कामात विविध डेटा आणि विश्लेषण साधने वापरतात.

कौटुंबिक विमा कंटेनर वापरण्यासाठी सेट केले नाही, परंतु डॉकरच्या उत्साहात अडकले. कंपनीने लवकरच शोधून काढले की GKE ने नवीन वैशिष्ट्यांची चाचणी घेण्यासाठी क्लस्टर तैनात करणे सोपे केले आहे. कंटेनर रेजिस्ट्री व्यवस्थित करण्यासाठी CI आणि Quay साठी जेनकिन्स जोडले गेले, जेनकिन्ससाठी स्क्रिप्ट लिहिल्या गेल्या ज्याने नवीन कंटेनर आणि कॉन्फिगरेशन GKE कडे ढकलले.

काही काळ गेला. अॅलिस आणि बॉब त्यांच्या निवडलेल्या पध्दतीच्या कामगिरीमुळे आणि व्यवसायावर त्याचा परिणाम पाहून निराश झाले. कंटेनरच्या परिचयामुळे उत्पादनात तितकी सुधारणा झाली नाही जितकी टीमने अपेक्षा केली होती. काहीवेळा उपयोजन खंडित होईल, आणि कोड बदल दोषी आहेत की नाही हे अस्पष्ट होते. कॉन्फिगरेशनमधील बदलांचा मागोवा घेणे देखील अवघड असल्याचे दिसून आले. बर्‍याचदा नवीन क्लस्टर तयार करणे आणि त्यावर ऍप्लिकेशन्स हलवणे आवश्यक होते, कारण सिस्टममध्ये झालेला गोंधळ दूर करण्याचा हा सर्वात सोपा मार्ग होता. अॅलिसला भीती होती की अॅप्लिकेशन विकसित झाल्यामुळे परिस्थिती आणखी वाईट होईल (याशिवाय, मशीन लर्निंगवर आधारित एक नवीन प्रकल्प तयार होत आहे). बॉबने बहुतेक काम स्वयंचलित केले होते आणि पाइपलाइन अद्याप अस्थिर का आहे, योग्य प्रमाणात नाही आणि वेळोवेळी मॅन्युअल हस्तक्षेप का आवश्यक आहे हे समजले नाही?

मग त्यांना GitOps बद्दल माहिती मिळाली. हा निर्णय त्यांना आत्मविश्वासाने पुढे जाण्यासाठी नेमका काय हवा होता.

एलिस आणि बॉब अनेक वर्षांपासून कोड वर्कफ्लो म्हणून Git, DevOps आणि पायाभूत सुविधांबद्दल ऐकत आहेत. GitOps मधील वैशिष्ट्य म्हणजे ते Kubernetes च्या संदर्भात या कल्पना अंमलात आणण्यासाठी सर्वोत्कृष्ट पद्धतींचा एक संच - निश्चित आणि मानक दोन्ही आणते. ही थीम वारंवार गुलाब, मध्ये समावेश Weaveworks ब्लॉग.

कौटुंबिक विमा GitOps लागू करण्याचा निर्णय घेते. कंपनीकडे आता एक स्वयंचलित ऑपरेशन मॉडेल आहे जे कुबर्नेट्स आणि कॉम्बाइन्सशी सुसंगत आहे गती со स्थिरताकारण ते:

• कोणालाही वेड न लावता संघाची उत्पादकता दुप्पट झाल्याचे आढळले;
• स्क्रिप्ट देणे बंद केले. त्याऐवजी, ते आता नवीन वैशिष्ट्यांवर लक्ष केंद्रित करू शकतात आणि अभियांत्रिकी पद्धती सुधारू शकतात - उदाहरणार्थ, कॅनरी रोलआउट्स सादर करणे आणि चाचणी सुधारणे;
• आम्ही उपयोजन प्रक्रियेत सुधारणा केली आहे जेणेकरून ती क्वचितच खंडित होते;
• मॅन्युअल हस्तक्षेपाशिवाय आंशिक अपयशानंतर उपयोजन पुनर्संचयित करण्याची संधी मिळाली;
• वापरले खरेदीоवितरण प्रणालीवर अधिक विश्वास. अॅलिस आणि बॉब यांनी शोधून काढले की ते समांतरपणे कार्यरत असलेल्या मायक्रोसर्व्हिस संघांमध्ये संघाचे विभाजन करू शकतात;
• प्रत्येक गटाच्या प्रयत्नातून प्रकल्पात दररोज 30-50 बदल करू शकतात आणि नवीन तंत्रे वापरून पाहू शकतात;
• नवीन विकासकांना प्रकल्पाकडे आकर्षित करणे सोपे आहे, ज्यांना काही तासांत पुल विनंत्या वापरून उत्पादनासाठी अद्यतने आणण्याची संधी आहे;
• SOC2 च्या चौकटीत सहजपणे ऑडिट पास करा (सुरक्षित डेटा व्यवस्थापनाच्या आवश्यकतांसह सेवा प्रदात्यांच्या अनुपालनासाठी; अधिक वाचा, उदाहरणार्थ, येथे - अंदाजे अनुवाद.).

काय झालं?

GitOps दोन गोष्टी आहेत:

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

Git बद्दल काही शब्द

तुम्ही आवृत्ती नियंत्रण प्रणाली आणि Git-आधारित वर्कफ्लोशी परिचित नसल्यास, आम्ही त्यांच्याबद्दल जाणून घेण्याची जोरदार शिफारस करतो. शाखा आणि पुल विनंत्यांसह कार्य करणे सुरुवातीला काळ्या जादूसारखे वाटू शकते, परंतु फायदे प्रयत्न करण्यासारखे आहेत. येथे चांगला लेख सुरू करण्यासाठी.

Kubernetes कसे कार्य करते

आमच्या कथेत, अॅलिस आणि बॉब काही काळ कुबर्नेट्ससोबत काम केल्यानंतर गिटऑप्सकडे वळले. खरंच, GitOps कुबर्नेट्सशी जवळून संबंधित आहे - हे कुबर्नेट्सवर आधारित पायाभूत सुविधा आणि अनुप्रयोगांसाठी एक ऑपरेशनल मॉडेल आहे.

Kubernetes वापरकर्त्यांना काय देते?

येथे काही मुख्य वैशिष्ट्ये आहेत:

1. कुबर्नेट्स मॉडेलमध्ये, सर्वकाही घोषणात्मक स्वरूपात वर्णन केले जाऊ शकते.
2. Kubernetes API सर्व्हर ही घोषणा इनपुट म्हणून घेतो आणि नंतर घोषणामध्ये वर्णन केलेल्या स्थितीत क्लस्टर आणण्याचा सतत प्रयत्न करतो.
3. विविध प्रकारच्या वर्कलोडचे वर्णन करण्यासाठी आणि व्यवस्थापित करण्यासाठी घोषणा पुरेशा आहेत—“अनुप्रयोग”.
4. परिणामी, अनुप्रयोग आणि क्लस्टरमधील बदल यामुळे होतात:
   • कंटेनर प्रतिमांमध्ये बदल;
   • घोषणात्मक तपशीलात बदल;
   • वातावरणातील त्रुटी - उदाहरणार्थ, कंटेनर क्रॅश.

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

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

• ऑटोमेशन: Kubernetes अद्यतने कृपापूर्वक आणि वेळेवर बदल लागू करण्याची प्रक्रिया स्वयंचलित करण्यासाठी एक यंत्रणा प्रदान करतात.
• अभिसरण: Kubernetes यशस्वी होईपर्यंत अपडेट्सचा प्रयत्न करत राहतील.
• निर्बुद्धता: अभिसरणाचे वारंवार अर्ज केल्याने समान परिणाम होतो.
• निर्धारवाद: संसाधने पुरेशी असताना, अद्यतनित क्लस्टरची स्थिती केवळ इच्छित स्थितीवर अवलंबून असते.

GitOps कसे कार्य करते

GitOps कसे कार्य करते हे स्पष्ट करण्यासाठी आम्ही Kubernetes बद्दल पुरेसे शिकलो आहोत.

फॅमिली इन्शुरन्सच्या मायक्रो सर्व्हिसेस टीम्सकडे परत जाऊ या. त्यांना सहसा काय करावे लागते? खालील यादी पहा (त्यातील कोणतेही आयटम विचित्र किंवा अपरिचित वाटत असल्यास, कृपया टीका करणे थांबवा आणि आमच्यासोबत रहा). ही फक्त जेनकिन्स आधारित वर्कफ्लोची उदाहरणे आहेत. इतर साधनांसह कार्य करताना इतर अनेक प्रक्रिया आहेत.

मुख्य गोष्ट अशी आहे की आम्ही पाहतो की प्रत्येक अपडेट कॉन्फिगरेशन फाइल्स आणि Git रेपॉजिटरीजमधील बदलांसह समाप्त होते. Git मधील हे बदल "GitOps ऑपरेटर" ला क्लस्टर अपडेट करण्यास कारणीभूत ठरतात:

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

• जेनकिन्सने टॅग केलेल्या प्रतिमा क्वेकडे ढकलल्या;
• जेनकिन्स कॉन्फिगरेशन आणि हेल्म चार्ट मास्टर स्टोरेज बकेटमध्ये ढकलतो;
• क्लाउड फंक्शन मास्टर स्टोरेज बकेटमधून मास्टर गिट रेपॉजिटरीमध्ये कॉन्फिगरेशन आणि चार्ट कॉपी करते;
• GitOps ऑपरेटर क्लस्टर अपडेट करतो.

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

• जेनकिन्सने टॅग न केलेल्या प्रतिमा क्वेकडे ढकलल्या;
• जेनकिन्स कॉन्फिगरेशन आणि हेल्म चार्ट स्टेजिंग स्टोरेज बकेटमध्ये ढकलतो;
• क्लाउड फंक्शन स्टेजिंग स्टोरेज बकेटपासून स्टेजिंग गिट रेपॉजिटरीमध्ये कॉन्फिगरेशन आणि चार्ट कॉपी करते;
• GitOps ऑपरेटर क्लस्टर अपडेट करतो.

3. जेनकिन्स बिल्ड - विकसित किंवा वैशिष्ट्य शाखा:

• जेनकिन्सने टॅग न केलेल्या प्रतिमा क्वेकडे ढकलल्या;
• जेनकिन्स कॉन्फिगरेशन आणि हेल्म चार्ट डेव्हलप स्टोरेज बकेटमध्ये ढकलतो;
• क्लाउड फंक्शन डेव्हलप स्टोरेज बकेटपासून डेव्हलप गिट रेपॉजिटरीमध्ये कॉन्फिगरेशन आणि चार्ट कॉपी करते;
• GitOps ऑपरेटर क्लस्टर अपडेट करतो.

4. नवीन क्लायंट जोडत आहे:

• व्यवस्थापक किंवा प्रशासक (LCM/ops) सुरुवातीला नेटवर्क लोड बॅलन्सर्स (NLBs) तैनात आणि कॉन्फिगर करण्यासाठी Gradle ला कॉल करतात;
• LCM/ops अद्यतनांसाठी उपयोजन तयार करण्यासाठी नवीन कॉन्फिगरेशन कमिट करते;
• GitOps ऑपरेटर क्लस्टर अपडेट करतो.

GitOps चे संक्षिप्त वर्णन

1. प्रत्येक वातावरणासाठी घोषणात्मक तपशील वापरून संपूर्ण सिस्टमच्या इच्छित स्थितीचे वर्णन करा (आमच्या कथेमध्ये, बॉबची टीम Git मध्ये संपूर्ण सिस्टम कॉन्फिगरेशन परिभाषित करते).
   • Git रिपॉझिटरी संपूर्ण सिस्टमच्या इच्छित स्थितीशी संबंधित सत्याचा एकमेव स्त्रोत आहे.
   • इच्छित स्थितीतील सर्व बदल गिटमधील कमिटद्वारे केले जातात.
   • सर्व इच्छित क्लस्टर पॅरामीटर्स देखील क्लस्टरमध्येच निरीक्षण करण्यायोग्य आहेत. अशा प्रकारे ते एकरूप होतात की नाही हे आपण ठरवू शकतो (एकत्रित, एकत्र करणे) किंवा भिन्न (भिन्न, वळवणे) इच्छित आणि निरीक्षण अवस्था.
2. इच्छित आणि निरीक्षण अवस्था भिन्न असल्यास, नंतर:
   • एक अभिसरण यंत्रणा आहे जी लवकर किंवा नंतर आपोआप लक्ष्य आणि निरीक्षण केलेल्या अवस्थांना समक्रमित करते. क्लस्टरच्या आत, कुबर्नेट्स हे करतात.
   • प्रक्रिया "बदल प्रतिबद्ध" सूचनेसह लगेच सुरू होते.
   • काही कॉन्फिगर करण्यायोग्य कालावधीनंतर, जर राज्ये भिन्न असतील तर "भिन्न" इशारा पाठविला जाऊ शकतो.
3. अशाप्रकारे, Git मधील सर्व कमिट क्लस्टरमध्ये पडताळणी करण्यायोग्य आणि अदम्य अद्यतनांना कारणीभूत ठरतात.
   • रोलबॅक म्हणजे पूर्वी इच्छित स्थितीत अभिसरण.
4. अभिसरण अंतिम आहे. त्याची घटना याद्वारे दर्शविली जाते:
   • ठराविक कालावधीसाठी कोणतेही भिन्न अलर्ट नाहीत.
   • "कन्व्हर्ज्ड" अलर्ट (उदा. वेबहुक, गिट राइटबॅक इव्हेंट).

विचलन म्हणजे काय?

चला पुन्हा पुनरावृत्ती करूया: सर्व इच्छित क्लस्टर गुणधर्म क्लस्टरमध्येच निरीक्षण करण्यायोग्य असणे आवश्यक आहे.

भिन्नतेची काही उदाहरणे:

• Git मध्ये शाखा विलीन झाल्यामुळे कॉन्फिगरेशन फाइलमध्ये बदल.
• GUI क्लायंटने केलेल्या Git कमिटमुळे कॉन्फिगरेशन फाइलमध्ये बदल.
• Git मधील PR मुळे इच्छित स्थितीत अनेक बदल आणि त्यानंतर कंटेनर प्रतिमा तयार करणे आणि कॉन्फिगरेशन बदल.
• त्रुटीमुळे क्लस्टरच्या स्थितीत बदल, "खराब वर्तन" किंवा मूळ स्थितीपासून यादृच्छिक विचलनामुळे स्त्रोत संघर्ष.

अभिसरणाची यंत्रणा काय आहे?

काही उदाहरणेः

• कंटेनर आणि क्लस्टर्ससाठी, अभिसरण यंत्रणा कुबर्नेट्सद्वारे प्रदान केली जाते.
• हीच यंत्रणा Kubernetes-आधारित ऍप्लिकेशन्स आणि डिझाइन्स (जसे की Istio आणि Kubeflow) व्यवस्थापित करण्यासाठी वापरली जाऊ शकते.
• कुबर्नेट्स, इमेज रिपॉझिटरीज आणि गिट यांच्यातील ऑपरेशनल परस्परसंवाद व्यवस्थापित करण्यासाठी एक यंत्रणा प्रदान करते GitOps ऑपरेटर विव्ह फ्लक्स, जो भाग आहे मेघ विणणे.
• बेस मशीनसाठी, अभिसरण यंत्रणा घोषणात्मक आणि स्वायत्त असणे आवश्यक आहे. आपल्या स्वतःच्या अनुभवावरून आपण असे म्हणू शकतो टेराफॉर्म या व्याख्येच्या सर्वात जवळ, परंतु तरीही मानवी नियंत्रण आवश्यक आहे. या अर्थाने, GitOps कोड म्हणून पायाभूत सुविधांची परंपरा वाढवते.

GitOps शोषणासाठी एक मॉडेल प्रदान करण्यासाठी Git ला Kubernetes च्या उत्कृष्ट अभिसरण इंजिनसह एकत्र करते.

GitOps आम्हाला असे म्हणण्याची परवानगी देते: केवळ त्या प्रणालींचे वर्णन आणि निरीक्षण केले जाऊ शकते ज्या स्वयंचलित आणि नियंत्रित केल्या जाऊ शकतात.

GitOps संपूर्ण क्लाउड नेटिव्ह स्टॅकसाठी आहे (उदाहरणार्थ, टेराफॉर्म इ.)

GitOps फक्त कुबर्नेट्स नाही. संपूर्ण प्रणाली घोषणात्मकपणे चालविली जावी आणि अभिसरण वापरावे अशी आमची इच्छा आहे. संपूर्ण प्रणालीद्वारे आमचा अर्थ कुबरनेटसह कार्य करणार्‍या वातावरणाचा संग्रह आहे - उदाहरणार्थ, “डेव्ह क्लस्टर 1”, “उत्पादन” इ. प्रत्येक वातावरणात मशीन्स, क्लस्टर्स, ऍप्लिकेशन्स, तसेच डेटा, मॉनिटरिंग प्रदान करणाऱ्या बाह्य सेवांसाठी इंटरफेस समाविष्ट असतात. आणि इ.

या प्रकरणात बूटस्ट्रॅपिंग समस्येसाठी टेराफॉर्म किती महत्त्वाचे आहे ते पहा. Kubernetes कुठेतरी तैनात करणे आवश्यक आहे, आणि Terraform वापरणे म्हणजे Kubernetes आणि ऍप्लिकेशन्सला अंडरपिन करणारे नियंत्रण स्तर तयार करण्यासाठी आम्ही समान GitOps वर्कफ्लो लागू करू शकतो. ही एक उपयुक्त सर्वोत्तम सराव आहे.

Kubernetes च्या वरच्या स्तरांवर GitOps संकल्पना लागू करण्यावर जोरदार फोकस आहे. याक्षणी, Istio, Helm, Ksonnet, OpenFaaS आणि Kubeflow साठी GitOps-प्रकारचे उपाय आहेत, तसेच, उदाहरणार्थ, Pulumi साठी, जे क्लाउड नेटिव्हसाठी ऍप्लिकेशन्स विकसित करण्यासाठी एक स्तर तयार करतात.

कुबर्नेट्स CI/CD: GitOps ची इतर पद्धतींशी तुलना करणे

म्हटल्याप्रमाणे, GitOps दोन गोष्टी आहेत:

1. वर वर्णन केलेले Kubernetes आणि क्लाउड नेटिव्ह साठी ऑपरेटिंग मॉडेल.
2. विकासक-केंद्रित अनुप्रयोग व्यवस्थापन वातावरणाचा मार्ग.

अनेकांसाठी, GitOps हे प्रामुख्याने Git pushes वर आधारित वर्कफ्लो आहे. आम्हालाही तो आवडतो. पण एवढेच नाही: आता CI/CD पाइपलाइन पाहू.

GitOps Kubernetes साठी सतत उपयोजन (CD) सक्षम करते

GitOps एक सतत उपयोजन यंत्रणा ऑफर करते जी स्वतंत्र "डिप्लॉयमेंट मॅनेजमेंट सिस्टम" ची गरज दूर करते. Kubernetes तुमच्यासाठी सर्व काम करते.

• अनुप्रयोग अद्यतनित करण्यासाठी Git मध्ये अद्यतनित करणे आवश्यक आहे. हे इच्छित स्थितीसाठी एक व्यवहार अद्यतन आहे. "डिप्लॉयमेंट" नंतर अद्ययावत वर्णनाच्या आधारे कुबर्नेट्सद्वारे क्लस्टरमध्ये केले जाते.
• कुबर्नेट्स कसे कार्य करतात या स्वरूपामुळे, ही अद्यतने अभिसरण आहेत. हे सतत तैनात करण्यासाठी एक यंत्रणा प्रदान करते ज्यामध्ये सर्व अद्यतने अणू असतात.
• टीप: मेघ विणणे GitOps ऑपरेटर ऑफर करतो जो Git आणि Kubernetes समाकलित करतो आणि क्लस्टरच्या इच्छित आणि वर्तमान स्थितीचा ताळमेळ साधून CD ला सादर करण्याची परवानगी देतो.

kubectl आणि स्क्रिप्ट शिवाय

तुमचा क्लस्टर अपडेट करण्यासाठी तुम्ही Kubectl वापरणे टाळले पाहिजे आणि विशेषत: kubectl कमांड्स गट करण्यासाठी स्क्रिप्ट वापरणे टाळावे. त्याऐवजी, GitOps पाइपलाइनसह, वापरकर्ता त्यांचे Kubernetes क्लस्टर Git द्वारे अपडेट करू शकतो.

फायद्यांमध्ये हे समाविष्ट आहे:

1. बरोबर. अपडेट्सचा एक गट लागू केला जाऊ शकतो, एकत्र केला जाऊ शकतो आणि शेवटी प्रमाणित केला जाऊ शकतो, ज्यामुळे आम्हाला अणू तैनातीच्या लक्ष्याच्या जवळ आणता येते. याउलट, स्क्रिप्ट वापरणे अभिसरणाची कोणतीही हमी देत ​​​​नाही (यावर खाली अधिक).
2. सुरक्षा. उद्धृत Kelsey Hightower: "तुमच्या Kubernetes क्लस्टरचा प्रवेश ऑटोमेशन टूल्स आणि प्रशासकांसाठी प्रतिबंधित करा जे ते डीबगिंग किंवा देखरेखीसाठी जबाबदार आहेत." देखील पहा माझे प्रकाशन सुरक्षा आणि तांत्रिक वैशिष्ट्यांचे पालन करण्याबद्दल, तसेच Homebrew हॅकिंग बद्दल लेख निष्काळजीपणे लिहिलेल्या जेनकिन्स स्क्रिप्टमधून क्रेडेन्शियल्स चोरून.
3. वापरकर्ता अनुभव. कुबेक्टल कुबेरनेट्स ऑब्जेक्ट मॉडेलचे यांत्रिकी उघड करते, जे खूपच गुंतागुंतीचे आहे. तद्वतच, वापरकर्त्यांनी अमूर्ततेच्या उच्च स्तरावर सिस्टमशी संवाद साधला पाहिजे. येथे मी पुन्हा केल्सीचा संदर्भ घेईन आणि पाहण्याची शिफारस करेन असा रेझ्युमे.

सीआय आणि सीडी मधील फरक

GitOps विद्यमान CI/CD मॉडेल सुधारते.

आधुनिक सीआय सर्व्हर हे ऑर्केस्ट्रेशन साधन आहे. विशेषतः, हे सीआय पाइपलाइन ऑर्केस्ट्रेट करण्यासाठी एक साधन आहे. यामध्ये बिल्ड, टेस्ट, मर्ज टू ट्रंक इत्यादींचा समावेश आहे. CI सर्व्हर जटिल मल्टी-स्टेप पाइपलाइनचे व्यवस्थापन स्वयंचलित करतात. कुबर्नेट्स अद्यतनांचा संच स्क्रिप्ट करणे आणि क्लस्टरमध्ये बदल करण्यासाठी पाइपलाइनचा भाग म्हणून चालवणे हा एक सामान्य प्रलोभन आहे. खरंच, अनेक तज्ञ हेच करतात. तथापि, हे इष्टतम नाही आणि ते येथे आहे.

ट्रंकवर अपडेट्स पुश करण्यासाठी CI चा वापर केला जावा, आणि कुबर्नेट्स क्लस्टरने सीडी अंतर्गतरित्या व्यवस्थापित करण्यासाठी त्या अद्यतनांच्या आधारे स्वतःला बदलले पाहिजे. आम्ही त्याला म्हणतो सीडी साठी पुल मॉडेल, CI पुश मॉडेलच्या विपरीत. सीडी भाग आहे रनटाइम ऑर्केस्ट्रेशन.

सीआय सर्व्हरने कुबर्नेट्समधील डायरेक्ट अपडेट्सद्वारे सीडी का करू नये

CI जॉब्सचा संच म्हणून कुबर्नेट्सवर थेट अपडेट्स ऑर्केस्ट्रेट करण्यासाठी CI सर्व्हर वापरू नका. हे आम्ही बोलत आहोत विरोधी नमुना आहे आधीच सांगितले तुमच्या ब्लॉगवर.

चला अॅलिस आणि बॉबकडे परत जाऊया.

त्यांना कोणत्या समस्यांचा सामना करावा लागला? बॉबचा सीआय सर्व्हर क्लस्टरमध्ये बदल लागू करतो, परंतु प्रक्रियेत तो क्रॅश झाल्यास, क्लस्टर कोणत्या स्थितीत आहे (किंवा असावा) किंवा त्याचे निराकरण कसे करावे हे बॉबला कळणार नाही. यशाच्या बाबतीतही असेच आहे.

समजू या की बॉबच्या टीमने एक नवीन प्रतिमा तयार केली आणि नंतर प्रतिमा उपयोजित करण्यासाठी त्यांची तैनाती पॅच केली (सर्व CI पाइपलाइनवरून).

प्रतिमा सामान्यपणे तयार होत असल्यास, परंतु पाइपलाइन अयशस्वी झाल्यास, संघाला हे शोधून काढावे लागेल:

• अपडेट आणले आहे का?
• आम्ही नवीन बिल्ड लाँच करत आहोत? यामुळे अनावश्यक साइड इफेक्ट्स होतील का - एकाच अपरिवर्तनीय प्रतिमेच्या दोन बिल्ड असण्याची शक्यता आहे?
• बिल्ड चालवण्यापूर्वी आम्ही पुढील अपडेटची प्रतीक्षा करावी का?
• नेमके काय चुकले? कोणत्या चरणांची पुनरावृत्ती करणे आवश्यक आहे (आणि कोणती पुनरावृत्ती करणे सुरक्षित आहे)?

Git-आधारित वर्कफ्लो स्थापित केल्याने बॉबच्या टीमला या समस्या येणार नाहीत याची हमी देत ​​नाही. कमिट पुश, टॅग किंवा इतर काही पॅरामीटरसह ते अजूनही चूक करू शकतात; तथापि, हा दृष्टीकोन अजूनही स्पष्टपणे सर्व-किंवा-काहीही नसलेल्या दृष्टिकोनाच्या अगदी जवळ आहे.

थोडक्यात, सीआय सर्व्हरने सीडीशी व्यवहार का करू नये ते येथे आहे:

• अपडेट स्क्रिप्ट नेहमी निर्धारक नसतात; त्यांच्यामध्ये चुका करणे सोपे आहे.
• CI सर्व्हर घोषणात्मक क्लस्टर मॉडेलमध्ये एकत्र येत नाहीत.
• अशक्तपणाची हमी देणे कठीण आहे. वापरकर्त्यांनी सिस्टमचे खोल शब्दार्थ समजून घेतले पाहिजेत.
• आंशिक अपयशातून सावरणे अधिक कठीण आहे.

हेल्मबद्दल टीप: तुम्हाला हेल्म वापरायचे असल्यास, आम्ही ते गिटऑप्स ऑपरेटरसह एकत्र करण्याची शिफारस करतो जसे की फ्लक्स-हेल्म. हे अभिसरण सुनिश्चित करण्यात मदत करेल. हेल्म स्वतः निर्धारवादी किंवा अणू नाही.

कुबर्नेट्ससाठी सतत वितरण लागू करण्याचा सर्वोत्तम मार्ग म्हणून GitOps

अॅलिस आणि बॉबची टीम GitOps लागू करते आणि सॉफ्टवेअर उत्पादनांसह काम करणे, उच्च कार्यक्षमता आणि स्थिरता राखणे खूप सोपे झाले आहे. त्यांचा नवीन दृष्टिकोन कसा दिसतो हे दर्शविणाऱ्या उदाहरणासह हा लेख संपवू. लक्षात ठेवा की आम्ही बहुतेक अनुप्रयोग आणि सेवांबद्दल बोलत आहोत, परंतु GitOps संपूर्ण प्लॅटफॉर्म व्यवस्थापित करण्यासाठी वापरला जाऊ शकतो.

Kubernetes साठी ऑपरेटिंग मॉडेल

खालील चित्र पहा. हे Git आणि कंटेनर इमेज रिपॉझिटरी दोन ऑर्केस्टेटेड लाइफसायकलसाठी सामायिक संसाधने म्हणून सादर करते:

• एक सतत एकत्रीकरण पाइपलाइन जी Git वर फायली वाचते आणि लिहिते आणि कंटेनर प्रतिमांचे भांडार अद्यतनित करू शकते.
• एक रनटाइम GitOps पाइपलाइन जी व्यवस्थापन आणि निरीक्षणक्षमतेसह तैनाती एकत्र करते. ते Git वर फायली वाचते आणि लिहिते आणि कंटेनर प्रतिमा डाउनलोड करू शकते.

मुख्य निष्कर्ष काय आहेत?

1. चिंता वेगळे करणे: कृपया लक्षात घ्या की दोन्ही पाइपलाइन फक्त Git किंवा इमेज रिपॉझिटरी अपडेट करून संवाद साधू शकतात. दुसऱ्या शब्दांत, सीआय आणि रनटाइम वातावरण यांच्यात फायरवॉल आहे. आम्ही त्याला "अपरिवर्तनीय फायरवॉल" म्हणतो (अपरिवर्तनीय फायरवॉल), कारण सर्व रेपॉजिटरी अद्यतने नवीन आवृत्त्या तयार करतात. या विषयावरील अधिक माहितीसाठी, स्लाइड्स 72-87 पहा हे सादरीकरण.
2. तुम्ही कोणतेही CI आणि Git सर्व्हर वापरू शकता: GitOps कोणत्याही घटकासह कार्य करते. तुम्ही तुमचे आवडते CI आणि Git सर्व्हर, इमेज रिपॉझिटरीज आणि चाचणी सूट वापरणे सुरू ठेवू शकता. बाजारातील जवळजवळ सर्व इतर सतत वितरण साधनांना त्यांचे स्वतःचे CI/Git सर्व्हर किंवा प्रतिमा भांडार आवश्यक आहे. हे क्लाउड नेटिव्हच्या विकासासाठी मर्यादित घटक बनू शकते. GitOps सह, तुम्ही परिचित साधने वापरू शकता.
3. एकीकरण साधन म्हणून कार्यक्रम: Git मधील डेटा अपडेट होताच, Weave Flux (किंवा Weave Cloud ऑपरेटर) रनटाइम सूचित करतो. जेव्हा जेव्हा कुबर्नेट्स बदल संच स्वीकारतात, तेव्हा Git अद्यतनित केले जाते. हे खाली दर्शविल्याप्रमाणे GitOps साठी वर्कफ्लो आयोजित करण्यासाठी एक साधे एकत्रीकरण मॉडेल प्रदान करते.

निष्कर्ष

GitOps कोणत्याही आधुनिक CI/CD टूलसाठी आवश्यक असलेली मजबूत अपडेट हमी देते:

• ऑटोमेशन;
• अभिसरण
• अशक्तपणा;
• निर्धारवाद

हे महत्त्वाचे आहे कारण ते क्लाउड नेटिव्ह डेव्हलपरसाठी ऑपरेशनल मॉडेल ऑफर करते.

• प्रणाली व्यवस्थापित करण्यासाठी आणि देखरेखीसाठी पारंपारिक साधने रनबुकमध्ये कार्यरत ऑपरेशन टीमशी संबंधित आहेत (नियमित प्रक्रिया आणि ऑपरेशन्सचा एक संच - अंदाजे अनुवाद.), विशिष्ट तैनातीशी जोडलेले.
• क्लाउड नेटिव्ह मॅनेजमेंटमध्ये, डिप्लॉयमेंटचे परिणाम मोजण्याचा सर्वोत्कृष्ट मार्ग निरीक्षण साधने आहेत जेणेकरून विकास कार्यसंघ त्वरित प्रतिसाद देऊ शकेल.

वेगवेगळ्या ढगांमध्ये विखुरलेल्या अनेक क्लस्टर्सची कल्पना करा आणि त्यांच्या स्वत:च्या टीम्स आणि तैनाती योजनांसह अनेक सेवा. GitOps ही सर्व विपुलता व्यवस्थापित करण्यासाठी स्केल-अपरिवर्तनीय मॉडेल ऑफर करते.

अनुवादकाकडून पुनश्च

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

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

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

हे दोन भाषांतर Habré वर दिसण्यापूर्वी तुम्हाला GitOps बद्दल माहिती होती का?

• होय, मला सर्व काही माहित होते

• केवळ वरवरचे

• कोणत्याही

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

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