ग्राहक के प्लेटफ़ॉर्म पर सतत परिनियोजन का हमारा कार्यान्वयन

ट्रू इंजीनियरिंग में हमने ग्राहक सर्वर पर अपडेट की निरंतर डिलीवरी के लिए एक प्रक्रिया स्थापित की है और इस अनुभव को साझा करना चाहते हैं।

शुरुआत करने के लिए, हमने ग्राहक के लिए एक ऑनलाइन सिस्टम विकसित किया और इसे अपने कुबेरनेट्स क्लस्टर में तैनात किया। अब हमारा हाई-लोड समाधान ग्राहक के प्लेटफ़ॉर्म पर चला गया है, जिसके लिए हमने पूरी तरह से स्वचालित सतत परिनियोजन प्रक्रिया स्थापित की है। इसके लिए धन्यवाद, हमने टाइम-टू-मार्केट - उत्पाद वातावरण में परिवर्तन की डिलीवरी को तेज कर दिया।

इस लेख में हम सतत परिनियोजन (सीडी) प्रक्रिया के सभी चरणों, या ग्राहक के प्लेटफ़ॉर्म पर अपडेट की डिलीवरी के बारे में बात करेंगे:

1. यह प्रक्रिया कैसे प्रारंभ होती है?
2. ग्राहक के Git भंडार के साथ सिंक्रनाइज़ेशन,
3. बैकएंड और फ्रंटएंड की असेंबली,
4. परीक्षण परिवेश में स्वचालित अनुप्रयोग परिनियोजन,
5. उत्पाद पर स्वचालित तैनाती।

हम रास्ते में सेटअप विवरण साझा करेंगे।

1. सीडी प्रारंभ करें

सतत परिनियोजन की शुरुआत डेवलपर द्वारा हमारे Git रिपॉजिटरी की रिलीज़ शाखा में परिवर्तन करने से होती है।

हमारा एप्लिकेशन एक माइक्रोसर्विस आर्किटेक्चर पर चलता है और इसके सभी घटक एक रिपॉजिटरी में संग्रहीत होते हैं। इसके लिए धन्यवाद, सभी माइक्रोसर्विसेज एकत्र और स्थापित किए जाते हैं, भले ही उनमें से एक बदल गया हो।

हमने कई कारणों से एक ही भंडार के माध्यम से कार्य को व्यवस्थित किया:

• विकास में आसानी - एप्लिकेशन सक्रिय रूप से विकसित हो रहा है, इसलिए आप एक ही बार में सभी कोड के साथ काम कर सकते हैं।
• एक एकल सीआई/सीडी पाइपलाइन जो गारंटी देती है कि एकल सिस्टम के रूप में एप्लिकेशन सभी परीक्षणों को पास कर लेता है और ग्राहक के उत्पादन वातावरण तक पहुंचा दिया जाता है।
• हम संस्करणों में भ्रम को खत्म करते हैं - हमें माइक्रोसर्विस संस्करणों का मानचित्र संग्रहीत करने और हेल्म स्क्रिप्ट में प्रत्येक माइक्रोसर्विस के लिए इसकी कॉन्फ़िगरेशन का वर्णन करने की आवश्यकता नहीं है।

2. ग्राहक के स्रोत कोड के Git रिपॉजिटरी के साथ सिंक्रनाइज़ेशन

किए गए परिवर्तन स्वचालित रूप से ग्राहक के Git रिपॉजिटरी के साथ सिंक्रनाइज़ हो जाते हैं। वहां एप्लिकेशन असेंबली कॉन्फ़िगर की गई है, जिसे शाखा को अपडेट करने और निरंतरता के लिए तैनाती के बाद लॉन्च किया गया है। दोनों प्रक्रियाएँ उनके वातावरण में Git रिपॉजिटरी से उत्पन्न होती हैं।

हम सीधे ग्राहक के भंडार के साथ काम नहीं कर सकते क्योंकि हमें विकास और परीक्षण के लिए अपने स्वयं के वातावरण की आवश्यकता है। हम इन उद्देश्यों के लिए अपने Git रिपॉजिटरी का उपयोग करते हैं - यह उनके Git रिपॉजिटरी के साथ सिंक्रनाइज़ है। जैसे ही कोई डेवलपर हमारे रिपॉजिटरी की उपयुक्त शाखा में परिवर्तन पोस्ट करता है, GitLab तुरंत इन परिवर्तनों को ग्राहक तक पहुंचा देता है।

इसके बाद आपको असेंबली करनी होगी. इसमें कई चरण होते हैं: बैकएंड और फ्रंटएंड असेंबली, परीक्षण और उत्पादन तक डिलीवरी।

3. बैकएंड और फ्रंटएंड को असेंबल करना

बैकएंड और फ्रंटएंड का निर्माण दो समानांतर कार्य हैं जो गिटलैब रनर सिस्टम में किए जाते हैं। इसका मूल असेंबली कॉन्फ़िगरेशन उसी रिपॉजिटरी में स्थित है।

GitLab में निर्माण के लिए YAML स्क्रिप्ट लिखने के लिए ट्यूटोरियल.

GitLab रनर आवश्यक रिपॉजिटरी से कोड लेता है, इसे जावा एप्लिकेशन बिल्ड कमांड के साथ इकट्ठा करता है और डॉकर रजिस्ट्री को भेजता है। यहां हम बैकएंड और फ्रंटएंड को इकट्ठा करते हैं, डॉकर छवियां प्राप्त करते हैं, जिन्हें हम ग्राहक की ओर से एक रिपॉजिटरी में डालते हैं। डॉकर छवियों को प्रबंधित करने के लिए हम इसका उपयोग करते हैं ग्रैडल प्लगइन.

हम अपनी छवियों के संस्करणों को रिलीज़ संस्करण के साथ सिंक्रनाइज़ करते हैं जो डॉकर में प्रकाशित किया जाएगा। सुचारू संचालन के लिए हमने कई समायोजन किए हैं:

1. परीक्षण परिवेश और उत्पादन परिवेश के बीच कंटेनरों का पुनर्निर्माण नहीं किया जाता है। हमने पैरामीट्रिज़ेशन बनाए ताकि एक ही कंटेनर परीक्षण वातावरण और उत्पादन दोनों में पुनर्निर्माण के बिना सभी सेटिंग्स, पर्यावरण चर और सेवाओं के साथ काम कर सके।

2. हेल्म के माध्यम से किसी एप्लिकेशन को अपडेट करने के लिए, आपको उसका संस्करण निर्दिष्ट करना होगा। हम बैकएंड, फ्रंटएंड बनाते हैं और एप्लिकेशन को अपडेट करते हैं - ये तीन अलग-अलग कार्य हैं, इसलिए हर जगह एप्लिकेशन के एक ही संस्करण का उपयोग करना महत्वपूर्ण है। इस कार्य के लिए, हम Git इतिहास से डेटा का उपयोग करते हैं, क्योंकि हमारा K8S क्लस्टर कॉन्फ़िगरेशन और एप्लिकेशन एक ही Git रिपॉजिटरी में हैं।

हमें कमांड निष्पादन परिणामों से एप्लिकेशन संस्करण मिलता है
git describe --tags --abbrev=7.

4. परीक्षण वातावरण (यूएटी) में सभी परिवर्तनों की स्वचालित तैनाती

इस बिल्ड स्क्रिप्ट में अगला चरण K8S क्लस्टर को स्वचालित रूप से अपडेट करना है। ऐसा तब होता है जब संपूर्ण एप्लिकेशन बनाया गया हो और सभी कलाकृतियाँ डॉकर रजिस्ट्री में प्रकाशित की गई हों। इसके बाद, परीक्षण परिवेश अद्यतन प्रारंभ होता है.

क्लस्टर अद्यतन का उपयोग प्रारंभ हो गया है हेल्म अद्यतन. यदि, परिणामस्वरूप, कुछ योजना के अनुसार नहीं हुआ, तो हेल्म स्वचालित रूप से और स्वतंत्र रूप से अपने सभी परिवर्तनों को वापस ले लेगा। उनके काम पर नियंत्रण की जरूरत नहीं है.

हम असेंबली के साथ K8S क्लस्टर कॉन्फ़िगरेशन की आपूर्ति करते हैं। इसलिए, अगला कदम इसे अपडेट करना है: कॉन्फिगमैप्स, परिनियोजन, सेवाएँ, रहस्य और कोई अन्य K8S कॉन्फ़िगरेशन जो हमने बदल दिया है।

इसके बाद हेल्म परीक्षण परिवेश में ही एप्लिकेशन का रोलआउट अपडेट चलाता है। एप्लिकेशन को उत्पादन में तैनात करने से पहले। ऐसा इसलिए किया जाता है ताकि उपयोगकर्ता उन व्यावसायिक सुविधाओं का मैन्युअल रूप से परीक्षण कर सकें जिन्हें हम परीक्षण वातावरण में डालते हैं।

5. उत्पाद में सभी परिवर्तनों की स्वचालित तैनाती

उत्पादन परिवेश में अपडेट तैनात करने के लिए, आपको GitLab में बस एक बटन पर क्लिक करना होगा - और कंटेनर तुरंत उत्पादन परिवेश में पहुंचा दिए जाएंगे।

एक ही एप्लिकेशन पुनर्निर्माण के बिना विभिन्न वातावरणों-परीक्षण और उत्पादन-में काम कर सकता है। हम एप्लिकेशन में कुछ भी बदले बिना समान कलाकृतियों का उपयोग करते हैं, और हम बाहरी रूप से पैरामीटर सेट करते हैं।

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

सबसे कठिन काम पर्यावरण पर निर्भर सभी उपयोग की गई सेवाओं और चर को पैरामीटराइज़ करना था, और उन्हें हेल्म के लिए पर्यावरण चर और पर्यावरण मापदंडों के विवरण-कॉन्फ़िगरेशन में अनुवाद करना था।

एप्लिकेशन सेटिंग्स पर्यावरण चर का उपयोग करती हैं। उनके मान K8S कॉन्फ़िगमैप का उपयोग करके कंटेनरों में सेट किए गए हैं, जो गो टेम्प्लेट का उपयोग करके टेम्प्लेट किया गया है। उदाहरण के लिए, डोमेन नाम पर एक पर्यावरण चर सेट करना इस प्रकार किया जा सकता है:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - यह वेरिएबल पर्यावरण का नाम (उत्पाद, चरण, यूएटी) संग्रहीत करता है।
.वैल्यूज़.ऐप.प्रॉपर्टीज़.ऐप_एक्सटर्नल_डोमेन - इस वेरिएबल में हम वांछित डोमेन को .Values.yaml फ़ाइल में सेट करते हैं

किसी एप्लिकेशन को अपडेट करते समय, हेल्म टेम्प्लेट से एक configmap.yaml फ़ाइल बनाता है और उस वातावरण के आधार पर APP_EXTERNAL_DOMAIN मान को वांछित मान से भरता है जिसमें एप्लिकेशन अपडेट शुरू होता है। यह वेरिएबल पहले से ही कंटेनर में सेट है। इसे एप्लिकेशन से एक्सेस किया जा सकता है, इसलिए प्रत्येक एप्लिकेशन वातावरण में इस वेरिएबल के लिए एक अलग मान होगा।

अपेक्षाकृत हाल ही में, K8S समर्थन स्प्रिंग क्लाउड में दिखाई दिया, जिसमें कॉन्फिगमैप्स के साथ काम भी शामिल है: स्प्रिंग क्लाउड कुबेरनेट्स. जबकि परियोजना सक्रिय रूप से विकसित हो रही है और मौलिक रूप से बदल रही है, हम इसे उत्पादन में उपयोग नहीं कर सकते हैं। लेकिन हम सक्रिय रूप से इसकी स्थिति की निगरानी करते हैं और DEV कॉन्फ़िगरेशन में इसका उपयोग करते हैं। जैसे ही यह स्थिर हो जाएगा, हम पर्यावरण चर का उपयोग करना बंद कर देंगे।

कुल मिलाकर

तो, सतत परिनियोजन कॉन्फ़िगर किया गया है और काम कर रहा है। सभी अपडेट एक कीस्ट्रोक से होते हैं। उत्पाद परिवेश में परिवर्तनों का वितरण स्वचालित है। और, महत्वपूर्ण बात यह है कि अपडेट सिस्टम को रोकते नहीं हैं।

भविष्य की योजनाएँ: स्वचालित डेटाबेस माइग्रेशन

हमने डेटाबेस को अपग्रेड करने और इन परिवर्तनों को वापस लाने की संभावना के बारे में सोचा। आख़िरकार, एप्लिकेशन के दो अलग-अलग संस्करण एक ही समय में चल रहे हैं: पुराना चल रहा है, और नया चल रहा है। और हम पुराने को तभी बंद करेंगे जब हमें यकीन हो जाएगा कि नया संस्करण काम करता है। डेटाबेस माइग्रेशन से आपको एप्लिकेशन के दोनों संस्करणों के साथ काम करने की अनुमति मिलनी चाहिए।

इसलिए, हम केवल कॉलम नाम या अन्य डेटा नहीं बदल सकते। लेकिन हम एक नया कॉलम बना सकते हैं, पुराने कॉलम से डेटा को इसमें कॉपी कर सकते हैं और ट्रिगर्स लिख सकते हैं, जो डेटा को अपडेट करते समय, साथ ही इसे दूसरे कॉलम में कॉपी और अपडेट करेंगे। और एप्लिकेशन के नए संस्करण की सफल तैनाती के बाद, पोस्ट लॉन्च समर्थन अवधि के बाद, हम पुराने कॉलम और अनावश्यक हो गए ट्रिगर को हटाने में सक्षम होंगे।

यदि एप्लिकेशन का नया संस्करण सही ढंग से काम नहीं करता है, तो हम डेटाबेस के पिछले संस्करण सहित पिछले संस्करण पर वापस जा सकते हैं। संक्षेप में, हमारे परिवर्तन आपको एप्लिकेशन के कई संस्करणों के साथ एक साथ काम करने की अनुमति देंगे।

हम K8S जॉब के माध्यम से डेटाबेस माइग्रेशन को स्वचालित करने, इसे सीडी प्रक्रिया में एकीकृत करने की योजना बना रहे हैं। और हम निश्चित रूप से इस अनुभव को हैबे पर साझा करेंगे।

स्रोत: www.habr.com