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

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

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

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

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

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

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

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

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

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

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

यो केवल थप्न बाँकी छ:

उपयोगिता आफै (werf) विधानसभा लागि प्रयोग गरिन्छ;
CI/CD प्रक्रियाहरू GitLab CI को आधारमा बनाइन्छ;
र यो सबै, निस्सन्देह, Kubernetes मा चल्छ।

कार्यहरू

अब सबै वर्णित विवरणहरूलाई ध्यानमा राख्ने कार्यहरू बनाउनुहोस्:

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

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

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

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

कार्यान्वयन

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

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

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

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

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") }}

साइटको स्थिर संस्करण कम्पाइल गर्ने कलाकृतिको विवरण सामान्यतया हामीलाई चाहिने सबै केसहरूको लागि समान हुन्छ (मूल संस्करण उत्पन्न गर्ने, साथै dev सर्किटको लागि संस्करण सहित)। त्यसकारण, हामी यसलाई प्रकार्य प्रयोग गरेर छुट्टै ब्लकमा सार्नेछौं 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 सम्पूर्ण चरणको हस्ताक्षरलाई असर गर्छ, किनकि यो उत्तरदायी कार्यको नामको अंश हो (प्यारामिटर 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 हुकबाट पाइपलाइन कल गर्दा सेट गर्नेछौं।

हामी Bash स्क्रिप्टमा आवश्यक बाह्य डाटा उत्पन्न गर्नेछौं 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 सेटिङहरू -> चरहरू).

आवश्यक तालिका संग एक सफाई कार्य थप्दै मा गरिन्छ CI/CD ->
तालिका.

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

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

gitlab-ci.yml;
werf.yaml.

परिणाम

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

निष्कर्ष

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

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

स्रोत: www.habr.com

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