დოკერის სურათების დინამიური შეკრება და განლაგება werf-ით ვერსიირებული დოკუმენტაციის საიტის მაგალითის გამოყენებით

ჩვენ უკვე არაერთხელ ვისაუბრეთ ჩვენს GitOps ინსტრუმენტზე ვერფდა ამჯერად გვსურს გაგიზიაროთ ვებსაიტის შექმნის გამოცდილება თავად პროექტის დოკუმენტაციასთან ერთად - werf.io (მისი რუსული ვერსიაა ru.werf.io). ეს არის ჩვეულებრივი სტატიკური საიტი, მაგრამ მისი აწყობა საინტერესოა იმით, რომ ის აგებულია არტეფაქტების დინამიური რაოდენობის გამოყენებით.

ჩვენ არ შევეხებით საიტის სტრუქტურის ნიუანსებს: ყველა ვერსიისთვის საერთო მენიუს გენერირებას, გამოშვებების შესახებ ინფორმაციის მქონე გვერდს და ა.შ. ამის ნაცვლად, ჩვენ ყურადღებას გავამახვილებთ დინამიური ასამბლეის საკითხებსა და მახასიათებლებზე და ცოტაოდენ თანმხლებ CI/CD პროცესებზე.

შესავალი: როგორ მუშაობს საიტი

დავიწყოთ იმით, რომ werf-ის დოკუმენტაცია ინახება მის კოდთან ერთად. ეს გარკვეულ მოთხოვნებს აკისრებს განვითარებას, რომლებიც ზოგადად სცილდება ამ სტატიის ფარგლებს, მაგრამ ყოველ შემთხვევაში შეგვიძლია ვთქვათ, რომ:

• ახალი werf ფუნქციები არ უნდა გამოვიდეს დოკუმენტაციის განახლების გარეშე და, პირიქით, დოკუმენტაციაში ნებისმიერი ცვლილება werf-ის ახალი ვერსიის გამოშვებას გულისხმობს;
• პროექტს საკმაოდ ინტენსიური განვითარება აქვს: ახალი ვერსიების გამოშვება დღეში რამდენჯერმეა შესაძლებელი;
• დოკუმენტაციის ახალი ვერსიით საიტის განლაგების ნებისმიერი ხელით შესრულება, სულ მცირე, დამღლელია;
• პროექტი იყენებს სემანტიკურ მიდგომას ვერსიირება, 5 სტაბილურობის არხით. გამოშვების პროცესი გულისხმობს ვერსიების თანმიმდევრულ გავლას არხებში სტაბილურობის ზრდის თანმიმდევრობით: ალფადან კლდის მსგავსებამდე;
• საიტს აქვს რუსულენოვანი ვერსია, რომელიც „ცოცხლობს და ვითარდება“ (ანუ მისი შინაარსი განახლდება) ძირითადი (ანუ ინგლისურენოვანი) ვერსიის პარალელურად.

მომხმარებლისგან ამ „შინაგანი მექანიზმების“ დასამალად და მისთვის ისეთი რამის შეთავაზებისთვის, რაც „უბრალოდ მუშაობს“, ჩვენ შევქმენით ცალკე ინსტრუმენტი werf-ის ინსტალაციისა და განახლების მიზნით - რამდენად მრავალმხრივი ვერსიისთქვენ მხოლოდ უნდა მიუთითოთ გამოშვების ნომერი და სტაბილურობის არხი, რომლის გამოყენებაც გსურთ და multiwerf შეამოწმებს, არის თუ არა არხზე ახალი ვერსია და საჭიროების შემთხვევაში გადმოწერს მას.

werf-ის უახლესი ვერსიები ხელმისაწვდომია თითოეულ არხზე საიტზე ვერსიის შერჩევის მენიუში. ნაგულისხმევად, werf.io/დოკუმენტაცია უახლესი ვერსიის არხის ყველაზე სტაბილური ვერსია იხსნება - ის ასევე ინდექსირებულია საძიებო სისტემების მიერ. არხის დოკუმენტაცია ხელმისაწვდომია ცალკეულ მისამართებზე (მაგალითად, werf.io/v1.0-beta/დოკუმენტაცია ბეტა ვერსიისთვის 1.0).

საერთო ჯამში, საიტზე ხელმისაწვდომია შემდეგი ვერსიები:

1. root (იხსნება სტანდარტულად),
2. თითოეული ვერსიის თითოეული აქტიური განახლების არხისთვის (მაგ. werf.io/v1.0-beta).

საიტის კონკრეტული ვერსიის გენერირებისთვის, ზოგადად, საკმარისია მისი კომპილაცია Jekyll, რომელიც მუშაობს დირექტორიაში /docs werf საცავი შესაბამისი ბრძანება (jekyll build), მას შემდეგ, რაც ადრე გადავედით საჭირო ვერსიის Git ტეგზე.

მხოლოდ ისღა დაგრჩენია დავამატოთ, რომ:

• თავად პროგრამა (werf) გამოიყენება ასამბლეისთვის;
• CI/CD პროცესები აგებულია GitLab CI-ის საფუძველზე;
• და ეს ყველაფერი, რა თქმა უნდა, Kubernetes-ში მუშაობს.

ამოცანები

ახლა მოდით ჩამოვაყალიბოთ დავალებები, რომლებიც გაითვალისწინებენ ყველა აღწერილ სპეციფიკას:

1. werf ვერსიის შეცვლის შემდეგ ნებისმიერ განახლების არხზე საიტზე არსებული დოკუმენტაცია ავტომატურად უნდა განახლდეს.
2. განვითარებისთვის, ზოგჯერ უნდა შეგეძლოთ საიტის წინასწარი ხედების ნახვა.

საიტის ხელახალი კომპილაცია უნდა განხორციელდეს შესაბამისი Git ტეგებიდან ნებისმიერ არხზე ვერსიის შეცვლის შემდეგ, მაგრამ სურათის აწყობის პროცესში მივიღებთ შემდეგ მახასიათებლებს:

• რადგან არხების ვერსიების სია იცვლება, საჭიროა მხოლოდ იმ არხების დოკუმენტაციის ხელახლა შექმნა, სადაც ვერსია შეიცვალა. ბოლოს და ბოლოს, ყველაფრის ნულიდან ხელახლა შექმნა არც ისე კარგია.
• შესაძლოა, გამოშვებების არხების ნაკრები შეიცვალოს. მაგალითად, გარკვეულ მომენტში, შესაძლოა, არხებზე არ არსებობდეს ვერსია, რომელიც უფრო სტაბილური იქნება, ვიდრე ადრეული წვდომის 1.1 ვერსია, მაგრამ ისინი დროთა განმავლობაში გამოჩნდება - ამ შემთხვევაში, ბილდის ხელით შეცვლა შეუძლებელია, არა?

გამოდის, რომ ასამბლეა დამოკიდებულია გარე მონაცემების შეცვლაზე.

Реализация

მიდგომის არჩევა

ალტერნატიულად, შეგიძლიათ Kubernetes-ში თითოეული საჭირო ვერსია ცალკე პოდად გაუშვათ. ეს ვარიანტი გულისხმობს კლასტერში ობიექტების უფრო დიდ რაოდენობას, რომელიც გაიზრდება სტაბილური werf-ის გამოშვებების რაოდენობის ზრდასთან ერთად. ეს კი, თავის მხრივ, უფრო რთულ მოვლა-პატრონობას გულისხმობს: თითოეულ ვერსიას აქვს საკუთარი HTTP სერვერი, მცირე დატვირთვით. რა თქმა უნდა, ეს ასევე უფრო დიდ რესურსების ხარჯებსაც გულისხმობს.

ჩვენც იგივე გზით წავედით ყველა საჭირო ვერსიის აწყობა ერთ სურათშისაიტის ყველა ვერსიის კომპილირებული სტატისტიკა NGINX-თან ერთად კონტეინერშია და შესაბამის განლაგებაზე ტრაფიკი NGINX Ingress-ის მეშვეობით ხორციელდება. მარტივი სტრუქტურა — უსტატუსო აპლიკაცია — საშუალებას გაძლევთ მარტივად მასშტაბირება გაუკეთოთ განლაგებას (დატვირთვის მიხედვით) თავად Kubernetes-ის გამოყენებით.

უფრო ზუსტად, ჩვენ ვაშენებთ ორ სურათს: ერთი წარმოების სქემისთვის, მეორე კი დამატებითია, დეველოპერის სქემისთვის. დამატებითი სურათი გამოიყენება (იშვება) მხოლოდ დეველოპერის წრედზე მთავართან ერთად და შეიცავს საიტის ვერსიას review commit-დან, ხოლო მათ შორის მარშრუტიზაცია ხორციელდება Ingress რესურსების გამოყენებით.

werf vs git კლონი და არტეფაქტები

როგორც აღვნიშნეთ, დოკუმენტაციის კონკრეტული ვერსიისთვის საიტის სტატიკის გენერირებისთვის, თქვენ უნდა შექმნათ შესაბამის საცავის ტეგზე გადასვლით. ამის გაკეთება ასევე შეგიძლიათ საცავის კლონირებით ყოველი შექმნისას, შესაბამისი ტეგების სიიდან არჩევით. თუმცა, ეს საკმაოდ რესურსების მომთხოვნი ოპერაციაა და, გარდა ამისა, მოითხოვს არატრივიალური ინსტრუქციების დაწერას... კიდევ ერთი სერიოზული ნაკლი ის არის, რომ ამ მიდგომით, შექმნის დროს არაფრის ქეშირება შეუძლებელია.

აქ თავად werf პროგრამა გვეხმარება, რომელიც ახორციელებს ჭკვიანი ქეშირება და საშუალებას გაძლევთ გამოიყენოთ გარე საცავები. რესურსიდან კოდის დასამატებლად werf-ის გამოყენება მნიშვნელოვნად დააჩქარებს აწყობის პროცესს, რადგან werf არსებითად ერთხელ კლონირებას უკეთებს რესურსს და შემდეგ ამუშავებს. მხოლოდ fetch საჭიროების შემთხვევაში. გარდა ამისა, საცავიდან მონაცემების დამატებისას, ჩვენ შეგვიძლია მხოლოდ საჭირო დირექტორიების არჩევა (ჩვენს შემთხვევაში, ეს არის დირექტორია docs), რაც მნიშვნელოვნად შეამცირებს დამატებული მონაცემების რაოდენობას.

რადგან Jekyll არის ინსტრუმენტი, რომელიც შექმნილია სტატიკური ფაილების კომპილაციისთვის და არ არის საჭირო საბოლოო სურათში, ლოგიკური იქნებოდა მისი კომპილაცია არტეფაქტის ვერფიდა საბოლოო სურათზე მხოლოდ კომპილაციის შედეგის იმპორტი.

ჩვენ ვწერთ werf.yaml-ს

ასე რომ, ჩვენ გადავწყვიტეთ, რომ თითოეული ვერსია ცალკე werf არტეფაქტად შეგვეგროვებინა. თუმცა, ჩვენ არ ვიცით, რამდენი ასეთი არტეფაქტი იქნება აწყობის დროს, ამიტომ ჩვენ არ შეგვიძლია ფიქსირებული აწყობის კონფიგურაციის დაწერა (მკაცრად რომ ვთქვათ, შეგვიძლია, მაგრამ ეს არ იქნება ძალიან ეფექტური).

werf საშუალებას გაძლევთ გამოიყენოთ Go შაბლონები თქვენს კონფიგურაციის ფაილში (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") }}

საიტის სტატიკური ვერსიის კომპილაციისთვის არტეფაქტის აღწერა ზოგადად იგივეა ყველა საჭირო შემთხვევისთვის (მათ შორის root ვერსიის გენერირებისთვის, ასევე dev-contour-ის ვერსიისთვის). ამიტომ, ფუნქციის გამოყენებით მას ცალკე ბლოკში გადავიტანთ. define — შემდგომი ხელახალი გამოყენებისთვის დახმარებით includeშაბლონს შემდეგ არგუმენტებს გადავცემთ:

• Version — გენერირებული ვერსია (ტეგის სახელი);
• Channel — განახლების არხის სახელი, რომლისთვისაც გენერირდება არტეფაქტი;
• Commit — commit ჰეში, თუ არტეფაქტი გენერირებულია განხილვის 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 საშუალებას გაძლევთ შეინახოთ Jekyll-ის ქეში მილსადენის გაშვებებს შორის, რაც მნიშვნელოვნად აჩქარებს ხელახლა აწყობას.

შესაძლოა, ასევე შეამჩნიოთ ფაილის გამოყენება releases.yml — არის YAML ფაილი, რომლის გამოშვების მონაცემებიც მოთხოვნილია Github.com (მილსადენის შესრულებისას მიღებული არტეფაქტი). ის საჭიროა საიტის კომპილაციისას, მაგრამ სტატიის კონტექსტში ჩვენთვის საინტერესოა, რადგან მისი მდგომარეობა დამოკიდებულია მხოლოდ ერთი არტეფაქტის ხელახლა აწყობა — საიტის root ვერსიის არტეფაქტი (სხვა არტეფაქტებში ის საჭირო არ არის).

ეს ხორციელდება პირობითი ოპერატორის გამოყენებით. if Go-ს შაბლონები და კონსტრუქციები {{ $Root.Files.Get "releases.yml" | sha256sum }} სცენაზე ეტაპებიის ასე მუშაობს: root ვერსიისთვის არტეფაქტის შექმნისას (ცვლადი .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-ს და root კონტექსტს.

ანალოგიურად, მაგრამ ციკლის გარეშე, არტეფაქტის შაბლონს ვიძახებთ „განსაკუთრებული შემთხვევებისთვის“: root ვერსიისთვის, ასევე review commit-ის ვერსიისთვის:

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

დამატებითი სურათი, რომელიც დეველოპერულ წრედზე მთავარ სურათთან ერთად იხსნება, საიტის მხოლოდ ორ ვერსიას შეიცავს: განხილვის კომიტიდან ვერსიას და საიტის root ვერსიას (ის შეიცავს საერთო აქტივებს და, თუ გახსოვთ, გამოშვების მონაცემებს). ამრიგად, დამატებითი სურათი ძირითადი სურათისგან მხოლოდ იმპორტის განყოფილებით (და, რა თქმა უნდა, სახელით) განსხვავდება:

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

როგორც ზემოთ აღინიშნა, მიმოხილვის კომიტისთვის არტეფაქტი მხოლოდ set environment ცვლადის გაშვებისას გენერირდება. REVIEW_SHA. შესაძლებელი იქნებოდა werf-dev იმიჯის საერთოდ არ გენერირება, თუ გარემოს ცვლადი არ იქნებოდა. REVIEW_SHA, მაგრამ იმისათვის, რომ დასუფთავება პოლიტიკის მიხედვით werf-ში Docker-ის იმიჯები werf-dev იმიჯისთვის მუშაობდა, მისი აგება მხოლოდ root ვერსიის არტეფაქტით მოხდება (ის ისედაც უკვე აგებულია), რათა გამარტივდეს pipeline სტრუქტურა.

აწყობა მზადაა! გადავიდეთ 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 მილსადენის სტანდარტული ეტაპების გამოყენებით: Build and Deploy. ჩვენ თავად მილსადენს ვუშვებთ werf GitHub რეპოზიტორიდან ჰუკების გამოყენებით (ანუ, როდესაც GitHub-ზე რეპოზიტორში ცვლილებებია). მათთვის მონაცემების აღება შესაძლებელია განყოფილებაში GitLab პროექტის თვისებებიდან. CI/CD პარამეტრები -> მილსადენის ტრიგერებიდა შემდეგ შექმენით შესაბამისი Webhook 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), რომლებიც შემდეგ გამოიყენება Helm-ის დიაგრამის შაბლონებში. ჩვენ არ მოგაწვდით შაბლონების შინაარსს, რადგან განსახილველი თემისთვის არაფერია საინტერესო, მაგრამ მათი პოვნა შეგიძლიათ სტატიის საცავები.

საბოლოო შეხება

რადგან werf ვერსიები საკმაოდ ხშირად გამოდის, ახალი სურათები ხშირად შეიქმნება და Docker-ის რეესტრი მუდმივად გაიზრდება. ამიტომ, აუცილებელია სურათების ავტომატური გაწმენდის დაყენება პოლიტიკის მიხედვით. ეს ძალიან მარტივია.

განხორციელებისთვის დაგჭირდებათ:

• დაამატეთ დასუფთავების ეტაპი .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

ზემოთ ეს თითქმის ყველაფერი უკვე ვნახეთ — მხოლოდ მის გასასუფთავებლად, ჯერ Docker Registry-ში უნდა შეხვიდეთ ისეთი ტოკენით, რომელსაც აქვს Docker Registry-ში სურათების წაშლის უფლება (GitLab CI დავალების ავტომატურად გაცემულ ტოკენს ასეთი უფლებები არ აქვს). ტოკენი წინასწარ უნდა შეიქმნას GitLab-ში და მისი მნიშვნელობა უნდა იყოს მითითებული გარემოს ცვლადში. WERF_IMAGES_CLEANUP_PASSWORD პროექტი (CI/CD პარამეტრები -> ცვლადები).

დასუფთავების დავალების დამატება საჭირო გრაფიკით ხდება CI/CD ->
სხდომები.

სულ ესაა: თქვენი Docker Registry პროექტი აღარ გაიზრდება მუდმივად გამოუყენებელი სურათებიდან.

პრაქტიკული ნაწილის დასასრულს, მინდა შეგახსენოთ, რომ სტატიიდან სრული ჩამონათვალი ხელმისაწვდომია წასვლა:

• .gitlab-ci.yml;
• werf.yaml.

შედეგი

1. ჩვენ მივიღეთ ლოგიკური ასამბლეის სტრუქტურა: ერთი არტეფაქტი თითო ვერსიაზე.
2. ასამბლეა უნივერსალურია და არ საჭიროებს ხელით ცვლილებებს werf-ის ახალი ვერსიების გამოსვლისას: საიტზე დოკუმენტაცია ავტომატურად განახლდება.
3. სხვადასხვა კონტურებისთვის ორი სურათია შეგროვებული.
4. ის სწრაფად მუშაობს, რადგან ქეშირება მაქსიმალურად გამოიყენება - როდესაც werf-ის ახალი ვერსია გამოდის ან GitHub hook გამოიძახება მიმოხილვის ჩასაწერად, მხოლოდ შეცვლილი ვერსიის შესაბამისი არტეფაქტი ხელახლა იქმნება.
5. არ არის საჭირო გამოუყენებელი სურათების წაშლაზე ფიქრი: werf პოლიტიკაზე დაფუძნებული გაწმენდა თქვენს Docker-ის რეესტრს მოწესრიგებულად შეინარჩუნებს.

დასკვნები

• werf-ის გამოყენება საშუალებას აძლევს ბილდს სწრაფად იმუშაოს როგორც თავად ბილდის, ასევე გარე რეპოზიტორებთან მუშაობისას ქეშირების გამო.
• გარე Git რეპოზიტორიებთან მუშაობა გამორიცხავს რეპოზიტორის ყოველ ჯერზე სრულად კლონირების ან რთული ოპტიმიზაციის ლოგიკით ბორბლის ხელახლა გამოგონების საჭიროებას. werf იყენებს ქეშს და კლონირებას ახდენს მხოლოდ ერთხელ, შემდეგ კი იყენებს fetch და მხოლოდ საჭიროების შემთხვევაში.
• Go შაბლონების გამოყენების შესაძლებლობა კონფიგურაციის ფაილში werf.yaml საშუალებას გაძლევთ აღწეროთ ასამბლეა, რომლის შედეგიც დამოკიდებულია გარე მონაცემებზე.
• werf-ში დამონტაჟების გამოყენება მნიშვნელოვნად აჩქარებს არტეფაქტების შეგროვებას - ქეშის წყალობით, რომელიც ყველა მილსადენისთვის საერთოა.
• werf აადვილებს გასუფთავების კონფიგურაციას, რაც განსაკუთრებით მნიშვნელოვანია დინამიური ბილდებისთვის.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ბრძანებების შესრულება Kubernetes-ში ახალი აპლიკაციის ვერსიის მიწოდების დროს";
• «შექმენით და განათავსეთ იმავე ტიპის მიკროსერვისები werf-ით და GitLab CI-ით";
• «Werf-ის გამოყენება რთული Helm სქემების შესაქმნელად";
• «წარმოგიდგენთ werf 1.0 stable: რა კავშირი აქვს GitOps-ს, სტატუსს და გეგმებს".

წყარო: www.habr.com