🧘 🐵 👩🏿‍🤝‍👨🏾 असेंबली और गिटलैब सीआई के साथ एक ही माइक्रोसर्विस की विधानसभा और तैनाती 🔉 👼🏼 🛋️

दो साल पहले हमने लेख " GitLab CI के साथ बिल्डिंग प्रोजेक्ट्स: एक .gitlab-ci.yml सैकड़ों आवेदन पत्र " प्रकाशित किए, और अब हम आज एक समान समस्या को हल करने के बारे में बात करेंगे। नई सामग्री इस बात के बारे में है कि आप बड़ी संख्या में समान अनुप्रयोगों के लिए CI / CD प्रक्रियाओं का निर्माण कैसे कर सकते include । .gitlab-ci.yml include हैं .gitlab-ci.yml और dapp को बदलने के लिए werf का आगमन।

परिचयात्मक

लेख में दिए गए अन्य निर्देशों में, निम्नलिखित स्थिति पर विचार किया गया है:

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

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

स्पष्ट रूप से, .gitlab-ci.yml , werf.yaml और .helm नकल करने से बहुत सारी समस्याएं आती हैं। आखिरकार, CI में किसी भी संपादन, विधानसभा प्रक्रिया या हेल्म-चार्ट का विवरण अन्य रिपॉजिटरी में जोड़ा जाना चाहिए ...

.Gitlab-ci.yml में टेम्प्लेट कनेक्ट करना

include:file के आगमन के साथ include:file गिटलैब सीई में include:file निर्देश ( संस्करण 11.7 के बाद से ), यह एक आम सीआई बनाने के लिए संभव हो गया। अपने आप को कुछ समय पहले (11.4 में) शामिल किया गया था, लेकिन इसने केवल सार्वजनिक URL से टेम्पलेट जोड़ने की अनुमति दी, जिसने इसकी कार्यक्षमता को कुछ हद तक सीमित कर दिया। GitLab प्रलेखन पूरी तरह से सभी सुविधाओं और उपयोग उदाहरणों का वर्णन करता है ।

इस प्रकार, रिपोजिटरी के बीच .gitlab-ci.yml को कॉपी करने और इसकी प्रासंगिकता का समर्थन करने से इनकार करना संभव था। यहाँ एक उदाहरण है।

 include: - project: 'infra/gitlab-ci' ref: 1.0.0 file: base-gitlab-ci.yaml - project: 'infra/gitlab-ci' ref: 1.0.0 file: cleanup.yaml

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

एक अलग रिपॉजिटरी से .helm को कनेक्ट करें

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

  - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/infra/helm.git .helm - cd .helm && git checkout tags/1.0.0 - type multiwerf && source <(multiwerf use 1.0 beta) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf deploy --stages-storage :local

गिट सबमॉड्यूल का उपयोग करते हुए भी विविधताएं थीं, लेकिन यह सब एक वर्कअराउंड की तरह लगता है ...

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

कर्मों का अनुक्रम

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

 helm repo add stable https://kubernetes-charts.storage.googleapis.com helm install stable/chartmuseum --name flant-chartmuseum

प्रवेश जोड़ें:

 apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/force-ssl-redirect: "false" nginx.ingress.kubernetes.io/proxy-body-size: 10m nginx.ingress.kubernetes.io/ssl-redirect: "false" name: chart-museum spec: rules: - host: flant-chartmuseum.example.net http: paths: - backend: serviceName: flant-chartmuseum servicePort: 8080 path: / status: loadBalancer: {}

परिनियोजन flant-chartmuseum को परिवेश चर DISABLE_API को false बदलने की आवश्यकता है। अन्यथा (डिफ़ॉल्ट रूप से), चार्टम्यूज़िन एपीआई अनुरोध काम नहीं करेगा और नए चार्ट बनाना संभव नहीं होगा।

अब हम उस रिपॉजिटरी का वर्णन करते हैं जिसमें साझा हेलम चार्ट संग्रहीत किए जाएंगे। इसकी निर्देशिकाओं की संरचना इस प्रकार है:

 . ├── charts │ └── yii2-microservice │ ├── Chart.yaml │ └── templates │ ├── app.yaml └── README.md

Chart.yaml इस तरह Chart.yaml सकता है:

 name: yii2-microservice version: 1.0.4

templates डायरेक्टरी में सभी आवश्यक कुबेरनेट प्राइमिटिव्स होने चाहिए जो क्लस्टर में एप्लिकेशन को तैनात करने के लिए आवश्यक होंगे। जैसा कि आप पहले ही अनुमान लगा सकते हैं, इस मामले में, माइक्रोसेवा yii2 फ्रेमवर्क पर आधारित एक PHP अनुप्रयोग है। आइए, इसके दो निगनेक्स और php-fpm कंटेनरों के साथ इसकी न्यूनतम तैनाती का वर्णन करें जो कि werf का उपयोग करके बनाए गए हैं:

 --- apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Values.global.werf.name }} spec: replicas: 1 revisionHistoryLimit: 3 template: metadata: labels: service: {{ .Values.global.werf.name }} spec: imagePullSecrets: - name: registrysecret containers: - name: backend {{ tuple "backend" . | include "werf_container_image" | indent 8 }} command: [ '/usr/sbin/php-fpm7', "-F" ] ports: - containerPort: 9000 protocol: TCP name: http env: {{ tuple "backend" . | include "werf_container_env" | indent 8 }} - name: frontend command: ['/usr/sbin/nginx'] {{ tuple "frontend" . | include "werf_container_image" | indent 8 }} ports: - containerPort: 80 name: http lifecycle: preStop: exec: command: ["/usr/sbin/nginx", "-s", "quit"] env: {{ tuple "frontend" . | include "werf_container_env" | indent 8 }} --- apiVersion: v1 kind: Service metadata: name: {{ .Values.global.werf.name }} spec: selector: service: {{ .Values.global.werf.name }} ports: - name: http port: 80 protocol: TCP

चर .Values.global.werf.name में परियोजना के नाम में से werf.yaml फ़ाइल है, जो आपको सेवाओं और तैनाती के आवश्यक नाम प्राप्त करने की अनुमति देती है।

मास्टर शाखा के लिए प्रतिबद्ध होने पर, अपने चार्ट के चार्टम्यूज में पुश के लिए सबसे सरल स्वचालन बनाएं। ऐसा करने के लिए, हम .gitlab-ci.yml वर्णन .gitlab-ci.yml :

 Build and push to chartmuseum: script: - for i in $(ls charts); do helm package "charts/$i"; done; - for i in $(find . -type f -name "*.tgz" -printf "%f\n"); do curl --data-binary "@$i" http://flant-chartmuseum.example.net/api/charts; done; stage: build environment: name: infra only: - master tags: - my-shell-runner-tag

चार्ट को चार्ट में बदल कर चार्ट तैयार किए जाते हैं। सभी नए चार्ट स्वचालित रूप से चार्टम्यूज में जोड़े जाएंगे।

हम फिनिश लाइन पर जाते हैं! प्रोजेक्ट में रिपॉजिटरी में .helm/requirements.yaml चार्ट के लिए निर्भरता लिखते हैं:

 dependencies: - name: yii2-microservice version: "1.0.4" repository: "@flant"

... और रिपॉजिटरी के साथ निर्देशिका में निष्पादित करें:

 werf helm repo init werf helm repo add flant http://flant-chartmuseum.example.net werf helm dependency update

हम इसमें .helm/requirements.lock । अब, क्लस्टर में एप्लिकेशन को परिनियोजित करने के लिए, werf deploy चलाने से पहले werf helm dependency build को चलाने के लिए पर्याप्त है।

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

निष्कर्ष

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

पुनश्च

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