GitOps: आणखी एक बझवर्ड किंवा ऑटोमेशनमधील प्रगती?

आपल्यापैकी बरेच जण, आयटी ब्लॉगस्फीअर किंवा कॉन्फरन्समध्ये आणखी एक नवीन शब्द लक्षात घेऊन, लवकरच किंवा नंतर एक समान प्रश्न विचारतात: “हे काय आहे? फक्त आणखी एक buzzword, एक "buzzword," किंवा काहीतरी खरोखर लक्ष देण्यासारखे आहे, अभ्यास करणे आणि नवीन क्षितिजे वचन देणे? माझ्या बाबतीतही असेच घडले GitOps काही काळापूर्वी. अनेक विद्यमान लेखांसह सशस्त्र, तसेच कंपनीतील सहकार्यांचे ज्ञान गिटॅब, मी हे कोणत्या प्रकारचे श्वापद आहे हे शोधण्याचा प्रयत्न केला आणि त्याचा उपयोग व्यवहारात कसा दिसतो.

तसे, या संज्ञेच्या नवीनतेबद्दल GitOps आमचे अलीकडील सर्वेक्षण असेही म्हणते: सर्वेक्षण केलेल्यांपैकी अर्ध्याहून अधिक लोकांनी अद्याप त्याच्या तत्त्वांनुसार कार्य करण्यास सुरुवात केलेली नाही.

त्यामुळे पायाभूत सुविधांच्या व्यवस्थापनाची समस्या नवीन नाही. अनेक क्लाउड प्रदाते सामान्य लोकांसाठी चांगल्या डझन वर्षांपासून उपलब्ध आहेत आणि असे दिसते की, पायाभूत सुविधांसाठी जबाबदार असलेल्या संघांचे कार्य सोपे आणि सरळ केले पाहिजे. तथापि, ऍप्लिकेशन डेव्हलपमेंट प्रक्रियेशी तुलना केली असता (जेथे ऑटोमेशन नवीन स्तरांवर पोहोचत आहे), पायाभूत सुविधा प्रकल्पांमध्ये अजूनही अनेकदा अनेक मॅन्युअल कार्ये समाविष्ट असतात आणि विशेष ज्ञान आणि कौशल्याची आवश्यकता असते, विशेषत: दोष सहिष्णुता, लवचिकता, स्केलेबिलिटी आणि लवचिकता या आजच्या आवश्यकता लक्षात घेता.

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

मग नेमका फरक काय? GitOps पासून आयएसी? या प्रश्नानेच मी माझी चौकशी सुरू केली. सहकाऱ्यांशी बोलल्यानंतर, मी खालील तुलना करू शकलो:

GitOps

आयएसी

सर्व कोड गिट रेपॉजिटरीमध्ये साठवले जातात

कोड आवृत्ती पर्यायी आहे

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

घोषणात्मक आणि अनिवार्य वर्णन दोन्ही स्वीकार्य आहेत

विलीनीकरण विनंती/पुल विनंती यंत्रणा वापरून बदल प्रभावी होतात

करार, मंजूरी आणि सहयोग ऐच्छिक आहेत

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

अपडेट रोलआउट प्रक्रिया प्रमाणित नाही (स्वयंचलित, मॅन्युअल, फायली कॉपी करणे, कमांड लाइन वापरणे इ.)

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

दुसरीकडे, पायाभूत सुविधा व्यवस्थापन प्रक्रिया स्वयंचलित करणे शक्य झाले. आता हे जलद, अधिक विश्वासार्ह आणि स्वस्त केले जाऊ शकते. शिवाय, सीआय / सीडीची तत्त्वे आधीपासूनच ज्ञात आणि सॉफ्टवेअर विकसकांमध्ये लोकप्रिय होती. आधीच ज्ञात ज्ञान आणि कौशल्ये नवीन क्षेत्रात हस्तांतरित करणे आणि लागू करणे आवश्यक होते. या पद्धती, तथापि, कोड म्हणून पायाभूत सुविधांच्या मानक व्याख्येच्या पलीकडे गेल्या आहेत, म्हणून संकल्पना GitOps.

उत्सुकता GitOps, अर्थातच, हे कोणत्याही विक्रेत्याशी संबंधित उत्पादन, प्लगइन किंवा प्लॅटफॉर्म नाही. हे आणखी एक नमुना आणि तत्त्वांचा संच आहे, जे आपण परिचित असलेल्या दुसर्‍या शब्दाप्रमाणेच आहे: DevOps.

कंपनी मध्ये गिटॅब आम्ही या नवीन शब्दाच्या दोन व्याख्या विकसित केल्या आहेत: सैद्धांतिक आणि व्यावहारिक. चला सैद्धांतिक सह प्रारंभ करूया:

GitOps ही एक पद्धत आहे जी अॅप्लिकेशन डेव्हलपमेंटसाठी वापरली जाणारी सर्वोत्तम DevOps तत्त्वे घेते, जसे की आवृत्ती नियंत्रण, सहयोग, ऑर्केस्ट्रेशन, CI/CD, आणि त्यांना स्वयंचलित पायाभूत सुविधा व्यवस्थापनाच्या आव्हानांना लागू करते.

सर्व प्रक्रिया GitOps मी विद्यमान साधने वापरून काम करतो. सर्व इन्फ्रास्ट्रक्चर कोड आधीच परिचित git रिपॉझिटरीमध्ये संग्रहित केले जातात, बदल इतर प्रोग्राम कोड प्रमाणेच मंजूरी प्रक्रियेतून जातात आणि रोलआउट प्रक्रिया स्वयंचलित असते, ज्यामुळे आम्हाला मानवी चुका कमी करता येतात, विश्वासार्हता आणि पुनरुत्पादन क्षमता वाढते.

व्यावहारिक दृष्टिकोनातून, आम्ही वर्णन करतो GitOps खालीलप्रमाणे:

या सूत्राच्या मुख्य घटकांपैकी एक म्हणून आम्ही कोड म्हणून पायाभूत सुविधांवर आधीच चर्चा केली आहे. बाकीच्या सहभागींची ओळख करून देऊ.

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

पण एमआर हे सहकार्य, परस्परसंवाद आणि संवादाचे एक साधन आहे. ज्या ठिकाणी चेक आणि बॅलन्सची यंत्रणा कार्यान्वित होते. साध्या टिप्पण्यांपासून औपचारिक मंजूरी आणि मंजुरीपर्यंत.

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

होय, पद GitOps आम्हाला पूर्णपणे नवीन कशाचीही ओळख करून देत नाही, चाक पुन्हा शोधून काढत नाही, परंतु नवीन क्षेत्रात आधीच जमा केलेला अनुभव लागू करतो. पण इथेच त्याची ताकद आहे.

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

• GitOps च्या मूलभूत तत्त्वांची अंमलबजावणी करा

• क्लाउड इन्फ्रास्ट्रक्चर तयार करा आणि त्यात बदल करा (यांडेक्स क्लाउडचे उदाहरण वापरून)

• सक्रिय मॉनिटरिंग वापरून इच्छित स्थितीतून सिस्टम ड्रिफ्टचा स्वयंचलित शोध

https://bit.ly/34tRpwZ

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