ग्राहकको प्लेटफर्ममा निरन्तर डिप्लोइमेन्टको हाम्रो कार्यान्वयन

हामीले ट्रु इन्जिनियरिङमा ग्राहक सर्भरहरूमा अद्यावधिकहरूको निरन्तर डेलिभरीको लागि प्रक्रिया सेट अप गरेका छौं र यो अनुभव साझा गर्न चाहन्छौं।

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

यस लेखमा हामी निरन्तर तैनाती (CD) प्रक्रिया वा ग्राहकको प्लेटफर्ममा अद्यावधिकहरूको डेलिभरीका सबै चरणहरूको बारेमा कुरा गर्नेछौं:

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

हामी बाटोमा सेटअप विवरणहरू साझेदारी गर्नेछौं।

1. CD सुरु गर्नुहोस्

निरन्तर परिनियोजन विकासकर्ताले हाम्रो Git भण्डारको रिलिज शाखामा परिवर्तनहरूलाई धक्का दिएर सुरु हुन्छ।

हाम्रो अनुप्रयोग माइक्रोसर्भिस आर्किटेक्चरमा चल्छ र यसका सबै कम्पोनेन्टहरू एउटै भण्डारमा भण्डारण गरिन्छ। यसका लागि धन्यबाद, सबै माइक्रोसेवाहरू सङ्कलन र स्थापना गरिएका छन्, भले पनि तिनीहरूमध्ये एउटा परिवर्तन भएको छ।

हामीले धेरै कारणहरूको लागि एउटा भण्डार मार्फत काम व्यवस्थित गर्यौं:

• विकासको सहजता - अनुप्रयोग सक्रिय रूपमा विकास भइरहेको छ, त्यसैले तपाइँ एकैचोटि सबै कोडसँग काम गर्न सक्नुहुन्छ।
• एकल CI/CD पाइपलाइन जसले ग्यारेन्टी दिन्छ कि एकल प्रणालीको रूपमा अनुप्रयोगले सबै परीक्षणहरू पास गर्छ र ग्राहकको उत्पादन वातावरणमा डेलिभर हुन्छ।
• हामी संस्करणहरूमा भ्रम हटाउँछौं - हामीले माइक्रोसर्भिस संस्करणहरूको नक्सा भण्डारण गर्न र हेल्म लिपिहरूमा प्रत्येक माइक्रोसर्भिसको लागि यसको कन्फिगरेसन वर्णन गर्नुपर्दैन।

2. ग्राहकको स्रोत कोडको Git भण्डारसँग सिंक्रोनाइजेसन

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

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

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

3. ब्याकएन्ड र फ्रन्टएन्ड जोड्दै

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

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

GitLab धावकले आवश्यक भण्डारबाट कोड लिन्छ, यसलाई जाभा एप्लिकेसन बिल्ड कमाण्डसँग भेला गर्छ र यसलाई डकर रजिस्ट्रीमा पठाउँछ। यहाँ हामी ब्याकएन्ड र फ्रन्टएन्ड जम्मा गर्छौं, डकर छविहरू प्राप्त गर्छौं, जुन हामीले ग्राहकको छेउमा भण्डारमा राख्छौं। डकर छविहरू व्यवस्थापन गर्न हामीले प्रयोग गर्छौं Gradle प्लगइन.

हामी हाम्रा छविहरूको संस्करणहरू रिलिज संस्करणसँग सिङ्क्रोनाइज गर्छौं जुन डकरमा प्रकाशित हुनेछ। सहज सञ्चालनको लागि हामीले धेरै समायोजन गरेका छौं:

1. कन्टेनर परीक्षण वातावरण र उत्पादन वातावरण बीच पुनर्निर्माण छैन। हामीले परिमितिहरू बनायौं ताकि एउटै कन्टेनरले परीक्षण वातावरणमा र उत्पादनमा पुन: निर्माण नगरी सबै सेटिङहरू, वातावरणीय चरहरू र सेवाहरूसँग काम गर्न सकोस्।

2. Helm मार्फत एप्लिकेसन अपडेट गर्न, तपाईंले यसको संस्करण निर्दिष्ट गर्नुपर्छ। हामी ब्याकइन्ड, फ्रन्टएन्ड र एप्लिकेसन अपडेट गर्छौं - यी तीन फरक कार्यहरू हुन्, त्यसैले अनुप्रयोगको एउटै संस्करण जताततै प्रयोग गर्नु महत्त्वपूर्ण छ। यस कार्यको लागि, हामी Git इतिहासबाट डाटा प्रयोग गर्छौं, किनकि हाम्रो K8S क्लस्टर कन्फिगरेसन र अनुप्रयोगहरू समान Git भण्डारमा छन्।

हामीले कमाण्ड कार्यान्वयन परिणामहरूबाट अनुप्रयोग संस्करण प्राप्त गर्छौं
git describe --tags --abbrev=7.

4. परीक्षण वातावरण (UAT) मा सबै परिवर्तनहरूको स्वचालित तैनाती

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

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

हामी K8S क्लस्टर कन्फिगरेसनलाई एसेम्बलीसँगै आपूर्ति गर्छौं। त्यसकारण, अर्को चरण यसलाई अद्यावधिक गर्नु हो: कन्फिगरेसन म्याप्स, डिप्लोइमेन्ट, सेवाहरू, गोप्य र हामीले परिवर्तन गरेका कुनै पनि अन्य K8S कन्फिगरेसनहरू।

हेल्मले त्यसपछि परीक्षण वातावरणमा अनुप्रयोगको रोलआउट अपडेट चलाउँछ। एप्लिकेसन उत्पादनमा प्रयोग गर्नु अघि। यो गरिन्छ ताकि प्रयोगकर्ताहरूले म्यानुअल रूपमा हामीले परीक्षण वातावरणमा राखेका व्यावसायिक सुविधाहरू परीक्षण गर्न सक्छन्।

5. प्रोडमा सबै परिवर्तनहरूको स्वचालित तैनाती

उत्पादन वातावरणमा अद्यावधिक तैनात गर्न, तपाईंले GitLab मा एउटा बटन क्लिक गर्न आवश्यक छ - र कन्टेनरहरू तुरुन्तै उत्पादन वातावरणमा डेलिभर हुन्छन्।

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

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

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

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

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

.values.global.env - यो चरले वातावरणको नाम भण्डार गर्दछ (प्रोड, स्टेज, UAT)।
.values.app.properties.app_external_domain - यो भेरिएबलमा हामीले .Values.yaml फाइलमा चाहिएको डोमेन सेट गर्छौं

एप्लिकेसन अपडेट गर्दा, हेलमले टेम्प्लेटहरूबाट एउटा configmap.yaml फाइल सिर्जना गर्छ र APP_EXTERNAL_DOMAIN मानलाई एप्लिकेसन अपडेट सुरु हुने वातावरणमा भर पर्छ। यो चर कन्टेनरमा पहिले नै सेट गरिएको छ। यो अनुप्रयोगबाट पहुँच गर्न सकिन्छ, त्यसैले प्रत्येक अनुप्रयोग वातावरणमा यो चरको लागि फरक मान हुनेछ।

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

कुल

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

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

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

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

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

हामी K8S कार्य मार्फत डाटाबेस माइग्रेसन स्वचालित गर्ने योजना बनाइरहेका छौं, यसलाई CD प्रक्रियामा एकीकृत गर्दै। र हामी पक्कै पनि Habré मा यो अनुभव साझा गर्नेछौं।

स्रोत: www.habr.com