ग्राहकांच्या प्लॅटफॉर्मवर सतत उपयोजनाची आमची अंमलबजावणी

आम्ही ट्रू इंजिनीअरिंगमध्ये ग्राहक सर्व्हरवर सतत अद्यतने वितरित करण्यासाठी एक प्रक्रिया सेट केली आहे आणि हा अनुभव सामायिक करू इच्छितो.

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

या लेखात आम्ही सतत उपयोजन (CD) प्रक्रियेच्या सर्व टप्प्यांबद्दल किंवा ग्राहकाच्या प्लॅटफॉर्मवर अद्यतने वितरित करण्याबद्दल बोलू:

1. ही प्रक्रिया कशी सुरू होते?
2. ग्राहकाच्या Git भांडारासह सिंक्रोनाइझेशन,
3. बॅकएंड आणि फ्रंटएंडचे असेंब्ली,
4. चाचणी वातावरणात स्वयंचलित अनुप्रयोग उपयोजन,
5. उत्पादनावर स्वयंचलित उपयोजन.

आम्ही वाटेत सेटअप तपशील सामायिक करू.

1. सीडी सुरू करा

विकासकाने आमच्या Git रेपॉजिटरीच्या प्रकाशन शाखेत बदल पुश करण्यापासून सतत उपयोजन सुरू होते.

आमचा अनुप्रयोग मायक्रोसर्व्हिस आर्किटेक्चरवर चालतो आणि त्याचे सर्व घटक एकाच भांडारात संग्रहित केले जातात. याबद्दल धन्यवाद, सर्व मायक्रोसेवा एकत्रित केल्या जातात आणि स्थापित केल्या जातात, जरी त्यापैकी एक बदलला असेल.

आम्ही अनेक कारणांसाठी एका भांडाराद्वारे कार्य आयोजित केले:

• विकासाची सुलभता - अनुप्रयोग सक्रियपणे विकसित होत आहे, म्हणून आपण एकाच वेळी सर्व कोडसह कार्य करू शकता.
• एक सिंगल सीआय/सीडी पाइपलाइन जी हमी देते की सिंगल सिस्टम म्हणून अॅप्लिकेशन सर्व चाचण्या उत्तीर्ण करते आणि ग्राहकाच्या उत्पादन वातावरणात वितरित केले जाते.
• आम्ही आवृत्त्यांमधील गोंधळ दूर करतो - आम्हाला मायक्रोसर्व्हिस आवृत्त्यांचा नकाशा संग्रहित करण्याची आणि हेल्म स्क्रिप्टमधील प्रत्येक मायक्रोसर्व्हिससाठी त्याच्या कॉन्फिगरेशनचे वर्णन करण्याची आवश्यकता नाही.

2. ग्राहकाच्या स्त्रोत कोडच्या Git भांडारासह सिंक्रोनाइझेशन

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

आम्ही ग्राहकांच्या भांडारात थेट काम करू शकत नाही कारण आम्हाला विकास आणि चाचणीसाठी आमच्या स्वतःच्या वातावरणाची आवश्यकता आहे. आम्ही आमच्या Git रिपॉझिटरी या उद्देशांसाठी वापरतो - ते त्यांच्या Git रेपॉजिटरीसह समक्रमित केले जाते. विकासकाने आमच्या भांडाराच्या योग्य शाखेत बदल केल्यावर GitLab ताबडतोब हे बदल ग्राहकांपर्यंत पोचवते.

या नंतर आपण विधानसभा करणे आवश्यक आहे. यात अनेक टप्पे असतात: बॅकएंड आणि फ्रंटएंड असेंब्ली, चाचणी आणि उत्पादनासाठी वितरण.

3. बॅकएंड आणि फ्रंटएंड एकत्र करणे

बॅकएंड आणि फ्रंटएंड तयार करणे ही दोन समांतर कार्ये आहेत जी GitLab रनर सिस्टममध्ये केली जातात. त्याचे मूळ असेंब्ली कॉन्फिगरेशन त्याच भांडारात स्थित आहे.

GitLab मध्ये बिल्डिंगसाठी YAML स्क्रिप्ट लिहिण्यासाठी ट्यूटोरियल.

GitLab रनर आवश्यक रेपॉजिटरीमधून कोड घेतो, तो जावा अॅप्लिकेशन बिल्ड कमांडसह एकत्र करतो आणि डॉकर रेजिस्ट्रीला पाठवतो. येथे आम्ही बॅकएंड आणि फ्रंटएंड एकत्र करतो, डॉकर प्रतिमा मिळवतो, ज्या आम्ही ग्राहकाच्या बाजूला असलेल्या भांडारात ठेवतो. डॉकर प्रतिमा व्यवस्थापित करण्यासाठी आम्ही वापरतो ग्रेडल प्लगइन.

आम्ही आमच्या प्रतिमांच्या आवृत्त्या डॉकरमध्ये प्रकाशित केलेल्या रिलीझ आवृत्तीसह समक्रमित करतो. सुरळीत ऑपरेशनसाठी आम्ही अनेक समायोजन केले आहेत:

1. चाचणी वातावरण आणि उत्पादन वातावरण यांच्यामध्ये कंटेनर पुन्हा तयार केले जात नाहीत. आम्ही पॅरामीटरायझेशन केले जेणेकरुन समान कंटेनर सर्व सेटिंग्ज, पर्यावरण व्हेरिएबल्स आणि सेवांसह चाचणी वातावरणात आणि उत्पादनात पुनर्बांधणी न करता कार्य करू शकेल.

2. हेल्म द्वारे अनुप्रयोग अद्यतनित करण्यासाठी, आपण त्याची आवृत्ती निर्दिष्ट करणे आवश्यक आहे. आम्ही बॅकएंड, फ्रंटएंड तयार करतो आणि अॅप्लिकेशन अपडेट करतो - ही तीन वेगवेगळी टास्क आहेत, त्यामुळे अॅप्लिकेशनची समान आवृत्ती सर्वत्र वापरणे महत्त्वाचे आहे. या कार्यासाठी, आम्ही Git इतिहासातील डेटा वापरतो, कारण आमचे K8S क्लस्टर कॉन्फिगरेशन आणि ऍप्लिकेशन्स एकाच Git भांडारात आहेत.

आम्हाला कमांडच्या अंमलबजावणीच्या परिणामांमधून ऍप्लिकेशन आवृत्ती मिळते
git describe --tags --abbrev=7.

4. चाचणी वातावरणातील सर्व बदलांचे स्वयंचलित उपयोजन (UAT)

या बिल्ड स्क्रिप्टमधील पुढील पायरी म्हणजे K8S क्लस्टर आपोआप अपडेट करणे. हे असे घडते की संपूर्ण अनुप्रयोग तयार केला गेला आहे आणि सर्व कलाकृती डॉकर रजिस्ट्रीमध्ये प्रकाशित केल्या गेल्या आहेत. यानंतर, चाचणी वातावरण अद्यतन सुरू होते.

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

आम्ही असेंब्लीसह K8S क्लस्टर कॉन्फिगरेशन पुरवतो. म्हणून, पुढील पायरी म्हणजे ते अपडेट करणे: configMaps, उपयोजन, सेवा, रहस्ये आणि आम्ही बदललेली कोणतीही K8S कॉन्फिगरेशन.

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

5. प्रोडमधील सर्व बदलांचे स्वयंचलित उपयोजन

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

समान अनुप्रयोग वेगवेगळ्या वातावरणात-चाचणी आणि उत्पादन-पुनर्बांधणीशिवाय कार्य करू शकतो. आम्ही अनुप्रयोगात काहीही न बदलता समान कलाकृती वापरतो आणि आम्ही पॅरामीटर्स बाह्यरित्या सेट करतो.

अनुप्रयोग सेटिंग्जचे लवचिक पॅरामीटरायझेशन ज्या वातावरणात अनुप्रयोग कार्यान्वित केले जाईल त्यावर अवलंबून असते. आम्ही सर्व पर्यावरण सेटिंग्ज बाहेरून हलवली आहेत: सर्व काही 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 समर्थन स्प्रिंग क्लाउडमध्ये दिसले, configMaps सह कार्य: स्प्रिंग मेघ कुबर्नेट्स. प्रकल्प सक्रियपणे विकसित होत असताना आणि आमूलाग्र बदलत असताना, आम्ही उत्पादनात त्याचा वापर करू शकत नाही. परंतु आम्ही त्याच्या स्थितीचे सक्रियपणे निरीक्षण करतो आणि ते DEV कॉन्फिगरेशनमध्ये वापरतो. ते स्थिर होताच, आम्ही पर्यावरण व्हेरिएबल्स वापरण्यापासून त्यावर स्विच करू.

एकूण

तर, सतत उपयोजन कॉन्फिगर केले आहे आणि कार्यरत आहे. सर्व अद्यतने एका कीस्ट्रोकने होतात. उत्पादन वातावरणातील बदलांचे वितरण स्वयंचलित आहे. आणि, महत्त्वाचे म्हणजे, अद्यतने सिस्टम थांबवत नाहीत.

भविष्यातील योजना: स्वयंचलित डेटाबेस स्थलांतर

आम्ही डेटाबेस श्रेणीसुधारित करण्याचा आणि हे बदल परत आणण्याच्या शक्यतेबद्दल विचार केला. शेवटी, अनुप्रयोगाच्या दोन भिन्न आवृत्त्या एकाच वेळी चालू आहेत: जुनी चालू आहे आणि नवीन चालू आहे. आणि जेव्हा आम्हाला खात्री असेल की नवीन आवृत्ती कार्य करते तेव्हाच आम्ही जुने बंद करू. डेटाबेस स्थलांतराने तुम्हाला अनुप्रयोगाच्या दोन्ही आवृत्त्यांसह कार्य करण्याची अनुमती दिली पाहिजे.

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

अनुप्रयोगाची नवीन आवृत्ती योग्यरित्या कार्य करत नसल्यास, आम्ही डेटाबेसच्या मागील आवृत्तीसह मागील आवृत्तीवर परत येऊ शकतो. थोडक्यात, आमचे बदल तुम्हाला अॅप्लिकेशनच्या अनेक आवृत्त्यांसह एकाच वेळी कार्य करण्यास अनुमती देतील.

आम्ही K8S जॉब द्वारे डेटाबेस स्थलांतर स्वयंचलित करण्याची योजना आखत आहोत, ते सीडी प्रक्रियेमध्ये समाकलित करू. आणि हा अनुभव आम्ही Habré वर नक्कीच शेअर करू.

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