🥇 संस्करणित कागजात साइटको उदाहरण प्रयोग गरेर werf सँग डकर छविहरूको गतिशील संयोजन र तैनाती

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

हामी साइट संरचनाको सूक्ष्मताहरूमा जाने छैनौं: सबै संस्करणहरूको लागि साझा मेनु उत्पन्न गर्ने, रिलीजहरूको बारेमा जानकारी भएको पृष्ठ, आदि। बरु, हामी गतिशील एसेम्बलीका मुद्दाहरू र सुविधाहरूमा ध्यान केन्द्रित गर्नेछौं र साथमा CI/CD प्रक्रियाहरूमा थोरै ध्यान केन्द्रित गर्नेछौं।

परिचय: साइट कसरी काम गर्छ

सुरुमा, werf कागजातहरू यसको कोडसँगै भण्डारण गरिएको छ भन्ने तथ्यबाट सुरु गरौं। यसले विकासमा केही आवश्यकताहरू लागू गर्दछ, जुन सामान्यतया यस लेखको दायराभन्दा बाहिर छन्, तर कम्तिमा हामी भन्न सक्छौं कि:

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

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

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

कुल मिलाएर, साइटमा निम्न संस्करणहरू उपलब्ध छन्:

रूट (पूर्वनिर्धारित रूपमा खुल्छ),
प्रत्येक रिलीजको प्रत्येक सक्रिय अपडेट च्यानलको लागि (जस्तै werf.io/v1.0-बीटा).

साइटको विशिष्ट संस्करण उत्पन्न गर्न, सामान्यतया, यसलाई प्रयोग गरेर कम्पाइल गर्न पर्याप्त हुन्छ Jekyll, डाइरेक्टरीमा चलिरहेको छ /docs werf भण्डार संगत आदेश (jekyll build), पहिले आवश्यक संस्करणको Git ट्यागमा स्विच गरिसकेपछि।

यो थप्न मात्र बाँकी छ:

उपयोगिता आफैं (werf) एसेम्बलीको लागि प्रयोग गरिन्छ;
CI/CD प्रक्रियाहरू GitLab CI को आधारमा बनाइएका छन्;
र यो सबै, अवश्य पनि, कुबर्नेट्समा चल्छ।

कार्यहरू

अब वर्णन गरिएका सबै विशिष्टताहरूलाई ध्यानमा राखेर कार्यहरू तयार गरौं:

कुनै पनि अपडेट च्यानलमा werf संस्करण परिवर्तन गरेपछि साइटमा भएका कागजातहरू स्वचालित रूपमा अद्यावधिक हुनुपर्छ.
विकास गर्नको लागि कहिलेकाहीं सक्षम हुनुपर्छ साइटको पूर्वावलोकन हेर्नुहोस्.

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

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

यसले त्यसबाट हटाउँछ एसेम्बली बाह्य डेटा परिवर्तनमा निर्भर गर्दछ।.

कार्यान्वयन

दृष्टिकोण छनौट गर्दै

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

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

अझ सटीक हुनको लागि, हामी दुई छविहरू निर्माण गर्छौं: एउटा उत्पादन सर्किटको लागि, दोस्रो अतिरिक्त हो, विकास सर्किटको लागि। अतिरिक्त छवि मुख्य छविसँगै विकास सर्किटमा मात्र प्रयोग गरिन्छ (चलाइएको) र समीक्षा कमिटबाट साइटको संस्करण समावेश गर्दछ, र तिनीहरू बीचको राउटिङ इन्ग्रेस स्रोतहरू प्रयोग गरेर गरिन्छ।

werf बनाम git क्लोन र कलाकृतिहरू

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

यहाँ werf उपयोगिता आफैं हाम्रो सहयोगमा आउँछ, कार्यान्वयन गर्दै स्मार्ट क्यासिङ र तपाईंलाई प्रयोग गर्न अनुमति दिन्छ बाह्य भण्डारहरू। भण्डारबाट कोड थप्न werf प्रयोग गर्नाले निर्माणलाई उल्लेखनीय रूपमा गति दिनेछ, किनकि werf ले अनिवार्य रूपमा एक पटक भण्डार क्लोन गर्छ र त्यसपछि चलाउँछ। मात्र fetch यदि आवश्यक छ भने। थप रूपमा, भण्डारबाट डेटा थप्दा, हामी आवश्यक निर्देशिकाहरू मात्र चयन गर्न सक्छौं (हाम्रो अवस्थामा, यो निर्देशिका हो)। docs), जसले थपिएको डेटाको मात्रालाई उल्लेखनीय रूपमा घटाउनेछ।

जेकिल स्थिर फाइलहरू कम्पाइल गर्न डिजाइन गरिएको उपकरण भएकोले र अन्तिम छविमा आवश्यक नभएकोले, यसलाई कम्पाइल गर्नु तार्किक हुनेछ। कलाकृति werf, र अन्तिम छविमा संकलन परिणाम मात्र आयात गर्नुहोस्.

हामी werf.yaml लेख्छौं

त्यसैले, हामीले प्रत्येक संस्करणलाई छुट्टै werf कलाकृतिमा संकलन गर्ने निर्णय गर्यौं। यद्यपि, हामी हामीलाई थाहा छैन कि यी कलाकृतिहरू कतिवटा एसेम्बलीको समयमा हुनेछन्।, त्यसैले हामी निश्चित निर्माण कन्फिगरेसन लेख्न सक्दैनौं (कडा शब्दमा भन्नुपर्दा, हामी सक्छौं, तर यो धेरै कुशल हुनेछैन)।

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 }}तर तपाईंले बुझ्नु आवश्यक छ कि कलाकृतिहरूबाट आयात गर्दा, तपाईंले उही नामहरू उल्लेख गर्नुपर्नेछ।

कुनै कलाकृतिको वर्णन गर्दा, निम्न werf सुविधा प्रयोग गरिन्छ: माउन्टिङनिर्दिष्ट गरिएको सेवा निर्देशिकासँग माउन्ट गर्दै build_dir तपाईंलाई पाइपलाइन रनहरू बीच जेकिल क्यास संरक्षण गर्न अनुमति दिन्छ, जुन पुन: संयोजनलाई उल्लेखनीय रूपमा गति दिन्छ.

तपाईंले फाइलको प्रयोग पनि याद गर्नुभएको हुन सक्छ releases.yml — अनुरोध गरिएको रिलीज डेटा भएको YAML फाइल हो github.com (पाइपलाइन कार्यान्वयन गर्दा प्राप्त गरिएको कलाकृति)। साइट कम्पाइल गर्दा यो आवश्यक पर्दछ, तर लेखको सन्दर्भमा यो हाम्रो लागि रोचक छ किनभने यसको अवस्था निर्भर गर्दछ एउटा मात्र कलाकृतिको पुन: संयोजन — साइटको मूल संस्करणको कलाकृति (अन्य कलाकृतिहरूमा यो आवश्यक छैन)।

यो सशर्त अपरेटर प्रयोग गरेर कार्यान्वयन गरिन्छ। if टेम्प्लेट र निर्माणहरू गो {{ $Root.Files.Get "releases.yml" | sha256sum }} चरणमा चरणहरू। यो यसरी काम गर्छ: मूल संस्करणको लागि कलाकृति निर्माण गर्दा (चर .Channel सँग बराबर छ root) फाइल ह्यास releases.yml सम्पूर्ण चरणको हस्ताक्षरलाई असर गर्छ, किनकि यो Ansible कार्य नामको एक घटक हो (प्यारामिटर 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.

कलाकृतिहरू तयार छन् - आयात सुरु गर्ने समय भयो!

कुबर्नेट्समा चलाउनको लागि बनाइएको अन्तिम छवि नियमित 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'

यस्तो स्क्रिप्टको आउटपुट प्रयोग गर्न सकिन्छ, उदाहरणका लागि, Bash प्रकार्य प्रयोग गरेर source.

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

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

यदि पुस्ता 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 सेटिङहरू -> चरहरू).

आवश्यक तालिका सहित सफाई कार्य थप्ने काम मा गरिन्छ सीआई/सीडी ->
तालिका.

यति नै हो: तपाईंको डकर रजिस्ट्री परियोजना अब प्रयोग नगरिएका छविहरूबाट निरन्तर बढ्नेछैन।

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

gitlab-ci.yml;
werf.yaml.

परिणाम

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

निष्कर्ष

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