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

यो काम वेबसाइट द्वारा प्रेरित थियो kubernetes.io, जुन बाट उत्पन्न हुन्छ स्रोत कोडहरू स्वचालित रूपमा, र प्रत्येक पूल अनुरोधको लागि पठाइयो, रोबोटले स्वचालित रूपमा तपाइँको परिवर्तनहरूको साथ साइटको पूर्वावलोकन संस्करण उत्पन्न गर्दछ र हेर्नको लागि लिङ्क प्रदान गर्दछ।

मैले स्क्र्याचबाट समान प्रक्रिया निर्माण गर्ने प्रयास गरें, तर पूर्ण रूपमा Gitlab CI र नि: शुल्क उपकरणहरूमा बनाइएको छ जुन म कुबर्नेट्समा अनुप्रयोगहरू डिप्लोय गर्न प्रयोग गर्न प्रयोग गरिरहेको छु। आज म अन्तमा तिनीहरूको बारेमा थप बताउनेछु।

लेखले उपकरणहरू छलफल गर्नेछ जस्तै:
ह्यूगो, qbec, कनिको, git-crypt и GitLab सीआई गतिशील वातावरण को निर्माण संग।

सामग्री

1. ह्युगोलाई भेट्नुहोस्
2. Dockerfile तयारी गर्दै
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 submodule:

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. कनिको चिन्ने

डकर छवि निर्माणकर्ताको रूपमा, मैले प्रयोग गर्ने निर्णय गरें कनिको, किनकि यसको सञ्चालनलाई डकर डेमनको आवश्यकता पर्दैन, र निर्माण आफैं कुनै पनि मेसिनमा गर्न सकिन्छ र क्यास सिधै रजिस्ट्रीमा भण्डारण गर्न सकिन्छ, जसले गर्दा पूर्ण-विकसित स्थिर भण्डारणको आवश्यकतालाई हटाउँछ।

छवि निर्माण गर्न, केवल कन्टेनर चलाउनुहोस् कनिको कार्यकारी र यसलाई हालको निर्माण सन्दर्भ पास गर्नुहोस्; यो स्थानीय रूपमा पनि गर्न सकिन्छ, डकर मार्फत:

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, जहाँ यसले उनीहरूका लागि प्यारामिटरहरू कहाँ प्राप्त गर्ने भनेर भन्छ।

अर्को हामी दुई डाइरेक्टरीहरू देख्छौं:

• घटक / - हाम्रो एप्लिकेसनका लागि सबै manifests यहाँ भण्डारण गरिनेछ; तिनीहरू 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

यस फाइलमा हामीले एकैचोटि तीनवटा Kubernetes संस्थाहरू वर्णन गरेका छौं, यी हुन्: तैनाथ, सेवा и आक्रामक। यदि हामीले चाहेको भए, हामी तिनीहरूलाई विभिन्न घटकहरूमा राख्न सक्छौं, तर यस चरणमा हाम्रो लागि एउटा पर्याप्त हुनेछ।

विन्यास jsonnet नियमित json सँग धेरै मिल्दोजुल्दो छ, सिद्धान्तमा, नियमित json पहिले नै मान्य jsonnet छ, त्यसैले सुरुमा तपाईंलाई अनलाइन सेवाहरू प्रयोग गर्न सजिलो हुन सक्छ। yaml2json तपाईंको सामान्य yaml लाई json मा रूपान्तरण गर्न, वा, यदि तपाईंको कम्पोनेन्टहरूमा कुनै चर समावेश छैन भने, त्यसपछि तिनीहरूलाई नियमित yaml को रूपमा वर्णन गर्न सकिन्छ।

संग काम गर्दा jsonnet म तपाईको सम्पादकको लागि प्लगइन स्थापना गर्न सिफारिस गर्दछु

उदाहरण को लागी, vim को लागी एक प्लगइन छ vim-jsonnet, जसले सिन्ट्याक्स हाइलाइटिङ खोल्छ र स्वचालित रूपमा कार्यान्वयन गर्छ jsonnet fmt प्रत्येक पटक तपाईंले बचत गर्नुहुन्छ (jsonnet स्थापना आवश्यक छ)।

सबै तयार छ, अब हामी तैनाती सुरु गर्न सक्छौं:

हामीले के पायौं भनेर हेर्न, दौडौं:

qbec show default

आउटपुटमा, तपाईंले रेन्डर गरिएको yaml manifests देख्नुहुनेछ जुन पूर्वनिर्धारित क्लस्टरमा लागू हुनेछ।

राम्रो, अब लागू गर्नुहोस्:

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- धावक Kubernetes मा सीधा हाम्रो परियोजना को एक भाग को रूप मा।

Gitlab ले Kubernetes मा 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 - तपाईंको Gitlab सर्भरको ठेगाना।
• yga8y-jdCusVDn_t4Wxc - तपाईंको परियोजनाको लागि दर्ता टोकन।
• rbac.create=true — kubernetes-executor को प्रयोग गरेर हाम्रा कार्यहरू गर्नका लागि पोडहरू सिर्जना गर्न सक्षम हुन आवश्यक विशेषाधिकारहरूको साथ धावकलाई प्रदान गर्दछ।

यदि सबै कुरा सही तरिकाले गरियो भने, तपाईंले सेक्सनमा दर्ता गरिएको धावक देख्नुपर्छ धावक, तपाईंको परियोजना सेटिङहरूमा।

थपिएको धावकको स्क्रिनसट

के यो सरल छ? - हो, यो एकदम सरल छ! म्यानुअल रूपमा धावकहरू दर्ता गर्न अब कुनै झन्झट छैन, अबदेखि धावकहरू स्वतः सिर्जना र नष्ट हुनेछन्।

6. QBEC सँग हेल्म चार्टहरू प्रयोग गर्नुहोस्

हामीले विचार गर्ने निर्णय गरेपछि gitlab- धावक हाम्रो परियोजनाको अंश, यो हाम्रो Git भण्डारमा वर्णन गर्ने समय हो।

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

cd deploy
qbec init gitlab-runner
cd gitlab-runner

यस पटक हामी Kubernetes निकायहरू म्यानुअल रूपमा वर्णन गर्दैनौं, तर तयार-निर्मित हेलम चार्ट लिनेछौं। Qbec को फाइदाहरू मध्ये एक Git भण्डारबाट सीधा हेल्म चार्टहरू रेन्डर गर्ने क्षमता हो।

Git submodule प्रयोग गरेर यसलाई जडान गरौं:

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

अब निर्देशिका विक्रेता / gitlab-धावक हामीसँग 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,
  }
)

को लागि पहिलो तर्क हेल्म टेम्प्लेट विस्तार गर्नुहोस् हामी चार्टमा बाटो पास गर्छौं, त्यसपछि 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. git-crypt को परिचय

Git-crypt एउटा उपकरण हो जसले तपाईंलाई आफ्नो भण्डारको लागि पारदर्शी इन्क्रिप्सन सेटअप गर्न अनुमति दिन्छ।

यस समयमा, gitlab-runner को लागि हाम्रो निर्देशिका संरचना यस्तो देखिन्छ:

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

तर Git मा गोप्य भण्डारण सुरक्षित छैन, यो हो? त्यसैले हामीले तिनीहरूलाई राम्ररी इन्क्रिप्ट गर्न आवश्यक छ।

सामान्यतया, एक चर को खातिर, यो सधैं अर्थ छैन। तपाईं गोप्य स्थानान्तरण गर्न सक्नुहुन्छ qbec र तपाईंको CI प्रणालीको वातावरणीय चर मार्फत।
तर यो ध्यान दिन लायक छ कि त्यहाँ धेरै जटिल परियोजनाहरू छन् जसमा धेरै रहस्यहरू समावेश हुन सक्छन्; ती सबैलाई वातावरणीय चरहरू मार्फत स्थानान्तरण गर्न अत्यन्त गाह्रो हुनेछ।

यसबाहेक, यस अवस्थामा म तपाईंलाई यस्तो अद्भुत उपकरणको बारेमा बताउन सक्षम हुनेछैन git-crypt.

git-crypt यो पनि सुविधाजनक छ कि यसले तपाईंलाई गोप्य इतिहासको सम्पूर्ण इतिहास बचत गर्न अनुमति दिन्छ, साथै तुलना, मर्ज र द्वन्द्वहरू समाधान गर्नको लागि हामी Git को मामलामा गर्ने बानी छ।

स्थापना पछि पहिलो कुरा git-crypt हामीले हाम्रो भण्डारको लागि कुञ्जीहरू उत्पन्न गर्न आवश्यक छ:

git crypt init

यदि तपाइँसँग PGP कुञ्जी छ भने, तपाइँ तुरुन्तै यस परियोजनाको लागि सहयोगीको रूपमा आफूलाई थप्न सक्नुहुन्छ:

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

यस तरिकाले तपाइँ सधैँ तपाइँको निजी कुञ्जी प्रयोग गरेर यो भण्डार डिक्रिप्ट गर्न सक्नुहुन्छ।

यदि तपाइँसँग PGP कुञ्जी छैन र यो आशा गर्नुहुन्न भने, तपाइँ अर्को तरिकामा जान सक्नुहुन्छ र परियोजना कुञ्जी निर्यात गर्न सक्नुहुन्छ:

git crypt export-key /path/to/keyfile

यसरी, जो कोही एक निर्यात छ कुञ्जी फाइल आफ्नो भण्डार डिक्रिप्ट गर्न सक्षम हुनेछ।

यो हाम्रो पहिलो गोप्य सेट अप गर्ने समय हो।
मलाई सम्झाउन दिनुहोस् कि हामी अझै निर्देशिकामा छौं deploy/gitlab-runner/जहाँ हामीसँग डाइरेक्टरी छ रहस्य/, यसमा भएका सबै फाइलहरू इन्क्रिप्ट गरौं, यसका लागि हामी एउटा फाइल सिर्जना गर्नेछौं रहस्य/gitattributes निम्न सामग्री संग:

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

सामग्रीबाट देख्न सकिन्छ, सबै फाइलहरू मास्क गरिएका छन् * मार्फत संचालित हुनेछ git-crypt, धेरै बाहेक .gitaविशेषताहरू

हामी यसलाई चलाएर जाँच गर्न सक्छौं:

git crypt status -e

आउटपुट भण्डारमा सबै फाइलहरूको सूची हुनेछ जसको लागि गुप्तिकरण सक्षम गरिएको छ

यति मात्रै हो, अब हामी सुरक्षित रूपमा हाम्रा परिवर्तनहरू गर्न सक्छौं:

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

भण्डार ब्लक गर्न, केवल चलाउनुहोस्:

git crypt lock

र तुरुन्तै सबै ईन्क्रिप्टेड फाइलहरू बाइनरीमा परिणत हुनेछ, तिनीहरूलाई पढ्न असम्भव हुनेछ।
भण्डार डिक्रिप्ट गर्न, चलाउनुहोस्:

git crypt unlock

8. एउटा उपकरण बाकस छवि सिर्जना गर्नुहोस्

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

यहाँ सबै कुरा सरल छ, एउटा नयाँ सिर्जना गरौं dockerfiles/toolbox/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, तर तपाईं पाइपलाइन सेटअप चरणको समयमा यसको वरिपरि खेल्न चाहानुहुन्छ।

साथै, Kubernetes सँग सञ्चार गर्न र यसलाई प्रयोग गर्न सक्षम हुनको लागि, हामीले gitlab-runner द्वारा उत्पन्न पोडहरूको लागि भूमिका कन्फिगर गर्न आवश्यक छ।

यो गर्नको लागि, 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 बुझाउँछ नाम घटक को लागी rbac

के परिवर्तन भयो जाँच गरौं:

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. तैनाती को स्वचालन

Gitlab-runner लाई हाम्रो गोप्य कुराहरू डिक्रिप्ट गर्नको लागि, हामीले भण्डार कुञ्जी निर्यात गर्न र यसलाई हाम्रो 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"

र पछी 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"

कृपया ध्यान दिनुहोस् कि हामीले एउटा थ्रेड थपेका छौं मास्टर к रेफ्री रोजगारीका लागि build_website र हामी अब प्रयोग गर्छौं $CI_COMMIT_REF_NAME को सट्टा $CI_COMMIT_TAG, त्यो हो, हामी Git मा ट्यागहरूबाट मुक्त छौं र अब हामी पाइपलाइन प्रारम्भ गर्ने प्रतिबद्ध शाखाको नामको साथ छवि पुश गर्नेछौं। यो ध्यान दिन लायक छ कि यसले ट्यागहरूसँग पनि काम गर्नेछ, जसले हामीलाई डकर-रेजिस्ट्रीमा एक विशिष्ट संस्करणको साथ साइटको स्न्यापशटहरू बचत गर्न अनुमति दिनेछ।

जब साइटको नयाँ संस्करणको लागि डकर ट्यागको नाम अपरिवर्तित हुन सक्छ, हामीले अझै पनि Kubernetes मा परिवर्तनहरू वर्णन गर्नुपर्दछ, अन्यथा यसले नयाँ छविबाट अनुप्रयोगलाई पुन: प्रयोग गर्दैन, किनकि यसले कुनै पनि परिवर्तनहरू याद गर्दैन। तैनाती प्रकट।

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

यहाँ हामीलाई फाइलमा डाइजेस्ट छवि बचत गर्न कानिकोको क्षमताले मद्दत गर्नेछ (विकल्प --digest-फाइल)
त्यसपछि हामी यो फाइल स्थानान्तरण गर्नेछौं र यसलाई प्रयोगको समयमा पढ्नेछौं।

हाम्रो लागि प्यारामिटरहरू अद्यावधिक गरौं 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"

हामी पछि जाँच गर्नेछौं 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/**/*

परिवर्तनहरू मा परिवर्तनहरू निगरानी गर्न अनुमति दिन्छ deploy/gitlab-runner/ र कुनै भएमा मात्र हाम्रो काम ट्रिगर गर्नेछ

हाम्रा परिवर्तनहरू गर्न नबिर्सनुहोस्:

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

git धक्का, त्यो राम्रो छ:

अपडेट गरिएको पाइपलाइनको स्क्रिनसट

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

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

पहिले, काम अद्यावधिक गरौं build_website हाम्रो मा 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-tag - यसले तपाइँलाई अनुप्रयोगको डिप्लोइड संस्करणहरू ट्याग गर्न र यो ट्याग भित्र मात्र काम गर्न अनुमति दिन्छ; Kubernetes मा स्रोतहरू सिर्जना गर्दा र नष्ट गर्दा, 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',
    },
  },
}

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

हाम्रा परिवर्तनहरू गर्न नबिर्सनुहोस्:

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

git धक्का, git checkout -b परीक्षण, git पुश उत्पत्ति परीक्षण, जाँच गर्नुहोस्:

Gitlab मा सिर्जना गरिएको वातावरणको स्क्रिनसट

सबै काम गरिरहेको छ? - राम्रो, हाम्रो परीक्षण शाखा मेटाउनुहोस्: git चेकआउट मास्टर, 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"

git धक्का, र जाँच गर्नुहोस्:

समीक्षा एप बटनको स्क्रिनसट

काम सकियो!

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

• Gitlab मा: https://gitlab.com/kvaps/docs.example.org
• GitHub मा: https://github.com/kvaps/docs.example.org

तपाइँको ध्यान को लागी धन्यवाद, मलाई आशा छ कि तपाइँ यो मनपर्छ

स्रोत: www.habr.com