🥇Docker attēlu dinamiska montāža un izvietošana ar Werf, izmantojot versijuotas dokumentācijas vietnes piemēru

Mēs jau vairāk nekā vienu reizi esam runājuši par mūsu GitOps rīku. werf, un šoreiz vēlamies dalīties pieredzē par vietnes komplektēšanu ar paša projekta dokumentāciju - werf.io (tā krievu versija ir en.werf.io). Šī ir parasta statiska vietne, taču tās montāža ir interesanta ar to, ka tā ir veidota, izmantojot dinamisku artefaktu skaitu.

Iedziļinieties vietnes struktūras niansēs: kopējas izvēlnes ģenerēšana visām versijām, lapas ar informāciju par izlaidumiem utt. - mēs to nedarīsim. Tā vietā pievērsīsimies dinamiskās montāžas problēmām un iezīmēm un nedaudz uz pavadošajiem CI/CD procesiem.

Ievads: kā vietne darbojas

Sākumā werf dokumentācija tiek saglabāta kopā ar tās kodu. Tas uzliek noteiktas izstrādes prasības, kas parasti neietilpst šī panta darbības jomā, taču vismaz var teikt, ka:

Jaunas werf funkcijas nedrīkst izlaist, neatjauninot dokumentāciju, un, gluži pretēji, jebkuras izmaiņas dokumentācijā nozīmē jaunas werf versijas izlaišanu;
Projektam ir diezgan intensīva attīstība: jaunas versijas var izdot vairākas reizes dienā;
Visas manuālās darbības, lai izvietotu vietni ar jaunu dokumentācijas versiju, ir vismaz nogurdinošas;
Projekts izmanto semantisko pieeju versiju veidošana, ar 5 stabilitātes kanāliem. Izlaišanas process ietver secīgu versiju pāreju pa kanāliem, lai palielinātu stabilitāti: no alfa uz cieto;
Vietnei ir versija krievu valodā, kas “dzīvo un attīstās” (t.i., kuras saturs tiek atjaunināts) paralēli galvenajai (t.i., angļu valodas) versijai.

Lai noslēptu visu šo “iekšējo virtuvi” no lietotāja, piedāvājot viņam kaut ko, kas “vienkārši darbojas”, mēs to darījām atsevišķs werf instalēšanas un atjaunināšanas rīks -Šo multiwerf. Jums vienkārši jānorāda izlaiduma numurs un stabilitātes kanāls, kuru esat gatavs izmantot, un multiwerf pārbaudīs, vai kanālā ir jauna versija, un nepieciešamības gadījumā to lejupielādēs.

Tīmekļa vietnes versiju izvēles izvēlnē ir pieejamas jaunākās werf versijas katrā kanālā. Pēc noklusējuma, pēc adreses werf.io/documentation tiek atvērta visstabilākā kanāla versija jaunākajam izlaidumam - to indeksē arī meklētājprogrammas. Kanāla dokumentācija ir pieejama atsevišķās adresēs (piemēram, werf.io/v1.0-beta/documentation beta versijai 1.0).

Kopumā vietnei ir pieejamas šādas versijas:

sakne (atveras pēc noklusējuma),
katram katra laidiena aktīvajam atjaunināšanas kanālam (piemēram, werf.io/v1.0-beta).

Lai ģenerētu konkrētu vietnes versiju, parasti pietiek ar tās kompilēšanu, izmantojot Jekyllpalaižot direktorijā /docs werf repozitorija atbilstošā komanda (jekyll build), pēc pārslēgšanās uz vajadzīgās versijas Git tagu.

Atliek tikai piebilst, ka:

montāžai tiek izmantota pati lietderība (werf);
CI/CD procesi ir veidoti uz GitLab CI bāzes;
un tas viss, protams, darbojas Kubernetes.

uzdevumi

Tagad formulēsim uzdevumus, kuros ņemta vērā visa aprakstītā specifika:

Pēc werf versijas maiņas jebkurā atjaunināšanas kanālā dokumentācija vietnē ir automātiski jāatjaunina.
Lai attīstītu, jums dažreiz ir jāspēj skatiet vietnes priekšskatījuma versijas.

Vietne ir jāpārkompilē pēc versijas maiņas jebkurā kanālā no atbilstošajiem Git tagiem, taču attēla veidošanas procesā mēs iegūsim šādas funkcijas:

Tā kā kanālu versiju saraksts mainās, ir nepieciešams tikai atjaunot dokumentāciju tiem kanāliem, kuru versija ir mainījusies. Galu galā atkal visu pārbūvēt nav īpaši jauki.
Izlaidumu kanālu kopa var mainīties. Piemēram, kādā brīdī kanālos var nebūt stabilākas versijas par agrīnās piekļuves 1.1 versiju, taču laika gaitā tās parādīsies — vai šajā gadījumā nevajadzētu manuāli mainīt komplektāciju?

Izrādās, ka montāža ir atkarīga no ārējo datu maiņas.

Ieviešana

Pieejas izvēle

Varat arī palaist katru nepieciešamo versiju kā atsevišķu aplikāciju pakalpojumā Kubernetes. Šī opcija nozīmē lielāku objektu skaitu klasterī, kas pieaugs, palielinoties stabilo werf izlaidumu skaitam. Un tas, savukārt, nozīmē sarežģītāku apkopi: katrai versijai ir savs HTTP serveris un ar nelielu slodzi. Protams, tas rada arī lielākas resursu izmaksas.

Mēs gājām to pašu ceļu visu nepieciešamo versiju salikšana vienā attēlā. Visu vietnes versiju apkopotā statistika atrodas konteinerā ar NGINX, un datplūsma uz atbilstošo izvietošanu tiek nodrošināta, izmantojot NGINX Ingress. Vienkārša struktūra - bezvalsts lietojumprogramma - ļauj viegli mērogot izvietošanu (atkarībā no slodzes), izmantojot pašu Kubernetes.

Precīzāk sakot, mēs apkopojam divus attēlus: vienu ražošanas ķēdei, otrs ir papildu attēls izstrādes shēmai. Papildu attēls tiek izmantots (palaists) tikai izstrādātāju shēmā kopā ar galveno, un tajā ir vietnes versija no pārskatīšanas saistības, un maršrutēšana starp tiem tiek veikta, izmantojot Ingress resursus.

werf vs git klons un artefakti

Kā jau minēts, lai ģenerētu vietnes statiku konkrētai dokumentācijas versijai, jums ir jāveido, pārslēdzoties uz atbilstošo repozitorija tagu. To var izdarīt arī, klonējot repozitoriju katru reizi, kad veidojat, sarakstā atlasot atbilstošos tagus. Taču šī ir diezgan resursietilpīga darbība un turklāt prasa rakstīt netriviālas instrukcijas... Vēl viens nopietns trūkums ir tas, ka ar šo pieeju montāžas laikā nav iespējams kaut ko saglabāt kešatmiņā.

Šeit mums palīgā nāk pati werf utilīta, ieviešot viedā kešatmiņa un ļaujot jums izmantot ārējās krātuves. Izmantojot werf, lai pievienotu kodu no repozitorija, ievērojami paātrinās būvniecību, jo werf būtībā vienreiz klonē repozitoriju un pēc tam izpilda tikai fetch ja nepieciešams. Turklāt, pievienojot datus no repozitorija, mēs varam atlasīt tikai nepieciešamos direktorijus (mūsu gadījumā tas ir direktorijs docs), kas ievērojami samazinās pievienoto datu apjomu.

Tā kā Jekyll ir rīks, kas paredzēts statisku datu apkopošanai un nav vajadzīgs galīgajā attēlā, būtu loģiski apkopot werf artefakts, un gala attēlā importēt tikai apkopošanas rezultātu.

Mēs rakstām werf.yaml

Tāpēc mēs nolēmām, ka mēs apkoposim katru versiju atsevišķā werf artefaktā. Tomēr mēs mēs nezinām, cik daudz šo artefaktu būs montāžas laikā, tāpēc mēs nevaram uzrakstīt fiksētu būvējuma konfigurāciju (stingri sakot, mēs joprojām varam, taču tas nebūs pilnīgi efektīvs).

werf ļauj izmantot Iet uz veidnēm konfigurācijas failā (werf.yaml), un tas padara to iespējamu ģenerēt konfigurāciju lidojumā atkarībā no ārējiem datiem (kas jums nepieciešams!). Ārējie dati mūsu gadījumā ir informācija par versijām un izlaidumiem, uz kuru pamata mēs savācam nepieciešamo artefaktu skaitu un rezultātā iegūstam divus attēlus: werf-doc и werf-dev darboties dažādās ķēdēs.

Ārējie dati tiek nodoti caur vides mainīgajiem. Šeit ir viņu sastāvs:

RELEASES — rinda ar izlaidumu sarakstu un atbilstošo pašreizējo werf versiju ar atstarpi atdalīta vērtību saraksta formā formātā <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Piemērs: 1.0%v1.0.4-beta.20
CHANNELS — rinda ar kanālu sarakstu un atbilstošo pašreizējo werf versiju ar atstarpi atdalīta vērtību saraksta formā formātā <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Piemērs: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — werf izlaiduma versija, kas pēc noklusējuma tiek rādīta vietnē (ne vienmēr ir nepieciešams parādīt dokumentāciju pēc lielākā izlaiduma numura). Piemērs: v1.0.4-beta.20
REVIEW_SHA — pārskatīšanas saistību jaucējkods, no kura jums ir jāizveido testa cilpas versija.

Šie mainīgie tiks aizpildīti GitLab CI konveijerā, un kā tieši tas ir rakstīts tālāk.

Pirmkārt, ērtības labad mēs definējam werf.yaml Dodieties uz veidņu mainīgajiem, piešķirot tiem vērtības no vides mainīgajiem:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

Vietnes statiskās versijas apkopošanai paredzētā artefakta apraksts parasti ir vienāds visiem mums nepieciešamajiem gadījumiem (tostarp saknes versijas ģenerēšanai, kā arī izstrādes shēmas versijai). Tāpēc mēs to pārvietosim atsevišķā blokā, izmantojot funkciju define - turpmākai atkārtotai lietošanai include. Mēs nodosim veidnei šādus argumentus:

Version — ģenerētā versija (taga nosaukums);
Channel — tā atjaunināšanas kanāla nosaukums, kuram artefakts ir ģenerēts;
Commit — veikt hash, ja artefakts ir ģenerēts pārskatīšanas saistībām;
kontekstā.

Artefakta veidnes apraksts

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

Artefakta nosaukumam ir jābūt unikālam. Mēs to varam panākt, piemēram, pievienojot kanāla nosaukumu (mainīgā vērtība .Channel) kā artefakta nosaukuma sufiksu: artifact: doc-{{ .Channel }}. Bet jums ir jāsaprot, ka, importējot no artefaktiem, jums būs jāatsaucas uz tiem pašiem nosaukumiem.

Aprakstot artefaktu, tiek izmantota šāda werf funkcija: montāža. Montāža, kas norāda servisa direktoriju build_dir ļauj saglabāt Jekyll kešatmiņu starp konveijera palaišanu, kas ievērojami paātrina montāžu.

Iespējams, arī esat pamanījis faila izmantošanu releases.yml ir YAML fails ar laidiena datiem, kas pieprasīti no github.com (artefakts, kas iegūts, izpildot cauruļvadu). Tas ir nepieciešams, veidojot vietni, bet raksta kontekstā tas mums ir interesants, jo tas ir atkarīgs no tā stāvokļa tikai viena artefakta montāža — vietnes saknes versijas artefakts (citos artefaktos tas nav vajadzīgs).

Tas tiek īstenots, izmantojot nosacījumu paziņojumu if Iet uz veidnēm un dizainu {{ $Root.Files.Get "releases.yml" | sha256sum }} stadijā posmos. Tas darbojas šādi: veidojot artefaktu saknes versijai (mainīgais .Channel vienāds root) failu hash releases.yml ietekmē visa posma parakstu, jo tā ir daļa no Ansible uzdevuma nosaukuma (parametrs name). Tādējādi, mainot saturu failu releases.yml attiecīgais artefakts tiks salikts no jauna.

Lūdzu, pievērsiet uzmanību arī darbam ar ārēju repozitoriju. Artefakta attēlā no werf repozitorijs, tiek pievienots tikai direktorijs /docs, un atkarībā no nodotajiem parametriem nekavējoties tiek pievienoti vajadzīgā taga vai pārskatīšanas saistības dati.

Lai izmantotu artefakta veidni, lai izveidotu kanālu un laidienu pārsūtīto versiju artefakta aprakstu, mainīgajam tiek organizēta cilpa. .WerfVersions в werf.yaml:

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

Jo cilpa ģenerēs vairākus artefaktus (mēs tā ceram), ir jāņem vērā atdalītājs starp tiem - secība --- (Papildinformāciju par konfigurācijas faila sintaksi skatiet sadaļā dokumentācija). Kā definēts iepriekš, izsaucot veidni cilpā, mēs nododam versijas parametrus, URL un saknes kontekstu.

Līdzīgi, bet bez cilpas, mēs saucam artefakta veidni “īpašiem gadījumiem”: saknes versijai, kā arī versijai no pārskatīšanas saistības:

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

Lūdzu, ņemiet vērā, ka artefakts pārskatīšanas saistībām tiks izveidots tikai tad, ja ir iestatīts mainīgais .WerfReviewCommit.

Artefakti ir gatavi — ir pienācis laiks sākt importēšanu!

Pēdējais attēls, kas paredzēts darbam ar Kubernetes, ir parasts NGINX ar pievienotu servera konfigurācijas failu nginx.conf un statiski no artefaktiem. Papildus vietnes saknes versijas artefaktam mums ir jāatkārto mainīgā cilpa .WerfVersions lai importētu kanālu un laidiena versiju artefaktus + ievērojiet artefaktu nosaukšanas noteikumu, ko mēs pieņēmām iepriekš. Tā kā katrā artefaktā tiek glabātas vietnes versijas divām valodām, mēs tās importējam konfigurācijas nodrošinātajās vietās.

Galīgā attēla apraksts 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 -}}

Papildu attēlā, kas kopā ar galveno tiek palaists izstrādes ķēdē, ir tikai divas vietnes versijas: versija no pārskatīšanas saistības un vietnes saknes versija (ir vispārīgi līdzekļi un, ja atceraties , izlaiduma dati). Tādējādi papildu attēls no galvenā atšķirsies tikai importa sadaļā (un, protams, nosaukumā):

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

Kā minēts iepriekš, artefakts pārskatīšanas saistībām tiks ģenerēts tikai tad, kad tiks palaists iestatītais vides mainīgais REVIEW_SHA. Ja nav vides mainīgā, werf-dev attēlu varētu neģenerēt vispār REVIEW_SHA, bet lai tīrīšana pēc politikām Docker attēli werf darbojās werf-dev attēlam, mēs atstāsim to veidot tikai ar saknes versijas artefaktu (tas jau ir uzbūvēts tik un tā), lai vienkāršotu cauruļvada struktūru.

Montāža ir gatava! Pāriesim pie CI/CD un svarīgām niansēm.

Cauruļvads GitLab CI un dinamiskās veidošanas funkcijas

Palaižot būvējumu, mums ir jāiestata izmantotie vides mainīgie werf.yaml. Tas neattiecas uz mainīgo REVIEW_SHA, ko iestatīsim, izsaucot konveijeru no GitHub āķa.

Mēs ģenerēsim nepieciešamos ārējos datus Bash skriptā generate_artifacts, kas ģenerēs divus GitLab cauruļvada artefaktus:

fails releases.yml ar izlaiduma datiem,
fails common_envs.sh, kas satur eksportējamos vides mainīgos.

Faila saturs generate_artifacts jūs atradīsiet mūsu krātuves ar piemēriem. Pati datu saņemšana nav raksta priekšmets, bet gan fails common_envs.sh mums ir svarīgi, jo no tā ir atkarīgs werfa darbs. Tās satura piemērs:

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'

Šāda skripta izvadi var izmantot, piemēram, izmantojot funkciju Bash source.

Tagad nāk jautrākā daļa. Lai gan lietojumprogrammas izveide, gan izvietošana darbotos pareizi, tas ir jānodrošina werf.yaml bija tas pats vismaz viena cauruļvada ietvaros. Ja šis nosacījums nav izpildīts, tad to posmu paraksti, kurus werf aprēķina montāžas un, piemēram, izvietošanas laikā, būs atšķirīgi. Tas radīs izvietošanas kļūdu, jo... izvietošanai nepieciešamā attēla trūks.

Citiem vārdiem sakot, ja vietnes attēla montāžas laikā informācija par laidieniem un versijām ir vienāda un izvietošanas laikā tiek izlaista jauna versija un vides mainīgajiem ir atšķirīgas vērtības, izvietošana neizdosies ar kļūdu: galu galā jaunās versijas artefakts vēl nav uzbūvēts.

Ja paaudze werf.yaml ir atkarīgs no ārējiem datiem (piemēram, pašreizējo versiju saraksta, kā mūsu gadījumā), tad šādu datu sastāvs un vērtības ir jāreģistrē cauruļvadā. Tas ir īpaši svarīgi, ja ārējie parametri mainās diezgan bieži.

Mēs būsim saņemt un ierakstīt ārējos datus cauruļvada pirmajā posmā GitLab (Iepriekšēja uzbūve) un pārsūtiet tos tālāk formā GitLab CI artefakts. Tas ļaus palaist un restartēt konveijera darbus (veidot, izvietot, tīrīt) ar tādu pašu konfigurāciju werf.yaml.

Skatuves saturs Iepriekšēja uzbūve failu .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

Pēc ārējo datu tveršanas artefaktā varat izveidot un izvietot, izmantojot standarta GitLab CI konveijera posmus: Build un Deploy. Mēs palaižam pašu cauruļvadu, izmantojot āķus no werf GitHub repozitorijas (t.i., kad GitHub repozitorijā ir izmaiņas). Datus par tiem var atrast GitLab projekta rekvizītos sadaļā CI/CD iestatījumi -> Cauruļvada aktivizētājiun pēc tam izveidojiet atbilstošo tīmekļa aizķeri GitHub (Iestatījumi -> Tīmekļa aizķeres).

Būvēšanas posms izskatīsies šādi:

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 pievienos divus artefaktus no skatuves izveides stadijai Iepriekšēja uzbūve, tāpēc mēs eksportējam mainīgos ar sagatavotiem ievades datiem, izmantojot konstrukciju source common_envs.sh. Mēs sākam būvniecības posmu visos gadījumos, izņemot cauruļvada palaišanu saskaņā ar grafiku. Atbilstoši grafikam izvadīsim cauruļvadu tīrīšanai - šajā gadījumā nav jāveic montāža.

Izvietošanas posmā mēs aprakstīsim divus uzdevumus — atsevišķi izvietošanai ražošanas un izstrādes shēmās, izmantojot YAML veidni:

.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

Uzdevumi būtībā atšķiras tikai ar to, ka tiek norādīts klastera konteksts, kurā werf jāveic izvietošana (WERF_KUBE_CONTEXT) un cilpas vides mainīgo iestatīšana (environment.name и environment.url), kuras pēc tam tiek izmantotas Helm diagrammas veidnēs. Veidņu saturu nesniegsim, jo... tur nav nekā interesanta par attiecīgo tēmu, bet tos var atrast raksta krātuves.

Galīgais pieskāriens

Tā kā werf versijas tiek izlaistas diezgan bieži, jauni attēli tiks veidoti bieži, un Docker reģistrs pastāvīgi pieaugs. Tāpēc ir obligāti jākonfigurē automātiskā attēla tīrīšana, pamatojoties uz politikām. Tas ir ļoti viegli izdarāms.

Lai īstenotu, jums būs nepieciešams:

Pievienojiet tīrīšanas darbību .gitlab-ci.yml;
Pievienojiet periodisku tīrīšanas uzdevuma izpildi;
Iestatiet vides mainīgo ar rakstīšanas piekļuves pilnvaru.

Tīrīšanas posma pievienošana .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

Gandrīz visu to jau esam redzējuši nedaudz augstāk – tikai lai to notīrītu, vispirms jāpiesakās Docker reģistrā ar marķieri, kuram ir tiesības dzēst attēlus Docker reģistrā (automātiski izsniegtais GitLab CI uzdevuma marķieris to nedara ir šādas tiesības). Tokens ir jāizveido GitLab iepriekš un tā vērtība jānorāda vides mainīgajā WERF_IMAGES_CLEANUP_PASSWORD projekts (CI/CD iestatījumi -> Mainīgie).

Tīrīšanas uzdevuma pievienošana ar nepieciešamo grafiku tiek veikta CI/CD ->
Grafiki.

Tas arī viss: projekts Docker reģistrā vairs nepārtraukti neizaugs no neizmantotiem attēliem.

Praktiskās daļas beigās atgādināšu, ka pilni saraksti no raksta ir pieejami Git:

Piedzīvojiet efektīvu rezultātu spēku

Mēs saņēmām loģisku montāžas struktūru: viens artefakts katrā versijā.
Montāža ir universāla un neprasa manuālas izmaiņas, kad tiek izlaistas jaunas werf versijas: dokumentācija vietnē tiek automātiski atjaunināta.
Divi attēli ir salikti dažādām kontūrām.
Tas darbojas ātri, jo Kešatmiņa tiek izmantota pēc iespējas vairāk — kad tiek izlaista jauna werf versija vai GitHub āķis tiek izsaukts pārskatīšanai, tiek pārbūvēts tikai atbilstošais artefakts ar mainīto versiju.
Nav jādomā par neizmantoto attēlu dzēšanu: tīrīšana saskaņā ar werf politikām uzturēs Docker reģistru kārtībā.

Atzinumi

Izmantojot werf, montāža var darboties ātri, jo tiek saglabāta kešatmiņa gan pašai montāžai, gan kešatmiņai, strādājot ar ārējām krātuvēm.
Strādājot ar ārējām Git krātuvēm, nav nepieciešams katru reizi klonēt visu repozitoriju vai no jauna izgudrot riteni, izmantojot sarežģītu optimizācijas loģiku. werf izmanto kešatmiņu un veic klonēšanu tikai vienu reizi un pēc tam izmanto fetch un tikai nepieciešamības gadījumā.
Iespēja izmantot Go veidnes būvējuma konfigurācijas failā werf.yaml ļauj aprakstīt montāžu, kuras rezultāts ir atkarīgs no ārējiem datiem.
Montāžas izmantošana werf ievērojami paātrina artefaktu vākšanu, pateicoties kešatmiņai, kas ir kopīga visiem cauruļvadiem.
werf ļauj viegli konfigurēt tīrīšanu, kas ir īpaši svarīgi, veidojot dinamiski.