वेयरफ - कुबेरनेट्स में सीआई / सीडी के लिए हमारा टूल (समीक्षा और वीडियो रिपोर्ट)

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

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



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

कुबेरनेट्स में कोड डिलीवरी

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

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

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

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

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

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

स्टेज का निर्माण

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

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

यह सिर्फ हिमशैल का टिप था जिसका सामना हर कोई कर रहा है। लेकिन अन्य समस्याएं हैं, और विशेष रूप से:

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

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

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

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

हर्फ में निर्माण

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



नीली छायांकित समस्याओं को पहले से ही लागू किया गया है, समानांतर विधानसभा एक ही मेजबान के भीतर की गई है, और हम गर्मियों के अंत तक पीले सवालों को पूरा करने की योजना बनाते हैं।

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

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

इतना जटिल क्या है? प्रतिलिपि प्रस्तुत करने योग्यता सुनिश्चित करें : Git में एक कमिट से, जो स्वाभाविक रूप से अपरिवर्तनीय है , एक डॉकर छवि के लिए जिसे समान रखा जाना चाहिए।

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

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

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



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

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

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

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

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



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

आप आगे बढ़ सकते हैं और चाल चल सकते हैं ... एक साधारण डॉकरफाइल के उदाहरण पर विचार करें:

 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. पूर्ण रीसेट । यदि आप सभी छवियों को हटाते हैं और केवल CI सिस्टम में संबंधित लोगों को फिर से बनाते हैं, तो एक समस्या उत्पन्न हो सकती है। यदि कंटेनर उत्पादन पर फिर से शुरू होता है, तो इसके लिए एक नई छवि लोड की जाएगी - एक जिसे अभी तक किसी ने भी परीक्षण नहीं किया है। यह अपरिवर्तनीय बुनियादी ढांचे के विचार को मारता है।
3. नीला-हरा । एक रजिस्ट्री अतिप्रवाह करने लगी - छवियों को दूसरे में लोड करना। पिछली पद्धति की तरह ही समस्या: किस बिंदु पर आप उस रजिस्ट्री को साफ कर सकते हैं जो ओवरफ्लो करना शुरू कर दिया है?
4. समय के हिसाब से । 1 महीने से पुरानी सभी छवियां हटाएं? लेकिन एक ऐसी सेवा होना निश्चित है जिसे एक महीने से अपडेट नहीं किया गया है ...
5. मैन्युअल रूप से निर्धारित करें कि पहले से ही क्या हटाया जा सकता है।

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

हम कहाँ गए थे? हम एकत्रित करते हैं:

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

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

परिनियोजन चरण (परिनियोजन)

मजबूत घोषणा

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

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

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

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

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

• अंतिम-लागू और नए की तुलना करते हुए, हम देखते हैं कि क्या हटा दिया गया है;
• नए और जीवंत की तुलना करते हुए, हम देखते हैं कि क्या जोड़ा या बदला गया है;
• जीने के लिए संक्षेप पैच लागू करें।

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

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

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



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

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

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

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

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



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

हफ़्ते में कुबेदोग के लिए दो और एनोटेशन हैं:

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

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

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

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

परिणाम

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

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



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

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

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



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

पुनश्च

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

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