werf - Kubernetes मा CI / CD को लागि हाम्रो उपकरण (अवलोकन र भिडियो रिपोर्ट)

उत्सवको एक भागको रूपमा आयोजित DevOpsConf 27 सम्मेलनको मुख्य हलमा मे 2019 RIT++ २०१९, "निरन्तर डेलिभरी" खण्डको भागको रूपमा, एउटा रिपोर्ट दिइएको थियो "werf - Kubernetes मा CI/CD को लागि हाम्रो उपकरण"। ती बारे कुरा गर्छ Kubernetes मा तैनात गर्दा सबैले सामना गर्ने समस्या र चुनौतीहरू, साथै न्युनसहरू बारे जुन तुरुन्तै ध्यान नदिने हुन सक्छ। सम्भावित समाधानहरूको विश्लेषण गर्दै, हामी यो खुला स्रोत उपकरणमा कसरी लागू हुन्छ भनेर देखाउँछौं वाफ.

प्रस्तुतीकरण पछि, हाम्रो उपयोगिता (पहिले dapp भनेर चिनिन्थ्यो) को ऐतिहासिक माइलस्टोनमा पुगेको छ GitHub मा 1000 ताराहरू — हामी आशा गर्छौं कि यसको प्रयोगकर्ताहरूको बढ्दो समुदायले धेरै DevOps इन्जिनियरहरूको जीवनलाई सजिलो बनाउनेछ।

त्यसैले, परिचय गरौं रिपोर्ट को भिडियो (~ 47 मिनेट, लेख भन्दा धेरै जानकारीमूलक) र यसबाट पाठको रूपमा मुख्य सार। जाउ!

Kubernetes लाई कोड डेलिभर गर्दै

कुराकानी अब werf को बारे मा हुनेछैन, तर Kubernetes मा CI/CD को बारे मा, हाम्रो सफ्टवेयर डकर कन्टेनर मा प्याक गरिएको छ भनेर संकेत गर्दछ। (मैले यस बारे मा कुरा गरेको छु 2016 रिपोर्ट), र K8s यसलाई उत्पादनमा चलाउन प्रयोग गरिनेछ (यस बारेमा थप मा 2017 वर्ष).

Kubernetes मा डेलिभरी कस्तो देखिन्छ?

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

यहाँ केहि महत्त्वपूर्ण नोटहरू छन्:

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

Kubernetes मा माथिको डेलिभरी योजनामा ​​फर्कौं: यो केवल हामी द्वारा आविष्कार गरिएको थिएन, तर शाब्दिक रूपमा यस समस्याको सामना गर्ने सबैले आविष्कार गरेका थिए। वास्तवमा, यो ढाँचा अब GitOps भनिन्छ (तपाईले शब्द र यसको पछाडि विचारहरू बारे थप पढ्न सक्नुहुन्छ यहाँ)। योजनाको चरणहरू हेरौं।

स्टेज निर्माण गर्नुहोस्

यस्तो देखिन्छ कि तपाइँ २०१९ मा डकर छविहरू निर्माण गर्ने बारे कुरा गर्न सक्नुहुन्छ, जब सबैलाई डकरफाइलहरू कसरी लेख्ने र चलाउने भनेर थाहा छ। docker build?.. यहाँ म ध्यान दिन चाहन्छु कि बारीकियों छन्:

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

यो सबैले सामना गर्ने हिमशैलीको टुप्पो मात्र थियो। तर त्यहाँ अन्य समस्याहरू छन्, विशेष गरी:

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

र यहाँ परियोजनाहरू छन्:

• moby/buildkit - डकर इंक (पहिले नै डकरको हालको संस्करणहरूमा एकीकृत) को एक बिल्डर, जसले यी सबै समस्याहरू समाधान गर्न प्रयास गरिरहेको छ;
• कनिको - गुगलबाट एक बिल्डर जसले तपाईंलाई डकर बिना निर्माण गर्न अनुमति दिन्छ;
• Buildpacks.io - CNCF को स्वचालित जादुई बनाउन को लागी प्रयास र, विशेष गरी, तहहरु को लागी रिबेस संग एक रोचक समाधान;
• र अन्य उपयोगिताहरूको गुच्छा, जस्तै बिल्डह, genuinetools/img...

...र हेर्नुहोस् GitHub मा कति ताराहरू छन्। अर्थात् एकातिर, docker build अवस्थित छ र केहि गर्न सक्छ, तर वास्तविकतामा समस्या पूर्ण रूपमा समाधान भएको छैन - यसको प्रमाण वैकल्पिक कलेक्टरहरूको समानान्तर विकास हो, जसमध्ये प्रत्येकले समस्याहरूको केही अंश हल गर्दछ।

werf मा विधानसभा

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

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

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

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

यसमा के गाह्रो छ? प्रजनन क्षमता सुनिश्चित गर्नुहोस्: Git मा कमिटबाट, जुन प्रकृतिमा अपरिवर्तनीय छ (अपरिवर्तनीय), डकर छविमा, जुन उस्तै राख्नुपर्छ।

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

ट्यागिङ रणनीतिहरू

पहिलो सरल छ git ट्याग। हामीसँग ट्याग गरिएको छविको साथ रजिस्ट्री छ 1.0। Kubernetes को स्टेज र उत्पादन छ, जहाँ यो छवि अपलोड गरिएको छ। Git मा हामी कमिट गर्छौं र केहि बिन्दुमा हामी ट्याग गर्छौं 2.0। हामी यसलाई भण्डारबाट निर्देशनहरू अनुसार सङ्कलन गर्छौं र यसलाई ट्यागको साथ रजिस्ट्रीमा राख्छौं 2.0। हामी यसलाई स्टेजमा रोल आउट गर्छौं र, यदि सबै ठीक छ भने, उत्पादनमा।

यस दृष्टिकोणको साथ समस्या यो हो कि हामीले पहिले ट्याग राख्यौं, र त्यसपछि मात्र परीक्षण र रोल आउट गर्यौं। किन? पहिलो, यो केवल अतार्किक छ: हामीले सफ्टवेयरको संस्करण जारी गर्दैछौं जुन हामीले अहिलेसम्म परीक्षण गरेका छैनौं (हामी अन्यथा गर्न सक्दैनौं, किनकि जाँच गर्नको लागि, हामीले ट्याग राख्नु पर्छ)। दोस्रो, यो मार्ग Gitflow संग उपयुक्त छैन।

दोस्रो विकल्प हो git कमिट + ट्याग। मास्टर शाखामा ट्याग छ 1.0; यसको लागि रजिस्ट्रीमा - उत्पादनमा तैनाथ गरिएको छवि। थप रूपमा, Kubernetes क्लस्टरमा पूर्वावलोकन र स्टेजिङ रूपरेखाहरू छन्। अर्को हामी 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) लिनुहोस्। यो हस्ताक्षर डकर छविको सामग्री परिभाषित गर्ने सबै कुरा।

हामी रेखाचित्रमा फर्कौं र कमिटको सट्टा हामी त्यस्ता हस्ताक्षरहरू प्रयोग गर्नेछौं, अर्थात् हस्ताक्षर सहित छविहरू ट्याग गर्नुहोस्।

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

बेफाइदा यो हो कि अब यो निर्धारण गर्न सम्भव छैन कि कस्तो प्रकारको प्रतिबद्धता उत्पादनमा धकेलियो - चेकसमहरू मात्र एक दिशामा काम गर्दछ। यो समस्या मेटाडेटाको साथ एक अतिरिक्त तह द्वारा हल गरिएको छ - म तपाईंलाई पछि बताउनेछु।

werf मा ट्याग गर्दै

werf मा हामी अझ अगाडि गयौं र एक मेसिनमा भण्डारण नगरिएको क्यासको साथ वितरित बिल्ड गर्ने तयारी गर्दैछौं... त्यसैले, हामी दुई प्रकारका डकर छविहरू निर्माण गर्दैछौं, हामी तिनीहरूलाई बोलाउँछौं। चरण и छवि.

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

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

तसर्थ, स्टेज छविहरू एक क्यास हो जुन वितरित रूपमा भण्डारण गर्न सकिन्छ, र यसबाट पहिले नै सिर्जना गरिएका छविहरू डकर रजिस्ट्रीमा अपलोड हुन्छन्।

रजिस्ट्री सफा गर्दै

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

सरसफाई रणनीति के हो?

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

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

हामी केमा आएका छौं वाफ? हामी सङ्कलन:

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

... र यस सेटबाट श्वेतसूची बनाउनुहोस् - छविहरूको सूची जुन हामीले मेटाउने छैनौं। हामी अरू सबै सफा गर्छौं, त्यसपछि हामी अनाथ स्टेज छविहरू फेला पार्छौं र तिनीहरूलाई पनि मेटाउँछौं।

स्टेज तैनात गर्नुहोस्

भरपर्दो घोषणात्मकता

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

1. पहिचानकर्ताहरू;
2. सेवा जानकारी;
3. धेरै पूर्वनिर्धारित मानहरू;
4. वर्तमान स्थिति संग खण्ड;
5. प्रवेश वेबहुकको भागको रूपमा परिवर्तनहरू;
6. विभिन्न नियन्त्रक (र अनुसूचक) को काम को परिणाम।

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

यो दृष्टिकोण भनिन्छ २-मार्ग मर्ज। यो प्रयोग गरिन्छ, उदाहरणका लागि, हेल्ममा।

पनि छ २-मार्ग मर्ज, जुन यसमा फरक छ:

• तुलना गर्दै पछिल्लो पटक लागू गरिएको и नयाँ, हामी के मेटाइएको थियो हेर्छौं;
• तुलना गर्दै नयाँ и बाँच्न, हामी के थपिएको वा परिवर्तन गरिएको छ हेर्छौं;
• संक्षेप प्याच लागू गरिएको छ बाँच्न.

हामीले हेल्मसँग १०००+ एप्लिकेसनहरू डिप्लोय गर्छौं, त्यसैले हामी वास्तवमा २-तर्फी मर्जसँग बाँचिरहेका छौं। यद्यपि, यसमा धेरै समस्याहरू छन् जुन हामीले हाम्रा प्याचहरूसँग हल गरेका छौं, जसले हेल्मलाई सामान्य रूपमा काम गर्न मद्दत गर्दछ।

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

हाम्रो CI प्रणालीले अर्को घटनामा आधारित Kubernetes को लागि नयाँ कन्फिगरेसन उत्पन्न गरेपछि, यसले यसलाई प्रयोगको लागि प्रसारण गर्दछ। (निवेदन गर्नु) क्लस्टरमा - हेलम वा प्रयोग गरेर kubectl apply। अर्को, पहिले नै वर्णन गरिएको N-way मर्ज हुन्छ, जसको लागि Kubernetes API ले CI प्रणालीलाई अनुमोदन गर्दै प्रतिक्रिया दिन्छ, र त्यो यसको प्रयोगकर्तालाई।

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

सबै कुरा सही तरिकाले गर्नको लागि, यो योजनालाई थप लिङ्क चाहिन्छ - एक विशेष ट्र्याकर जसले Kubernetes API बाट स्थिति जानकारी प्राप्त गर्नेछ र चीजहरूको वास्तविक अवस्थाको थप विश्लेषणको लागि प्रसारण गर्नेछ। हामीले Go मा एउटा खुला स्रोत पुस्तकालय बनायौं - cubedog (यसको घोषणा हेर्नुहोस् यहाँ), जसले यो समस्या समाधान गर्छ र werf मा निर्मित छ।

werf स्तरमा यो ट्रयाकरको व्यवहार डिप्लोयमेन्ट वा स्टेटफुलसेटहरूमा राखिएका एनोटेसनहरू प्रयोग गरेर कन्फिगर गरिएको छ। मुख्य टिप्पणी - fail-mode - निम्न अर्थ बुझ्छ:

• IgnoreAndContinueDeployProcess - हामी यो कम्पोनेन्ट रोल आउट गर्ने समस्याहरूलाई बेवास्ता गर्छौं र तैनाती जारी राख्छौं;
• FailWholeDeployProcessImmediately - यो घटक मा एक त्रुटि तैनाती प्रक्रिया रोक्छ;
• HopeUntilEndOfDeployProcess — हामी आशा गर्छौं कि यो कम्पोनेन्टले परिनियोजनको अन्त्यसम्म काम गर्नेछ।

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

जब हामी पहिलो पटक डिप्लोय गर्छौं, डाटाबेस (MongoDB) अझै तयार नहुन सक्छ - डिप्लोयमेन्टहरू असफल हुनेछन्। तर तपाइँ यसलाई सुरु हुनको लागि क्षणको लागि पर्खन सक्नुहुन्छ, र तैनाती अझै पनि हुनेछ।

werf मा kubedog को लागी दुई थप एनोटेसनहरू छन्:

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

हामी तैनातीबाट अरू के चाहन्छौं?

पहिले नै वर्णन गरिएका दुई बिन्दुहरूको अतिरिक्त, हामी चाहन्छौं:

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

परिणामहरू

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

एउटा निष्कर्ष को सट्टा:

werf को सहयोगमा, हामीले DevOps इन्जिनियरहरूका लागि ठूलो संख्यामा समस्याहरू समाधान गर्नमा राम्रो प्रगति गरेका छौं र व्यापक समुदायले कम्तिमा पनि यो उपयोगितालाई कार्यमा प्रयास गरेमा खुसी हुनेछौं। सँगै राम्रो परिणाम प्राप्त गर्न सजिलो हुनेछ।

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

प्रदर्शनबाट भिडियो (~ ५० मिनेट):

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

PS

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

• «Kubernetes मा स्वत: स्केलिंग र स्रोत व्यवस्थापन» (दिमित्री स्टोल्यारोभ; 27 अप्रिल, 2019 "स्ट्राइक" मा);
• «Kubernetes विस्तार र पूरक» (Andrey Polovov; अप्रिल 8, 2019 सेन्ट हाईलोड++ मा);
• «डाटाबेस र Kubernetes» (दिमित्री स्टोल्यारोभ; नोभेम्बर 8, 2018 HighLoad++ मा);
• «निगरानी र Kubernetes» (दिमित्री स्टोल्यारोभ; मे २८, २०१८ रूटकन्फमा);
• «Kubernetes र GitLab संग CI/CD उत्तम अभ्यासहरू» (दिमित्री स्टोल्यारोभ; नोभेम्बर 7, 2017 HighLoad++ मा);
• «साना परियोजनाहरूमा Kubernetes संग हाम्रो अनुभव» (दिमित्री Stolyarov; जुन 6, 2017 RootConf मा).

स्रोत: www.habr.com