🥇 Докер сүрөттөрүн werf менен динамикалык чогултуу жана жайылтуу версияланган документация сайтынын мисалын колдонуу

Биз GitOps куралыбыз жөнүндө бир нече жолу сүйлөшкөнбүз. werf, жана бул жолу биз долбоордун өзүнүн документтери менен сайтты чогултуу боюнча тажрыйба бөлүшкүбүз келет - 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).

Сайттын белгилүү бир версиясын түзүү үчүн, жалпысынан аны колдонуу менен компиляциялоо жетиштүү спамекаталогдо иштетүү менен /docs werf репозиторийине тиешелүү команда (jekyll build), талап кылынган версиянын Git тегине өткөндөн кийин.

Муну кошуу гана калды:

утилитанын өзү (werf) чогултуу үчүн колдонулат;
CI/CD процесстери GitLab CI базасында курулган;
жана мунун баары, албетте, Kubernetes иштейт.

милдеттери

Эми бардык сүрөттөлгөн өзгөчөлүктөрдү эске алган тапшырмаларды түзөлү:

Каалаган жаңыртуу каналында werf версиясын өзгөрткөндөн кийин сайттагы документтер автоматтык түрдө жаңыртылышы керек.
Өнүгүү үчүн кээде жөндөмдүү болушуң керек сайттын алдын ала көрүү версияларын көрүү.

Тиешелүү Git тегтеринен каалаган каналдагы версияны өзгөрткөндөн кийин сайт кайра түзүлүшү керек, бирок сүрөттү куруу процессинде биз төмөнкү функцияларды алабыз:

Каналдардагы версиялардын тизмеси өзгөргөндүктөн, версиясы өзгөргөн каналдар үчүн документацияны кайра түзүү гана керек. Анткени, бардыгын кайра куруу анча жакшы эмес.
Чыгарылган каналдардын топтому өзгөрүшү мүмкүн. Кайсы бир убакта, мисалы, каналдарда эрте жетүүчү 1.1 релизине караганда туруктуураак версия жок болушу мүмкүн, бирок убакыттын өтүшү менен алар пайда болот - бул учурда, жыйынды кол менен өзгөртүү керек эмеспи?

Ал экен жыйын тышкы маалыматтарды өзгөртүүгө көз каранды.

Реализация

Ыкчам тандоо

Же болбосо, сиз ар бир талап кылынган версияны Kubernetesте өзүнчө подколь катары иштетсеңиз болот. Бул параметр кластердеги объекттердин көбүрөөк санын билдирет, алар туруктуу werf релиздердин санынын өсүшү менен өсөт. Ал эми бул, өз кезегинде, татаалыраак тейлөөнү билдирет: ар бир версия өзүнүн HTTP серверине ээ жана кичинекей жүктөм менен. Албетте, бул дагы чоң ресурстук чыгымдарды талап кылат.

Ошол эле жолду басып өттүк бир сүрөттөлүштө бардык керектүү версияларды чогултуу. Сайттын бардык версияларынын түзүлгөн статикасы NGINX менен контейнерде жайгашкан жана тиешелүү Жайгаштыруу трафик NGINX Ingress аркылуу келет. Жөнөкөй түзүм - жарандыгы жок тиркеме - Kubernetesтин өзүн колдонуу менен Жайгаштырууну (жүккө жараша) оңой масштабдоого мүмкүндүк берет.

Тагыраак айтканда, биз эки сүрөттү чогултуп жатабыз: бири өндүрүш схемасы үчүн, экинчиси - иштеп чыгуу схемасы үчүн кошумча. Кошумча сүрөт негизгиси менен бирге иштеп чыгуучу схемада гана колдонулат (ишке киргизилет) жана кароодон алынган сайттын версиясын камтыйт жана алардын ортосундагы багыттоо Ingress ресурстары аркылуу ишке ашырылат.

werf vs git клону жана артефакттары

Жогоруда айтылгандай, документтердин белгилүү бир версиясы үчүн сайт статикасын түзүү үчүн, тиешелүү репозиторий тегине өтүү аркылуу куруу керек. Муну сиз ар бир курган сайын репозиторийди клондоштуруу менен, тизмеден тиешелүү тегдерди тандап алсаңыз болот. Бирок, бул кыйла ресурсту талап кылган операция жана анын үстүнө майда-чүйдө эмес инструкцияларды жазууну талап кылат... Дагы бир олуттуу кемчилик - бул ыкма менен монтаж учурунда бир нерсени кэштөөнүн эч кандай жолу жок.

Бул жерде werf утилитасы бизге жардамга келет, ишке ашырат акылдуу кэштөө жана колдонууга мүмкүндүк берет тышкы репозиторийлер. Репозиторийден кодду кошуу үчүн werf колдонуу курулушту кыйла тездетет, анткени werf репозиторийди бир жолу клондоп, анан аткарат гана fetch зарыл болсо. Мындан тышкары, репозиторийден маалыматтарды кошуп жатканда, биз керектүү каталогдорду гана тандай алабыз (биздин учурда бул каталог docs), бул кошумча маалыматтардын көлөмүн кыйла азайтат.

Jekyll статикалык маалыматтарды түзүү үчүн иштелип чыккан курал болгондуктан жана акыркы сүрөттө кереги жок, аны компиляциялоо логикалуу болмок. верф артефакты, жана акыркы сүрөткө компиляциянын жыйынтыгын гана импорттоо.

Биз 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 түтүк өткөргүчтөрдүн ортосунда Jekyll кэшин сактоого мүмкүндүк берет, бул кайра монтаждоону бир кыйла тездетет.

Сиз ошондой эле файлдын колдонулушун байкаган болушуңуз мүмкүн releases.yml суралган чыгаруу маалыматтары менен YAML файл болуп саналат github.com (трубопроводду ишке ашырууда алынган артефакт). Бул сайтты түзүүдө керек, бирок макаланын контекстинде бул биз үчүн кызыктуу, анткени ал анын абалынан көз каранды бир гана артефактты кайра чогултуу — сайттын түпкү версиясынын артефакты (башка артефакттарда бул кереги жок).

Бул шарттуу билдирүүнү колдонуу менен ишке ашырылат if Калыптарга жана дизайнга өтүңүз {{ $Root.Files.Get "releases.yml" | sha256sum }} этапта этаптары. Ал төмөнкүдөй иштейт: тамыр версиясы үчүн артефакт курууда (variable .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.

Артефакттар даяр - импорттоону баштоого убакыт келди!

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. Бул GitHub илгичинен куурду чакырганда орното турган REVIEW_SHA өзгөрмөсүнө тиешеси жок.

Биз Bash скриптинде керектүү тышкы маалыматтарды жаратабыз generate_artifacts, ал эки GitLab түтүк артефактын жаратат:

билэ releases.yml чыгаруу маалыматтары менен,
билэ common_envs.sh, экспорттолуучу чөйрө өзгөрмөлөрүн камтыган.

Файлдын мазмуну generate_artifacts бизден табасыз мисалдар менен репозиторийлер. Маалыматтарды кабыл алуунун өзү макаланын темасы эмес, файл common_envs.sh биз үчүн маанилүү, анткени верфтин иши андан көз каранды. Анын мазмунуна мисал:

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'да тиешелүү Webhook түзүңүз (Орнотуулар -> Webhooks).

Куруу этабы төмөнкүдөй болот:

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 Реестрине Docker Реестриндеги сүрөттөрдү жок кылуу укугуна ээ белги менен кирүүңүз керек (автоматтык түрдө чыгарылган GitLab CI тапшырма белгиси жок ушундай укуктарга ээ). Токен алдын ала GitLabда түзүлүшү керек жана анын мааниси чөйрө өзгөрмөсүндө көрсөтүлүшү керек WERF_IMAGES_CLEANUP_PASSWORD долбоору (CI/CD Орнотуулары -> Өзгөрмөлөр).

Керектүү расписание менен тазалоо тапшырмасын кошуу жылы жасалат CI/CD ->
Расписание.

Болду: Докер реестриндеги долбоор мындан ары пайдаланылбаган сүрөттөрдөн тынымсыз өспөйт.

Практикалык бөлүктүн аягында макаланын толук тизмеси бар экенин эскерте кетейин барып,:

жыйынтык

Биз логикалык ассамблея түзүмүн алдык: ар бир версияга бир артефакт.
Ассамблея универсалдуу жана werfтин жаңы версиялары чыкканда кол менен өзгөртүүнү талап кылбайт: веб-сайттагы документтер автоматтык түрдө жаңыланат.
Эки сүрөт ар кандай контурлар үчүн чогултулган.
Ал тез иштейт, анткени Кэштөө мүмкүн болушунча көбүрөөк колдонулат - werfтин жаңы версиясы чыкканда же GitHub илгичи кайра кароого чакырылганда, өзгөртүлгөн версиясы менен гана тиешелүү артефакт кайра курулат.
Колдонулбаган сүрөттөрдү жок кылуу жөнүндө ойлонуунун кереги жок: werf саясатына ылайык тазалоо Докер реестрин иретке келтирет.

табылгалары

Werf колдонуу ассамблеянын өзүн жана тышкы репозиторийлер менен иштөөдө кэштөөнүн эсебинен тез иштөөгө мүмкүндүк берет.
Тышкы Git репозиторийлери менен иштөө ар бир жолу бүт репозиторийди клондоо же татаал оптималдаштыруу логикасы менен дөңгөлөктү кайра ойлоп табуу зарылдыгын жок кылат. werf кэш колдонот жана клондоштурууну бир гана жолу жасайт, анан колдонот fetch жана зарыл болгондо гана.
Куруу конфигурация файлында Go шаблондорун колдонуу мүмкүнчүлүгү werf.yaml натыйжасы тышкы маалыматтарга көз каранды болгон жыйынды сүрөттөөгө мүмкүндүк берет.
Werf'те монтажды колдонуу артефакттарды чогултууну кыйла тездетет - бардык түтүктөр үчүн жалпы болгон кэштин эсебинен.
werf тазалоону конфигурациялоону жеңилдетет, бул динамикалык курууда өзгөчө маанилүү.