🥇एक संस्करणित दस्तावेज़ीकरण साइट के उदाहरण का उपयोग करके वेयरफ़ के साथ डॉकर छवियों की गतिशील असेंबली और तैनाती

हम पहले ही अपने GitOps टूल के बारे में एक से अधिक बार बात कर चुके हैं। Werf, और इस बार हम प्रोजेक्ट के दस्तावेज़ीकरण के साथ साइट को असेंबल करने में अपना अनुभव साझा करना चाहेंगे - werf.io (इसका रूसी संस्करण है en.werf.io). यह एक सामान्य स्थैतिक साइट है, लेकिन इसकी असेंबली दिलचस्प है क्योंकि इसे गतिशील संख्या में कलाकृतियों का उपयोग करके बनाया गया है।

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

परिचय: साइट कैसे काम करती है

आरंभ करने के लिए, वेयरफ़ दस्तावेज़ को उसके कोड के साथ संग्रहीत किया जाता है। यह कुछ विकास आवश्यकताओं को लागू करता है जो आम तौर पर इस लेख के दायरे से परे हैं, लेकिन कम से कम यह कहा जा सकता है कि:

दस्तावेज़ीकरण को अद्यतन किए बिना नए वेयरफ़ फ़ंक्शंस जारी नहीं किए जाने चाहिए और, इसके विपरीत, दस्तावेज़ीकरण में कोई भी परिवर्तन वेयरफ़ के नए संस्करण की रिलीज़ का संकेत देता है;
परियोजना का काफी गहन विकास हुआ है: नए संस्करण दिन में कई बार जारी किए जा सकते हैं;
दस्तावेज़ीकरण के नए संस्करण के साथ किसी साइट को तैनात करने के लिए कोई भी मैन्युअल संचालन कम से कम कठिन है;
परियोजना एक अर्थपूर्ण दृष्टिकोण अपनाती है वर्ज़निंग, 5 स्थिरता चैनलों के साथ। रिलीज़ प्रक्रिया में स्थिरता बढ़ाने के क्रम में चैनलों के माध्यम से संस्करणों का क्रमिक मार्ग शामिल है: अल्फा से रॉक-सॉलिड तक;
साइट में एक रूसी-भाषा संस्करण है, जो मुख्य (यानी, अंग्रेजी-भाषा) संस्करण के समानांतर "जीवित और विकसित होता है" (यानी, जिसकी सामग्री अद्यतन की जाती है)।

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

वेबसाइट पर संस्करण चयन मेनू में, प्रत्येक चैनल में वेयरफ़ के नवीनतम संस्करण उपलब्ध हैं। डिफ़ॉल्ट रूप से, पते से werf.io/documentation नवीनतम रिलीज़ के लिए सबसे स्थिर चैनल का संस्करण खुलता है - इसे खोज इंजन द्वारा भी अनुक्रमित किया जाता है। चैनल के लिए दस्तावेज़ीकरण अलग-अलग पते पर उपलब्ध है (उदाहरण के लिए, werf.io/v1.0-beta/documentation बीटा रिलीज़ 1.0 के लिए)।

कुल मिलाकर, साइट पर निम्नलिखित संस्करण उपलब्ध हैं:

रूट (डिफ़ॉल्ट रूप से खुलता है),
प्रत्येक रिलीज़ के प्रत्येक सक्रिय अद्यतन चैनल के लिए (उदाहरण के लिए, werf.io/v1.0-बीटा).

किसी साइट का एक विशिष्ट संस्करण तैयार करने के लिए, सामान्य तौर पर, इसका उपयोग करके इसे संकलित करना ही पर्याप्त है Jekyllनिर्देशिका में चलाकर /docs वेयरफ़ रिपॉजिटरी संबंधित कमांड (jekyll build), आवश्यक संस्करण के Git टैग पर स्विच करने के बाद।

केवल यह जोड़ना बाकी है:

उपयोगिता स्वयं (वेर्फ़) का उपयोग असेंबली के लिए किया जाता है;
CI/CD प्रक्रियाएँ GitLab CI के आधार पर बनाई गई हैं;
और यह सब, निस्संदेह, कुबेरनेट्स में चलता है।

कार्य

आइए अब उन कार्यों को तैयार करें जो वर्णित सभी विशिष्टताओं को ध्यान में रखते हैं:

किसी भी अद्यतन चैनल पर वेयरफ़ संस्करण बदलने के बाद साइट पर दस्तावेज़ीकरण स्वचालित रूप से अद्यतन किया जाना चाहिए.
विकास के लिए आपको कभी-कभी सक्षम होने की आवश्यकता होती है साइट के पूर्वावलोकन संस्करण देखें.

संबंधित Git टैग से किसी भी चैनल पर संस्करण बदलने के बाद साइट को पुन: संकलित किया जाना चाहिए, लेकिन छवि निर्माण की प्रक्रिया में हमें निम्नलिखित विशेषताएं मिलेंगी:

चूंकि चैनलों पर संस्करणों की सूची बदल जाती है, इसलिए केवल उन चैनलों के लिए दस्तावेज़ का पुनर्निर्माण करना आवश्यक है जहां संस्करण बदल गया है। आख़िरकार, हर चीज़ को दोबारा बनाना बहुत अच्छा नहीं है।
रिलीज़ के लिए चैनलों का सेट बदल सकता है। किसी समय, उदाहरण के लिए, चैनलों पर अर्ली-एक्सेस 1.1 रिलीज़ से अधिक स्थिर कोई संस्करण नहीं हो सकता है, लेकिन समय के साथ वे दिखाई देंगे - इस मामले में, क्या आपको असेंबली को मैन्युअल रूप से नहीं बदलना चाहिए?

यह पता चला है कि असेंबली बाहरी डेटा बदलने पर निर्भर करती है.

कार्यान्वयन

एक दृष्टिकोण चुनना

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

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

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

वेयरफ़ बनाम गिट क्लोन और कलाकृतियाँ

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

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

चूँकि जेकिल एक उपकरण है जो स्थैतिक डेटा को संकलित करने के लिए डिज़ाइन किया गया है और अंतिम छवि में इसकी आवश्यकता नहीं है, इसलिए इसे संकलित करना तर्कसंगत होगा वेयरफ़ कलाकृति, और अंतिम छवि में केवल संकलन परिणाम आयात करें.

हम werf.yaml लिखते हैं

इसलिए, हमने निर्णय लिया कि हम प्रत्येक संस्करण को एक अलग वेयरफ़ आर्टिफैक्ट में संकलित करेंगे। हालांकि, हम हम नहीं जानते कि संयोजन के दौरान इनमें से कितनी कलाकृतियाँ होंगी, इसलिए हम एक निश्चित बिल्ड कॉन्फ़िगरेशन नहीं लिख सकते (सख्ती से कहें तो, हम अभी भी कर सकते हैं, लेकिन यह पूरी तरह से प्रभावी नहीं होगा)।

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

बाहरी डेटा को पर्यावरण चर के माध्यम से पारित किया जाता है। यहाँ उनकी रचना है:

RELEASES - रिलीज़ की सूची और वेयरफ़ के संबंधित वर्तमान संस्करण के साथ एक पंक्ति, प्रारूप में मानों की एक स्थान-पृथक सूची के रूप में <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. उदाहरण: 1.0%v1.0.4-beta.20
CHANNELS - चैनलों की सूची और वेयरफ़ के संबंधित वर्तमान संस्करण के साथ एक पंक्ति, प्रारूप में मानों की एक स्थान-पृथक सूची के रूप में <КАНАЛ>%<НОМЕР_ВЕРСИИ>. उदाहरण: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION - वेयरफ़ रिलीज़ संस्करण को साइट पर डिफ़ॉल्ट रूप से प्रदर्शित किया जाना चाहिए (उच्चतम रिलीज़ संख्या द्वारा दस्तावेज़ प्रदर्शित करना हमेशा आवश्यक नहीं होता है)। उदाहरण: 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 पूरे चरण के हस्ताक्षर को प्रभावित करता है, क्योंकि यह Ansible कार्य (पैरामीटर) के नाम का हिस्सा है name). इस प्रकार, बदलते समय सामग्री फ़ाइल releases.yml संबंधित आर्टिफैक्ट को फिर से जोड़ा जाएगा।

कृपया बाहरी भंडार के साथ काम करने पर भी ध्यान दें। से एक कलाकृति की छवि में वेयरफ़ भंडार, केवल निर्देशिका जोड़ी गई है /docs, और पारित मापदंडों के आधार पर, आवश्यक टैग या समीक्षा समिति का डेटा तुरंत जोड़ा जाता है।

चैनलों और रिलीज़ के स्थानांतरित संस्करणों के आर्टिफैक्ट का विवरण उत्पन्न करने के लिए आर्टिफैक्ट टेम्पलेट का उपयोग करने के लिए, हम वेरिएबल पर एक लूप व्यवस्थित करते हैं .WerfVersions в werf.yaml:

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

क्योंकि लूप कई कलाकृतियाँ उत्पन्न करेगा (हमें ऐसी आशा है), उनके बीच विभाजक को ध्यान में रखना आवश्यक है - अनुक्रम --- (कॉन्फ़िगरेशन फ़ाइल सिंटैक्स पर अधिक जानकारी के लिए, देखें प्रलेखन). जैसा कि पहले परिभाषित किया गया है, लूप में टेम्पलेट को कॉल करते समय, हम संस्करण पैरामीटर, यूआरएल और रूट संदर्भ पास करते हैं।

इसी तरह, लेकिन लूप के बिना, हम "विशेष मामलों" के लिए आर्टिफैक्ट टेम्पलेट को कॉल करते हैं: रूट संस्करण के लिए, साथ ही समीक्षा प्रतिबद्धता से संस्करण के लिए:

{{ 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.

कलाकृतियाँ तैयार हैं - आयात शुरू करने का समय आ गया है!

अंतिम छवि, जिसे कुबेरनेट्स पर चलाने के लिए डिज़ाइन किया गया है, एक नियमित एनजीआईएनएक्स है जिसमें एक सर्वर कॉन्फ़िगरेशन फ़ाइल जोड़ी गई है nginx.conf और कलाकृतियों से स्थिर. साइट के रूट संस्करण की कलाकृतियों के अलावा, हमें वेरिएबल पर लूप को दोहराने की आवश्यकता है .WerfVersions चैनल और रिलीज़ संस्करणों की कलाकृतियों को आयात करने के लिए + कलाकृतियों के नामकरण नियम का पालन करें जिसे हमने पहले अपनाया था। चूँकि प्रत्येक आर्टिफैक्ट दो भाषाओं के लिए साइट के संस्करणों को संग्रहीत करता है, हम उन्हें कॉन्फ़िगरेशन द्वारा प्रदान किए गए स्थानों में आयात करते हैं।

अंतिम छवि वेयरफ़-डॉक का विवरण

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. यदि कोई पर्यावरण चर नहीं है तो वेयरफ़-डेव छवि उत्पन्न करना संभव नहीं होगा REVIEW_SHA, लेकिन करने के लिए नीतियों द्वारा सफाई वेयरफ़ में डॉकर छवियां वेयरफ़-डेव छवि के लिए काम करती हैं, हम पाइपलाइन संरचना को सरल बनाने के लिए इसे केवल रूट संस्करण आर्टिफैक्ट (यह वैसे भी पहले से ही बनाया गया है) के साथ बनाने के लिए छोड़ देंगे।

असेंबली तैयार है! आइए सीआई/सीडी और महत्वपूर्ण बारीकियों पर चलते हैं।

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 सीआई विरूपण साक्ष्य. यह आपको समान कॉन्फ़िगरेशन के साथ पाइपलाइन नौकरियों (निर्माण, तैनाती, सफाई) को चलाने और पुनः आरंभ करने की अनुमति देगा 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 पाइपलाइन चरणों का उपयोग करके निर्माण और तैनाती कर सकते हैं: बिल्ड और तैनाती। हम वेयरफ़ GitHub रिपॉजिटरी से हुक का उपयोग करके पाइपलाइन स्वयं लॉन्च करते हैं (यानी, जब GitHub रिपॉजिटरी में परिवर्तन होते हैं)। उनके लिए डेटा अनुभाग में GitLab प्रोजेक्ट गुणों में पाया जा सकता है सीआई/सीडी सेटिंग्स -> पाइपलाइन ट्रिगर्स, और फिर 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_KUBE_CONTEXT), और लूप पर्यावरण चर सेट करना (environment.name и environment.url), जिनका उपयोग हेल्म चार्ट टेम्पलेट्स में किया जाता है। हम टेम्प्लेट की सामग्री प्रदान नहीं करेंगे, क्योंकि... प्रश्नगत विषय के लिए वहां कुछ भी दिलचस्प नहीं है, लेकिन आप उन्हें इसमें पा सकते हैं लेख के लिए भंडार.

अंतिम परिष्करण

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

कार्यान्वयन के लिए आपको आवश्यकता होगी:

इसमें एक सफ़ाई चरण जोड़ें .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 परियोजना (सीआई/सीडी सेटिंग्स -> वेरिएबल्स).

आवश्यक शेड्यूल के साथ सफाई कार्य को जोड़ना इसमें किया जाता है सीआई/सीडी ->
अनुसूचियों.

बस इतना ही: डॉकर रजिस्ट्री में एक प्रोजेक्ट अब लगातार अप्रयुक्त छवियों से विकसित नहीं होगा।

व्यावहारिक भाग के अंत में, मैं आपको याद दिला दूं कि लेख की पूरी सूची यहां उपलब्ध है जाना:

परिणाम

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

निष्कर्ष

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

पुनश्च

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

स्रोत: www.habr.com

एक संस्करणित दस्तावेज़ीकरण साइट के उदाहरण का उपयोग करके वेयरफ़ के साथ डॉकर छवियों की गतिशील असेंबली और तैनाती