📴 🏕️ 👨🏿‍🏭 हमने ग्राहक के प्लेटफ़ॉर्म पर निरंतर अपडेट डिलीवरी कैसे लागू की ⏳ 🕕 🤴🏽

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

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

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

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

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

1. सीडी शुरू करें

निरंतर तैनाती इस तथ्य से शुरू होती है कि डेवलपर हमारे गिट रिपॉजिटरी की रिलीज शाखा में परिवर्तन पोस्ट करता है।

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

हमने कई कारणों से एक रिपॉजिटरी के माध्यम से काम का आयोजन किया:

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

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

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

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

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

3. बैकएंड और फ्रंटेंड का निर्माण करें

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

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

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

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

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

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

हम कमांड के परिणामों से आवेदन संस्करण प्राप्त करते हैं
git describe --tags --abbrev=7 ।

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

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

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

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

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

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

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

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

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

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

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

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

.Values.global.env - पर्यावरण (ठेस, मंच, यूएटी ) का नाम इस चर में संग्रहीत है।
.Values.app.properties.app_external_domain - इस चर में हम .Values.yaml फ़ाइल में इच्छित डोमेन सेट करते हैं।

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

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

कुल मिलाकर

तो, कंटिन्युअस डिप्लॉयमेंट ऊपर और चल रहा है। सभी अपडेट एक बटन के क्लिक पर होते हैं। खाद्य पर्यावरण में परिवर्तन का वितरण स्वचालित है। और, महत्वपूर्ण बात, अपडेट सिस्टम को रोकते नहीं हैं।

भविष्य की योजना: स्वचालित आधार प्रवासन

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

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

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

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

हमने ग्राहक के प्लेटफ़ॉर्म पर निरंतर अपडेट डिलीवरी कैसे लागू की