कुबेरनेट्स को एक नया आवेदन जारी करने की प्रक्रिया में दौड़ने वाली टीमें

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

Helm और werf के साथ मनमाना आदेश

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

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

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

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

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

रिहाई से पहले पलायन

किसी भी डेटाबेस एप्लिकेशन के रिलीज का एक अभिन्न हिस्सा डेटा स्कीमा को अद्यतन कर रहा है। अलग-अलग कमांड चलाकर माइग्रेशन लागू करने वाले अनुप्रयोगों के लिए मानक परिनियोजन निम्न चरणों का पालन करता है:

1. कोड आधार अपडेट;
2. प्रवास की शुरुआत;
3. अनुप्रयोग के नए संस्करण में ट्रैफ़िक स्विच करना।

कुबेरनेट्स के भीतर, प्रक्रिया समान होनी चाहिए, लेकिन हमें जो चाहिए उसके लिए समायोजित किया गया है:

1. एक नए कोड के साथ एक कंटेनर लॉन्च करें, जिसमें माइग्रेशन का एक नया सेट हो सकता है;
2. इसमें माइग्रेशन लागू करने की प्रक्रिया शुरू करें, आवेदन के संस्करण को अपडेट करने से पहले ऐसा करें।

उस विकल्प पर विचार करें जब एप्लिकेशन के लिए डेटाबेस पहले से ही चल रहा हो और हमें एप्लिकेशन को तैनात करने वाले रिलीज के हिस्से के रूप में इसे तैनात करने की आवश्यकता नहीं है। माइग्रेशन लागू करने के लिए दो हुक उपयुक्त हैं:

• pre-install - यह सभी टेम्पलेट्स को संसाधित करने के बाद, लेकिन कुबेरनेट्स में संसाधन बनाने से पहले आवेदन के पहले हेल-रिलीज़ पर काम करता है;
• pre-upgrade - हेल्म रिलीज को अपडेट करने पर काम करता है और टेम्पलेट्स को प्रोसेस pre-install के बाद, pre-install तरह चलता है, लेकिन कुबेरनेट में संसाधन बनाने से पहले।

हेल्म और उल्लिखित दो हुक का उपयोग करके नौकरी का उदाहरण:

 --- apiVersion: batch/v1 kind: Job metadata: name: {{ .Chart.Name }}-apply-migrations annotations: "helm.sh/hook": pre-install,pre-upgrade spec: activeDeadlineSeconds: 60 backoffLimit: 0 template: metadata: name: {{ .Chart.Name }}-apply-migrations spec: imagePullSecrets: - name: {{ required ".Values.registry.secret_name required" .Values.registry.secret_name }} containers: - name: job command: ["/usr/bin/php7.2", "artisan", "migrate", "--force"] {{ tuple "backend" . | include "werf_container_image" | indent 8 }} env: {{ tuple "backend" . | include "werf_container_env" | indent 8 }} - name: DB_HOST value: postgres restartPolicy: Never 

नोट : उपरोक्त YAML टेम्प्लेट को werf की बारीकियों को ध्यान में रखते हुए बनाया गया था। इसे "स्वच्छ" हेल्म के अनुकूल बनाने के लिए, यह पर्याप्त है:

• {{ tuple "backend" . | include "werf_container_image" | indent 8 }} बदलें {{ tuple "backend" . | include "werf_container_image" | indent 8 }} {{ tuple "backend" . | include "werf_container_image" | indent 8 }} {{ tuple "backend" . | include "werf_container_image" | indent 8 }} लिए आवश्यक कंटेनर छवि के लिए;
• लाइन {{ tuple "backend" . | include "werf_container_env" | indent 8 }} हटाएं {{ tuple "backend" . | include "werf_container_env" | indent 8 }} {{ tuple "backend" . | include "werf_container_env" | indent 8 }} {{ tuple "backend" . | include "werf_container_env" | indent 8 }} , जो env कुंजी में निर्दिष्ट है।

तो, इस हेल्म टेम्पलेट को .helm/templates डायरेक्टरी में .helm/templates , जिसमें पहले से ही रिलीज के बाकी संसाधन हैं। जब werf deploy --stages-storage :local कहा जाता है, सभी टेम्प्लेट को पहले संसाधित किया जाएगा, और फिर उन्हें कुबेरनेट्स क्लस्टर में लोड किया जाएगा।

रिलीज प्रक्रिया के दौरान माइग्रेशन शुरू करना

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

NB : यदि आप किसी समापन बिंदु के साथ सेवा का उपयोग करते हैं जो डेटाबेस से डेटाबेस से कनेक्ट करने के लिए डेटाबेस का IP पता शामिल है, तो उत्पादन परिवेश में रोल करते समय आपको एक समान समस्या आ सकती है।

इस मामले में, pre-install और pre-upgrade हुक हमारे लिए उपयुक्त नहीं हैं, क्योंकि एप्लिकेशन डेटाबेस में उन माइग्रेशन को लागू करने का प्रयास करेगा जो अभी तक मौजूद नहीं हैं । इस प्रकार, रिहाई के बाद पलायन करना आवश्यक है।

हेल्म का उपयोग करते समय, ऐसा कार्य प्राप्त करने योग्य है, क्योंकि यह अनुप्रयोगों की स्थिति की निगरानी नहीं करता है । कुबेरनेट्स में संसाधन लोड करने के बाद, पोस्ट हुक हमेशा आग लगाते हैं:

• पहले रिलीज पर K8s में सभी संसाधनों को लोड post-install बाद post-install ;
• post-upgrade बाद - रिलीज को अपडेट करते समय K8 में सभी संसाधनों को अपडेट करने के बाद।

हालाँकि, जैसा कि हमने ऊपर बताया है, रिलीज़ के दौरान वेयरफ़ के पास संसाधन ट्रैकिंग प्रणाली है । मैं इस पर विस्तार से थोड़ा और ध्यान दूंगा:

• ट्रैकिंग के लिए, werf kubedog लाइब्रेरी की क्षमताओं का उपयोग करता है, जिसके बारे में हम पहले ही ब्लॉग में बात कर चुके हैं।
• वेयरफ में यह सुविधा हमें विशिष्ट रूप से रिलीज की स्थिति निर्धारित करने और सीआई / सीडी-सिस्टम के इंटरफेस में तैनाती के सफल या असफल समापन पर जानकारी प्रदर्शित करने की अनुमति देती है।
• यह जानकारी प्राप्त किए बिना, कोई भी रिलीज़ प्रक्रिया के किसी भी स्वचालन के बारे में बात नहीं कर सकता, क्योंकि कुबेरनेट क्लस्टर में संसाधनों का सफल निर्माण चरणों में से एक है। उदाहरण के लिए, एप्लिकेशन गलत कॉन्फ़िगरेशन के कारण या नेटवर्क समस्या के कारण शुरू नहीं हो सकता है, लेकिन helm upgrade बाद इसे देखने के helm upgrade , आपको अतिरिक्त चरण करने होंगे।

अब हेल्म पोस्ट-हुक पर माइग्रेशन के आवेदन पर वापस जाएं। हमने जिन समस्याओं का सामना किया:

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

परिणामस्वरूप, हम निम्नलिखित आए:

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

परिणामी कॉन्फ़िगरेशन कुछ इस तरह दिखता है:

 --- apiVersion: batch/v1 kind: Job metadata: name: {{ printf "%s-apply-migrations-%s" .Chart.Name (now | date "2006-01-02-15-04-05") }} spec: activeDeadlineSeconds: 60 backoffLimit: 0 template: metadata: name: {{ printf "%s-apply-migrations-%s" .Chart.Name (now | date "2006-01-02-15-04-05") }} spec: imagePullSecrets: - name: {{ required ".Values.registry.secret_name required" .Values.registry.secret_name }} initContainers: - name: wait-db image: alpine:3.6 ommand: ["/bin/sh", "-c", "while ! nc -z postgres 5432; do sleep 1; done;"] containers: - name: job command: ["/usr/bin/php7.2", "artisan", "migrate", "--force"] {{ tuple "backend" . | include "werf_container_image" | indent 8 }} env: {{ tuple "backend" . | include "werf_container_env" | indent 8 }} - name: DB_HOST value: postgres restartPolicy: Never 

NB : कड़ाई से बोलना, डेटाबेस उपलब्धता की जाँच के लिए init कंटेनरों को वैसे भी सबसे अच्छा उपयोग किया जाता है।

सभी तैनात संचालन के लिए एक सार्वभौमिक टेम्पलेट का एक उदाहरण

हालाँकि, रिलीज़ के दौरान जिन ऑपरेशनों को करने की आवश्यकता होती है, वे पहले से उल्लेखित माइग्रेशन के लॉन्च से अधिक हो सकते हैं। आप न केवल हुक के प्रकारों के माध्यम से, बल्कि उनमें से प्रत्येक को वज़न असाइन करके भी - अय्यूब के निष्पादन आदेश को नियंत्रित कर सकते हैं - एनोटेशन helm.sh/hook-weight माध्यम से। हुक को आरोही क्रम में वजन द्वारा हल किया जाता है, और यदि वजन समान है, तो संसाधन नाम से।

बड़ी संख्या में नौकरियों के साथ यह जॉब्स के लिए एक सार्वभौमिक टेम्पलेट बनाने के लिए सुविधाजनक है, और कॉन्फ़िगरेशन को values.yaml में डाल दिया है। उत्तरार्द्ध इस तरह लग सकता है:

 deploy_jobs: - name: migrate command: '["/usr/bin/php7.2", "artisan", "migrate", "--force"]' activeDeadlineSeconds: 120 when: production: 'pre-install,pre-upgrade' staging: 'pre-install,pre-upgrade' _default: '' - name: cache-clear command: '["/usr/bin/php7.2", "artisan", "responsecache:clear"]' activeDeadlineSeconds: 60 when: _default: 'post-install,post-upgrade' 

... और टेम्पलेट स्वयं इस प्रकार है:

 {{- range $index, $job := .Values.deploy_jobs }} --- apiVersion: batch/v1 kind: Job metadata: name: {{ $.Chart.Name }}-{{ $job.name }} annotations: "helm.sh/hook": {{ pluck $.Values.global.env $job.when | first | default $job.when._default }} "helm.sh/hook-weight": "1{{ $index }}" spec: activeDeadlineSeconds: {{ $job.activeDeadlineSeconds }} backoffLimit: 0 template: metadata: name: {{ $.Chart.Name }}-{{ $job.name }} spec: imagePullSecrets: - name: {{ required "$.Values.registry.secret_name required" $.Values.registry.secret_name }} initContainers: - name: wait-db image: alpine:3.6 ommand: ["/bin/sh", "-c", "while ! nc -z postgres 5432; do sleep 1; done;"] containers: - name: job command: {{ $job.command }} {{ tuple "backend" $ | include "werf_container_image" | indent 8 }} env: {{ tuple "backend" $ | include "werf_container_env" | indent 8 }} - name: DB_HOST value: postgres restartPolicy: Never {{- end }} 

यह दृष्टिकोण आपको रिलीज की प्रक्रिया में नए कमांड को जल्दी से जोड़ने की अनुमति देता है और निष्पादन योग्य कमांड की सूची को अधिक दृश्य बनाता है।

निष्कर्ष

लेख उन टेम्पलेट्स के उदाहरण प्रदान करता है जो आपको उन सामान्य ऑपरेशनों का वर्णन करने की अनुमति देते हैं जिन्हें आपको एप्लिकेशन के नए संस्करण के रिलीज़ के दौरान प्रदर्शन करने की आवश्यकता होती है। यद्यपि वे दर्जनों परियोजनाओं में सीआई / सीडी प्रक्रियाओं को लागू करने में अनुभव का परिणाम थे, हम इस बात पर जोर नहीं देते हैं कि सभी कार्यों के लिए केवल एक सही समाधान है। यदि लेख में वर्णित उदाहरण आपकी परियोजना की जरूरतों को पूरा नहीं करते हैं, तो हमें टिप्पणियों में स्थितियों को देखकर खुशी होगी जो इस सामग्री के पूरक में मदद करेंगे।

वेयरफ डेवलपर्स से टिप्पणी:

भविष्य में, वेयरफ ने संसाधनों के उपयोगकर्ता-विन्यास योग्य तैनाती चरणों को पेश करने की योजना बनाई है। ऐसे चरणों की मदद से दोनों मामलों का वर्णन करना संभव होगा और न केवल।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " जटिल हेल चार्ट को रोल आउट करने के लिए वेयरफ़ का उपयोग करना ";
• " असेंबली और गीतालाब सीआई के साथ एक ही प्रकार के माइक्रोसिस्टर्स की असेंबली और तैनाती ";
• " 3-वेज़ में मर्ज: हेल्म के साथ कुबेरनेट्स में तैनाती" स्टेरॉयड पर " ";
• " कुबेरनेट्स टिप्स एंड ट्रिक्स: बड़े डेटाबेस के बूटस्ट्रैप को तेज करता है। "