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

यह कार्य वेबसाइट से प्रेरित था Kubernetes.io, जो से उत्पन्न होता है स्रोत कोड स्वचालित रूप से, और भेजे गए प्रत्येक पूल अनुरोध के लिए, रोबोट स्वचालित रूप से आपके परिवर्तनों के साथ साइट का एक पूर्वावलोकन संस्करण तैयार करता है और देखने के लिए एक लिंक प्रदान करता है।

मैंने स्क्रैच से एक समान प्रक्रिया बनाने की कोशिश की, लेकिन पूरी तरह से गिटलैब सीआई और मुफ्त टूल पर बनाया गया जिसका उपयोग मैं कुबेरनेट्स पर एप्लिकेशन तैनात करने के लिए करता था। आज मैं अंततः आपको उनके बारे में और बताऊंगा।

लेख में निम्नलिखित टूल पर चर्चा की जाएगी:
ह्यूगो, क्यूबेक, कनिको, git-क्रिप्ट и गिटलैब सीआई गतिशील वातावरण के निर्माण के साथ.

अंतर्वस्तु

1. ह्यूगो से मिलें
2. डॉकरफ़ाइल तैयार करना
3. कनिको को जानना
4. क्यूबेक को जानना
5. Kubernetes-निष्पादक के साथ Gitlab-धावक का प्रयास कर रहा हूँ
6. क्यूबेक के साथ हेल्म चार्ट तैनात करना
7. गिट-क्रिप्ट का परिचय
8. टूलबॉक्स छवि बनाना
9. हमारी पहली पाइपलाइन और टैग द्वारा छवियों का संयोजन
10. परिनियोजन स्वचालन
11. मास्टर करने के लिए दबाव डालते समय कलाकृतियाँ और संयोजन
12. गतिशील वातावरण
13. ऐप्स की समीक्षा करें

1. ह्यूगो को जानना

हमारे प्रोजेक्ट के उदाहरण के रूप में, हम ह्यूगो पर निर्मित एक दस्तावेज़ीकरण प्रकाशन साइट बनाने का प्रयास करेंगे। ह्यूगो एक स्थिर सामग्री जनरेटर है।

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

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

आप ह्यूगो को स्थानीय रूप से इंस्टॉल कर सकते हैं और इसे आज़मा सकते हैं:

एक नई साइट प्रारंभ करना:

hugo new site docs.example.org

और उसी समय git रिपॉजिटरी:

cd docs.example.org
git init

अब तक, हमारी साइट प्राचीन है और इस पर कुछ प्रदर्शित करने के लिए, हमें पहले एक थीम कनेक्ट करने की आवश्यकता है; एक थीम केवल टेम्पलेट्स और निर्दिष्ट नियमों का एक सेट है जिसके द्वारा हमारी साइट बनाई जाती है।

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

मैं इस तथ्य पर विशेष ध्यान देना चाहूंगा कि हमें अपने प्रोजेक्ट रिपॉजिटरी में थीम फ़ाइलों को सहेजने की आवश्यकता नहीं है; इसके बजाय, हम इसे आसानी से कनेक्ट कर सकते हैं गिट सबमॉड्यूल:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

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

आइए कॉन्फ़िगरेशन को ठीक करें config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

पहले से ही इस स्तर पर आप चला सकते हैं:

hugo server

और पते पर http://localhost:1313/ हमारी नव निर्मित वेबसाइट की जांच करें, निर्देशिका में किए गए सभी परिवर्तन स्वचालित रूप से ब्राउज़र में खुले पृष्ठ को अपडेट करते हैं, बहुत सुविधाजनक!

आइए एक कवर पेज बनाने का प्रयास करें सामग्री/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

नव निर्मित पृष्ठ का स्क्रीनशॉट

एक साइट बनाने के लिए, बस चलाएँ:

hugo

निर्देशिका सामग्री जनता/ और आपकी वेबसाइट होगी.
हाँ, वैसे, आइए इसे तुरंत इसमें जोड़ें .गरिग्नोर:

echo /public > .gitignore

हमारे परिवर्तन करना न भूलें:

git add .
git commit -m "New site created"

2. डॉकरफाइल तैयार करना

अब हमारे भंडार की संरचना को परिभाषित करने का समय आ गया है। मैं आमतौर पर कुछ इस तरह का उपयोग करता हूं:

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• dockerfiles/ - इसमें Dockerfiles वाली निर्देशिकाएँ और हमारी Docker छवियाँ बनाने के लिए आवश्यक सभी चीज़ें शामिल हैं।
• तैनात करना/ - कुबेरनेट्स पर हमारे अनुप्रयोगों को तैनात करने के लिए निर्देशिकाएं शामिल हैं

इस प्रकार, हम पथ पर अपना पहला डॉकरफ़ाइल बनाएंगे dockerfiles/वेबसाइट/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

जैसा कि आप देख सकते हैं, Dockerfile में दो हैं से, इस सुविधा को कहा जाता है मल्टी-स्टेज निर्माण और आपको अंतिम डॉकर छवि से सभी अनावश्यक चीजों को बाहर करने की अनुमति देता है।
इस प्रकार, अंतिम छवि में केवल शामिल होगा अँधेराhttpd (हल्के HTTP सर्वर) और जनता/ - हमारी स्थिर रूप से तैयार की गई वेबसाइट की सामग्री।

हमारे परिवर्तन करना न भूलें:

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. कनिको को जानना

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

छवि बनाने के लिए, बस कंटेनर को चलाएं कनिको निष्पादक और इसे वर्तमान बिल्ड संदर्भ पास करें; यह स्थानीय रूप से डॉकर के माध्यम से भी किया जा सकता है:

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

जहाँ रजिस्ट्री.gitlab.com/kvaps/docs.example.org/website - आपकी डॉकर छवि का नाम; निर्माण के बाद, इसे स्वचालित रूप से डॉकर रजिस्ट्री में लॉन्च किया जाएगा।

प्राचल --कैश आपको डॉकर रजिस्ट्री में परतों को कैश करने की अनुमति देता है; दिए गए उदाहरण के लिए, उन्हें इसमें सहेजा जाएगा रजिस्ट्री.gitlab.com/kvaps/docs.example.org/website/cache, लेकिन आप पैरामीटर का उपयोग करके कोई अन्य पथ निर्दिष्ट कर सकते हैं --कैश-रेपो.

डॉकर-रजिस्ट्री का स्क्रीनशॉट

4. क्यूबेक को जानना

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

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

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

जैसा कि मैंने पहले कहा था, हम सभी तैनाती को एक निर्देशिका में संग्रहीत करेंगे तैनात करना/:

mkdir deploy
cd deploy

आइए अपना पहला एप्लिकेशन प्रारंभ करें:

qbec init website
cd website

अब हमारे एप्लिकेशन की संरचना इस तरह दिखती है:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

आइए फ़ाइल देखें qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

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

आपके सभी परिवेशों का वर्णन इसमें किया गया है qbec.yaml, और फ़ाइल में पैराम्स.libsonnet, जहां यह कहा गया है कि उनके लिए पैरामीटर कहां से प्राप्त करें।

आगे हम दो निर्देशिकाएँ देखते हैं:

• घटक / - हमारे एप्लिकेशन के लिए सभी मैनिफ़ेस्ट यहां संग्रहीत किए जाएंगे; उन्हें jsonnet और नियमित yaml फ़ाइलों दोनों में वर्णित किया जा सकता है
• वातावरण/ - यहां हम अपने पर्यावरण के लिए सभी चर (पैरामीटर) का वर्णन करेंगे।

डिफ़ॉल्ट रूप से हमारे पास दो फ़ाइलें हैं:

• वातावरण/बेस.libsonnet - इसमें सभी परिवेशों के लिए सामान्य पैरामीटर शामिल होंगे
• वातावरण/default.libsonnet - इसमें पर्यावरण के लिए ओवरराइड किए गए पैरामीटर शामिल हैं चूक

चलो, खोलो वातावरण/बेस.libsonnet और वहां हमारे पहले घटक के लिए पैरामीटर जोड़ें:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

आइए अपना पहला घटक भी बनाएं घटक/वेबसाइट.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

इस फ़ाइल में हमने एक साथ तीन Kubernetes संस्थाओं का वर्णन किया है, ये हैं: तैनाती, सर्विस и प्रवेश. हम चाहें तो उन्हें अलग-अलग घटकों में रख सकते हैं, लेकिन इस स्तर पर हमारे लिए एक ही पर्याप्त होगा।

वाक्य-विन्यास jsonnet नियमित json के समान ही है, सिद्धांत रूप में, नियमित json पहले से ही वैध jsonnet है, इसलिए पहली बार में आपके लिए ऑनलाइन सेवाओं का उपयोग करना आसान हो सकता है yaml2json अपने सामान्य yaml को json में बदलने के लिए, या, यदि आपके घटकों में कोई चर नहीं है, तो उन्हें नियमित yaml के रूप में वर्णित किया जा सकता है।

जब साथ काम कर रहे हों jsonnet मैं आपके संपादक के लिए एक प्लगइन स्थापित करने की अत्यधिक अनुशंसा करता हूँ

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

सब कुछ तैयार है, अब हम तैनाती शुरू कर सकते हैं:

यह देखने के लिए कि हमें क्या मिला, आइए दौड़ें:

qbec show default

आउटपुट पर, आप रेंडर किए गए yaml मेनिफ़ेस्ट देखेंगे जो डिफ़ॉल्ट क्लस्टर पर लागू होंगे।

बढ़िया, अब आवेदन करें:

qbec apply default

आउटपुट पर आप हमेशा देखेंगे कि आपके क्लस्टर में क्या किया जाएगा, क्यूबेक आपको टाइप करके परिवर्तनों से सहमत होने के लिए कहेगा y आप अपने इरादों की पुष्टि कर सकेंगे.

हमारा एप्लिकेशन तैयार और तैनात है!

यदि आप परिवर्तन करते हैं, तो आप हमेशा यह कर सकते हैं:

qbec diff default

यह देखने के लिए कि ये परिवर्तन वर्तमान तैनाती को कैसे प्रभावित करेंगे

हमारे परिवर्तन करना न भूलें:

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. कुबेरनेट्स-निष्पादक के साथ गिटलैब-रनर का प्रयास करना

हाल तक मैं केवल नियमित उपयोग करता था gitlab-धावक शेल या डॉकर-निष्पादक के साथ पूर्व-तैयार मशीन (एलएक्ससी कंटेनर) पर। प्रारंभ में, हमारे गिटलैब में विश्व स्तर पर ऐसे कई धावक परिभाषित थे। उन्होंने सभी परियोजनाओं के लिए डॉकर छवियां एकत्र कीं।

लेकिन जैसा कि अभ्यास से पता चला है, यह विकल्प व्यावहारिकता और सुरक्षा दोनों ही दृष्टि से सबसे आदर्श नहीं है। प्रत्येक परियोजना या यहां तक ​​कि प्रत्येक परिवेश के लिए अलग-अलग धावकों को तैनात करना बहुत बेहतर और वैचारिक रूप से अधिक सही है।

सौभाग्य से, यह कोई समस्या नहीं है, क्योंकि अब हम तैनात करेंगे gitlab-धावक सीधे कुबेरनेट्स में हमारे प्रोजेक्ट के हिस्से के रूप में।

गिटलैब कुबेरनेट्स को गिटलैब-रनर तैनात करने के लिए एक तैयार हेल्म चार्ट प्रदान करता है। तो आपको बस यह पता लगाना है पंजीकरण टोकन हमारे प्रोजेक्ट के लिए सेटिंग्स -> सीआई / सीडी -> रनर और इसे पतवार को सौंपें:

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

कहाँ:

• https://gitlab.com - आपके Gitlab सर्वर का पता।
• yga8y-jdCusVDn_t4Wxc - आपके प्रोजेक्ट के लिए पंजीकरण टोकन।
• rbac.create=सत्य - कुबेरनेट्स-निष्पादक का उपयोग करके हमारे कार्यों को करने के लिए पॉड बनाने में सक्षम होने के लिए धावक को आवश्यक मात्रा में विशेषाधिकार प्रदान करता है।

यदि सब कुछ सही ढंग से किया गया है, तो आपको अनुभाग में एक पंजीकृत धावक देखना चाहिए धावकों, आपकी प्रोजेक्ट सेटिंग में।

जोड़े गए धावक का स्क्रीनशॉट

क्या यह इतना आसान है? - हाँ, यह इतना आसान है! धावकों को मैन्युअल रूप से पंजीकृत करने में अब कोई परेशानी नहीं होगी, अब से धावक स्वचालित रूप से बनाए और नष्ट किए जाएंगे।

6. क्यूबीईसी के साथ हेल्म चार्ट तैनात करें

चूँकि हमने विचार करने का निर्णय लिया gitlab-धावक हमारे प्रोजेक्ट का हिस्सा, अब हमारे Git रिपॉजिटरी में इसका वर्णन करने का समय आ गया है।

हम इसे एक अलग घटक के रूप में वर्णित कर सकते हैं वेबसाइट , लेकिन भविष्य में हम अलग-अलग प्रतियाँ तैनात करने की योजना बना रहे हैं वेबसाइट बहुत बार, इसके विपरीत gitlab-धावक, जिसे प्रति कुबेरनेट्स क्लस्टर में केवल एक बार तैनात किया जाएगा। तो आइए इसके लिए एक अलग एप्लिकेशन प्रारंभ करें:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

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

आइए इसे git सबमॉड्यूल का उपयोग करके कनेक्ट करें:

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

अब निर्देशिका विक्रेता/जीटलैब-धावक हमारे पास गिटलैब-रनर के लिए चार्ट वाला एक भंडार है।

इसी तरह, आप अन्य रिपॉजिटरी को, उदाहरण के लिए, संपूर्ण रिपॉजिटरी को आधिकारिक चार्ट से जोड़ सकते हैं https://github.com/helm/charts

आइए घटक का वर्णन करें घटक/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

के लिए पहला तर्क विस्तारहेल्मटेम्पलेट फिर, हम चार्ट का पथ पार करते हैं पैरामीटर.मान, जिसे हम पर्यावरण मापदंडों से लेते हैं, फिर वस्तु आती है

• नाम टेम्पलेट - रिलीज़ शीर्षक
• नाम स्थान - नेमस्पेस को हेल्म में स्थानांतरित कर दिया गया
• यह फ़ाइल - एक आवश्यक पैरामीटर जो वर्तमान फ़ाइल का पथ पास करता है
• वाचाल - आदेश दिखाता है हेल्म टेम्पलेट चार्ट प्रस्तुत करते समय सभी तर्कों के साथ

आइए अब हमारे घटक के मापदंडों का वर्णन करें वातावरण/बेस.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

ध्यान दें धावक पंजीकरणटोकन हम एक बाहरी फ़ाइल से लेते हैं रहस्य/बेस.libsonnet, आइए इसे बनाएं:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

आइए देखें कि क्या सब कुछ काम करता है:

qbec show default

यदि सब कुछ क्रम में है, तो हम हेल्म के माध्यम से अपनी पहले से तैनात रिलीज़ को हटा सकते हैं:

helm uninstall gitlab-runner

और इसे उसी तरह तैनात करें, लेकिन क्यूबेक के माध्यम से:

qbec apply default

7. गिट-क्रिप्ट का परिचय

गिट-क्रिप्ट एक उपकरण है जो आपको अपने भंडार के लिए पारदर्शी एन्क्रिप्शन स्थापित करने की अनुमति देता है।

फिलहाल, gitlab-runner के लिए हमारी निर्देशिका संरचना इस तरह दिखती है:

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

लेकिन Git में रहस्य संग्रहीत करना सुरक्षित नहीं है, क्या ऐसा है? इसलिए हमें उन्हें ठीक से एन्क्रिप्ट करने की आवश्यकता है।

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

इसके अलावा, इस मामले में मैं आपको ऐसे अद्भुत टूल के बारे में नहीं बता पाऊंगा git-क्रिप्ट.

git-क्रिप्ट यह इस मायने में भी सुविधाजनक है कि यह आपको रहस्यों के पूरे इतिहास को सहेजने के साथ-साथ तुलना करने, विलय करने और संघर्षों को उसी तरह हल करने की अनुमति देता है जैसे हम Git के मामले में करने के आदी हैं।

इंस्टालेशन के बाद पहली बात git-क्रिप्ट हमें अपने भंडार के लिए कुंजियाँ उत्पन्न करने की आवश्यकता है:

git crypt init

यदि आपके पास पीजीपी कुंजी है, तो आप तुरंत स्वयं को इस परियोजना के लिए सहयोगी के रूप में जोड़ सकते हैं:

git-crypt add-gpg-user [email protected]

इस तरह आप अपनी निजी कुंजी का उपयोग करके इस रिपॉजिटरी को हमेशा डिक्रिप्ट कर सकते हैं।

यदि आपके पास पीजीपी कुंजी नहीं है और आप इसकी उम्मीद नहीं करते हैं, तो आप दूसरा रास्ता अपना सकते हैं और प्रोजेक्ट कुंजी निर्यात कर सकते हैं:

git crypt export-key /path/to/keyfile

इस प्रकार, जिस किसी के पास निर्यात है कीफाइल आपके भंडार को डिक्रिप्ट करने में सक्षम होगा।

यह हमारा पहला रहस्य स्थापित करने का समय है।
मैं आपको याद दिला दूं कि हम अभी भी निर्देशिका में हैं परिनियोजन/gitlab-धावक/, जहां हमारे पास एक निर्देशिका है रहस्य/, आइए इसमें सभी फाइलों को एन्क्रिप्ट करें, इसके लिए हम एक फाइल बनाएंगे रहस्य/.gitattributes निम्नलिखित सामग्री के साथ:

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

जैसा कि सामग्री से देखा जा सकता है, सभी फ़ाइलें छिपी हुई हैं * के माध्यम से चलाया जाएगा git-क्रिप्ट, अधिकांश को छोड़कर .gitattributes

हम इसे चलाकर जाँच सकते हैं:

git crypt status -e

आउटपुट रिपॉजिटरी में उन सभी फ़ाइलों की एक सूची होगी जिनके लिए एन्क्रिप्शन सक्षम है

बस, अब हम सुरक्षित रूप से अपने परिवर्तन कर सकते हैं:

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

किसी रिपॉजिटरी को ब्लॉक करने के लिए, बस चलाएँ:

git crypt lock

और तुरंत सभी एन्क्रिप्टेड फ़ाइलें बाइनरी में बदल जाएंगी, उन्हें पढ़ना असंभव हो जाएगा।
रिपॉजिटरी को डिक्रिप्ट करने के लिए, चलाएँ:

git crypt unlock

8. एक टूलबॉक्स छवि बनाएं

टूलबॉक्स छवि उन सभी टूल वाली एक छवि है जिसका उपयोग हम अपने प्रोजेक्ट को तैनात करने के लिए करेंगे। इसका उपयोग गिटलैब रनर द्वारा विशिष्ट परिनियोजन कार्यों को करने के लिए किया जाएगा।

यहां सब कुछ सरल है, आइए एक नया बनाएं dockerfiles/टूलबॉक्स/Dockerfile निम्नलिखित सामग्री के साथ:

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

जैसा कि आप देख सकते हैं, इस छवि में हम उन सभी उपयोगिताओं को स्थापित करते हैं जिनका उपयोग हम अपने एप्लिकेशन को तैनात करने के लिए करते थे। जब तक हमें यहां इसकी आवश्यकता नहीं है Kubectl, लेकिन हो सकता है कि आप पाइपलाइन सेटअप चरण के दौरान इसके साथ खेलना चाहें।

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

ऐसा करने के लिए, आइए gitlab-runner वाली निर्देशिका पर जाएँ:

cd deploy/gitlab-runner

और एक नया घटक जोड़ें घटक/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

हम इसमें नए मापदंडों का भी वर्णन करेंगे वातावरण/बेस.libsonnet, जो अब इस तरह दिखता है:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

ध्यान दें $.components.rbac.name का अर्थ है नाम घटक के लिए RBAC

आइए देखें कि क्या बदल गया है:

qbec diff default

और हमारे परिवर्तनों को कुबेरनेट्स पर लागू करें:

qbec apply default

इसके अलावा, git में हमारे परिवर्तन करना न भूलें:

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. हमारी पहली पाइपलाइन और टैग द्वारा छवियों का संयोजन

प्रोजेक्ट के मूल में हम बनाएंगे .gitlab-ci.yml निम्नलिखित सामग्री के साथ:

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

कृपया ध्यान दें कि हम उपयोग करते हैं GIT_SUBMODULE_STRATEGY: सामान्य उन नौकरियों के लिए जहां आपको निष्पादन से पहले सबमॉड्यूल को स्पष्ट रूप से प्रारंभ करने की आवश्यकता होती है।

हमारे परिवर्तन करना न भूलें:

git add .gitlab-ci.yml
git commit -m "Automate docker build"

मुझे लगता है कि हम इसे सुरक्षित रूप से एक संस्करण कह सकते हैं v0.0.1 और टैग जोड़ें:

git tag v0.0.1

जब भी हमें कोई नया संस्करण जारी करने की आवश्यकता होगी हम टैग जोड़ देंगे। डॉकर छवियों में टैग Git टैग से जुड़े होंगे। एक नए टैग के साथ प्रत्येक पुश इस टैग के साथ छवियों के निर्माण को आरंभ करेगा।

चलो यह करते हैं गिट पुश--टैग, और आइए हमारी पहली पाइपलाइन देखें:

पहली पाइपलाइन का स्क्रीनशॉट

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

इस समस्या को हल करने के लिए, आमतौर पर डॉकर छवियों का निर्माण टैग से जुड़ा होता है, और एप्लिकेशन को एक शाखा में तैनात किया जाता है मास्टर, जिसमें एकत्रित छवियों के संस्करण हार्डकोड किए गए हैं। यह वह जगह है जहां आप एक साधारण रिवर्ट के साथ रोलबैक आरंभ कर सकते हैं मास्टर-शाखाएँ।

10. तैनाती का स्वचालन

Gitlab-रनर द्वारा हमारे रहस्यों को डिक्रिप्ट करने के लिए, हमें रिपॉजिटरी कुंजी को निर्यात करने और इसे हमारे CI पर्यावरण चर में जोड़ने की आवश्यकता होगी:

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

हम परिणामी पंक्ति को Gitlab में सहेजेंगे; ऐसा करने के लिए, आइए अपनी प्रोजेक्ट सेटिंग्स पर जाएँ:
सेटिंग्स -> सीआई / सीडी -> वेरिएबल्स

और आइए एक नया वेरिएबल बनाएं:

प्रकार
कुंजी
वैल्यू
संरक्षित
अनदेखा
विस्तार

File
GITCRYPT_KEY
<your string>
true (प्रशिक्षण के दौरान आप कर सकते हैं false)
true
All environments

जोड़े गए वेरिएबल का स्क्रीनशॉट

अब आइए अपना अपडेट करें .gitlab-ci.yml इसमें जोड़ना:

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

यहां हमने क्यूबेक के लिए कई नए विकल्प सक्षम किए हैं:

• --कुछ/ऐप रूट करें - आपको किसी विशिष्ट एप्लिकेशन की निर्देशिका निर्धारित करने की अनुमति देता है
• --बल:k8s-संदर्भ __incluster__ - यह एक जादुई वैरिएबल है जो कहता है कि तैनाती उसी क्लस्टर में होगी जिसमें gtilab-runner चल रहा है। यह आवश्यक है क्योंकि अन्यथा qbec आपके kubeconfig में एक उपयुक्त Kubernetes सर्वर खोजने का प्रयास करेगा
• --इंतज़ार - क्यूबेक को तब तक इंतजार करने के लिए मजबूर करता है जब तक कि उसके द्वारा बनाए गए संसाधन तैयार स्थिति में न चले जाएं और उसके बाद ही एक सफल निकास-कोड के साथ बाहर निकलें।
• -हाँ - बस इंटरैक्टिव शेल को अक्षम कर देता है तुम्हें यकीन है? जब तैनात किया गया.

हमारे परिवर्तन करना न भूलें:

git add .gitlab-ci.yml
git commit -m "Automate deploy"

और बाद में git धक्का हम देखेंगे कि हमारे एप्लिकेशन कैसे तैनात किए गए हैं:

दूसरी पाइपलाइन का स्क्रीनशॉट

11. मास्टर की ओर धकेलते समय कलाकृतियाँ और संयोजन

आमतौर पर, ऊपर वर्णित चरण लगभग किसी भी माइक्रोसर्विस को बनाने और वितरित करने के लिए पर्याप्त हैं, लेकिन हम हर बार साइट को अपडेट करने के लिए एक टैग जोड़ना नहीं चाहते हैं। इसलिए, हम अधिक गतिशील मार्ग अपनाएंगे और मास्टर शाखा में डाइजेस्ट परिनियोजन स्थापित करेंगे।

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

आइए हमारे इन दोनों जॉब्स को अपडेट करें .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

कृपया ध्यान दें कि हमने एक थ्रेड जोड़ा है मास्टर к refs नौकरियों के लिए बिल्ड_वेबसाइट और अब हम उपयोग करते हैं $CI_COMMIT_REF_NAME के बदले $CI_COMMIT_TAG, यानी, हम Git में टैग से मुक्त हो गए हैं और अब हम उस कमिट ब्रांच के नाम के साथ एक इमेज पुश करेंगे जिसने पाइपलाइन को इनिशियलाइज़ किया था। यह ध्यान देने योग्य है कि यह टैग के साथ भी काम करेगा, जो हमें डॉकर-रजिस्ट्री में एक विशिष्ट संस्करण के साथ साइट के स्नैपशॉट को सहेजने की अनुमति देगा।

जब साइट के नए संस्करण के लिए डॉकर टैग का नाम अपरिवर्तित हो सकता है, तब भी हमें कुबेरनेट्स में परिवर्तनों का वर्णन करना होगा, अन्यथा यह नई छवि से एप्लिकेशन को फिर से तैनात नहीं करेगा, क्योंकि इसमें कोई बदलाव नज़र नहीं आएगा परिनियोजन प्रकट.

विकल्प —vm:ext-str डाइजेस्ट=”$DIGEST” क्यूबेक के लिए - आपको jsonnet पर एक बाहरी वेरिएबल पास करने की अनुमति देता है। हम चाहते हैं कि हमारे एप्लिकेशन के प्रत्येक रिलीज़ के साथ इसे क्लस्टर में पुनः तैनात किया जाए। हम अब टैग नाम का उपयोग नहीं कर सकते हैं, जो अब अपरिवर्तनीय हो सकता है, क्योंकि हमें छवि के एक विशिष्ट संस्करण से बंधे रहने और इसके बदलने पर तैनाती को ट्रिगर करने की आवश्यकता है।

यहां हमें कनिको की डाइजेस्ट छवि को एक फ़ाइल (विकल्प) में सहेजने की क्षमता से मदद मिलेगी --डाइजेस्ट-फ़ाइल)
फिर हम इस फ़ाइल को स्थानांतरित करेंगे और तैनाती के समय इसे पढ़ेंगे।

आइए हमारे लिए पैरामीटर अपडेट करें परिनियोजन/वेबसाइट/वातावरण/base.libsonnet जो अब इस तरह दिखेगा:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

हो गया, अब कोई भी प्रतिबद्ध है मास्टर के लिए डॉकर छवि के निर्माण को आरंभ करता है वेबसाइट , और फिर इसे कुबेरनेट्स पर तैनात करें।

हमारे परिवर्तन करना न भूलें:

git add .
git commit -m "Configure dynamic build"

हम बाद में जाँच करेंगे git धक्का हमें कुछ इस तरह देखना चाहिए:

मास्टर के लिए पाइपलाइन का स्क्रीनशॉट

सिद्धांत रूप में, हमें प्रत्येक पुश के साथ गिटलैब-रनर को फिर से तैनात करने की आवश्यकता नहीं है, जब तक कि निश्चित रूप से, इसके कॉन्फ़िगरेशन में कुछ भी नहीं बदला है, आइए इसे ठीक करें .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

परिवर्तन आपको परिवर्तनों की निगरानी करने की अनुमति देगा परिनियोजन/gitlab-धावक/ और हमारा काम तभी शुरू होगा जब कोई होगा

हमारे परिवर्तन करना न भूलें:

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

git धक्का, वह बेहतर है:

अद्यतन पाइपलाइन का स्क्रीनशॉट

12. गतिशील वातावरण

यह गतिशील वातावरण के साथ हमारी पाइपलाइन में विविधता लाने का समय है।

सबसे पहले, आइए कार्य को अद्यतन करें बिल्ड_वेबसाइट हमारे में .gitlab-ci.yml, इसमें से ब्लॉक हटा रहा है केवल, जो Gitlab को किसी भी शाखा में किसी भी प्रतिबद्धता पर इसे ट्रिगर करने के लिए मजबूर करेगा:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

फिर कार्य को अद्यतन करें परिनियोजन_वेबसाइट, वहां एक ब्लॉक जोड़ें वातावरण:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

इससे Gitlab को इस कार्य से जुड़ने की अनुमति मिल जाएगी ठेस पर्यावरण और उसका सही लिंक प्रदर्शित करें।

आइए अब दो और नौकरियां जोड़ें:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

उन्हें मास्टर को छोड़कर किसी भी शाखा में पुश करने पर लॉन्च किया जाएगा और साइट का पूर्वावलोकन संस्करण तैनात किया जाएगा।

हम क्यूबेक के लिए एक नया विकल्प देखते हैं: --ऐप-टैग - यह आपको एप्लिकेशन के तैनात संस्करणों को टैग करने और केवल इस टैग के भीतर काम करने की अनुमति देता है; कुबेरनेट्स में संसाधनों को बनाते और नष्ट करते समय, क्यूबेक केवल उनके साथ काम करेगा।
इस तरह हम प्रत्येक समीक्षा के लिए एक अलग वातावरण नहीं बना सकते हैं, बल्कि उसी का पुन: उपयोग कर सकते हैं।

यहां हम भी प्रयोग करते हैं क्यूबेक समीक्षा लागू करेंके बजाय क्यूबेक डिफ़ॉल्ट लागू करें - यही वह क्षण है जब हम अपने परिवेश (समीक्षा और डिफ़ॉल्ट) के लिए अंतरों का वर्णन करने का प्रयास करेंगे:

जोड़ना की समीक्षा पर्यावरण में परिनियोजन/वेबसाइट/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

फिर हम इसकी घोषणा करेंगे परिनियोजन/वेबसाइट/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

और इसके लिए कस्टम पैरामीटर लिखें परिनियोजन/वेबसाइट/वातावरण/समीक्षा.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

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

हमारे परिवर्तन करना न भूलें:

git add .
git commit -m "Enable automatic review"

git धक्का, गिट चेकआउट-बी टेस्ट, गिट पुश मूल परीक्षण, जाँच करना:

Gitlab में निर्मित परिवेश का स्क्रीनशॉट

सब कुछ काम कर रहा है? - बढ़िया, हमारी परीक्षण शाखा हटाएँ: गिट चेकआउट मास्टर, गिट पुश उत्पत्ति: परीक्षण, हम जांचते हैं कि पर्यावरण विलोपन कार्य त्रुटियों के बिना काम करता है।

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

13. ऐप्स की समीक्षा करें

ऐप्स की समीक्षा करें यह एक GitLab सुविधा है जो आपको तैनात वातावरण में इसे तुरंत देखने के लिए रिपॉजिटरी में प्रत्येक फ़ाइल के लिए एक बटन जोड़ने की अनुमति देती है।

इन बटनों को प्रदर्शित करने के लिए, आपको एक फ़ाइल बनानी होगी .gitlab/route-map.yml और इसमें सभी पथ परिवर्तनों का वर्णन करें; हमारे मामले में यह बहुत सरल होगा:

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

हमारे परिवर्तन करना न भूलें:

git add .gitlab/
git commit -m "Enable review apps"

git धक्का, और जाँच करें:

समीक्षा ऐप बटन का स्क्रीनशॉट

काम पूरा हो गया!

परियोजना स्रोत:

• गिटलैब पर: https://gitlab.com/kvaps/docs.example.org
• गिटहब पर: https://github.com/kvaps/docs.example.org

आपके ध्यान के लिए धन्यवाद, मुझे आशा है कि आपको यह पसंद आया होगा

स्रोत: www.habr.com