werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)

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

प्रस्तुति के बाद से, हमारी उपयोगिता (जिसे पहले डैप के नाम से जाना जाता था) एक ऐतिहासिक मील के पत्थर तक पहुंच गई है GitHub पर 1000 सितारे - हमें उम्मीद है कि इसके उपयोगकर्ताओं का बढ़ता समुदाय कई DevOps इंजीनियरों के लिए जीवन आसान बना देगा।

तो, हम प्रस्तुत करते हैं रिपोर्ट का वीडियो (~47 मिनट, लेख से कहीं अधिक जानकारीपूर्ण) और पाठ्य रूप में इसका मुख्य अंश। जाना!

कुबेरनेट्स को कोड वितरित करना

बात अब वेयरफ़ के बारे में नहीं होगी, बल्कि कुबेरनेट्स में सीआई/सीडी के बारे में होगी, जिसका अर्थ है कि हमारा सॉफ़्टवेयर डॉकर कंटेनरों में पैक किया गया है (मैंने इस बारे में बात की थी 2016 रिपोर्ट), और इसे उत्पादन में चलाने के लिए K8s का उपयोग किया जाएगा (इसके बारे में अधिक जानकारी में 2017 साल).

कुबेरनेट्स में डिलीवरी कैसी दिखती है?

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

यहां कुछ महत्वपूर्ण नोट्स हैं:

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

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

मंच का निर्माण

ऐसा प्रतीत होता है कि आप 2019 में डॉकर इमेज बनाने के बारे में बात कर सकते हैं, जब हर कोई जानता है कि डॉकरफाइल्स कैसे लिखना और चलाना है docker build?.. यहां वे बारीकियां हैं जिन पर मैं ध्यान देना चाहूंगा:

1. छवि वजन मायने रखता है, इसलिए उपयोग करें बहुमंज़िलाछवि में केवल वही एप्लिकेशन छोड़ें जो ऑपरेशन के लिए वास्तव में आवश्यक है।
2. परतों की संख्या की शृंखलाओं को मिलाकर न्यूनतम किया जाना चाहिए RUN-अर्थ के अनुसार आदेश।
3. हालाँकि, इससे समस्याएँ बढ़ती हैं डिबगिंग, क्योंकि जब असेंबली क्रैश हो जाती है, तो आपको उस श्रृंखला से सही कमांड ढूंढनी होगी जो समस्या का कारण बनी।
4. असेंबली गति महत्वपूर्ण है क्योंकि हम परिवर्तन शीघ्रता से लागू करना और परिणाम देखना चाहते हैं। उदाहरण के लिए, हर बार जब आप कोई एप्लिकेशन बनाते हैं तो आप भाषा पुस्तकालयों में निर्भरता का पुनर्निर्माण नहीं करना चाहते हैं।
5. अक्सर आपको एक Git रिपॉजिटरी की आवश्यकता होती है कई छवियाँ, जिसे Dockerfiles (या एक फ़ाइल में नामित चरणों) के एक सेट और उनकी अनुक्रमिक असेंबली के साथ एक बैश स्क्रिप्ट द्वारा हल किया जा सकता है।

यह तो बस हिमशैल का सिरा था जिसका सामना हर किसी को करना पड़ता है। लेकिन विशेष रूप से अन्य समस्याएं भी हैं:

1. अक्सर असेंबली स्टेज पर हमें कुछ न कुछ चाहिए होता है पर्वत (उदाहरण के लिए, किसी तृतीय-पक्ष निर्देशिका में apt जैसे कमांड के परिणाम को कैश करें)।
2. हम चाहते हैं Ansible शेल में लिखने के बजाय.
3. हम चाहते हैं डॉकर के बिना निर्माण करें (हमें एक अतिरिक्त वर्चुअल मशीन की आवश्यकता क्यों है जिसमें हमें इसके लिए सब कुछ कॉन्फ़िगर करने की आवश्यकता है, जब हमारे पास पहले से ही एक कुबेरनेट्स क्लस्टर है जिसमें हम कंटेनर चला सकते हैं?)।
4. समानांतर संयोजन, जिसे अलग-अलग तरीकों से समझा जा सकता है: Dockerfile से अलग-अलग कमांड (यदि मल्टी-स्टेज का उपयोग किया जाता है), एक ही रिपॉजिटरी के कई कमिट, कई Dockerfiles।
5. वितरित विधानसभा: हम उन चीजों को पॉड्स में इकट्ठा करना चाहते हैं जो "क्षणिक" हैं क्योंकि उनका कैश गायब हो जाता है, जिसका अर्थ है कि इसे कहीं अलग से संग्रहीत करने की आवश्यकता है।
6. अंत में, मैंने इच्छाओं के शिखर का नाम दिया स्वचालित: रिपॉजिटरी में जाना, कुछ कमांड टाइप करना और एक तैयार छवि प्राप्त करना आदर्श होगा, जिसे सही ढंग से कैसे और क्या करना है, इसकी समझ के साथ इकट्ठा किया गया है। हालाँकि, मुझे व्यक्तिगत रूप से यकीन नहीं है कि सभी बारीकियों का इस तरह से अनुमान लगाया जा सकता है।

और यहाँ परियोजनाएँ हैं:

• मोबी/बिल्डकिट - डॉकर इंक का एक बिल्डर (पहले से ही डॉकर के मौजूदा संस्करणों में एकीकृत), जो इन सभी समस्याओं को हल करने की कोशिश कर रहा है;
• कनिको - Google का एक बिल्डर जो आपको डॉकर के बिना निर्माण करने की अनुमति देता है;
• Buildpacks.io - सीएनसीएफ का स्वचालित जादू बनाने का प्रयास और, विशेष रूप से, परतों के लिए रिबेस के साथ एक दिलचस्प समाधान;
• और अन्य उपयोगिताओं का एक समूह, जैसे बिल्डहा, जेनुइनटूल्स/img...

...और देखो GitHub पर उनके पास कितने सितारे हैं। यानि कि एक तरफ, docker build अस्तित्व में है और कुछ कर सकता है, लेकिन वास्तव में समस्या पूरी तरह हल नहीं हुई है - इसका प्रमाण वैकल्पिक संग्राहकों का समानांतर विकास है, जिनमें से प्रत्येक समस्या का कुछ हिस्सा हल करता है।

वेयरफ़ में विधानसभा

तो हमें मिल गया Werf (पूर्व में ज्ञात डैप की तरह) — फ़्लैंट कंपनी की एक ओपन सोर्स उपयोगिता, जिसे हम कई वर्षों से बना रहे हैं। यह सब 5 साल पहले बैश स्क्रिप्ट्स के साथ शुरू हुआ था, जिसने डॉकरफाइल्स की असेंबली को अनुकूलित किया था, और पिछले 3 वर्षों से अपने स्वयं के गिट रिपॉजिटरी के साथ एक प्रोजेक्ट के ढांचे के भीतर पूर्ण विकास किया गया है। (पहले रूबी में, और फिर फिर से लिखा जाने के लिए, और उसी समय नाम बदला गया). वेयरफ़ में कौन से असेंबली मुद्दे हल किए जाते हैं?

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

रजिस्ट्री में प्रकाशन का चरण (प्रकाशन)

हमने डायल किया docker push... - रजिस्ट्री में छवि अपलोड करने में क्या मुश्किल हो सकती है? और फिर सवाल उठता है: "मुझे छवि पर कौन सा टैग लगाना चाहिए?" यह उस कारण से उत्पन्न होता है जो हमारे पास है गिटफ्लो (या अन्य Git रणनीति) और Kubernetes, और उद्योग यह सुनिश्चित करने का प्रयास कर रहा है कि Kubernetes में जो होता है वह Git में होता है। आख़िरकार, Git ही सत्य का हमारा एकमात्र स्रोत है।

इसमें इतना कठिन क्या है? प्रतिलिपि प्रस्तुत करने योग्यता सुनिश्चित करें: Git में एक प्रतिबद्धता से, जो प्रकृति में अपरिवर्तनीय है (अपरिवर्तनीय), एक डॉकर छवि के लिए, जिसे वही रखा जाना चाहिए।

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

रणनीतियाँ टैग करना

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

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

दूसरा विकल्प है गिट कमिट + टैग. मास्टर शाखा में एक टैग है 1.0; इसके लिए रजिस्ट्री में - उत्पादन के लिए तैनात एक छवि। इसके अलावा, कुबेरनेट्स क्लस्टर में पूर्वावलोकन और स्टेजिंग रूपरेखाएं हैं। आगे हम Gitflow का अनुसरण करते हैं: विकास के लिए मुख्य शाखा में (develop) हम नई सुविधाएँ बनाते हैं, जिसके परिणामस्वरूप पहचानकर्ता के साथ प्रतिबद्धता होती है #c1. हम इसे एकत्र करते हैं और इस पहचानकर्ता का उपयोग करके इसे रजिस्ट्री में प्रकाशित करते हैं (#c1). उसी पहचानकर्ता के साथ हम पूर्वावलोकन के लिए रोल आउट करते हैं। हम कमिट के साथ भी ऐसा ही करते हैं #c2 и #c3.

जब हमें एहसास हुआ कि पर्याप्त सुविधाएँ हैं, तो हमने सब कुछ स्थिर करना शुरू कर दिया। Git में एक शाखा बनाएँ release_1.1 (आधार पर #c3 से develop). इस रिलीज़ को एकत्र करने की कोई आवश्यकता नहीं है, क्योंकि... यह पिछले चरण में किया गया था. इसलिए, हम इसे आसानी से स्टेजिंग तक रोल आउट कर सकते हैं। हम इसमें बग ठीक करते हैं #c4 और इसी तरह स्टेजिंग के लिए रोल आउट करें। साथ ही इसमें विकास कार्य भी चल रहा है develop, जहां से समय-समय पर परिवर्तन लिए जाते हैं release_1.1. कुछ बिंदु पर, हमें एक कमिट संकलित होती है और स्टेजिंग पर अपलोड की जाती है, जिससे हम खुश होते हैं (#c25).

फिर हम रिलीज ब्रांच का मर्ज (फास्ट-फॉरवर्ड के साथ) करते हैं (release_1.1) मास्टर में. हमने इस कमिट पर नए संस्करण के साथ एक टैग लगाया है (1.1). लेकिन यह छवि पहले से ही रजिस्ट्री में एकत्र की गई है, इसलिए इसे दोबारा एकत्र न करने के लिए, हम बस मौजूदा छवि में एक दूसरा टैग जोड़ते हैं (अब इसमें रजिस्ट्री में टैग हैं #c25 и 1.1). उसके बाद, हम इसे उत्पादन में उतारते हैं।

एक कमी यह है कि स्टेजिंग पर केवल एक छवि अपलोड की जाती है (#c25), और उत्पादन में यह अलग तरह का है (1.1), लेकिन हम जानते हैं कि "भौतिक रूप से" ये रजिस्ट्री से वही छवि हैं।

वास्तविक नुकसान यह है कि मर्ज कमिट के लिए कोई समर्थन नहीं है, आपको तेजी से आगे बढ़ना होगा।

हम आगे बढ़ सकते हैं और एक तरकीब अपना सकते हैं... आइए एक सरल डॉकरफाइल का एक उदाहरण देखें:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

आइए निम्नलिखित सिद्धांत के अनुसार इससे एक फ़ाइल बनाएं:

• उपयोग की गई छवियों के पहचानकर्ताओं से SHA256 (ruby:2.3 и nginx:alpine), जो उनकी सामग्री के चेकसम हैं;
• सभी टीमें (RUN, CMD और इसी तरह।);
• जोड़ी गई फ़ाइलों से SHA256.

... और ऐसी फ़ाइल से चेकसम (फिर से SHA256) लें। यह हस्ताक्षर वह सब कुछ जो डॉकर छवि की सामग्री को परिभाषित करता है।

आइए आरेख पर वापस जाएं और प्रतिबद्धताओं के बजाय हम ऐसे हस्ताक्षरों का उपयोग करेंगे, अर्थात। हस्ताक्षरों के साथ छवियों को टैग करें।

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

नुकसान यह है कि अब यह निर्धारित करना संभव नहीं होगा कि उत्पादन के लिए किस प्रकार की प्रतिबद्धता को आगे बढ़ाया गया था - चेकसम केवल एक दिशा में काम करते हैं। यह समस्या मेटाडेटा के साथ एक अतिरिक्त परत द्वारा हल की गई है - मैं आपको बाद में बताऊंगा।

वर्फ़ में टैग करना

वेयरफ़ में हम और भी आगे बढ़ गए और एक कैश के साथ एक वितरित निर्माण करने की तैयारी कर रहे हैं जो एक मशीन पर संग्रहीत नहीं है... इसलिए, हम दो प्रकार की डॉकर छवियां बना रहे हैं, हम उन्हें कहते हैं मंच и की छवि.

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

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

इस प्रकार, स्टेज इमेज एक कैश है जिसे वितरित रूप से संग्रहीत किया जा सकता है, और इससे पहले से बनाई गई छवियां डॉकर रजिस्ट्री पर अपलोड की जाती हैं।

रजिस्ट्री की सफाई

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

सफ़ाई रणनीतियाँ क्या हैं?

1. आप बस कुछ नहीं कर सकते साफ़ मत करो. कभी-कभी टैग की एक बड़ी उलझन को सुलझाने की तुलना में अतिरिक्त स्थान के लिए थोड़ा भुगतान करना वास्तव में आसान होता है। लेकिन यह केवल एक निश्चित बिंदु तक ही काम करता है।
2. पूर्ण रीसेट. यदि आप सभी छवियों को हटा देते हैं और सीआई सिस्टम में केवल मौजूदा छवियों को फिर से बनाते हैं, तो एक समस्या उत्पन्न हो सकती है। यदि कंटेनर को उत्पादन में पुनः आरंभ किया जाता है, तो इसके लिए एक नई छवि लोड की जाएगी - जिसका अभी तक किसी के द्वारा परीक्षण नहीं किया गया है। यह अपरिवर्तनीय बुनियादी ढांचे के विचार को खत्म कर देता है।
3. नीला हरा. एक रजिस्ट्री ओवरफ्लो होने लगी - हम दूसरे पर चित्र अपलोड करते हैं। पिछली विधि जैसी ही समस्या: आप उस रजिस्ट्री को किस बिंदु पर साफ़ कर सकते हैं जो ओवरफ्लो होना शुरू हो गई है?
4. समय के हिसाब से. 1 महीने से अधिक पुरानी सभी छवियां हटाएं? लेकिन ऐसी कोई सेवा जरूर होगी जो एक महीने से अपडेट न हुई हो...
5. मैन्युअल निर्धारित करें कि क्या पहले से ही हटाया जा सकता है।

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

हम क्या करने आये हैं? Werf? हम एकत्र करते हैं:

1. Git हेड: सभी टैग, सभी शाखाएँ - यह मानते हुए कि हमें छवियों में Git में टैग की गई हर चीज़ की आवश्यकता है (और यदि नहीं, तो हमें इसे Git में ही हटाने की आवश्यकता है);
2. सभी पॉड्स जो वर्तमान में कुबेरनेट्स में पंप किए गए हैं;
3. पुराने रेप्लिकासेट्स (जो हाल ही में जारी किया गया था), और हम हेल्म रिलीज को स्कैन करने और वहां नवीनतम छवियों का चयन करने की भी योजना बना रहे हैं।

...और इस सेट से एक श्वेतसूची बनाएं - उन छवियों की एक सूची जिन्हें हम नहीं हटाएंगे। हम बाकी सब कुछ साफ कर देते हैं, जिसके बाद हम अनाथ मंच की छवियां ढूंढते हैं और उन्हें भी हटा देते हैं।

मंच तैनात करें

विश्वसनीय घोषणात्मकता

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

1. पहचानकर्ता;
2. सेवा कि जानकारी;
3. कई डिफ़ॉल्ट मान;
4. वर्तमान स्थिति वाला अनुभाग;
5. प्रवेश वेबहुक के भाग के रूप में किए गए परिवर्तन;
6. विभिन्न नियंत्रकों (और अनुसूचक) के कार्य का परिणाम।

इसलिए, जब कोई नया संसाधन कॉन्फ़िगरेशन प्रकट होता है (नई), हम इसके साथ वर्तमान, "लाइव" कॉन्फ़िगरेशन को ले और अधिलेखित नहीं कर सकते हैं (जीना). ऐसा करने के लिए हमें तुलना करनी होगी नई अंतिम लागू कॉन्फ़िगरेशन के साथ (अंतिम बार लागू किया गया) और रोल ऑन करें जीना प्राप्त पैच.

इस दृष्टिकोण को कहा जाता है 2-तरफ़ा विलय. इसका उपयोग, उदाहरण के लिए, हेल्म में किया जाता है।

वहाँ भी 3-तरफ़ा विलय, जो इसमें भिन्न है:

• की तुलना अंतिम बार लागू किया गया и नई, हम देखते हैं कि क्या हटाया गया था;
• की तुलना नई и जीना, हम देखते हैं कि क्या जोड़ा या बदला गया है;
• सारांशित पैच को लागू किया जाता है जीना.

हम हेल्म के साथ 1000+ एप्लिकेशन तैनात करते हैं, इसलिए हम वास्तव में 2-तरफ़ा मर्ज के साथ रहते हैं। हालाँकि, इसमें कई समस्याएं हैं जिन्हें हमने अपने पैच से हल किया है, जो हेल्म को सामान्य रूप से काम करने में मदद करते हैं।

वास्तविक रोलआउट स्थिति

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

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

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

वेयरफ़ स्तर पर इस ट्रैकर का व्यवहार उन एनोटेशन का उपयोग करके कॉन्फ़िगर किया गया है जो परिनियोजन या स्टेटफुलसेट्स पर रखे गए हैं। मुख्य टिप्पणी - fail-mode - निम्नलिखित अर्थ समझता है:

• IgnoreAndContinueDeployProcess - हम इस घटक को रोल आउट करने की समस्याओं को नजरअंदाज करते हैं और तैनाती जारी रखते हैं;
• FailWholeDeployProcessImmediately - इस घटक में एक त्रुटि परिनियोजन प्रक्रिया को रोक देती है;
• HopeUntilEndOfDeployProcess - हमें उम्मीद है कि यह घटक तैनाती के अंत तक काम करेगा।

उदाहरण के लिए, संसाधनों और एनोटेशन मानों का यह संयोजन fail-mode:

जब हम पहली बार तैनात करते हैं, तो डेटाबेस (MongoDB) अभी तक तैयार नहीं हो सकता है - तैनाती विफल हो जाएगी। लेकिन आप इसके शुरू होने का इंतजार कर सकते हैं और तैनाती अभी भी होगी।

वेयरफ़ में कुबेडॉग के लिए दो और एनोटेशन हैं:

• failures-allowed-per-replica - प्रत्येक प्रतिकृति के लिए अनुमत फ़ॉल्स की संख्या;
• show-logs-until - उस क्षण को नियंत्रित करता है जब तक कि वेयरफ़ सभी रोल आउट पॉड्स से (स्टडआउट में) लॉग नहीं दिखाता। डिफ़ॉल्ट है PodIsReady (उन संदेशों को नज़रअंदाज़ करने के लिए जो हम शायद तब नहीं चाहते जब ट्रैफ़िक पॉड पर आने लगे), लेकिन मान भी मान्य हैं: ControllerIsReady и EndOfDeploy.

हम तैनाती से और क्या चाहते हैं?

पहले से वर्णित दो बिंदुओं के अलावा, हम चाहेंगे:

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

परिणाम

एक कंपनी के रूप में हमारे लिए, डिलीवरी के विभिन्न चरणों (निर्माण, प्रकाशन, तैनाती) पर सभी वर्णित बारीकियों को लागू करने के लिए, एक सीआई प्रणाली और उपयोगिता पर्याप्त हैं Werf.

निष्कर्ष के बजाय:

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

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

प्रदर्शन से वीडियो (~47 मिनट):

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

पुनश्च

हमारे ब्लॉग पर कुबेरनेट्स के बारे में अन्य रिपोर्ट:

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

स्रोत: www.habr.com