GitOps: अर्को buzzword वा स्वचालन मा एक सफलता?

हामी मध्ये धेरै जसो, आईटी ब्लोगोस्फियर वा सम्मेलनमा अर्को नयाँ शब्द हेर्दै, ढिलो वा पछि समान प्रश्न सोध्नुहोस्: "यो के हो? केवल अर्को buzzword, एक "buzzword," वा केहि साँच्चै ध्यान दिन लायक छ, अध्ययन, र नयाँ क्षितिजको प्रतिज्ञा? पदको साथमा पनि त्यस्तै भयो GitOps केहि समय अगाडी। धेरै अवस्थित लेखहरू, साथै कम्पनीका सहकर्मीहरूको ज्ञानको साथ सशस्त्र GitLab, मैले यो कस्तो प्रकारको जनावर हो भनेर पत्ता लगाउने प्रयास गरें, र यसको प्रयोग व्यवहारमा कस्तो देखिन्छ।

वैसे, शब्द को नवीनता को बारे मा GitOps हाम्रो भर्खरको सर्वेक्षणले यो पनि भन्छ: सर्वेक्षण गरिएका आधा भन्दा बढीले अझै यसको सिद्धान्तहरूसँग काम गर्न थालेका छैनन्।

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

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

त्यसोभए वास्तवमा के फरक छ? GitOps देखि आईएसी? यही प्रश्नका साथ मैले मेरो अनुसन्धान सुरु गरें। सहकर्मीहरूसँग कुरा गरेपछि, म निम्न तुलनाको साथ आउन सक्षम भएँ:

GitOps

आईएसी

सबै कोड गिट रिपोजिटरीमा भण्डार गरिएको छ

कोड संस्करण वैकल्पिक छ

घोषणात्मक कोड विवरण / इडम्पोटेन्सी

दुबै घोषणात्मक र अनिवार्य विवरणहरू स्वीकार्य छन्

परिवर्तनहरू मर्ज अनुरोध / पुल अनुरोध संयन्त्रहरू प्रयोग गरेर प्रभावकारी हुन्छन्

सम्झौता, अनुमोदन र सहयोग ऐच्छिक छन्

अपडेट रोलआउट प्रक्रिया स्वचालित छ

अद्यावधिक रोलआउट प्रक्रिया मानकीकृत छैन (स्वचालित, म्यानुअल, प्रतिलिपि फाइलहरू, कमाण्ड लाइन प्रयोग गरेर, आदि)।

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

अर्कोतर्फ, पूर्वाधार व्यवस्थापन प्रक्रियाहरू स्वचालित गर्न सम्भव भयो। अब यो छिटो, थप भरपर्दो र सस्तो गर्न सकिन्छ। यसबाहेक, CI / CD को सिद्धान्तहरू पहिले नै सफ्टवेयर विकासकर्ताहरू बीच ज्ञात र लोकप्रिय थिए। यो केवल नयाँ क्षेत्रमा पहिले नै ज्ञात ज्ञान र सीपहरू हस्तान्तरण गर्न र लागू गर्न आवश्यक थियो। यी अभ्यासहरू, तथापि, कोडको रूपमा पूर्वाधारको मानक परिभाषाभन्दा पर गए, त्यसैले अवधारणा GitOps.

जिज्ञासा GitOps, अवश्य पनि, यो तथ्यमा पनि कि यो कुनै पनि विक्रेतासँग सम्बन्धित उत्पादन, प्लगइन वा प्लेटफर्म होइन। यो एक प्रतिमान र सिद्धान्तहरूको एक सेट हो, हामीसँग परिचित अर्को शब्द जस्तै: DevOps।

कम्पनीमा GitLab हामीले यस नयाँ शब्दको दुई परिभाषाहरू विकास गरेका छौं: सैद्धान्तिक र व्यावहारिक। सैद्धान्तिक संग सुरु गरौं:

GitOps एउटा पद्धति हो जसले अनुप्रयोग विकासको लागि प्रयोग गरिने उत्कृष्ट DevOps सिद्धान्तहरू लिन्छ, जस्तै संस्करण नियन्त्रण, सहयोग, अर्केस्ट्रेसन, CI/CD, र तिनीहरूलाई स्वचालित पूर्वाधार व्यवस्थापनका चुनौतीहरूमा लागू गर्दछ।

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

व्यावहारिक दृष्टिकोणबाट, हामी वर्णन गर्छौं GitOps निम्न अनुसार:

हामीले पूर्वाधारलाई यस सूत्रको मुख्य अंगको रूपमा कोडको रूपमा छलफल गरिसकेका छौं। बाँकी सहभागीहरूको परिचय गरौं।

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

तर एमआर सहयोग, अन्तरक्रिया र सञ्चारको माध्यम पनि हो। चेक र ब्यालेन्सको प्रणाली खेल्ने ठाउँ। साधारण टिप्पणी देखि औपचारिक अनुमोदन र अनुमोदन सम्म।

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

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

र यदि तपाइँ अचानक यो सबै व्यवहारमा कसरी देखिन्छ भन्नेमा रुचि राख्नुहुन्छ भने, म तपाइँलाई हाम्रो हेर्न आमन्त्रित गर्दछु। मास्टर वर्ग, जसमा म तपाईंलाई GitLab कसरी प्रयोग गर्ने भनेर चरणबद्ध रूपमा बताउँछु:

• GitOps को आधारभूत सिद्धान्तहरू लागू गर्नुहोस्

• क्लाउड पूर्वाधार सिर्जना गर्नुहोस् र परिवर्तन गर्नुहोस् (यान्डेक्स क्लाउडको उदाहरण प्रयोग गरेर)

• सक्रिय निगरानी प्रयोग गरेर इच्छित अवस्थाबाट प्रणाली बहावको स्वचालित पत्ता लगाउने

https://bit.ly/34tRpwZ

स्रोत: www.habr.com