werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)

उत्सवाचा भाग म्हणून आयोजित DevOpsConf 27 परिषदेच्या मुख्य हॉलमध्ये 2019 मे RIT++ 2019, “कंटिन्युअस डिलिव्हरी” विभागाचा एक भाग म्हणून, “werf - कुबर्नेट्स मधील CI/CD साठी आमचे साधन” असा अहवाल देण्यात आला. त्याबद्दल बोलतो कुबर्नेट्समध्ये तैनात करताना प्रत्येकाला ज्या समस्या आणि आव्हानांचा सामना करावा लागतो, तसेच बारकावे बद्दल जे लगेच लक्षात येऊ शकत नाहीत. संभाव्य उपायांचे विश्लेषण करून, हे ओपन सोर्स टूलमध्ये कसे लागू केले जाते ते आम्ही दाखवतो werf.

सादरीकरण झाल्यापासून, आमची उपयुक्तता (पूर्वी dapp म्हणून ओळखली जात होती) चा ऐतिहासिक टप्पा गाठला आहे GitHub वर 1000 तारे — आम्हाला आशा आहे की त्याच्या वापरकर्त्यांचा वाढता समुदाय अनेक DevOps अभियंत्यांसाठी जीवन सोपे करेल.

तर, ओळख करून देऊ अहवालाचा व्हिडिओ (~47 मिनिटे, लेखापेक्षा जास्त माहितीपूर्ण) आणि त्यातील मुख्य उतारा मजकूर स्वरूपात. जा!

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

चर्चा यापुढे werf बद्दल नाही, परंतु Kubernetes मधील CI/CD बद्दल असेल, हे सूचित करते की आमचे सॉफ्टवेअर डॉकर कंटेनरमध्ये पॅकेज केलेले आहे. (मी मध्ये याबद्दल बोललो 2016 अहवाल), आणि K8s चा वापर उत्पादनात चालवण्यासाठी केला जाईल (यात याबद्दल अधिक 2017 वर्ष).

कुबर्नेट्समध्ये डिलिव्हरी कशी दिसते?

• कोड आणि ते तयार करण्यासाठी निर्देशांसह एक Git भांडार आहे. अनुप्रयोग डॉकर प्रतिमेमध्ये तयार केला आहे आणि डॉकर रेजिस्ट्रीमध्ये प्रकाशित केला आहे.
• त्याच रेपॉजिटरीमध्ये अॅप्लिकेशन कसे उपयोजित आणि कसे चालवावे याबद्दल सूचना देखील आहेत. तैनातीच्या टप्प्यावर, या सूचना कुबर्नेट्सला पाठवल्या जातात, जे रेजिस्ट्रीमधून इच्छित प्रतिमा प्राप्त करते आणि ते लॉन्च करते.
• शिवाय, सहसा चाचण्या असतात. प्रतिमा प्रकाशित करताना यापैकी काही केले जाऊ शकतात. तुम्ही (त्याच सूचनांचे पालन करून) अर्जाची प्रत (वेगळ्या K8s नेमस्पेसमध्ये किंवा वेगळ्या क्लस्टरमध्ये) तैनात करू शकता आणि तेथे चाचण्या चालवू शकता.
• शेवटी, तुम्हाला एक CI प्रणाली आवश्यक आहे जी Git (किंवा बटण क्लिक) वरून इव्हेंट प्राप्त करते आणि सर्व नियुक्त चरणांना कॉल करते: तयार करा, प्रकाशित करा, तैनात करा, चाचणी करा.

येथे काही महत्त्वाच्या टिपा आहेत:

1. कारण आपल्याकडे अपरिवर्तनीय पायाभूत सुविधा आहेत (अपरिवर्तनीय पायाभूत सुविधा), अनुप्रयोग प्रतिमा जी सर्व टप्प्यांवर वापरली जाते (स्टेजिंग, उत्पादन, इ.), एक असणे आवश्यक आहे. मी याबद्दल अधिक तपशीलवार आणि उदाहरणांसह बोललो. येथे.
2. कारण आम्ही कोड अ‍ॅप्रोच म्हणून पायाभूत सुविधा फॉलो करतो (IaC), ऍप्लिकेशन कोड, ते असेंबल आणि लॉन्च करण्याच्या सूचना असाव्यात अगदी एका भांडारात. याबद्दल अधिक माहितीसाठी, पहा समान अहवाल.
3. वितरण साखळी (वितरण) आम्ही हे सहसा असे पाहतो: अनुप्रयोग एकत्र केला गेला, चाचणी केली गेली, सोडली गेली (रिलीझ स्टेज) आणि तेच आहे - वितरण झाले आहे. पण प्रत्यक्षात, वापरकर्त्याला ते मिळते जे तुम्ही आणले आहे, नाही मग जेव्हा तुम्ही ते प्रॉडक्शनसाठी वितरित केले, आणि जेव्हा तो तिथे जाऊ शकला आणि हे उत्पादन काम केले. त्यामुळे वितरण साखळी संपेल असा माझा विश्वास आहे फक्त ऑपरेशनल टप्प्यावर (धावणे), किंवा अधिक तंतोतंत, अगदी त्या क्षणी जेव्हा कोड उत्पादनातून काढला गेला होता (त्याच्या जागी नवीनसह).

चला कुबर्नेट्समधील वरील डिलिव्हरी योजनेकडे परत जाऊया: याचा शोध केवळ आपल्याद्वारेच नाही तर या समस्येचा सामना करणाऱ्या प्रत्येकाने केला होता. खरं तर, या पॅटर्नला आता GitOps म्हणतात (आपण संज्ञा आणि त्यामागील कल्पनांबद्दल अधिक वाचू शकता येथे). योजनेचे टप्पे पाहू.

स्टेज तयार करा

असे दिसते की आपण 2019 मध्ये डॉकर प्रतिमा तयार करण्याबद्दल बोलू शकता, जेव्हा प्रत्येकाला डॉकरफाईल्स कसे लिहायचे आणि कसे चालवायचे हे माहित असते docker build?.. येथे मी लक्ष देऊ इच्छितो अशा बारकावे आहेत:

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

हे हिमनगाचे फक्त टोक होते ज्याला प्रत्येकजण तोंड देतो. परंतु इतर समस्या आहेत, विशेषतः:

1. अनेकदा असेंब्ली स्टेजवर आपल्याला काहीतरी हवे असते माउंट (उदाहरणार्थ, थर्ड-पार्टी डिरेक्टरीमध्ये apt सारख्या कमांडचा परिणाम कॅशे करा).
2. आम्हाला पाहिजे उत्तर द्या शेलमध्ये लिहिण्याऐवजी.
3. आम्हाला पाहिजे डॉकरशिवाय तयार करा (आम्हाला एक अतिरिक्त व्हर्च्युअल मशीन का आवश्यक आहे ज्यामध्ये आम्हाला यासाठी सर्वकाही कॉन्फिगर करण्याची आवश्यकता आहे, जेव्हा आमच्याकडे आधीच कुबर्नेट्स क्लस्टर आहे ज्यामध्ये आम्ही कंटेनर चालवू शकतो?).
4. समांतर असेंब्ली, ज्याला वेगवेगळ्या प्रकारे समजले जाऊ शकते: डॉकरफाइलमधील भिन्न कमांड (मल्टी-स्टेज वापरल्यास), एकाच रेपॉजिटरीच्या अनेक कमिट, अनेक डॉकरफाइल.
5. वितरित विधानसभा: आम्हाला अशा शेंगांमध्ये गोष्टी गोळा करायच्या आहेत ज्या “तात्कालिक” आहेत कारण त्यांचे कॅशे अदृश्य होते, याचा अर्थ ते कुठेतरी वेगळे संग्रहित करणे आवश्यक आहे.
6. शेवटी, मी इच्छांच्या शिखराला नाव दिले स्वयंचलित: रिपॉझिटरीमध्ये जाणे, काही कमांड टाईप करणे आणि योग्यरित्या कसे आणि काय करावे हे समजून घेऊन तयार केलेली प्रतिमा मिळवणे योग्य असेल. तथापि, मला वैयक्तिकरित्या खात्री नाही की सर्व बारकावे अशा प्रकारे अंदाज लावल्या जाऊ शकतात.

आणि येथे प्रकल्प आहेत:

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

...आणि GitHub वर त्यांच्याकडे किती तारे आहेत ते पहा. म्हणजे एकीकडे, docker build अस्तित्वात आहे आणि काहीतरी करू शकते, परंतु प्रत्यक्षात समस्या पूर्णपणे सुटलेली नाही - याचा पुरावा पर्यायी कलेक्टर्सचा समांतर विकास आहे, ज्यापैकी प्रत्येक समस्या काही भाग सोडवते.

werf मध्ये विधानसभा

त्यामुळे आम्हाला मिळाले werf (पूर्वी प्रसिद्ध डॅप सारखे) — फ्लॅंट कंपनीची एक मुक्त स्रोत उपयुक्तता, जी आम्ही अनेक वर्षांपासून बनवत आहोत. हे सर्व 5 वर्षांपूर्वी बॅश स्क्रिप्ट्ससह सुरू झाले ज्याने डॉकरफाईल्सचे असेंब्ली ऑप्टिमाइझ केले आणि गेल्या 3 वर्षांपासून त्याच्या स्वत: च्या गिट रिपॉझिटरीसह एका प्रकल्पाच्या चौकटीत पूर्ण विकास केला गेला. (प्रथम रुबी मध्ये, आणि नंतर पुन्हा लिहिले जाण्यासाठी, आणि त्याच वेळी पुनर्नामित). werf मध्ये कोणते असेंब्लीचे प्रश्न सोडवले जातात?

निळ्या रंगात छायांकित केलेल्या समस्या आधीच अंमलात आणल्या गेल्या आहेत, समांतर बिल्ड त्याच होस्टमध्ये केले गेले होते आणि पिवळ्या रंगात हायलाइट केलेल्या समस्या उन्हाळ्याच्या शेवटी पूर्ण करण्याचे नियोजित आहे.

नोंदणीमध्ये प्रकाशनाचा टप्पा (प्रकाशित)

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

यात इतके अवघड काय आहे? पुनरुत्पादनक्षमता सुनिश्चित करा: गिटमधील कमिटमधून, जे निसर्गात अपरिवर्तनीय आहे (अपरिवर्तनीय), डॉकर प्रतिमेसाठी, जी समान ठेवली पाहिजे.

ते आमच्यासाठीही महत्त्वाचे आहे मूळ निश्चित करा, कारण आम्हाला हे समजून घ्यायचे आहे की कुबर्नेट्समध्ये चालणारे ऍप्लिकेशन कोणत्या कमिटमधून तयार केले गेले आहे (मग आपण डिफ आणि तत्सम गोष्टी करू शकतो).

टॅगिंग धोरणे

पहिला सोपा आहे git टॅग. आमच्याकडे अशी टॅग केलेली प्रतिमा असलेली नोंदणी आहे 1.0. Kubernetes मध्ये स्टेज आणि उत्पादन आहे, जिथे ही प्रतिमा अपलोड केली आहे. Git मध्ये आपण कमिट करतो आणि कधीतरी टॅग करतो 2.0. आम्ही रेपॉजिटरीमधील सूचनांनुसार ते गोळा करतो आणि टॅगसह रेजिस्ट्रीमध्ये ठेवतो 2.0. आम्ही ते स्टेजवर आणतो आणि सर्व काही ठीक असल्यास उत्पादनासाठी.

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

दुसरा पर्याय आहे git कमिट + टॅग. मास्टर शाखेला टॅग आहे 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) घ्या. या स्वाक्षरी डॉकर प्रतिमेची सामग्री परिभाषित करणारी प्रत्येक गोष्ट.

चला आकृतीवर परत जाऊया आणि कमिट ऐवजी आम्ही अशा स्वाक्षऱ्या वापरू, म्हणजे स्वाक्षरीसह प्रतिमा टॅग करा.

आता, जेव्हा आवश्यक असेल, उदाहरणार्थ, रिलीझमधून मास्टरमध्ये बदल विलीन करण्यासाठी, आम्ही वास्तविक विलीन कमिट करू शकतो: त्यात भिन्न अभिज्ञापक असेल, परंतु समान स्वाक्षरी असेल. त्याच आयडेंटिफायरसह आम्ही प्रतिमा उत्पादनात आणू.

गैरसोय असा आहे की आता उत्पादनासाठी कोणत्या प्रकारचे कमिट ढकलले गेले हे निर्धारित करणे शक्य होणार नाही - चेकसम केवळ एका दिशेने कार्य करतात. ही समस्या मेटाडेटासह अतिरिक्त स्तराद्वारे सोडविली जाते - मी तुम्हाला नंतर अधिक सांगेन.

werf मध्ये टॅग करणे

werf मध्ये आम्ही आणखी पुढे गेलो आणि एका मशीनवर संग्रहित नसलेल्या कॅशेसह वितरित बिल्ड करण्याची तयारी करत आहोत... म्हणून, आम्ही दोन प्रकारच्या डॉकर प्रतिमा तयार करत आहोत, आम्ही त्यांना म्हणतो टप्पा и प्रतिमा.

werf Git रेपॉजिटरी बिल्ड-विशिष्ट सूचना संग्रहित करते ज्या बिल्डच्या वेगवेगळ्या टप्प्यांचे वर्णन करतात (स्थापित करण्यापूर्वी, स्थापित करा, सेटअप करण्यापूर्वी, सेटअप). आम्ही पहिल्या टप्प्यातील चेकसम म्हणून परिभाषित केलेल्या स्वाक्षरीसह पहिल्या टप्प्यातील प्रतिमा गोळा करतो. मग आम्ही सोर्स कोड जोडतो, नवीन स्टेज इमेजसाठी आम्ही त्याची चेकसम मोजतो... ही ऑपरेशन्स सर्व टप्प्यांसाठी पुनरावृत्ती केली जातात, परिणामी आम्हाला स्टेज इमेजेसचा संच मिळतो. मग आम्ही अंतिम प्रतिमा बनवतो, ज्यामध्ये त्याच्या उत्पत्तीबद्दल मेटाडेटा देखील असतो. आणि आम्ही ही प्रतिमा वेगवेगळ्या प्रकारे टॅग करतो (तपशील नंतर).

समजा यानंतर एक नवीन कमिट दिसेल ज्यामध्ये फक्त ऍप्लिकेशन कोड बदलला आहे. काय होईल? कोड बदलांसाठी, एक पॅच तयार केला जाईल आणि एक नवीन स्टेज प्रतिमा तयार केली जाईल. त्याची स्वाक्षरी जुन्या स्टेज इमेज आणि नवीन पॅचचा चेकसम म्हणून निर्धारित केली जाईल. या प्रतिमेतून एक नवीन अंतिम प्रतिमा तयार केली जाईल. तत्सम वर्तन इतर टप्प्यांतील बदलांसह होईल.

अशा प्रकारे, स्टेज प्रतिमा ही एक कॅशे आहे जी वितरीतपणे संग्रहित केली जाऊ शकते आणि त्यातून तयार केलेल्या प्रतिमा डॉकर रेजिस्ट्रीमध्ये अपलोड केल्या जातात.

रेजिस्ट्री साफ करणे

आम्ही हटविलेल्या टॅग्जनंतर लटकलेले स्तर हटविण्याबद्दल बोलत नाही - हे डॉकर रेजिस्ट्रीचेच एक मानक वैशिष्ट्य आहे. आम्ही अशा परिस्थितीबद्दल बोलत आहोत जेव्हा बरेच डॉकर टॅग जमा होतात आणि आम्हाला समजते की आम्हाला त्यापैकी काहींची गरज नाही, परंतु ते जागा घेतात (आणि/किंवा आम्ही त्यासाठी पैसे देतो).

साफसफाईची रणनीती काय आहेत?

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

दोन खरोखर व्यवहार्य पर्याय आहेत: स्वच्छ करू नका किंवा निळा-हिरवा + स्वहस्ते संयोजन. नंतरच्या प्रकरणात, आम्ही खालील गोष्टींबद्दल बोलत आहोत: जेव्हा तुम्हाला समजते की रेजिस्ट्री साफ करण्याची वेळ आली आहे, तेव्हा तुम्ही एक नवीन तयार कराल आणि त्यामध्ये सर्व नवीन प्रतिमा जोडता, उदाहरणार्थ, एका महिन्यामध्ये. आणि एका महिन्यानंतर, कुबर्नेट्समधील कोणते पॉड अजूनही जुनी रेजिस्ट्री वापरत आहेत ते पहा आणि ते देखील नवीन नोंदणीमध्ये हस्तांतरित करा.

आम्ही काय आलो आहोत werf? आम्ही गोळा करतो:

1. गिट हेड: सर्व टॅग, सर्व शाखा - असे गृहीत धरून की आम्हाला चित्रांमध्ये गिटमध्ये टॅग केलेल्या प्रत्येक गोष्टीची आवश्यकता आहे (आणि नसल्यास, आम्हाला ते गिटमध्येच हटवावे लागेल);
2. सर्व शेंगा ज्या सध्या कुबर्नेट्समध्ये बाहेर टाकल्या जातात;
3. जुने ReplicaSets (जे नुकतेच रिलीझ झाले होते), आणि आम्ही हेल्म रिलीझ स्कॅन करण्याची आणि तेथे नवीनतम प्रतिमा निवडण्याची देखील योजना आखत आहोत.

... आणि या संचातून एक श्वेतसूची बनवा - प्रतिमांची सूची जी आम्ही हटवणार नाही. आम्ही इतर सर्व काही साफ करतो, त्यानंतर आम्हाला अनाथ स्टेज प्रतिमा सापडतात आणि त्या देखील हटवतात.

स्टेज तैनात करा

विश्वासार्ह घोषणात्मकता

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

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

म्हणून, जेव्हा नवीन संसाधन कॉन्फिगरेशन दिसते (नवीन), आम्ही फक्त वर्तमान, "लाइव्ह" कॉन्फिगरेशन घेऊन त्यावर अधिलिखित करू शकत नाही (राहतात). हे करण्यासाठी आपल्याला तुलना करावी लागेल नवीन शेवटच्या लागू केलेल्या कॉन्फिगरेशनसह (शेवटचे लागू) आणि त्यावर रोल करा राहतात पॅच प्राप्त.

या दृष्टिकोनाला म्हणतात 2-मार्ग विलीनीकरण. हे हेल्ममध्ये वापरले जाते, उदाहरणार्थ.

तसेच आहे 3-मार्ग विलीनीकरण, जे त्यामध्ये भिन्न आहे:

• तुलना करणे शेवटचे लागू и नवीन, आम्ही काय हटवले होते ते पाहतो;
• तुलना करणे नवीन и राहतात, आम्ही काय जोडले किंवा बदलले आहे ते पाहतो;
• बेरीज पॅच लागू आहे राहतात.

आम्ही हेल्मसह 1000+ अनुप्रयोग उपयोजित करतो, म्हणून आम्ही प्रत्यक्षात 2-वे मर्जसह जगतो. तथापि, यात अनेक समस्या आहेत ज्या आम्ही आमच्या पॅचने सोडवल्या आहेत, ज्या हेल्मला सामान्यपणे कार्य करण्यास मदत करतात.

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

आमची CI प्रणाली पुढील इव्हेंटवर आधारित कुबर्नेट्ससाठी नवीन कॉन्फिगरेशन तयार केल्यानंतर, ते वापरण्यासाठी ते प्रसारित करते (लागू करा) क्लस्टरमध्ये - हेल्म वापरून किंवा kubectl apply. पुढे, आधीच वर्णन केलेले एन-वे विलीनीकरण होते, ज्याला कुबर्नेट्स API CI प्रणालीला आणि त्याच्या वापरकर्त्याला अनुमोदनाने प्रतिसाद देते.

तथापि, एक मोठी समस्या आहे: सर्व केल्यानंतर यशस्वी अर्ज म्हणजे यशस्वी रोलआउट असा नाही. जर कुबेरनेट्सला समजले की कोणते बदल लागू करणे आवश्यक आहे आणि ते लागू केले, तरीही आम्हाला परिणाम काय होईल हे माहित नाही. उदाहरणार्थ, फ्रंटएंडमध्ये पॉड्स अपडेट करणे आणि रीस्टार्ट करणे यशस्वी होऊ शकते, परंतु बॅकएंडमध्ये नाही आणि आम्हाला चालू असलेल्या ऍप्लिकेशन प्रतिमांच्या भिन्न आवृत्त्या मिळतील.

सर्वकाही योग्यरित्या करण्यासाठी, या योजनेला अतिरिक्त दुव्याची आवश्यकता आहे - एक विशेष ट्रॅकर जो कुबर्नेट्स API कडून स्थिती माहिती प्राप्त करेल आणि गोष्टींच्या वास्तविक स्थितीच्या पुढील विश्लेषणासाठी प्रसारित करेल. आम्ही गो मध्ये एक मुक्त स्रोत लायब्ररी तयार केली - 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.

निष्कर्षाऐवजी:

werf च्या मदतीने, आम्ही DevOps अभियंत्यांसाठी मोठ्या संख्येने समस्या सोडवण्यात चांगली प्रगती केली आहे आणि मोठ्या समुदायाने किमान या उपयुक्ततेचा प्रयत्न केला तर आनंद होईल. एकत्रितपणे चांगला परिणाम प्राप्त करणे सोपे होईल.

व्हिडिओ आणि स्लाइड्स

कामगिरीमधील व्हिडिओ (~47 मिनिटे):

अहवालाचे सादरीकरण:

PS

आमच्या ब्लॉगवर कुबर्नेट्स बद्दल इतर अहवाल:

• «Kubernetes मध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन» (दिमित्री स्टोल्यारोव; 27 एप्रिल, 2019 “स्ट्राइक” वर);
• «कुबर्नेट्सचा विस्तार आणि पूरक» (Andrey Polovov; सेंट हायलोड++ वर 8 एप्रिल 2019);
• «डेटाबेस आणि कुबर्नेट्स» (दिमित्री स्टोल्यारोव्ह; 8 नोव्हेंबर, 2018 HighLoad++ वर);
• «देखरेख आणि Kubernetes» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 28 मे 2018);
• «कुबर्नेट्स आणि गिटलॅबसह CI/CD सर्वोत्तम पद्धती» (दिमित्री स्टोल्यारोव्ह; 7 नोव्हेंबर, 2017 HighLoad++ वर);
• «लहान प्रकल्पांमध्ये कुबर्नेट्ससोबतचा आमचा अनुभव» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 6 जून 2017).

स्त्रोत: www.habr.com