डकरको साथ निरन्तर डेलिभरी अभ्यासहरू (समीक्षा र भिडियो)

हामी हाम्रो प्राविधिक निर्देशकको पछिल्लो भाषणहरूमा आधारित प्रकाशनहरूका साथ हाम्रो ब्लग सुरु गर्नेछौं डिस्टोल (दिमित्री Stolyarov)। ती सबै 2016 मा विभिन्न व्यावसायिक कार्यक्रमहरूमा भएका थिए र DevOps र Docker को विषयमा समर्पित थिए। Badoo अफिसमा डकर मस्को बैठकको एउटा भिडियो, हामीसँग पहिले नै छ प्रकाशित अनलाइन। रिपोर्टहरूको सार बताउने लेखहरूसँगै नयाँहरू हुनेछन्। तर…

सम्मेलनमा मे ३१ RootConf 2016फेस्टिभल "रशियन इन्टरनेट टेक्नोलोजी" (RIT++ 2016) को एक भागको रूपमा आयोजित, "निरन्तर तैनाती र तैनाती" खण्ड "डकरसँग निरन्तर डेलिभरीको उत्तम अभ्यासहरू" रिपोर्टको साथ खोलियो। यसले डकर र अन्य खुला स्रोत उत्पादनहरू प्रयोग गरेर निरन्तर डेलिभरी (CD) प्रक्रिया निर्माण गर्नका लागि उत्तम अभ्यासहरूलाई संक्षेप र व्यवस्थित गरेको छ। हामी उत्पादनमा यी समाधानहरूसँग काम गर्छौं, जसले हामीलाई व्यावहारिक अनुभवमा भर पर्न अनुमति दिन्छ।

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

डकरको साथ निरन्तर डेलिभरी

द्वारा लगातार वितरण हामी घटनाहरूको श्रृंखला बुझ्दछौं जसको परिणाम स्वरूप Git भण्डारबाट अनुप्रयोग कोड उत्पादनमा आउँछ, र त्यसपछि अभिलेखमा समाप्त हुन्छ। उनी यस्तो देखिन्छिन्: Git → निर्माण → परीक्षण → रिलीज → सञ्चालन.

अधिकांश प्रतिवेदन निर्माण चरण (एप्लिकेशन एसेम्बली) मा समर्पित छ, र विषयहरू रिलीज र सञ्चालन छोटकरीमा छोइएका छन्। हामी समस्या र ढाँचाहरूको बारेमा कुरा गर्नेछौं जसले तपाईंलाई तिनीहरूलाई समाधान गर्न अनुमति दिन्छ, र यी ढाँचाहरूको विशिष्ट कार्यान्वयनहरू फरक हुन सक्छन्।

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

मुख्य रोलआउट ढाँचा

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

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

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

संक्षेप गरौं मुख्य रोलआउट ढाँचा निम्न कारकहरूलाई ध्यानमा राख्दै नयाँ संस्करणहरू:

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

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

अन्तिम पहिलो सिफारिस यस्तो देखिन्छ कि क्याप्टेनले पनि गल्ती फेला पार्न सकेन: "[डकरको साथ निरन्तर डेलिभरी व्यवस्थित गर्दा] डकर प्रयोग गर्नुहोस् [र बुझ्नुहोस् यसले के दिन्छ]" याद गर्नुहोस्, यो चाँदीको गोली होइन जसले हरेक समस्याको समाधान गर्छ, तर एउटा उपकरण जसले अद्भुत आधार प्रदान गर्दछ।

प्रजनन क्षमता

"पुनरुत्पादन योग्यता" भन्नाले हामीले एप सञ्चालन गर्दा सामना गर्ने समस्याहरूको सामान्यीकृत सेटलाई बुझाउँछौं। हामी त्यस्ता केसहरूको बारेमा कुरा गर्दैछौं:

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

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

पूर्वाधार भनेको कोड हो

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

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

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

डकर छविहरू, Git संग संचार

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

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

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

dapp

वर्णन गरिएका सबै कुराहरू (रोलआउट, छवि असेंबली, पछिको मर्मत) बास स्क्रिप्टहरू र अन्य "सुधारित" उपकरणहरू प्रयोग गरेर स्वतन्त्र रूपमा लागू गर्न सकिन्छ। तर यदि तपाईंले यो गर्नुभयो भने, त्यसपछि कुनै समय कार्यान्वयनले ठूलो जटिलता र कमजोर नियन्त्रणको नेतृत्व गर्नेछ। यो बुझेर, हामी CI/CD निर्माणको लागि हाम्रो आफ्नै विशेष कार्यप्रवाह उपयोगिता सिर्जना गर्न आएका छौं - dapp.

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

अगस्ट १३, २०१९ अद्यावधिक गरिएको: हाल एक परियोजना dapp मा पुन: नामाकरण गरियो वाफ, यसको कोड पूर्ण रूपमा Go मा पुन: लेखिएको छ, र यसको कागजातहरू उल्लेखनीय रूपमा सुधार गरिएको छ।

कुबर्नेट्स

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

रोलआउटको लागि, Kubernetes प्रस्तावहरू:

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

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

अन्तिम सिफारिसहरू

1. डकर प्रयोग गर्नुहोस्।
2. तपाईंको सबै आवश्यकताहरूको लागि अनुप्रयोगहरूको डकर छविहरू सिर्जना गर्नुहोस्।
3. "पूर्वाधार भनेको कोड हो" भन्ने सिद्धान्तको पालना गर्नुहोस्।
4. Git लाई डकरमा लिङ्क गर्नुहोस्।
5. रोलआउट को क्रम विनियमित।
6. तयार प्लेटफर्म प्रयोग गर्नुहोस् (Kubernetes वा अन्य)।

भिडियो र स्लाइडहरू

प्रदर्शनबाट भिडियो (लगभग एक घण्टा) YouTube मा प्रकाशित (रिपोर्ट आफैं 5 औं मिनेटबाट सुरु हुन्छ - यस क्षणबाट प्ले गर्न लिङ्क पछ्याउनुहोस्).

प्रतिवेदन प्रस्तुति:

PS

हाम्रो ब्लगमा शीर्षकमा अन्य रिपोर्टहरू:

• «werf - Kubernetes मा CI / CD को लागि हाम्रो उपकरण (अवलोकन र भिडियो रिपोर्ट)» (दिमित्री स्टोल्यारोभ; मे २७, २०१९ DevOpsConf मा);
• «डाटाबेस र Kubernetes» (दिमित्री स्टोल्यारोभ; नोभेम्बर 8, 2018 HighLoad++ मा);
• «Kubernetes र GitLab संग CI/CD उत्तम अभ्यासहरू» (दिमित्री स्टोल्यारोभ; नोभेम्बर 7, 2017 HighLoad++ मा);
• «साना परियोजनाहरूमा Kubernetes संग हाम्रो अनुभव» (दिमित्री Stolyarov; जुन 6, 2017 RootConf मा).

स्रोत: www.habr.com