🥇 आवृत्तीकृत दस्तऐवजीकरण साइटच्या उदाहरणाचा वापर करून werf सह डॉकर प्रतिमांचे गतिमान असेंब्ली आणि तैनाती

आम्ही आमच्या GitOps टूलबद्दल एकापेक्षा जास्त वेळा बोललो आहोत. werf, आणि यावेळी आम्ही प्रकल्पाच्या दस्तऐवजीकरणासह साइट एकत्र करण्याचा आमचा अनुभव सामायिक करू इच्छितो - werf.io (त्याची रशियन आवृत्ती आहे en.werf.io). ही एक सामान्य स्थिर साइट आहे, परंतु त्याची असेंब्ली मनोरंजक आहे कारण ती कलाकृतींच्या डायनॅमिक संख्येचा वापर करून तयार केली गेली आहे.

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

परिचय: साइट कशी कार्य करते

सुरुवातीला, werf दस्तऐवजीकरण त्याच्या कोडसह संग्रहित केले जाते. हे काही विकास आवश्यकता लादते जे सामान्यत: या लेखाच्या व्याप्तीच्या पलीकडे असतात, परंतु कमीतकमी असे म्हटले जाऊ शकते की:

नवीन werf फंक्शन्स दस्तऐवजीकरण अद्यतनित केल्याशिवाय सोडले जाऊ नयेत आणि त्याउलट, दस्तऐवजीकरणातील कोणतेही बदल werf च्या नवीन आवृत्तीचे प्रकाशन सूचित करतात;
प्रकल्पाचा बऱ्यापैकी गहन विकास आहे: नवीन आवृत्त्या दिवसातून अनेक वेळा सोडल्या जाऊ शकतात;
दस्तऐवजीकरणाच्या नवीन आवृत्तीसह साइट तैनात करण्यासाठी कोणतेही मॅन्युअल ऑपरेशन किमान कंटाळवाणे आहेत;
प्रकल्प एक अर्थपूर्ण दृष्टीकोन स्वीकारतो आवृत्ती तयार करणे, 5 स्थिरता चॅनेलसह. रिलीझ प्रक्रियेमध्ये स्थिरता वाढवण्याच्या क्रमाने चॅनेलद्वारे आवृत्त्यांचा अनुक्रमिक मार्ग समाविष्ट असतो: अल्फा ते रॉक-सोलिड;
साइटची रशियन-भाषेची आवृत्ती आहे, जी मुख्य (म्हणजे इंग्रजी-भाषा) आवृत्तीच्या समांतर "जगते आणि विकसित करते" (म्हणजे, त्यातील सामग्री अद्यतनित केली जाते).

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

वेबसाइटवरील आवृत्ती निवड मेनूमध्ये, प्रत्येक चॅनेलमध्ये werf च्या नवीनतम आवृत्त्या उपलब्ध आहेत. डिफॉल्टनुसार, पत्त्यानुसार werf.io/documentation नवीनतम रिलीझसाठी सर्वात स्थिर चॅनेलची आवृत्ती उघडते - ती शोध इंजिनद्वारे देखील अनुक्रमित केली जाते. चॅनेलसाठी दस्तऐवजीकरण स्वतंत्र पत्त्यांवर उपलब्ध आहे (उदाहरणार्थ, werf.io/v1.0-beta/documentation बीटा रिलीज 1.0 साठी).

एकूण, साइटवर खालील आवृत्त्या उपलब्ध आहेत:

रूट (डिफॉल्टनुसार उघडते),
प्रत्येक प्रकाशनाच्या प्रत्येक सक्रिय अद्यतन चॅनेलसाठी (उदाहरणार्थ, werf.io/v1.0-beta).

साइटची विशिष्ट आवृत्ती व्युत्पन्न करण्यासाठी, सर्वसाधारणपणे, ते वापरून संकलित करणे पुरेसे आहे जेकिलनिर्देशिकेत चालवून /docs werf रेपॉजिटरी संबंधित आदेश (jekyll build), आवश्यक आवृत्तीच्या Git टॅगवर स्विच केल्यानंतर.

हे फक्त जोडणे बाकी आहे:

युटिलिटी स्वतः (werf) असेंब्लीसाठी वापरली जाते;
CI/CD प्रक्रिया GitLab CI च्या आधारावर तयार केल्या जातात;
आणि हे सर्व अर्थातच कुबर्नेट्समध्ये चालते.

कार्ये

आता वर्णन केलेली सर्व वैशिष्ट्ये विचारात घेणारी कार्ये तयार करूया:

कोणत्याही अपडेट चॅनेलवर werf आवृत्ती बदलल्यानंतर साइटवरील दस्तऐवज स्वयंचलितपणे अद्यतनित केले जावे.
विकासासाठी तुम्हाला कधीकधी सक्षम असणे आवश्यक आहे साइटच्या पूर्वावलोकन आवृत्त्या पहा.

संबंधित गिट टॅग्जवरून कोणत्याही चॅनेलवरील आवृत्ती बदलल्यानंतर साइट पुन्हा संकलित करणे आवश्यक आहे, परंतु प्रतिमा तयार करण्याच्या प्रक्रियेत आम्हाला खालील वैशिष्ट्ये मिळतील:

चॅनेलवरील आवृत्त्यांची सूची बदलत असल्याने, आवृत्ती बदललेल्या चॅनेलसाठी कागदपत्रे पुन्हा तयार करणे आवश्यक आहे. शेवटी, सर्वकाही पुन्हा तयार करणे खूप छान नाही.
रिलीझसाठी चॅनेलचा संच बदलू शकतो. काही वेळेस, उदाहरणार्थ, चॅनेलवर लवकर-प्रवेश 1.1 रिलीझपेक्षा अधिक स्थिर आवृत्ती असू शकत नाही, परंतु कालांतराने ती दिसून येईल - या प्रकरणात, तुम्ही असेंब्ली व्यक्तिचलितपणे बदलू नये?

तो बाहेर वळते की असेंबली बाह्य डेटा बदलण्यावर अवलंबून असते.

अंमलबजावणी

एक दृष्टीकोन निवडणे

वैकल्पिकरित्या, तुम्ही प्रत्येक आवश्यक आवृत्ती Kubernetes मध्ये स्वतंत्र पॉड म्हणून चालवू शकता. हा पर्याय क्लस्टरमध्ये मोठ्या संख्येने ऑब्जेक्ट्स सूचित करतो, जे स्थिर वेर्फ रिलीझच्या संख्येत वाढ होईल. आणि हे, यामधून, अधिक जटिल देखभाल सूचित करते: प्रत्येक आवृत्तीचे स्वतःचे HTTP सर्व्हर असते आणि लहान लोडसह. अर्थात, यासाठी जास्त संसाधन खर्च देखील आवश्यक आहे.

आम्ही तोच मार्ग स्वीकारला एका प्रतिमेत सर्व आवश्यक आवृत्त्या एकत्र करणे. साइटच्या सर्व आवृत्त्यांचे संकलित स्टॅटिक्स NGINX सह कंटेनरमध्ये स्थित आहेत आणि संबंधित तैनातीकडे रहदारी NGINX इंग्रेसद्वारे येते. एक साधी रचना - एक स्टेटलेस ऍप्लिकेशन - तुम्हाला कुबर्नेट्सचा वापर करून डिप्लॉयमेंट (लोडवर अवलंबून) सहजपणे स्केल करण्यास अनुमती देते.

अधिक अचूक होण्यासाठी, आम्ही दोन प्रतिमा गोळा करत आहोत: एक उत्पादन सर्किटसाठी, दुसरी डेव्ह सर्किटसाठी अतिरिक्त आहे. अतिरिक्त प्रतिमा मुख्यसह केवळ डेव्ह सर्किटवर वापरली जाते (लाँच केलेली) आणि पुनरावलोकन कमिटमधील साइटची आवृत्ती समाविष्ट करते आणि त्या दरम्यान राउटिंग इनग्रेस संसाधने वापरून केले जाते.

werf vs git क्लोन आणि कलाकृती

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

येथे werf उपयुक्तता स्वतःच आमच्या मदतीला येते, अंमलबजावणी करते स्मार्ट कॅशिंग आणि तुम्हाला वापरण्याची परवानगी देतो बाह्य भांडार. रेपॉजिटरीमधून कोड जोडण्यासाठी werf वापरल्याने बिल्डला लक्षणीय गती मिळेल, कारण werf मूलत: एकदा रेपॉजिटरी क्लोन करते आणि नंतर कार्यान्वित करते फक्त fetch आवश्यक असल्यास. याव्यतिरिक्त, रेपॉजिटरीमधून डेटा जोडताना, आम्ही फक्त आवश्यक निर्देशिका निवडू शकतो (आमच्या बाबतीत ही निर्देशिका आहे docs), जे जोडलेल्या डेटाचे प्रमाण लक्षणीयरीत्या कमी करेल.

जेकिल हे स्टॅटिक डेटा संकलित करण्यासाठी डिझाइन केलेले एक साधन असल्याने आणि अंतिम प्रतिमेमध्ये त्याची आवश्यकता नसल्यामुळे, संकलित करणे तर्कसंगत असेल. werf कलाकृती, आणि अंतिम प्रतिमेमध्ये फक्त संकलन परिणाम आयात करा.

आम्ही werf.yaml लिहितो

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

werf तुम्हाला वापरण्याची परवानगी देते जा टेम्पलेट्स तुमच्या कॉन्फिगरेशन फाइलमध्ये (werf.yaml), आणि हे शक्य करते फ्लाय वर कॉन्फिगरेशन व्युत्पन्न करा बाह्य डेटावर अवलंबून (आपल्याला काय हवे आहे!). आमच्या बाबतीत बाह्य डेटा म्हणजे आवृत्त्या आणि प्रकाशनांबद्दलची माहिती, ज्याच्या आधारावर आम्ही आवश्यक संख्येने कलाकृती गोळा करतो आणि परिणामी आम्हाला दोन प्रतिमा मिळतात: werf-doc и werf-dev वेगवेगळ्या सर्किट्सवर चालण्यासाठी.

बाह्य डेटा पर्यावरण व्हेरिएबल्सद्वारे पास केला जातो. येथे त्यांची रचना आहे:

RELEASES - रिलीझची सूची आणि werf च्या संबंधित वर्तमान आवृत्तीसह एक ओळ, फॉरमॅटमधील मूल्यांच्या स्पेस-विभक्त सूचीच्या स्वरूपात <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. उदाहरणः 1.0%v1.0.4-beta.20
CHANNELS — चॅनेलची सूची आणि werf ची संबंधित वर्तमान आवृत्ती असलेली एक ओळ, फॉरमॅटमधील मूल्यांच्या स्पेस-विभक्त सूचीच्या स्वरूपात <КАНАЛ>%<НОМЕР_ВЕРСИИ>. उदाहरणः 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — साइटवर डीफॉल्टनुसार प्रदर्शित करण्यासाठी werf रिलीझ आवृत्ती (सर्वोच्च प्रकाशन क्रमांकाद्वारे दस्तऐवजीकरण प्रदर्शित करणे नेहमीच आवश्यक नसते). उदाहरण: v1.0.4-beta.20
REVIEW_SHA — पुनरावलोकन कमिटचा हॅश ज्यामधून तुम्हाला चाचणी लूपसाठी आवृत्ती तयार करायची आहे.

हे व्हेरिएबल्स GitLab CI पाइपलाइनमध्ये भरले जातील आणि खाली नेमके कसे लिहिले आहे.

सर्व प्रथम, सोयीसाठी, आम्ही परिभाषित करतो werf.yaml टेम्प्लेट व्हेरिएबल्सवर जा, त्यांना पर्यावरण व्हेरिएबल्समधून मूल्ये नियुक्त करा:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

साइटची स्थिर आवृत्ती संकलित करण्यासाठी आर्टिफॅक्टचे वर्णन सामान्यत: आम्हाला आवश्यक असलेल्या सर्व प्रकरणांसाठी समान असते (मूळ आवृत्ती तयार करणे, तसेच डेव्ह सर्किटसाठी आवृत्तीसह). म्हणून, फंक्शन वापरून आम्ही ते वेगळ्या ब्लॉकमध्ये हलवू define - त्यानंतरच्या वापरासाठी include. आम्ही खालील युक्तिवाद टेम्पलेटमध्ये पास करू:

Version — व्युत्पन्न आवृत्ती (टॅग नाव);
Channel — अद्ययावत चॅनेलचे नाव ज्यासाठी आर्टिफॅक्ट व्युत्पन्न केले आहे;
Commit — कमिट हॅश, जर आर्टिफॅक्ट पुनरावलोकन कमिटसाठी व्युत्पन्न केले असेल;
संदर्भ

आर्टिफॅक्ट टेम्पलेट वर्णन

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

कलाकृतीचे नाव अद्वितीय असणे आवश्यक आहे. आम्ही हे साध्य करू शकतो, उदाहरणार्थ, चॅनेलचे नाव जोडून (व्हेरिएबलचे मूल्य .Channel) आर्टिफॅक्टच्या नावाचा प्रत्यय म्हणून: artifact: doc-{{ .Channel }}. परंतु आपल्याला हे समजून घेणे आवश्यक आहे की कलाकृतींमधून आयात करताना, आपल्याला समान नावांचा संदर्भ घ्यावा लागेल.

आर्टिफॅक्टचे वर्णन करताना, खालील वेर्फ वैशिष्ट्य वापरले जाते: आरोहित. सेवा निर्देशिका दर्शविणारे माउंटिंग build_dir तुम्हाला जेकिल कॅशे पाइपलाइन रन दरम्यान जतन करण्यास अनुमती देते, जे पुनर्संचयित करण्यासाठी लक्षणीय गती वाढते.

फाईलचा वापरही तुमच्या लक्षात आला असेल releases.yml रिलीझ डेटाची विनंती केलेली YAML फाइल आहे Github.com (पाइपलाइन कार्यान्वित करताना प्राप्त केलेली कलाकृती). साइट संकलित करताना हे आवश्यक आहे, परंतु लेखाच्या संदर्भात ते आमच्यासाठी मनोरंजक आहे कारण ते त्याच्या स्थितीवर अवलंबून आहे फक्त एका कलाकृतीचे पुन्हा एकत्रीकरण — साइटच्या मूळ आवृत्तीची कलाकृती (इतर कलाकृतींमध्ये त्याची आवश्यकता नाही).

हे सशर्त विधान वापरून लागू केले जाते if टेम्पलेट्स आणि डिझाईन्स जा {{ $Root.Files.Get "releases.yml" | sha256sum }} टप्प्यात टप्पे. हे खालीलप्रमाणे कार्य करते: रूट आवृत्तीसाठी आर्टिफॅक्ट तयार करताना (व्हेरिएबल .Channel च्या समान root) फाइल हॅश releases.yml संपूर्ण स्टेजच्या स्वाक्षरीवर परिणाम करते, कारण ते उत्तरदायी कार्याच्या नावाचा भाग आहे (पॅरामीटर name). अशा प्रकारे, बदलताना सामग्री फाइल releases.yml संबंधित कलाकृती पुन्हा एकत्र केली जाईल.

कृपया बाह्य रेपॉजिटरीसह कार्य करण्याकडे देखील लक्ष द्या. पासून एक कलाकृती च्या प्रतिमेत werf भांडार, फक्त निर्देशिका जोडली आहे /docs, आणि पास केलेल्या पॅरामीटर्सवर अवलंबून, आवश्यक टॅग किंवा पुनरावलोकन कमिटचा डेटा त्वरित जोडला जातो.

चॅनेल आणि रिलीझच्या हस्तांतरित आवृत्त्यांच्या आर्टिफॅक्टचे वर्णन तयार करण्यासाठी आर्टिफॅक्ट टेम्पलेट वापरण्यासाठी, आम्ही व्हेरिएबलवर एक लूप आयोजित करतो .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

कारण लूप अनेक कलाकृती तयार करेल (आम्ही अशी आशा करतो), त्यांच्यामधील विभाजक लक्षात घेणे आवश्यक आहे - अनुक्रम --- (कॉन्फिगरेशन फाइल सिंटॅक्सबद्दल अधिक माहितीसाठी, पहा दस्तऐवजीकरण). आधी परिभाषित केल्याप्रमाणे, लूपमध्ये टेम्पलेट कॉल करताना, आम्ही आवृत्ती पॅरामीटर्स, URL आणि रूट संदर्भ पास करतो.

त्याचप्रमाणे, परंतु लूपशिवाय, आम्ही "विशेष प्रकरणांसाठी" आर्टिफॅक्ट टेम्पलेट म्हणतो: रूट आवृत्तीसाठी, तसेच पुनरावलोकन वचनबद्धतेची आवृत्ती:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

कृपया लक्षात घ्या की पुनरावलोकन कमिटसाठी आर्टिफॅक्ट व्हेरिएबल सेट केले असल्यासच तयार केले जाईल .WerfReviewCommit.

कलाकृती तयार आहेत - आयात सुरू करण्याची वेळ आली आहे!

अंतिम प्रतिमा, Kubernetes वर चालवण्यासाठी डिझाइन केलेली, सर्व्हर कॉन्फिगरेशन फाइल जोडलेली एक नियमित NGINX आहे nginx.conf आणि कलाकृतींमधून स्थिर. साइटच्या मूळ आवृत्तीच्या आर्टिफॅक्ट व्यतिरिक्त, आम्हाला व्हेरिएबलवरील लूप पुन्हा करणे आवश्यक आहे .WerfVersions चॅनेलच्या आर्टिफॅक्ट्स इंपोर्ट करण्यासाठी आणि आवृत्त्या रिलीझ करण्यासाठी + आम्ही आधी स्वीकारलेल्या आर्टिफॅक्ट नेमिंग नियमाचे अनुसरण करा. प्रत्येक आर्टिफॅक्ट दोन भाषांसाठी साइटच्या आवृत्त्या संग्रहित करत असल्याने, आम्ही त्यांना कॉन्फिगरेशनद्वारे प्रदान केलेल्या ठिकाणी आयात करतो.

अंतिम प्रतिमेचे वर्णन werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

अतिरिक्त प्रतिमा, जी मुख्य चित्रासह, डेव्ह सर्किटवर लॉन्च केली गेली आहे, त्यामध्ये साइटच्या फक्त दोन आवृत्त्या आहेत: पुनरावलोकन कमिटमधील आवृत्ती आणि साइटची मूळ आवृत्ती (सामान्य मालमत्ता आहेत आणि, तुम्हाला आठवत असल्यास , डेटा रिलीज करा). अशा प्रकारे, अतिरिक्त प्रतिमा केवळ आयात विभागात (आणि अर्थातच नावात) मुख्य प्रतिमापेक्षा भिन्न असेल:

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

वर नमूद केल्याप्रमाणे, रिव्ह्यू कमिटसाठी आर्टिफॅक्ट तेव्हाच तयार केले जाईल जेव्हा सेट एन्व्हायर्नमेंट व्हेरिएबल चालवले जाईल REVIEW_SHA. जर वातावरणीय व्हेरिएबल नसेल तर werf-dev प्रतिमा अजिबात तयार न करणे शक्य होईल REVIEW_SHA, पण क्रमाने धोरणांद्वारे स्वच्छता werf मधील डॉकर प्रतिमांनी werf-dev प्रतिमेसाठी काम केले आहे, पाइपलाइन संरचना सुलभ करण्यासाठी आम्ही ती केवळ मूळ आवृत्तीच्या आर्टिफॅक्टसह (ते आधीच तयार केली आहे) तयार करण्यासाठी सोडू.

विधानसभा तयार आहे! चला CI/CD आणि महत्त्वाच्या बारकावे कडे वळू.

GitLab CI मधील पाइपलाइन आणि डायनॅमिक बिल्डची वैशिष्ट्ये

बिल्ड चालवताना आपल्याला त्यात वापरलेले पर्यावरण व्हेरिएबल्स सेट करावे लागतील werf.yaml. हे REVIEW_SHA व्हेरिएबलवर लागू होत नाही, जे आम्ही GitHub हुकवरून पाइपलाइन कॉल करताना सेट करू.

आम्ही बॅश स्क्रिप्टमध्ये आवश्यक बाह्य डेटा तयार करू generate_artifacts, जे दोन GitLab पाइपलाइन आर्टिफॅक्ट्स व्युत्पन्न करेल:

файл releases.yml प्रकाशन डेटासह,
файл common_envs.sh, निर्यात करण्यासाठी पर्यावरण चल समाविष्टीत.

फाइल सामग्री generate_artifacts तुम्हाला आमच्या मध्ये सापडेल उदाहरणांसह भांडार. डेटा स्वतः प्राप्त करणे हा लेखाचा विषय नसून फाइल आहे common_envs.sh आमच्यासाठी महत्वाचे आहे, कारण werf चे काम त्यावर अवलंबून आहे. त्याच्या सामग्रीचे उदाहरणः

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

तुम्ही अशा स्क्रिप्टचे आउटपुट वापरू शकता, उदाहरणार्थ, बॅश फंक्शन वापरून source.

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

दुसऱ्या शब्दांत, जर साइटच्या प्रतिमेच्या असेंब्ली दरम्यान रिलीझ आणि आवृत्त्यांबद्दल माहिती समान असेल आणि उपयोजनाच्या वेळी नवीन आवृत्ती रिलीझ केली गेली असेल आणि पर्यावरण व्हेरिएबल्सची मूल्ये भिन्न असतील, तर तैनाती त्रुटीसह अयशस्वी होईल: तथापि, नवीन आवृत्तीची कलाकृती अद्याप तयार केलेली नाही.

जर पिढी werf.yaml बाह्य डेटावर अवलंबून असते (उदाहरणार्थ, वर्तमान आवृत्त्यांची सूची, आमच्या बाबतीत), नंतर अशा डेटाची रचना आणि मूल्ये पाइपलाइनमध्ये रेकॉर्ड केली जावीत. बाह्य पॅरामीटर्स बर्याचदा बदलत असल्यास हे विशेषतः महत्वाचे आहे.

आम्ही करू बाह्य डेटा प्राप्त आणि रेकॉर्ड करा GitLab मधील पाइपलाइनच्या पहिल्या टप्प्यावर (पूर्वनिर्मित) आणि त्यांना फॉर्ममध्ये पुढे पाठवा GitLab CI आर्टिफॅक्ट. हे तुम्हाला त्याच कॉन्फिगरेशनसह पाइपलाइन जॉब्स (बांधणे, तैनात करणे, साफ करणे) चालवण्यास आणि रीस्टार्ट करण्यास अनुमती देईल werf.yaml.

स्टेजची सामग्री पूर्वनिर्मित फाइल .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

आर्टिफॅक्टमधील बाह्य डेटा कॅप्चर केल्यावर, तुम्ही मानक GitLab CI पाइपलाइन टप्पे वापरून तयार आणि तैनात करू शकता: तयार करा आणि तैनात करा. आम्ही werf GitHub रेपॉजिटरी (म्हणजे जेव्हा GitHub रेपॉजिटरीमध्ये बदल होतात तेव्हा) हुक वापरून पाइपलाइन स्वतः लाँच करतो. विभागातील GitLab प्रकल्प गुणधर्मांमध्ये त्यांच्यासाठी डेटा आढळू शकतो CI/CD सेटिंग्ज -> पाइपलाइन ट्रिगर, आणि नंतर GitHub मध्ये संबंधित वेबहुक तयार करा (सेटिंग्ज -> वेबहुक).

बिल्ड स्टेज असे दिसेल:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab स्टेजपासून बिल्ड स्टेजवर दोन कलाकृती जोडेल पूर्वनिर्मित, म्हणून आम्ही कन्स्ट्रक्ट वापरून तयार इनपुट डेटासह व्हेरिएबल्स एक्सपोर्ट करतो source common_envs.sh. शेड्यूलनुसार पाइपलाइन लाँच करण्याशिवाय आम्ही सर्व प्रकरणांमध्ये बिल्ड स्टेज सुरू करतो. वेळापत्रकानुसार, आम्ही साफसफाईसाठी पाइपलाइन चालवू - या प्रकरणात असेंब्ली करण्याची आवश्यकता नाही.

उपयोजन टप्प्यावर, आम्ही दोन कार्यांचे वर्णन करू - YAML टेम्पलेट वापरून उत्पादन आणि डेव्ह सर्किट्सच्या तैनातीसाठी स्वतंत्रपणे:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

कार्ये मूलत: केवळ क्लस्टर संदर्भ दर्शविण्यामध्ये भिन्न असतात ज्यामध्ये werf ने तैनाती करावी (WERF_KUBE_CONTEXT), आणि लूप पर्यावरण व्हेरिएबल्स सेट करणे (environment.name и environment.url), जे नंतर हेल्म चार्ट टेम्प्लेटमध्ये वापरले जातात. आम्ही टेम्पलेट्सची सामग्री प्रदान करणार नाही, कारण... प्रश्नातील विषयासाठी तेथे काहीही मनोरंजक नाही, परंतु आपण ते शोधू शकता लेखासाठी भांडार.

अंतिम स्पर्श

werf आवृत्त्या बऱ्याचदा रिलीझ केल्या जात असल्याने, नवीन प्रतिमा वारंवार तयार केल्या जातील आणि डॉकर रेजिस्ट्री सतत वाढत जाईल. म्हणून, धोरणांच्या आधारे स्वयंचलित प्रतिमा क्लीनअप कॉन्फिगर करणे अत्यावश्यक आहे. हे करणे खूप सोपे आहे.

अंमलबजावणी करण्यासाठी आपल्याला आवश्यक असेलः

मध्ये साफसफाईची पायरी जोडा .gitlab-ci.yml;
स्वच्छता कार्याची नियतकालिक अंमलबजावणी जोडा;
लेखन प्रवेश टोकनसह पर्यावरण व्हेरिएबल सेट करा.

मध्ये स्वच्छता स्टेज जोडणे .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

आम्ही जवळजवळ हे सर्व थोडे वर पाहिले आहे - फक्त ते साफ करण्यासाठी तुम्हाला प्रथम डॉकर रेजिस्ट्रीमध्ये डॉकर रेजिस्ट्रीमधील प्रतिमा हटविण्याचे अधिकार असलेल्या टोकनसह लॉग इन करणे आवश्यक आहे (स्वयंचलितपणे जारी केलेले GitLab CI टास्क टोकन असे करत नाही. असे अधिकार आहेत). टोकन आगाऊ GitLab मध्ये तयार केले जाणे आवश्यक आहे आणि त्याचे मूल्य पर्यावरण व्हेरिएबलमध्ये निर्दिष्ट करणे आवश्यक आहे WERF_IMAGES_CLEANUP_PASSWORD प्रकल्प (CI/CD सेटिंग्ज -> व्हेरिएबल्स).

आवश्यक वेळापत्रकासह साफसफाईचे कार्य जोडणे मध्ये केले जाते CI/CD ->
वेळापत्रक.

तेच आहे: डॉकर रेजिस्ट्रीमधील प्रकल्प यापुढे न वापरलेल्या प्रतिमांमधून सतत वाढणार नाही.

व्यावहारिक भागाच्या शेवटी, मी तुम्हाला आठवण करून देतो की लेखातील संपूर्ण सूची उपलब्ध आहेत Git:

परिणाम

आम्हाला तार्किक असेंबली रचना प्राप्त झाली: प्रति आवृत्ती एक कलाकृती.
असेंब्ली सार्वत्रिक आहे आणि जेव्हा werf च्या नवीन आवृत्त्या रिलीझ केल्या जातात तेव्हा मॅन्युअल बदलांची आवश्यकता नसते: वेबसाइटवरील दस्तऐवजीकरण स्वयंचलितपणे अद्यतनित केले जाते.
वेगवेगळ्या आकृतिबंधांसाठी दोन प्रतिमा एकत्र केल्या जातात.
हे त्वरीत कार्य करते, कारण कॅशिंग शक्य तितके वापरले जाते - जेव्हा werf ची नवीन आवृत्ती रिलीझ केली जाते किंवा GitHub हुकला पुनरावलोकन कमिटसाठी कॉल केले जाते, तेव्हा केवळ बदललेल्या आवृत्तीसह संबंधित कलाकृती पुन्हा तयार केली जाते.
न वापरलेल्या प्रतिमा हटविण्याबद्दल विचार करण्याची गरज नाही: werf धोरणांनुसार साफसफाई केल्याने डॉकर रजिस्ट्री व्यवस्थित राहील.

निष्कर्ष

werf वापरल्याने असेंबली स्वतःच कॅशिंग आणि बाह्य रेपॉजिटरीसह कार्य करताना कॅशिंगमुळे असेंब्लीला त्वरीत कार्य करण्यास अनुमती देते.
बाह्य Git रेपॉजिटरीसह कार्य केल्याने प्रत्येक वेळी संपूर्ण रेपॉजिटरी क्लोन करण्याची किंवा अवघड ऑप्टिमायझेशन लॉजिकसह चाक पुन्हा शोधण्याची गरज नाहीशी होते. werf कॅशे वापरतो आणि क्लोनिंग फक्त एकदाच करतो आणि नंतर वापरतो fetch आणि जेव्हा आवश्यक असेल तेव्हाच.
बिल्ड कॉन्फिगरेशन फाइलमध्ये गो टेम्पलेट्स वापरण्याची क्षमता werf.yaml ज्याचा परिणाम बाह्य डेटावर अवलंबून असतो अशा असेंब्लीचे वर्णन करण्यास आपल्याला अनुमती देते.
माउंट इन वेर्फ वापरल्याने कलाकृतींच्या संकलनास लक्षणीय गती मिळते - कॅशेमुळे, जे सर्व पाइपलाइनसाठी सामान्य आहे.
werf क्लीनअप कॉन्फिगर करणे सोपे करते, जे डायनॅमिकली बिल्डिंग करताना विशेषतः महत्वाचे आहे.