नमस्कार! अलीकडे, डॉकर प्रतिमा तयार करण्यासाठी आणि कुबर्नेट्सवर तैनात करण्यासाठी बरीच छान ऑटोमेशन साधने सोडली गेली आहेत. या संदर्भात, मी गिटलॅबसह खेळण्याचा निर्णय घेतला, त्याच्या क्षमतांचा सखोल अभ्यास केला आणि अर्थातच पाइपलाइन सेट केली.

या कामाची प्रेरणा संकेतस्थळावरून मिळाली kubernetes.io, जे पासून व्युत्पन्न केले जाते स्रोत कोड स्वयंचलितपणे, आणि पाठवलेल्या प्रत्येक पूल विनंतीसाठी, रोबोट स्वयंचलितपणे तुमच्या बदलांसह साइटची पूर्वावलोकन आवृत्ती तयार करतो आणि पाहण्यासाठी लिंक प्रदान करतो.

मी सुरवातीपासून एक समान प्रक्रिया तयार करण्याचा प्रयत्न केला, परंतु पूर्णपणे गिटलॅब सीआय आणि विनामूल्य टूल्सवर तयार केला आहे ज्याचा वापर मला कुबर्नेट्सवर अनुप्रयोग उपयोजित करण्यासाठी वापरण्याची सवय आहे. आज मी तुम्हाला त्यांच्याबद्दल अधिक सांगेन.

लेख यासारख्या साधनांवर चर्चा करेल:
ह्युगो, qbec, कनिको, git-क्रिप्ट и गिटलाब सीआय डायनॅमिक वातावरणाच्या निर्मितीसह.

सामग्री

1. ह्यूगोला भेटा
2. डॉकरफाइल तयार करत आहे
3. कनिकोला जाणून घेणे
4. qbec जाणून घेणे
5. Kubernetes-executor सह Gitlab-धावणारा प्रयत्न करत आहे
6. qbec सह हेल्म चार्ट तैनात करणे
7. Git-crypt सादर करत आहे
8. टूलबॉक्स प्रतिमा तयार करणे
9. आमची पहिली पाइपलाइन आणि टॅगद्वारे प्रतिमांची असेंब्ली
10. उपयोजन ऑटोमेशन
11. कलाकृती आणि असेंब्ली जेव्हा मास्टरकडे ढकलणे
12. डायनॅमिक वातावरण
13. अॅप्सचे पुनरावलोकन करा

1. ह्यूगोला जाणून घेणे

आमच्या प्रकल्पाचे उदाहरण म्हणून, आम्ही ह्यूगोवर तयार केलेली दस्तऐवजीकरण प्रकाशन साइट तयार करण्याचा प्रयत्न करू. ह्यूगो एक स्थिर सामग्री जनरेटर आहे.

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

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

तुम्ही स्थानिकरित्या ह्यूगो स्थापित करू शकता आणि ते वापरून पहा:

नवीन साइट सुरू करत आहे:

hugo new site docs.example.org

आणि त्याच वेळी git रेपॉजिटरी:

cd docs.example.org
git init

आतापर्यंत, आमची साइट मूळ आहे आणि त्यावर काहीतरी दिसण्यासाठी, आम्हाला प्रथम थीम कनेक्ट करणे आवश्यक आहे; थीम हा फक्त टेम्पलेट्स आणि निर्दिष्ट नियमांचा संच आहे ज्याद्वारे आमची साइट तयार केली जाते.

थीमसाठी आम्ही वापरू जाणून घ्या, जे, माझ्या मते, दस्तऐवजीकरण साइटसाठी पूर्णपणे अनुकूल आहे.

मला या वस्तुस्थितीकडे विशेष लक्ष द्यायचे आहे की आम्हाला आमच्या प्रोजेक्ट रिपॉझिटरीमध्ये थीम फाइल्स सेव्ह करण्याची आवश्यकता नाही; त्याऐवजी, आम्ही ते वापरून कनेक्ट करू शकतो. git सबमॉड्यूल:

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/ आमची नवीन तयार केलेली वेबसाइट तपासा, निर्देशिकेत केलेले सर्व बदल ब्राउझरमध्ये उघडलेले पृष्ठ स्वयंचलितपणे अद्यतनित करा, अतिशय सोयीस्कर!

मध्ये कव्हर पेज तयार करण्याचा प्रयत्न करूया content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

नव्याने तयार केलेल्या पृष्ठाचा स्क्रीनशॉट

साइट व्युत्पन्न करण्यासाठी, फक्त चालवा:

hugo

निर्देशिका सामग्री सार्वजनिक/ आणि तुमची वेबसाइट असेल.
होय, तसे, लगेच त्यात जोडूया .gitignore:

echo /public > .gitignore

आमचे बदल करण्यास विसरू नका:

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

2. डॉकरफाइल तयार करणे

आमच्या भांडाराची रचना परिभाषित करण्याची वेळ आली आहे. मी सहसा असे काहीतरी वापरतो:

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

• डॉकरफाईल्स/ - डॉकरफाईल्ससह निर्देशिका आणि आमच्या डॉकर प्रतिमा तयार करण्यासाठी आवश्यक असलेल्या सर्व गोष्टी समाविष्ट करा.
• तैनात करणे/ — Kubernetes वर आमचे अनुप्रयोग उपयोजित करण्यासाठी निर्देशिका समाविष्टीत आहे

अशा प्रकारे, आम्ही मार्गावर आमची पहिली डॉकरफाइल तयार करू डॉकरफाईल्स/वेबसाइट/डॉकरफाइल

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" ]

जसे आपण पाहू शकता, डॉकरफाइलमध्ये दोन आहेत प्रेषक, या संधीला म्हणतात मल्टी-स्टेज बिल्ड आणि तुम्हाला अंतिम डॉकर इमेजमधून अनावश्यक सर्वकाही वगळण्याची परवानगी देते.
अशा प्रकारे, अंतिम प्रतिमेमध्ये फक्त समाविष्ट असेल गडदhttpd (हलके HTTP सर्व्हर) आणि सार्वजनिक/ — आमच्या स्थिरपणे व्युत्पन्न केलेल्या वेबसाइटची सामग्री.

आमचे बदल करण्यास विसरू नका:

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

3. कनिकोला ओळखणे

डॉकर इमेज बिल्डर म्हणून मी वापरायचे ठरवले कनिको, कारण त्याच्या ऑपरेशनसाठी डॉकर डिमनची आवश्यकता नसते आणि बिल्ड स्वतः कोणत्याही मशीनवर चालते आणि कॅशे थेट रेजिस्ट्रीमध्ये संग्रहित केले जाऊ शकते, ज्यामुळे पूर्ण वाढीव पर्सिस्टंट स्टोरेजची आवश्यकता दूर होते.

प्रतिमा तयार करण्यासाठी, फक्त कंटेनर चालवा kaniko एक्झिक्युटर आणि त्यास वर्तमान बिल्ड संदर्भ पास करा; हे डॉकरद्वारे स्थानिक पातळीवर देखील केले जाऊ शकते:

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

कुठे registry.gitlab.com/kvaps/docs.example.org/website - तुमच्या डॉकर इमेजचे नाव; तयार केल्यानंतर, ते आपोआप डॉकर रेजिस्ट्रीमध्ये लॉन्च केले जाईल.

पॅरामीटर --कॅशे तुम्हाला डॉकर रेजिस्ट्रीमध्ये स्तर कॅशे करण्याची परवानगी देते; दिलेल्या उदाहरणासाठी, ते सेव्ह केले जातील registry.gitlab.com/kvaps/docs.example.org/website/cache, परंतु तुम्ही पॅरामीटर वापरून दुसरा मार्ग निर्दिष्ट करू शकता --cache-repo.

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

4. qbec जाणून घेणे

Qbec एक उपयोजन साधन आहे जे तुम्हाला तुमचा ऍप्लिकेशन मॅनिफेस्टचे वर्णनात्मक वर्णन करू देते आणि त्यांना कुबर्नेट्समध्ये तैनात करू देते. मुख्य वाक्यरचना म्हणून Jsonnet वापरणे तुम्हाला अनेक वातावरणातील फरकांचे वर्णन मोठ्या प्रमाणात सुलभ करण्यास अनुमती देते आणि कोडची पुनरावृत्ती जवळजवळ पूर्णपणे काढून टाकते.

हे विशेषत: अशा प्रकरणांमध्ये खरे असू शकते जेव्हा तुम्हाला वेगवेगळ्या पॅरामीटर्ससह अनेक क्लस्टर्समध्ये अॅप्लिकेशन उपयोजित करण्याची आवश्यकता असते आणि Git मध्ये त्यांचे वर्णनात्मक वर्णन करायचे असते.

Qbec तुम्हाला हेल्म चार्ट्स त्यांना आवश्यक पॅरामीटर्स पास करून रेंडर करण्याची आणि नंतर नियमित मॅनिफेस्ट प्रमाणेच ऑपरेट करण्याची परवानगी देते, ज्यामध्ये तुम्ही त्यांना विविध उत्परिवर्तन लागू करू शकता आणि यामुळे तुम्हाला आवश्यकतेपासून मुक्तता मिळते. चार्ट म्युझियम वापरा. म्हणजेच, आपण थेट 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: {}

येथे आम्हाला प्रामुख्याने स्वारस्य आहे spec.environments, qbec ने आमच्यासाठी आधीच डिफॉल्ट वातावरण तयार केले आहे आणि आमच्या वर्तमान kubeconfig वरून सर्व्हर पत्ता तसेच नेमस्पेस घेतला आहे.
आता तैनात करताना डीफॉल्ट पर्यावरण, qbec नेहमी फक्त निर्दिष्ट केलेल्या Kubernetes क्लस्टरवर आणि निर्दिष्ट नेमस्पेसमध्ये तैनात करेल, म्हणजेच, उपयोजन करण्यासाठी तुम्हाला संदर्भ आणि नेमस्पेसमध्ये स्विच करण्याची गरज नाही.
आवश्यक असल्यास, आपण या फाईलमधील सेटिंग्ज नेहमी अद्यतनित करू शकता.

तुमच्या सर्व वातावरणाचे वर्णन केले आहे qbec.yaml, आणि फाइलमध्ये params.libsonnet, जिथे ते त्यांच्यासाठी पॅरामीटर्स कोठे मिळवायचे ते सांगते.

पुढे आपण दोन निर्देशिका पाहतो:

• घटक/ - आमच्या अनुप्रयोगासाठी सर्व मॅनिफेस्ट येथे संग्रहित केले जातील; त्यांचे वर्णन jsonnet आणि नियमित yaml फायलींमध्ये केले जाऊ शकते
• वातावरण/ — येथे आपण आपल्या वातावरणासाठी सर्व व्हेरिएबल्स (पॅरामीटर्स) चे वर्णन करू.

डीफॉल्टनुसार आमच्याकडे दोन फाइल्स आहेत:

• वातावरण/base.libsonnet - त्यात सर्व वातावरणासाठी सामान्य पॅरामीटर्स असतील
• वातावरण/default.libsonnet — पर्यावरणासाठी अधिलिखित पॅरामीटर्स समाविष्टीत आहे डीफॉल्ट

चला उघडूया वातावरण/base.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',
    },
  },
}

चला आपला पहिला घटक देखील तयार करूया components/website.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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

या फाईलमध्ये आम्ही एकाच वेळी तीन कुबर्नेट्स घटकांचे वर्णन केले आहे, ते आहेत: तैनात करणे, सेवा и प्रवेश. आम्ही इच्छित असल्यास, आम्ही त्यांना वेगवेगळ्या घटकांमध्ये घालू शकतो, परंतु या टप्प्यावर आमच्यासाठी एक पुरेसे असेल.

वाक्यरचना jsonnet नियमित json सारखेच आहे, तत्त्वतः, नियमित json आधीपासून वैध jsonnet आहे, त्यामुळे सुरुवातीला तुमच्यासाठी ऑनलाइन सेवा वापरणे सोपे होऊ शकते. yaml2json तुमच्‍या नेहमीच्‍या yaml चे json मध्‍ये रूपांतर करण्‍यासाठी, किंवा, जर तुमच्‍या घटकांमध्‍ये कोणतेही व्हेरिएबल नसल्‍यास, त्‍यांचे रेग्युलर yamlच्‍या रूपात वर्णन करता येईल.

सोबत काम करताना jsonnet मी तुमच्या संपादकासाठी प्लगइन स्थापित करण्याची शिफारस करतो

उदाहरणार्थ, vim साठी एक प्लगइन आहे vim-jsonnet, जे सिंटॅक्स हायलाइटिंग चालू करते आणि स्वयंचलितपणे कार्यान्वित होते jsonnet fmt प्रत्येक वेळी आपण जतन करा (jsonnet स्थापित करणे आवश्यक आहे).

सर्व काही तयार आहे, आता आम्ही उपयोजित करणे सुरू करू शकतो:

आम्हाला काय मिळाले ते पाहण्यासाठी, चला धावूया:

qbec show default

आउटपुटवर, तुम्हाला रेंडर केलेले yaml मॅनिफेस्ट दिसेल जे डीफॉल्ट क्लस्टरवर लागू केले जातील.

छान, आता अर्ज करा:

qbec apply default

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

आमचा अर्ज तयार आणि तैनात आहे!

तुम्ही बदल केल्यास, तुम्ही नेहमी हे करू शकता:

qbec diff default

या बदलांचा सध्याच्या तैनातीवर कसा परिणाम होईल हे पाहण्यासाठी

आमचे बदल करण्यास विसरू नका:

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

5. Kubernetes-executor सह Gitlab-धावणारा प्रयत्न करत आहे

अलीकडे पर्यंत मी फक्त नियमित वापरले gitlab-धावणारा शेल किंवा डॉकर-एक्झिक्युटरसह पूर्व-तयार मशीनवर (LXC कंटेनर). सुरुवातीला, आमच्या गिटलॅबमध्ये असे अनेक धावपटू जागतिक स्तरावर परिभाषित केले होते. त्यांनी सर्व प्रकल्पांसाठी डॉकर प्रतिमा गोळा केल्या.

परंतु सरावाने दर्शविल्याप्रमाणे, हा पर्याय व्यावहारिकता आणि सुरक्षिततेच्या दृष्टीने सर्वात आदर्श नाही. प्रत्येक प्रकल्पासाठी किंवा प्रत्येक वातावरणासाठी स्वतंत्र धावपटू तैनात करणे अधिक चांगले आणि वैचारिकदृष्ट्या अधिक योग्य आहे.

सुदैवाने, ही अजिबात समस्या नाही, कारण आता आम्ही तैनात करू gitlab-धावणारा आमच्या प्रकल्पाचा भाग म्हणून थेट कुबर्नेट्समध्ये.

गिटलॅब कुबरनेटेसला गिटलॅब-रनर तैनात करण्यासाठी तयार-तयार हेल्म चार्ट प्रदान करते. त्यामुळे तुम्हाला फक्त शोधण्याची गरज आहे नोंदणी टोकन आमच्या प्रकल्पासाठी सेटिंग्ज -> CI / CD -> धावपटू आणि ते सुकाणूकडे द्या:

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 - तुमच्या गिटलॅब सर्व्हरचा पत्ता.
• yga8y-jdCusVDn_t4Wxc - तुमच्या प्रकल्पासाठी नोंदणी टोकन.
• rbac.create=true — kubernetes-executor वापरून आमची कार्ये करण्यासाठी पॉड तयार करण्यास सक्षम होण्यासाठी धावपटूला आवश्यक प्रमाणात विशेषाधिकार प्रदान करते.

सर्वकाही योग्यरित्या केले असल्यास, आपण विभागात नोंदणीकृत धावपटू पहावे धावपटू, तुमच्या प्रकल्प सेटिंग्जमध्ये.

जोडलेल्या धावपटूचा स्क्रीनशॉट

हे इतके सोपे आहे का? - होय, ते सोपे आहे! धावपटूंची मॅन्युअली नोंदणी करताना आणखी त्रास होणार नाही, आतापासून धावपटू आपोआप तयार आणि नष्ट होतील.

6. QBEC सह हेल्म चार्ट तैनात करा

आम्ही विचार करण्याचा निर्णय घेतल्यापासून gitlab-धावणारा आमच्या प्रकल्पाचा एक भाग, आमच्या Git भांडारात त्याचे वर्णन करण्याची वेळ आली आहे.

आम्ही त्याचे स्वतंत्र घटक म्हणून वर्णन करू शकतो वेबसाइट, परंतु भविष्यात आम्ही वेगवेगळ्या प्रती उपयोजित करण्याची योजना आखत आहोत वेबसाइट खूप वेळा, विपरीत gitlab-धावणारा, जे प्रति Kubernetes क्लस्टर फक्त एकदाच तैनात केले जाईल. चला तर मग त्यासाठी स्वतंत्र अर्ज सुरू करूया:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

यावेळी आम्‍ही कुबर्नेट्स एंटिटीजचे वर्णन मॅन्युअली करणार नाही, परंतु रेडीमेड हेल्म चार्ट घेऊ. qbec चा एक फायदा म्हणजे थेट Git रेपॉजिटरीमधून हेल्म चार्ट रेंडर करण्याची क्षमता.

चला git सबमॉड्यूल वापरून कनेक्ट करूया:

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

आता निर्देशिका विक्रेता/गिटलॅब-रनर आमच्याकडे गिटलॅब-रनरसाठी चार्ट असलेले भांडार आहे.

त्याच प्रकारे, तुम्ही इतर रेपॉजिटरी कनेक्ट करू शकता, उदाहरणार्थ, संपूर्ण रेपॉजिटरी अधिकृत चार्टसह https://github.com/helm/charts

चला घटकाचे वर्णन करूया components/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,
  }
)

साठी पहिला युक्तिवाद expandHelmTemplate त्यानंतर, आम्ही चार्टचा मार्ग पास करतो params.values, जे आपण पर्यावरण पॅरामीटर्समधून घेतो, त्यानंतर ऑब्जेक्ट येतो

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

आता आपल्या घटकाच्या पॅरामीटर्सचे वर्णन करू वातावरण/base.libsonnet:

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

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

लक्ष द्या धावणारा नोंदणी टोकन आम्ही बाह्य फाइलमधून घेतो secrets/base.libsonnet, चला ते तयार करूया:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

सर्वकाही कार्य करते का ते तपासूया:

qbec show default

सर्वकाही व्यवस्थित असल्यास, आम्ही हेल्म द्वारे आमचे पूर्वी तैनात केलेले प्रकाशन हटवू शकतो:

helm uninstall gitlab-runner

आणि त्याच प्रकारे तैनात करा, परंतु qbec द्वारे:

qbec apply default

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

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

याक्षणी, गिटलॅब-रनरसाठी आमची निर्देशिका रचना अशी दिसते:

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

पण गिटमध्ये गुपिते साठवणे सुरक्षित नाही, आहे का? म्हणून आपण त्यांना योग्यरित्या एनक्रिप्ट करणे आवश्यक आहे.

सहसा, एका व्हेरिएबलच्या फायद्यासाठी, हे नेहमीच अर्थपूर्ण नसते. तुम्ही गुपिते हस्तांतरित करू शकता qbec आणि तुमच्या CI प्रणालीच्या पर्यावरणीय चलांद्वारे.
परंतु हे लक्षात घेण्यासारखे आहे की आणखी जटिल प्रकल्प देखील आहेत ज्यात अनेक रहस्ये असू शकतात; ते सर्व पर्यावरणीय चलने हस्तांतरित करणे अत्यंत कठीण होईल.

शिवाय, या प्रकरणात मी तुम्हाला अशा आश्चर्यकारक साधनाबद्दल सांगू शकणार नाही git-क्रिप्ट.

git-क्रिप्ट हे देखील सोयीस्कर आहे की ते तुम्हाला संपूर्ण रहस्यांचा इतिहास जतन करण्यास, तसेच तुलना, विलीन आणि संघर्षांचे निराकरण करण्याची परवानगी देते जसे की आम्हाला Git च्या बाबतीत करण्याची सवय आहे.

स्थापनेनंतर पहिली गोष्ट git-क्रिप्ट आम्हाला आमच्या भांडारासाठी की व्युत्पन्न करणे आवश्यक आहे:

git crypt init

जर तुमच्याकडे PGP की असेल, तर तुम्ही या प्रकल्पासाठी तत्काळ स्वतःला सहयोगी म्हणून जोडू शकता:

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

अशा प्रकारे तुम्ही तुमची खाजगी की वापरून हे भांडार नेहमी डिक्रिप्ट करू शकता.

तुमच्याकडे PGP की नसेल आणि तुमची अपेक्षा नसेल, तर तुम्ही दुसऱ्या मार्गाने जाऊन प्रोजेक्ट की एक्सपोर्ट करू शकता:

git crypt export-key /path/to/keyfile

अशा प्रकारे, जो कोणी निर्यात केला आहे की फाइल तुमचा रेपॉजिटरी डिक्रिप्ट करण्यात सक्षम असेल.

आमचे पहिले रहस्य सेट करण्याची वेळ आली आहे.
मी तुम्हाला आठवण करून देतो की आम्ही अजूनही निर्देशिकेत आहोत deploy/gitlab-runner/, जिथे आमच्याकडे एक निर्देशिका आहे गुपिते/, त्यातील सर्व फाईल्स एन्क्रिप्ट करूया, यासाठी आपण एक फाईल बनवू secrets/.gitattributes खालील सामग्रीसह:

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

सामग्रीवरून पाहिले जाऊ शकते, सर्व फायली मुखवटा घातलेल्या आहेत * द्वारे चालविले जाईल git-क्रिप्ट, बहुतेक वगळता .gitaattributes

आम्ही हे चालवून तपासू शकतो:

git crypt status -e

आउटपुट रेपॉजिटरीमधील सर्व फाइल्सची सूची असेल ज्यासाठी एनक्रिप्शन सक्षम केले आहे

एवढेच, आता आम्ही आमचे बदल सुरक्षितपणे करू शकतो:

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

रेपॉजिटरी अवरोधित करण्यासाठी, फक्त चालवा:

git crypt lock

आणि ताबडतोब सर्व एनक्रिप्टेड फायली बायनरीमध्ये बदलतील, त्या वाचणे अशक्य होईल.
रेपॉजिटरी डिक्रिप्ट करण्यासाठी, चालवा:

git crypt unlock

8. टूलबॉक्स प्रतिमा तयार करा

टूलबॉक्स इमेज ही सर्व टूल्स असलेली इमेज आहे जी आम्ही आमचा प्रोजेक्ट डिप्लॉय करण्यासाठी वापरू. हे गिटलॅब रनरद्वारे ठराविक उपयोजन कार्ये करण्यासाठी वापरले जाईल.

येथे सर्व काही सोपे आहे, चला एक नवीन तयार करूया डॉकरफाईल्स/टूलबॉक्स/डॉकरफाइल खालील सामग्रीसह:

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

आणि एक नवीन घटक जोडा components/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,
      },
    ],
  },
]

आम्ही नवीन पॅरामीटर्सचे वर्णन देखील करू वातावरण/base.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 संदर्भित नाव घटकासाठी आरबॅक

काय बदलले आहे ते तपासूया:

qbec diff default

आणि आमचे बदल Kubernetes वर लागू करा:

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 टॅगशी जोडले जातील. नवीन टॅगसह प्रत्येक पुश या टॅगसह प्रतिमा तयार करण्यास प्रारंभ करेल.

चला करूया git push --tags, आणि आमची पहिली पाइपलाइन पाहू:

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

डॉकर प्रतिमा तयार करण्यासाठी टॅगद्वारे असेंब्ली योग्य आहे, परंतु कुबर्नेट्सवर अनुप्रयोग तैनात करण्यासाठी योग्य नाही या वस्तुस्थितीकडे आपले लक्ष वेधून घेण्यासारखे आहे. जुन्या कमिटांना नवीन टॅग नियुक्त केले जाऊ शकतात, या प्रकरणात, त्यांच्यासाठी पाइपलाइन सुरू केल्याने जुनी आवृत्ती तैनात केली जाईल.

या समस्येचे निराकरण करण्यासाठी, सामान्यत: डॉकर प्रतिमा तयार करणे टॅगशी बांधले जाते आणि अनुप्रयोग शाखेत तैनात केले जाते. मास्टर, ज्यामध्ये संकलित प्रतिमांच्या आवृत्त्या हार्डकोड केलेल्या आहेत. येथे तुम्ही एका साध्या रिव्हर्टसह रोलबॅक सुरू करू शकता मास्टर- शाखा.

10. तैनातीचे ऑटोमेशन

गिटलॅब-रनरने आमची गुपिते डिक्रिप्ट करण्यासाठी, आम्हाला रिपॉझिटरी की निर्यात करावी लागेल आणि ती आमच्या CI पर्यावरण व्हेरिएबल्समध्ये जोडावी लागेल:

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

आम्ही Gitlab मध्ये परिणामी ओळ जतन करू; हे करण्यासाठी, आमच्या प्रकल्प सेटिंग्जवर जाऊया:
सेटिंग्ज -> CI / CD -> व्हेरिएबल्स

आणि एक नवीन व्हेरिएबल तयार करूया:

प्रकार
की
मूल्य
संरक्षित
मास्क केलेले
व्याप्ती

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

येथे आम्ही qbec साठी अनेक नवीन पर्याय सक्षम केले आहेत:

• --रूट काही/अॅप — तुम्हाला विशिष्ट अनुप्रयोगाची निर्देशिका निर्धारित करण्यास अनुमती देते
• --force:k8s-context __incluster__ - हे एक मॅजिक व्हेरिएबल आहे जे सांगते की डिप्लॉयमेंट त्याच क्लस्टरमध्ये होईल ज्यामध्ये gtilab-runner चालू आहे. हे आवश्यक आहे कारण अन्यथा qbec तुमच्या kubeconfig मध्ये योग्य Kubernetes सर्व्हर शोधण्याचा प्रयत्न करेल.
• -- प्रतीक्षा करा — qbec ला ते तयार केलेली संसाधने तयार स्थितीत जाईपर्यंत प्रतीक्षा करण्यास भाग पाडते आणि त्यानंतरच यशस्वी एक्झिट-कोडसह बाहेर पडते.
• - होय - फक्त परस्परसंवादी शेल अक्षम करते तुला खात्री आहे? तैनात केल्यावर.

आमचे बदल करण्यास विसरू नका:

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

आणि नंतर गिट पुश आमचे अर्ज कसे तैनात केले गेले आहेत ते आम्ही पाहू:

दुसऱ्या पाइपलाइनचा स्क्रीनशॉट

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"

कृपया लक्षात ठेवा आम्ही एक धागा जोडला आहे मास्टर к रेफर्स नोकऱ्यांसाठी बिल्ड_वेबसाइट आणि आम्ही आता वापरतो $CI_COMMIT_REF_NAME त्याऐवजी $CI_COMMIT_TAG, म्हणजे, आम्ही Git मधील टॅग्जपासून मुक्त झालो आहोत आणि आता आम्ही पाइपलाइन सुरू करणाऱ्या कमिट शाखेच्या नावासह प्रतिमा पुश करू. हे लक्षात घेण्यासारखे आहे की हे टॅगसह देखील कार्य करेल, जे आम्हाला डॉकर-रेजिस्ट्रीमध्ये विशिष्ट आवृत्तीसह साइटचे स्नॅपशॉट जतन करण्यास अनुमती देईल.

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

पर्याय —vm:ext-str digest="$DIGEST" qbec साठी - तुम्हाला jsonnet ला बाह्य व्हेरिएबल पास करण्याची परवानगी देते. आमच्या ऍप्लिकेशनच्या प्रत्येक रिलीझसह ते क्लस्टरमध्ये पुन्हा तैनात केले जावे अशी आमची इच्छा आहे. आम्ही यापुढे टॅगचे नाव वापरू शकत नाही, जे आता अपरिवर्तनीय असू शकते, कारण आम्हाला प्रतिमेच्या विशिष्ट आवृत्तीशी जोडले जाणे आवश्यक आहे आणि जेव्हा ते बदलते तेव्हा उपयोजन ट्रिगर करणे आवश्यक आहे.

येथे आपल्याला फाईलमध्ये डायजेस्ट प्रतिमा जतन करण्याच्या कनिकोच्या क्षमतेद्वारे मदत केली जाईल (पर्याय --डायजेस्ट-फाइल)
मग आम्ही ही फाईल हस्तांतरित करू आणि तैनातीच्या वेळी ती वाचू.

चला आमच्यासाठी पॅरामीटर्स अपडेट करूया deploy/website/environments/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',
    },
  },
}

पूर्ण झाले, आता कोणतीही कमिट इन करा मास्टर साठी डॉकर इमेजच्या बिल्डला सुरुवात करते वेबसाइट, आणि नंतर ते Kubernetes वर तैनात करा.

आमचे बदल करण्यास विसरू नका:

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

आम्ही नंतर तपासू गिट पुश आपण असे काहीतरी पाहिले पाहिजे:

मास्टरसाठी पाइपलाइनचा स्क्रीनशॉट

तत्वतः, आम्हाला प्रत्येक पुशसह गिटलॅब-रनर पुन्हा तैनात करण्याची आवश्यकता नाही, जोपर्यंत, अर्थातच, त्याच्या कॉन्फिगरेशनमध्ये काहीही बदललेले नाही, चला त्याचे निराकरण करूया. .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/**/*

बदल मधील बदलांचे निरीक्षण करण्यास अनुमती देईल deploy/gitlab-runner/ आणि जर काही असेल तरच आमचे कार्य ट्रिगर करेल

आमचे बदल करण्यास विसरू नका:

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

गिट पुश, हे उत्तम झाले:

अपडेट केलेल्या पाइपलाइनचा स्क्रीनशॉट

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, तेथे एक ब्लॉक जोडा पर्यावरण:

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 साठी एक नवीन पर्याय पाहतो: --app-टॅग — हे तुम्हाला अॅप्लिकेशनच्या उपयोजित आवृत्त्यांना टॅग करण्याची आणि फक्त या टॅगमध्ये कार्य करण्यास अनुमती देते; कुबर्नेट्समध्ये संसाधने तयार करताना आणि नष्ट करताना, qbec फक्त त्यांच्यासह कार्य करेल.
अशा प्रकारे आम्ही प्रत्येक पुनरावलोकनासाठी स्वतंत्र वातावरण तयार करू शकत नाही, परंतु फक्त तेच पुनर्वापर करू शकतो.

येथे आपण देखील वापरतो qbec पुनरावलोकन लागू करा, ऐवजी qbec डीफॉल्ट लागू करा - हाच क्षण आहे जेव्हा आम्ही आमच्या वातावरणातील फरकांचे वर्णन करण्याचा प्रयत्न करू (पुनरावलोकन आणि डीफॉल्ट):

जोडूया पुनरावलोकन मध्ये वातावरण deploy/website/qbec.yaml

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

मग आम्ही ते घोषित करू deploy/website/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

आणि त्यात सानुकूल पॅरामीटर्स लिहा deploy/website/environments/review.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',
    },
  },
}

चला jobu वर देखील जवळून नजर टाकूया थांबा_पुनरावलोकन, जेव्हा शाखा हटविली जाईल तेव्हा ते ट्रिगर केले जाईल आणि म्हणून गिटलॅब चेकआउट करण्याचा प्रयत्न करू नये म्हणून ती वापरली जाईल GIT_STRATEGY: काहीही नाही, नंतर आम्ही क्लोन करतो मास्टर- शाखा आणि त्याद्वारे पुनरावलोकन हटवा.
हे थोडे गोंधळात टाकणारे आहे, परंतु मला अजून सुंदर मार्ग सापडला नाही.
पर्यायी पर्याय म्हणजे प्रत्येक पुनरावलोकन हॉटेलच्या नेमस्पेसवर तैनात करणे, जे नेहमी पूर्णपणे नष्ट केले जाऊ शकते.

आमचे बदल करण्यास विसरू नका:

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

गिट पुश, git checkout -b चाचणी, git पुश मूळ चाचणी, तपासा:

Gitlab मध्ये तयार केलेल्या वातावरणाचा स्क्रीनशॉट

सर्व काही कार्यरत आहे? - छान, आमची चाचणी शाखा हटवा: गिट चेकआउट मास्टर, git पुश मूळ: चाचणी, आम्ही तपासतो की पर्यावरण हटवण्याच्या जॉबने त्रुटींशिवाय काम केले.

येथे मी ताबडतोब स्पष्ट करू इच्छितो की प्रकल्पातील कोणताही विकासक शाखा तयार करू शकतो, तो बदलू देखील शकतो .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"

गिट पुश, आणि तपासा:

पुनरावलोकन अॅप बटणाचा स्क्रीनशॉट

काम झाले!

प्रकल्प स्रोत:

• Gitlab वर: https://gitlab.com/kvaps/docs.example.org
• GitHub वर: https://github.com/kvaps/docs.example.org

तुमचे लक्ष दिल्याबद्दल धन्यवाद, मला आशा आहे की तुम्हाला ते आवडले असेल

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