GitOps के हो?

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

एक वर्ष पहिले हामीले प्रकाशित गरेका थियौं GitOps को परिचय। त्यसबेला, हामीले साझा गर्नुभयो कि कसरी Weaveworks टोलीले पूर्ण रूपमा Kubernetes मा आधारित SaaS सुरु गर्‍यौं र क्लाउड नेटिभ वातावरणमा डिप्लोइ, प्रबन्ध र अनुगमनका लागि उत्तम अभ्यासहरूको सेट विकास गर्‍यौं।

लेख लोकप्रिय भयो। अन्य व्यक्तिहरूले GitOps को बारेमा कुरा गर्न थाले र नयाँ उपकरणहरू प्रकाशित गर्न थाले git धक्का, विकास, रहस्यहरू, कार्यहरू, निरन्तर एकीकरण र यस्तै। हाम्रो वेबसाइटमा देखा पर्यो एक ठूलो संख्या प्रकाशनहरू र GitOps प्रयोग केसहरू। तर केही मानिसहरू अझै पनि प्रश्नहरू छन्। परम्परागत मोडेल कसरी फरक छ? कोडको रूपमा पूर्वाधार र निरन्तर वितरण (निरन्तर वितरण)? के यो Kubernetes प्रयोग गर्न आवश्यक छ?

हामीले चाँडै बुझ्यौं कि नयाँ विवरण आवश्यक छ, प्रस्ताव गर्दै:

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

यस लेखमा हामीले यी सबै विषयहरूलाई समेट्ने प्रयास गरेका छौं। यसले GitOps र एक विकासकर्ता र CI/CD परिप्रेक्ष्यमा अपडेट गरिएको परिचय प्रदान गर्दछ। हामी मुख्य रूपमा Kubernetes मा फोकस गर्छौं, यद्यपि मोडेल सामान्यीकृत गर्न सकिन्छ।

GitOps लाई भेट्नुहोस्

एलिस कल्पना गर्नुहोस्। उनी परिवार बीमा चलाउँछिन्, जसले स्वास्थ्य, अटो, घर, र यात्रा बीमा प्रदान गर्दछ जो व्यक्तिहरू आफैं अनुबंधको इन्स र आउटहरू बुझ्न धेरै व्यस्त छन्। उनको व्यवसाय एक साइड प्रोजेक्टको रूपमा सुरु भयो जब एलिस बैंकमा डाटा वैज्ञानिकको रूपमा काम गरिरहेकी थिइन्। एक दिन उनले महसुस गरिन् कि उनले डाटालाई अझ प्रभावकारी रूपमा विश्लेषण गर्न र बीमा प्याकेजहरू बनाउन उन्नत कम्प्युटर एल्गोरिदमहरू प्रयोग गर्न सक्छिन्। लगानीकर्ताहरूले यस परियोजनालाई वित्त पोषण गरे, र अब उनको कम्पनीले एक वर्षमा $ 20 मिलियन भन्दा बढी ल्याउँछ र द्रुत रूपमा बढिरहेको छ। हाल, यसले विभिन्न पदहरूमा 180 जनालाई रोजगारी दिन्छ। यसमा एक टेक्नोलोजी टोली समावेश छ जसले वेबसाइट, डाटाबेसको विकास, मर्मत र ग्राहक आधारको विश्लेषण गर्दछ। ६० जनाको टोलीको नेतृत्व कम्पनीका प्राविधिक निर्देशक बबले गरेका छन् ।

बबको टोलीले क्लाउडमा उत्पादन प्रणालीहरू प्रयोग गर्छ। गुगल क्लाउडमा Kubernetes को फाइदा उठाउँदै तिनीहरूको मूल अनुप्रयोगहरू GKE मा चल्छन्। थप रूपमा, तिनीहरूले आफ्नो काममा विभिन्न डाटा र विश्लेषण उपकरणहरू प्रयोग गर्छन्।

पारिवारिक बीमाले कन्टेनरहरू प्रयोग गर्न सेट गरेन, तर डकरको उत्साहमा फस्यो। कम्पनीले चाँडै पत्ता लगायो कि GKE ले नयाँ सुविधाहरू परीक्षण गर्न क्लस्टरहरू प्रयोग गर्न सजिलो बनायो। CI र Quay का लागि जेनकिन्सहरू कन्टेनर रजिस्ट्री व्यवस्थित गर्न थपिएका थिए, जेनकिन्सका लागि स्क्रिप्टहरू लेखिएका थिए जसले नयाँ कन्टेनरहरू र कन्फिगरेसनहरू GKE मा धकेल्यो।

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

त्यसपछि तिनीहरूले GitOps बारे सिके। यो निर्णय उनीहरूलाई आत्मविश्वासका साथ अगाडि बढ्नको लागि आवश्यक पर्ने कुरा हो।

एलिस र बबले वर्षौंदेखि कोड कार्यप्रवाहको रूपमा Git, DevOps र पूर्वाधारको बारेमा सुन्दै आएका छन्। GitOps को बारेमा के अद्वितीय छ कि यसले Kubernetes को सन्दर्भमा यी विचारहरू लागू गर्नका लागि - निश्चित र मानक दुवै - उत्कृष्ट अभ्यासहरूको सेट ल्याउँछ। यो विषयवस्तु बारम्बार उठ्यो, सहित Weaveworks ब्लग.

परिवार बीमा GitOps लागू गर्ने निर्णय गर्दछ। कम्पनीसँग अब कुबेरनेट र कम्बाइन्ससँग मिल्दो स्वचालित सञ्चालन मोडेल छ गति संग स्थिरताकिनभने तिनीहरू:

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

के भयो?

GitOps दुई चीजहरू छन्:

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

Git बारेमा केहि शब्दहरू

यदि तपाईं संस्करण नियन्त्रण प्रणाली र Git-आधारित कार्यप्रवाहसँग परिचित हुनुहुन्न भने, हामी तिनीहरूको बारेमा सिक्न सिफारिस गर्छौं। शाखाहरू र पुल अनुरोधहरूसँग काम गर्दा सुरुमा कालो जादू जस्तो लाग्न सक्छ, तर फाइदाहरू प्रयासको लायक छन्। यहाँ राम्रो लेख सुरु गर्न।

Kubernetes कसरी काम गर्दछ

हाम्रो कथामा, एलिस र बब केही समय कुबर्नेट्ससँग काम गरेपछि GitOps मा फर्किए। वास्तवमा, GitOps Kubernetes सँग नजिकबाट सम्बन्धित छ - यो Kubernetes मा आधारित पूर्वाधार र अनुप्रयोगहरूको लागि एक परिचालन मोडेल हो।

Kubernetes ले प्रयोगकर्ताहरूलाई के दिन्छ?

यहाँ केहि मुख्य सुविधाहरू छन्:

1. Kubernetes मोडेलमा, सबै कुरा घोषणात्मक रूपमा वर्णन गर्न सकिन्छ।
2. Kubernetes API सर्भरले यो घोषणालाई इनपुटको रूपमा लिन्छ र त्यसपछि घोषणामा वर्णन गरिएको राज्यमा क्लस्टर ल्याउने प्रयास गर्दछ।
3. घोषणाहरू कार्यभारहरूको विस्तृत विविधता वर्णन गर्न र व्यवस्थापन गर्न पर्याप्त छन्—“अनुप्रयोगहरू।”
4. नतिजाको रूपमा, अनुप्रयोग र क्लस्टरमा परिवर्तनहरू निम्न कारणले हुन्छन्:
   • कन्टेनर छविहरूमा परिवर्तनहरू;
   • घोषणात्मक विनिर्देशमा परिवर्तनहरू;
   • वातावरणमा त्रुटिहरू - उदाहरणका लागि, कन्टेनर क्र्यासहरू।

Kubernetes' महान अभिसरण क्षमताहरू

जब प्रशासकले कन्फिगरेसन परिवर्तन गर्छ, Kubernetes अर्केस्ट्रेटरले तिनीहरूलाई क्लस्टरमा लागू गर्नेछ जबसम्म यसको स्थिति छ। नयाँ कन्फिगरेसनको नजिक आउँदैन। यो मोडेल कुनै पनि Kubernetes स्रोत को लागी काम गर्दछ र अनुकूलन संसाधन परिभाषा (CRDs) को साथ एक्स्टेन्सिबल छ। तसर्थ, Kubernetes परिनियोजनमा निम्न अद्भुत गुणहरू छन्:

• स्वचालन: Kubernetes अद्यावधिकहरूले अनुग्रहपूर्ण र समयमै परिवर्तनहरू लागू गर्ने प्रक्रियालाई स्वचालित गर्न संयन्त्र प्रदान गर्दछ।
• अभिसरण: Kubernetes सफल नभएसम्म अद्यावधिक प्रयास जारी रहनेछ।
• इडम्पोटेन्सी: अभिसरणको दोहोर्याइएको अनुप्रयोगले समान परिणाम निम्त्याउँछ।
• निश्चयवाद: जब स्रोतहरू पर्याप्त हुन्छन्, अद्यावधिक गरिएको क्लस्टरको अवस्था चाहिने अवस्थामा मात्र निर्भर हुन्छ।

GitOps कसरी काम गर्दछ

GitOps ले कसरी काम गर्छ भनेर व्याख्या गर्न हामीले Kubernetes को बारेमा पर्याप्त सिकेका छौं।

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

मुख्य कुरा यो हो कि हामी देख्छौं कि प्रत्येक अपडेट कन्फिगरेसन फाइलहरू र Git भण्डारहरूमा परिवर्तनहरूसँग समाप्त हुन्छ। Git मा यी परिवर्तनहरूले "GitOps अपरेटर" लाई क्लस्टर अपडेट गर्न दिन्छ:

1. कार्य प्रक्रिया: "जेनकिन्स निर्माण - मास्टर शाखा"।
कार्य सूची:

• जेन्किन्सले ट्याग गरिएका तस्बिरहरूलाई क्वेमा पुश गर्छन्;
• जेनकिन्सले कन्फिगरेसन र हेल्म चार्टहरूलाई मास्टर भण्डारण बाल्टीमा पुश गर्छ;
• क्लाउड प्रकार्यले मास्टर भण्डारण बाल्टीबाट मास्टर Git भण्डारमा कन्फिगरेसन र चार्टहरू प्रतिलिपि गर्दछ;
• GitOps अपरेटरले क्लस्टर अपडेट गर्दछ।

2. जेनकिन्स निर्माण - रिलीज वा हटफिक्स शाखा:

• जेन्किन्सले ट्याग नगरिएका तस्बिरहरूलाई क्वेमा धकेल्छन्;
• जेनकिन्सले कन्फिगरेसन र हेल्म चार्टहरूलाई स्टेजिङ भण्डारण बाल्टीमा पुश गर्छ;
• क्लाउड प्रकार्यले स्टेजिङ भण्डारण बाल्टीबाट स्टेजिङ Git भण्डारमा कन्फिगरेसन र चार्टहरू प्रतिलिपि गर्दछ;
• GitOps अपरेटरले क्लस्टर अपडेट गर्दछ।

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

• जेन्किन्सले ट्याग नगरिएका तस्बिरहरूलाई क्वेमा धकेल्छन्;
• जेनकिन्सले कन्फिगरेसन र हेल्म चार्टहरू विकास भण्डारण बाल्टीमा पुश गर्दछ;
• क्लाउड प्रकार्यले विकास भण्डारण बाल्टीबाट विकास Git भण्डारमा कन्फिगरेसन र चार्टहरू प्रतिलिपि गर्दछ;
• GitOps अपरेटरले क्लस्टर अपडेट गर्दछ।

4. नयाँ ग्राहक थप्दै:

• प्रबन्धक वा प्रशासक (LCM/ops) ले Gradle लाई सुरुमा नेटवर्क लोड ब्यालेन्सरहरू (NLBs) डिप्लोय र कन्फिगर गर्न कल गर्दछ;
• LCM/ops ले अपडेटहरूको लागि डिप्लोयमेन्ट तयार गर्न नयाँ कन्फिगरेसन कमिट गर्छ;
• GitOps अपरेटरले क्लस्टर अपडेट गर्दछ।

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

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

विचलन भनेको के हो?

फेरि दोहोर्याउनुहोस्: सबै वांछित क्लस्टर गुणहरू क्लस्टरमा नै अवलोकनयोग्य हुनुपर्छ.

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

• Git मा शाखाहरू मर्ज गर्दा कन्फिगरेसन फाइलमा परिवर्तन।
• GUI क्लाइन्ट द्वारा बनाईएको Git कमिटको कारण कन्फिगरेसन फाइलमा परिवर्तन।
• कन्टेनर छवि र कन्फिगरेसन परिवर्तनहरू निर्माण गरेर Git मा PR को कारणले वांछित स्थितिमा बहु परिवर्तनहरू।
• त्रुटिको कारण क्लस्टरको स्थितिमा परिवर्तन, स्रोत द्वन्द्वको परिणामस्वरूप "खराब व्यवहार", वा मूल अवस्थाबाट मात्र अनियमित विचलन।

अभिसरण को संयन्त्र के हो?

केहि उदाहरणहरू:

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

GitOps ले Git लाई Kubernetes को उत्कृष्ट अभिसरण इन्जिनसँग संयोजन गर्दछ शोषणको लागि मोडेल प्रदान गर्न।

GitOps ले हामीलाई भन्न अनुमति दिन्छ: केवल ती प्रणालीहरू जुन वर्णन गर्न सकिन्छ र अवलोकन गर्न सकिन्छ स्वचालित र नियन्त्रण गर्न सकिन्छ.

GitOps सम्पूर्ण क्लाउड नेटिभ स्ट्याक (उदाहरणका लागि, Terraform, आदि) को लागी लक्षित छ।

GitOps Kubernetes मात्र होइन। हामी सम्पूर्ण प्रणाली घोषणात्मक रूपमा संचालित र अभिसरण प्रयोग गर्न चाहन्छौं। सम्पूर्ण प्रणालीबाट हामीले Kubernetes सँग काम गर्ने वातावरणहरूको सङ्कलनलाई बुझाउँछौं - उदाहरणका लागि, "dev cluster 1", "production", आदि। प्रत्येक वातावरणमा मेशिन, क्लस्टर, एप्लिकेसन, साथै डेटा, निगरानी प्रदान गर्ने बाह्य सेवाहरूका लागि इन्टरफेसहरू समावेश हुन्छन्। र आदि

यस अवस्थामा बुटस्ट्र्यापिङ समस्याको लागि Terraform कति महत्त्वपूर्ण छ ध्यान दिनुहोस्। Kubernetes लाई कतै तैनाथ गरिनु पर्छ, र Terraform को प्रयोग गर्नु भनेको हामी समान GitOps कार्यप्रवाहहरू लागू गर्न सक्छौं नियन्त्रण तह सिर्जना गर्न जसले Kubernetes र अनुप्रयोगहरूलाई अन्डरपिन गर्दछ। यो एक उपयोगी उत्तम अभ्यास हो।

Kubernetes को माथि तहहरूमा GitOps अवधारणाहरू लागू गर्नमा बलियो फोकस छ। यस समयमा, त्यहाँ Istio, Helm, Ksonnet, OpenFaaS र Kubeflow को लागि GitOps-प्रकार समाधानहरू छन्, साथै, उदाहरणका लागि, Pulumi को लागि, जसले क्लाउड नेटिभका लागि अनुप्रयोगहरू विकास गर्न तह सिर्जना गर्दछ।

Kubernetes CI/CD: अन्य दृष्टिकोणहरूसँग GitOps तुलना गर्दै

भनिएको छ, GitOps दुई चीजहरू छन्:

1. माथि वर्णन गरिएको Kubernetes र क्लाउड नेटिभ को लागी अपरेटिङ मोडेल।
2. विकासकर्ता-केन्द्रित अनुप्रयोग व्यवस्थापन वातावरणको बाटो।

धेरैका लागि, GitOps मुख्य रूपमा Git pushes मा आधारित कार्यप्रवाह हो। हामी पनि उहाँलाई मनपर्छ। तर त्यो सबै होइन: अब CI/CD पाइपलाइनहरू हेरौं।

GitOps ले Kubernetes को लागि निरन्तर तैनाती (CD) सक्षम गर्दछ

GitOps ले एक निरन्तर डिप्लोइमेन्ट मेकानिजम प्रदान गर्दछ जसले छुट्टै "डिप्लोइमेन्ट म्यानेजमेन्ट सिस्टम" को आवश्यकतालाई हटाउँछ। Kubernetes ले तपाइँको लागि सबै काम गर्दछ।

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

kubectl र स्क्रिप्ट बिना

तपाईंले आफ्नो क्लस्टर अपडेट गर्न Kubectl प्रयोग गर्नबाट जोगिनै पर्छ, र विशेष गरी kubectl आदेशहरू समूहमा लिपिहरू प्रयोग गर्नबाट जोगिनु पर्छ। यसको सट्टा, GitOps पाइपलाइनको साथ, प्रयोगकर्ताले Git मार्फत आफ्नो Kubernetes क्लस्टर अद्यावधिक गर्न सक्छन्।

लाभहरू समावेश छन्:

1. सहि। अद्यावधिकहरूको समूह लागू गर्न सकिन्छ, अभिसरण र अन्ततः मान्य, हामीलाई परमाणु तैनातीको लक्ष्यको नजिक ल्याउँछ। यसको विपरित, स्क्रिप्टहरू प्रयोग गर्दा अभिसरणको कुनै ग्यारेन्टी प्रदान गर्दैन (तलको बारेमा थप)।
2. सुरक्षा. उद्धृत गर्दै Kelsey Hightower: "तपाईँको Kubernetes क्लस्टरमा स्वचालन उपकरण र प्रशासकहरूलाई पहुँच प्रतिबन्ध गर्नुहोस् जो यसलाई डिबग गर्न वा मर्मत गर्न जिम्मेवार छन्।" पनि हेर्नुहोस् मेरो प्रकाशन सुरक्षा र प्राविधिक विनिर्देशहरूको साथ अनुपालनको बारेमा, साथै Homebrew ह्याक गर्ने बारे लेख लापरवाहीपूर्वक लिखित जेनकिन्स लिपिबाट प्रमाणहरू चोरी गरेर।
3. प्रयोगकर्ता अनुभव। Kubectl ले Kubernetes वस्तु मोडेलको मेकानिक्सलाई उजागर गर्दछ, जुन धेरै जटिल छन्। आदर्श रूपमा, प्रयोगकर्ताहरूले अमूर्तताको उच्च स्तरमा प्रणालीसँग अन्तरक्रिया गर्नुपर्छ। यहाँ म फेरि केल्सीलाई सन्दर्भ गर्नेछु र हेर्न सिफारिस गर्नेछु यस्तो रिजुमे.

सीआई र सीडी बीचको भिन्नता

GitOps ले अवस्थित CI/CD मोडेलहरूलाई सुधार गर्दछ।

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

CI लाई ट्रंकमा अद्यावधिकहरू पुश गर्न प्रयोग गरिनुपर्छ, र Kubernetes क्लस्टरले CD लाई आन्तरिक रूपमा व्यवस्थापन गर्न ती अद्यावधिकहरूको आधारमा परिवर्तन गर्नुपर्छ। हामी यसलाई बोलाउँछौं सीडी लागि मोडेल पुल, CI पुश मोडेलको विपरीत। सीडी भाग हो रनटाइम अर्केस्ट्रेशन.

किन CI सर्भरहरूले Kubernetes मा प्रत्यक्ष अपडेटहरू मार्फत सीडीहरू गर्नु हुँदैन

CI कार्यहरूको सेटको रूपमा Kubernetes मा प्रत्यक्ष अपडेटहरू अर्केस्ट्रेट गर्न CI सर्भर प्रयोग नगर्नुहोस्। यो हामीले कुरा गर्दैछौं विरोधी ढाँचा हो पहिले नै भनिएको छ तपाईको ब्लगमा।

एलिस र बबमा फर्कौं।

उनीहरूले कस्ता समस्याहरू सामना गरे? बबको CI सर्भरले क्लस्टरमा परिवर्तनहरू लागू गर्छ, तर यदि यो प्रक्रियामा क्र्यास भयो भने, बबले क्लस्टर कुन अवस्थामा छ (वा हुनुपर्छ) वा यसलाई कसरी ठीक गर्ने भनेर थाहा हुँदैन। सफलताको हकमा पनि त्यस्तै हुन्छ।

मानौं कि बबको टोलीले एउटा नयाँ छवि बनाए र त्यसपछि छवि (सबै CI पाइपलाइनबाट) डिप्लोय गर्नको लागि तिनीहरूको डिप्लोयमेन्टहरू प्याच गर्यो।

यदि छवि सामान्य रूपमा बनाउँछ, तर पाइपलाइन असफल भयो भने, टोलीले पत्ता लगाउनु पर्छ:

• के अपडेट रोल आउट भयो?
• के हामी नयाँ निर्माण सुरु गर्दैछौं? के यसले अनावश्यक साइड इफेक्टहरू निम्त्याउनेछ - एउटै अपरिवर्तनीय छविको दुई निर्माण हुने सम्भावनाको साथ?
• के हामीले निर्माण चलाउनु अघि अर्को अपडेटको लागि पर्खनुपर्छ?
• वास्तवमा के गल्ती भयो? कुन चरणहरू दोहोर्याउन आवश्यक छ (र कुन चरणहरू दोहोर्याउन सुरक्षित छन्)?

Git-आधारित कार्यप्रवाह स्थापनाले बबको टोलीले यी समस्याहरूको सामना गर्नेछैन भन्ने ग्यारेन्टी गर्दैन। तिनीहरू अझै पनि कमिट पुश, ट्याग, वा केही अन्य प्यारामिटरको साथ गल्ती गर्न सक्छन्; यद्यपि, यो दृष्टिकोण अझै पनि स्पष्ट सबै वा केही नभएको दृष्टिकोणको धेरै नजिक छ।

संक्षेपमा, यहाँ छ किन CI सर्भरहरूले सीडीसँग व्यवहार गर्नु हुँदैन:

• अद्यावधिक लिपिहरू सधैं निर्धारक हुँदैनन्; तिनीहरूमा गल्ती गर्न सजिलो छ।
• CI सर्भरहरू घोषणात्मक क्लस्टर मोडेलमा रूपान्तरण गर्दैनन्।
• अदम्यताको ग्यारेन्टी गर्न गाह्रो छ। प्रयोगकर्ताहरूले प्रणालीको गहिरो शब्दार्थ बुझ्नुपर्छ।
• आंशिक असफलताबाट पुन: प्राप्ति गर्न अझ गाह्रो छ।

हेल्मको बारेमा नोट: यदि तपाईं हेल्म प्रयोग गर्न चाहनुहुन्छ भने, हामी यसलाई GitOps अपरेटरसँग संयोजन गर्न सिफारिस गर्छौं जस्तै फ्लक्स-हेल्म। यसले अभिसरण सुनिश्चित गर्न मद्दत गर्नेछ। हेलम आफैं न निश्चयवादी हो न आणविक।

GitOps Kubernetes को लागि निरन्तर डेलिभरी लागू गर्ने सबैभन्दा राम्रो तरिका हो

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

Kubernetes को लागि अपरेटिङ मोडेल

तलको रेखाचित्र हेर्नुहोस्। यसले Git र कन्टेनर छवि भण्डारलाई दुई अर्केस्ट्रेटेड जीवनचक्रहरूको लागि साझा स्रोतहरूको रूपमा प्रस्तुत गर्दछ:

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

मुख्य निष्कर्ष के हो?

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

निष्कर्षमा

GitOps ले कुनै पनि आधुनिक CI/CD उपकरण द्वारा आवश्यक बलियो अद्यावधिक ग्यारेन्टीहरू प्रदान गर्दछ:

• स्वचालन;
• अभिसरण;
• निर्दोषता;
• निर्धारणवाद।

यो महत्त्वपूर्ण छ किनभने यसले क्लाउड नेटिभ विकासकर्ताहरूको लागि परिचालन मोडेल प्रदान गर्दछ।

• प्रबन्धन र अनुगमन प्रणालीहरूको लागि परम्परागत उपकरणहरू रनबुक भित्र सञ्चालन हुने अपरेसन टोलीहरूसँग सम्बन्धित छन् (नियमित प्रक्रिया र सञ्चालनहरूको सेट - लगभग अनुवाद।), एक विशिष्ट परिनियोजनमा बाँधिएको।
• क्लाउड नेटिभ व्यवस्थापनमा, पर्यवेक्षण उपकरणहरू डिप्लोइमेन्टको नतिजाहरू मापन गर्ने उत्तम तरिका हो ताकि विकास टोलीले छिटो प्रतिक्रिया दिन सक्छ।

कल्पना गर्नुहोस् धेरै क्लस्टरहरू विभिन्न क्लाउडहरूमा छरिएका छन् र तिनीहरूका आफ्नै टोलीहरू र तैनाती योजनाहरूसँग धेरै सेवाहरू। GitOps ले यो सबै प्रचुरता प्रबन्ध गर्न स्केल-अपरिवर्तनीय मोडेल प्रदान गर्दछ।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «GitOps: पुल र पुश विधिहरूको तुलना»;
• «Kubernetes स्रोतहरु को निगरानी को लागी kubedog पुस्तकालय को परिचय»;
• «Kubernetes को विस्तार र पूरक (अवलोकन र भिडियो रिपोर्ट)"।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

Habré मा यी दुई अनुवादहरू देखा पर्नु अघि के तपाईंलाई GitOps को बारेमा थाहा थियो?

• हो, मलाई सबै थाहा थियो

• सतही रुपमा मात्र

• कुनै

35 प्रयोगकर्ताहरूले मतदान गरे। 10 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com