डॉकर के साथ सतत वितरण अभ्यास (समीक्षा और वीडियो)

हम अपने ब्लॉग की शुरुआत अपने तकनीकी निदेशक के नवीनतम भाषणों पर आधारित प्रकाशनों से करेंगे डिस्टोल (दिमित्री स्टोलारोव)। ये सभी 2016 में विभिन्न व्यावसायिक आयोजनों में हुए और DevOps और Docker के विषय के लिए समर्पित थे। Badoo कार्यालय में डॉकर मॉस्को मीटिंग का एक वीडियो हमारे पास पहले ही है प्रकाशित ऑनलाइन। नए लेखों के साथ रिपोर्ट का सार बताने वाले लेख भी होंगे। इसलिए…

सम्मेलन में 31 मई रूटकॉन्फ 2016, उत्सव "रूसी इंटरनेट टेक्नोलॉजीज" (आरआईटी++ 2016) के हिस्से के रूप में आयोजित, "सतत परिनियोजन और परिनियोजन" अनुभाग "डॉकर के साथ निरंतर वितरण की सर्वोत्तम प्रथाओं" रिपोर्ट के साथ खोला गया। इसने डॉकर और अन्य ओपन सोर्स उत्पादों का उपयोग करके सतत वितरण (सीडी) प्रक्रिया के निर्माण के लिए सर्वोत्तम प्रथाओं को संक्षेप और व्यवस्थित किया। हम उत्पादन में इन समाधानों के साथ काम करते हैं, जो हमें व्यावहारिक अनुभव पर भरोसा करने की अनुमति देता है।

यदि आपके पास एक घंटा बिताने का अवसर है रिपोर्ट का वीडियो, हम इसे पूरा देखने की सलाह देते हैं। अन्यथा, नीचे पाठ्य रूप में मुख्य सारांश है।

डॉकर के साथ निरंतर डिलीवरी

नीचे निरंतर वितरण हम घटनाओं की श्रृंखला को समझते हैं जिसके परिणामस्वरूप Git रिपॉजिटरी से एप्लिकेशन कोड पहले उत्पादन में आता है, और फिर संग्रह में समाप्त होता है। यह इस तरह दिख रहा है: Git → बिल्ड → टेस्ट → रिलीज़ → ऑपरेट.

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

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

मुख्य रोलआउट पैटर्न

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

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

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

आइए संक्षेप करें मुख्य रोलआउट पैटर्न निम्नलिखित कारकों को ध्यान में रखते हुए नए संस्करण:

1. सबसे पहले, एप्लिकेशन का पुराना संस्करण पहले कंटेनर में चलता है।
2. फिर नए संस्करण को बाहर निकाला जाता है और दूसरे कंटेनर में "वार्म अप" किया जाता है। यह उल्लेखनीय है कि यह नया संस्करण स्वयं न केवल अद्यतन एप्लिकेशन कोड, बल्कि इसकी किसी भी निर्भरता, साथ ही सिस्टम घटकों (उदाहरण के लिए, ओपनएसएसएल का एक नया संस्करण या संपूर्ण वितरण) को भी ले जा सकता है।
3. जब नया संस्करण अनुरोधों को पूरा करने के लिए पूरी तरह से तैयार हो जाता है, तो ट्रैफ़िक पहले कंटेनर से दूसरे कंटेनर में स्विच हो जाता है।
4. पुराने वर्जन को अब बंद किया जा सकता है.

एप्लिकेशन के विभिन्न संस्करणों को अलग-अलग कंटेनरों में तैनात करने का यह दृष्टिकोण एक और सुविधा प्रदान करता है - त्वरित रोलबैक पुराने संस्करण में (आखिरकार, यह ट्रैफ़िक को वांछित कंटेनर में स्विच करने के लिए पर्याप्त है)।

अंतिम पहली सिफ़ारिश कुछ ऐसी लगती है जिसमें कैप्टन भी गलती नहीं ढूंढ सका: "[डॉकर के साथ सतत वितरण का आयोजन करते समय] डॉकर का प्रयोग करें [और समझें कि यह क्या देता है]" याद रखें, यह कोई चांदी की गोली नहीं है जो हर समस्या का समाधान कर देगी, बल्कि एक उपकरण है जो एक अद्भुत आधार प्रदान करता है।

reproducibility

"पुनरुत्पादन" से हमारा तात्पर्य अनुप्रयोगों के संचालन के दौरान आने वाली समस्याओं के एक सामान्यीकृत समूह से है। हम ऐसे मामलों के बारे में बात कर रहे हैं:

• स्टेजिंग के लिए गुणवत्ता विभाग द्वारा जांची गई स्क्रिप्ट को उत्पादन में सटीक रूप से पुन: प्रस्तुत किया जाना चाहिए।
• एप्लिकेशन उन सर्वरों पर प्रकाशित होते हैं जो विभिन्न रिपॉजिटरी मिरर से पैकेज प्राप्त कर सकते हैं (समय के साथ वे अपडेट होते हैं, और उनके साथ इंस्टॉल किए गए एप्लिकेशन के संस्करण भी)।
• "मेरे लिए स्थानीय स्तर पर सब कुछ काम करता है!" (...और डेवलपर्स को उत्पादन की अनुमति नहीं है।)
• आपको पुराने (संग्रहीत) संस्करण में कुछ जांचना होगा।
• ...

उनका सामान्य सार इस तथ्य पर उबलता है कि उपयोग किए गए वातावरण (साथ ही मानव कारक की अनुपस्थिति) का पूर्ण अनुपालन आवश्यक है। हम प्रतिलिपि प्रस्तुत करने योग्यता की गारंटी कैसे दे सकते हैं? डॉकर छवियां बनाएं Git के कोड के आधार पर, और फिर उन्हें किसी भी कार्य के लिए उपयोग करें: परीक्षण साइटों पर, उत्पादन में, प्रोग्रामर की स्थानीय मशीनों पर... साथ ही, किए जाने वाले कार्यों को कम करना महत्वपूर्ण है के बाद छवि को असेंबल करना: यह जितना सरल होगा, त्रुटियाँ होने की संभावना उतनी ही कम होगी।

इंफ्रास्ट्रक्चर कोड है

यदि बुनियादी ढाँचे की आवश्यकताएँ (सर्वर सॉफ़्टवेयर की उपलब्धता, उसका संस्करण, आदि) औपचारिक और "प्रोग्राम्ड" नहीं हैं, तो किसी भी एप्लिकेशन अपडेट के रोलआउट के परिणामस्वरूप विनाशकारी परिणाम हो सकते हैं। उदाहरण के लिए, स्टेजिंग में आप पहले ही PHP 7.0 पर स्विच कर चुके हैं और तदनुसार कोड को फिर से लिख चुके हैं - फिर कुछ पुराने PHP (5.5) के साथ उत्पादन में इसकी उपस्थिति निश्चित रूप से किसी को आश्चर्यचकित कर देगी। आप दुभाषिया संस्करण में एक बड़े बदलाव के बारे में नहीं भूल सकते हैं, लेकिन "शैतान विवरण में है": आश्चर्य किसी भी निर्भरता के मामूली अद्यतन में हो सकता है।

इस समस्या को हल करने के लिए एक दृष्टिकोण के रूप में जाना जाता है IaC (कोड के रूप में बुनियादी ढांचा, "कोड के रूप में बुनियादी ढांचा") और इसमें एप्लिकेशन कोड के साथ बुनियादी ढांचे की आवश्यकताओं को संग्रहीत करना शामिल है। इसका उपयोग करके, डेवलपर्स और DevOps विशेषज्ञ एक ही Git एप्लिकेशन रिपॉजिटरी के साथ काम कर सकते हैं, लेकिन इसके विभिन्न हिस्सों पर। इस कोड से, Git में एक Docker छवि बनाई जाती है, जिसमें एप्लिकेशन को बुनियादी ढांचे की सभी बारीकियों को ध्यान में रखते हुए तैनात किया जाता है। सीधे शब्दों में कहें तो, छवियों को इकट्ठा करने के लिए स्क्रिप्ट (नियम) स्रोत कोड के साथ एक ही भंडार में होनी चाहिए और एक साथ विलय होनी चाहिए।

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

डॉकर छवियां, गिट के साथ संचार

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

इसे अस्थायी छवियों में एकत्रित करना समझ में आता है: मास्टर शाखा (मास्टर के वर्तमान संस्करण को लगातार देखने के लिए आप इसे स्वचालित रूप से एक अलग साइट पर रोल आउट कर सकते हैं), रिलीज वाली शाखाएं, विशिष्ट नवाचारों की शाखाएं।

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

dapp

वर्णित हर चीज (रोलआउट, इमेज असेंबली, बाद में रखरखाव) को बैश स्क्रिप्ट और अन्य "इंप्रोवाइज्ड" टूल का उपयोग करके स्वतंत्र रूप से कार्यान्वित किया जा सकता है। लेकिन यदि आप ऐसा करते हैं, तो किसी बिंदु पर कार्यान्वयन में बड़ी जटिलता और खराब नियंत्रणीयता आ जाएगी। इसे समझते हुए, हम सीआई/सीडी के निर्माण के लिए अपनी स्वयं की विशेष वर्कफ़्लो उपयोगिता बनाने आए - dapp.

इसका स्रोत कोड रूबी में लिखा गया है, खुला स्रोत है और प्रकाशित किया गया है GitHub. दुर्भाग्य से, दस्तावेज़ीकरण वर्तमान में टूल का सबसे कमजोर बिंदु है, लेकिन हम इस पर काम कर रहे हैं। और हम डैप के बारे में एक से अधिक बार लिखेंगे और बात करेंगे, क्योंकि... हम ईमानदारी से पूरे इच्छुक समुदाय के साथ इसकी क्षमताओं को साझा करने के लिए इंतजार नहीं कर सकते हैं, लेकिन इस बीच, अपने मुद्दे भेजें और अनुरोध भेजें और/या GitHub पर परियोजना के विकास का अनुसरण करें।

13 अगस्त 2019 को अपडेट किया गया: वर्तमान में एक परियोजना dapp का नाम बदल दिया गया Werf, इसका कोड पूरी तरह से गो में फिर से लिखा गया है, और इसके दस्तावेज़ीकरण में काफी सुधार किया गया है।

Kubernetes

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

रोलआउट के लिए, कुबेरनेट्स ऑफ़र करता है:

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

चूंकि सतत वितरण न केवल एक नए संस्करण की रिलीज है, कुबेरनेट्स के पास बाद के बुनियादी ढांचे के रखरखाव के लिए कई क्षमताएं हैं: सभी कंटेनरों के लिए अंतर्निहित निगरानी और लॉगिंग, स्वचालित स्केलिंग इत्यादि। यह सब पहले से ही काम कर रहा है और बस उचित होने की प्रतीक्षा कर रहा है आपकी प्रक्रियाओं में कार्यान्वयन।

अंतिम सिफ़ारिशें

1. डॉकर का प्रयोग करें.
2. अपनी सभी आवश्यकताओं के लिए एप्लिकेशन की डॉकर छवियां बनाएं।
3. सिद्धांत का पालन करें "बुनियादी ढांचा कोड है।"
4. Git को डॉकर से लिंक करें।
5. रोलआउट के क्रम को विनियमित करें.
6. तैयार प्लेटफ़ॉर्म (कुबेरनेट्स या अन्य) का उपयोग करें।

वीडियो और स्लाइड

प्रदर्शन का वीडियो (लगभग एक घंटा) यूट्यूब पर प्रकाशित (रिपोर्ट स्वयं 5वें मिनट से शुरू होती है - इस क्षण से खेलने के लिए लिंक का अनुसरण करें).

रिपोर्ट की प्रस्तुति:

पुनश्च

हमारे ब्लॉग पर इस विषय पर अन्य रिपोर्ट:

• «werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)» (दिमित्री स्टोलारोव; 27 मई, 2019 DevOpsConf पर);
• «डेटाबेस और कुबेरनेट्स» (दिमित्री स्टोलारोव; 8 नवंबर, 2018 हाईलोड++ पर);
• «कुबेरनेट्स और गिटलैब के साथ सीआई/सीडी सर्वोत्तम अभ्यास» (दिमित्री स्टोलारोव; 7 नवंबर, 2017 हाईलोड++ पर);
• «छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव» (दिमित्री स्टोलारोव; 6 जून, 2017 रूटकॉन्फ पर).

स्रोत: www.habr.com