Dünaamiline Docker-piltide kogumine ja juurutamine werf abil versioonitud dokumentatsiooni veebisaidi näitel

Oleme juba korduvalt rääkinud oma GitOps tööriistast werf, seekord tahame jagada kogemusi projekti dokumentatsiooniga saidi koostamisest — werf.io (tema venekeelne versioon — ru.werf.io). See on tavaline staatiline veebileht, kuid selle koostamine on huvitav selle poolest, et see on üles ehitatud dünaamiliste artefaktide arvuga.

Ei hakka süvenema saidi struktuuri nüanssidesse: ühise menüü genereerimine kõigi versioonide jaoks, väljalaskeinfot sisaldavad lehed jms — jääme selle kõrval. Selle asemel keskendume dünaamilise koosseisu küsimustele ja omadustele ning veidi ka CI/CD seotud protsessidele.

Sissejuhatus: kuidas veebisait on üles ehitatud

Alustame sellest, et werfi dokumentatsioon on salvestatud koos tema koodiga. See seab arendusele teatud nõuded, mis ületavad üleüldiselt selle artikli raamistikku, kuid vähemalt võib öelda, et:

• Werfi uued funktsioonid ei tohiks ilmuda ilma dokumentatsiooni uuendamiseta ja vastupidi, dokumentatsiooni muudatused eeldavad uue werfi versiooni väljalaskmist;
• Projektis toimub üsna intensiivne arendus: uusi versioone võib välja tulla mitu korda päevas;
• Igasugused käsitsi teostatavad toimingud saidi juurutamiseks koos uue dokumentatsiooni versiooniga on vähemalt kurnavad;
• Projektis on kasutusel semantilise versioonihalduse, kus on 5 stabiilsuse kanalit. Väljalaskmisprotsess hõlmab versioonide järkjärast liikumist kanalite kaudu stabiilsuse tõstmise järjekorras: alfaloomingust kuni rock-solid tasemeni;
• Saidil on olemas venekeelne versioon, mis "elab ja areneb" (st selle sisu uuendatakse) paralleelselt peamise (st ingliskeelse) versiooniga.

Kuna soovime varjata kasutajalt kogu selle "siseellu", pakkudes talle seda, mis "lihtsalt töötab", oleme loonud eraldi installimise ja värskendamise tööriista werf — see on multiwerf. Piisab, kui näitate väljaandmise numbrit ja stabiilsuse kanalit, mida olete valmis kasutama, ja multiwerf kontrollib, kas kanalil on uus versioon, ning allalaadib selle vajadusel.

Versioonide valimise menüüs on saidil saadaval viimased werfi versioonid igas kanalil. Vaikselt, aadressil werf.io/documentation avatakse kõige stabiilsema kanali versioon viimase väljaande jaoks — see on ka indekseeritud otsingumootorites. Kanali dokumentatsioon on saadaval eraldi aadressidel (näiteks, werf.io/v1.0-beta/documentation beta-väljaande 1.0).

Kokku on saidil saadaval järgmised versioonid:

1. juurkataloog (avatakse vaikimisi),
2. iga aktiivse värskenduse kanali jaoks iga väljaande puhul (näiteks, werf.io/v1.0-beta).

Konkreetse saidi versiooni genereerimiseks piisab üleüldiselt selle kompileerimise teostamisest vahenditega Jekyll, käivitades vastava käsu werfi kataloogis ( /docs jekyll build), eelnevalt lülitudes vajaliku versiooni Git-sildile.), предварительно переключившись на Git-тег необходимой версии.

Peab veel lisama, et:

• koostamiseks kasutatakse utiliiti (werf);
• CI/CD-protsessid on üles ehitatud GitLabi CI põhjal;
• ja kõik see töötab loomulikult Kuberneteses.

Ülesanded

Nüüd formuleerime ülesanded, arvestades kogu eespool toodud spetsiifikat:

1. Pärast versiooni muutmist werfi mõnel värskenduste kanalil peab saidi dokumentatsioon automaatselt värskendama.
2. Arendamiseks peab olema võimalik aeg-ajalt vaadata saidi eelvaate versioone.

Veebisaidi ümberkompileerimist tuleb teha pärast versiooni muutmist igas kanalis vastavatest Git-märkidest, kuid pildi loomise protsessis saame järgmistest omadustest:

• Kuna versioonide loetelu kanalites muutub, tuleb ümberkompileerida ainult dokumentatsioon neile kanalitele, kus versioon on muutunud. Lõppude lõpuks ei ole kõike uuesti ümberkompileerimine just ilus.
• Väljalaskekanalite komplekt võib samuti muutuda. Mõnel hetkel, näiteks, ei pruugi olla versiooni kanalis, mis on stabiilsem kui varase juurdepääsu versioon 1.1, kuid aja möödudes need ilmuvad - ei saa ju selle tõttu käsitsi koostamist muuta?

Selgub, et koostamine sõltub muutuvatest välistest andmetest.

Rakendus

Lähenemise valik

Ühe võimalusena võib käivitada iga vajaliku versiooni eraldi pod'ina Kuberneteses. See lahendus eeldab suuremat objektide arvu klastris, mis kasvab stabiilsete werf'i väljalaskete arvu suurenedes. See tähendab aga keerukamat hooldust: iga versiooni jaoks tekib oma HTTP-server, millel on väike koormus. Loomulikult toob see kaasa suuremad ressursikulud.

Käisime oma teed kõikide vajalike versioonide kogumine ühes pildis. Kõikide saidi versioonide kompileeritud staatika asub NGINX-i konteineris ning vastav liiklus jõuab Deployment'ile läbi NGINX Ingress'i. Lihtne struktuur — staateless-rakendus — võimaldab kerge vaevaga skaleerida Deployment'i (koos koormusega) Kubernetes'i enda vahenditega.

Kuna olla täpsem, kogume me kaks pilti: üks — tootmisvoolu jaoks, teine — täiendav, arendusvoolu jaoks. Täiendav pilt kasutatakse (käivitatakse) ainult arendusvoolus koos peamisega ning sisaldab saidi versiooni ülevaatamise commit'ist, samas kui marsruudistamine nende vahel toimub Ingress'i ressursside abil.

werf vs git clone ja artefaktid

Nagu juba mainitud, tuleb veebisaidi staatika genereerimiseks konkreetse dokumendi versiooni jaoks teha ehitus, vahetades vastavasse tag'i repos. Seda võiks teha ka, kloonides reposse iga kord ehituse ajal ja valides vastavad tag'id loendist. Kuid see on üsna ressursimahukas tegevus ja lisaks vajab keeruliste juhiste kirjutamist... Teine tõsine miinus on see, et sellise lähenemise korral ei ole võimalik ehituse ajal midagi vahemällu talletada.

Siin aitab meid utiliit werf, mis realiseerib nutikat vahemällu salvestamist ja võimaldab kasutada välist reposid. Werf'i kasutamine koodi lisamiseks reposse kiirendab ehitust oluliselt, kuna werf teeb põhimõtteliselt kloonimise reposse ainult üks kord ja seejärel täidab ainult fetch vajaduse korral. Lisaks, andmete lisamisel reposse saame valida vaid vajalikud kataloogid (meie puhul on see kataloog docs), mis vähendab oluliselt lisatavate andmete mahtu.

Kuna Jekyll on tööriist, mis on mõeldud staatika kompileerimiseks ja ei ole lõpppildis vajalik, oleks mõistlik teha kompileerimine werf-i artefaktis, ja lõpppildis importida ainult kompileerimise tulemus.

Kirjutame werf.yaml

Seega oleme otsustanud, et kompileerime iga versiooni eraldi werf-i artefakti. Siiski, me ei tea, kui palju neid artefakte ehitamisel tuleb, seega ei saa me kirjutada fikseeritud ehitusk.Configuatsiooni (tegelikult saame, kuid see ei oleks tõhus).

werf võimaldab kasutada Go-malle oma konfiguratsioonifailis (werf.yaml), mis annab võimaluse generate config ‘on the fly’ sõltuvalt välistest andmetest (mida vajame!). Välisteks andmeteks on meie puhul versioonide ja väljaannete teave, mille alusel kogume vajaliku arvu artefakte ja saame tulemusena kaks pilti: werf-doc ja werf-dev mille käivitamiseks erinevates ringides.

Välimised andmed edastatakse keskkonnamuutujate kaudu. Siin on nende koostisosad:

• RELEASES — string, mis sisaldab väljaannete nimekirja ja nende vastavat jooksvaid werf versiooni, loetletuna tühikute kaudu väärtuste loendina formaadis %. Näide: 1.0%v1.0.4-beta.20
• KANALID — rida kanalite loetlemiseks ja vastava werf'i versiooniga, väärtuste loetelu tühikute kaudu formaadis %. Näide: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — werf'i väljalaskeversioon, mis kuvatakse vaikimisi veebilehel (ei pruugi alati kuvada dokumentatsiooni kõrgeimale väljaannetele). Näide: v1.0.4-beta.20
• REVIEW_SHA — review-commit'i hash, millest versioon testiringi jaoks kokku panna.

Need muutujad täidetakse GitLab CI pipeline'is, kuidas täpselt — on antud allpool.

Esmalt mugavuse huvides määrame werf.yaml Go-muutujate ülesannetes, omistades neile väärtused keskkonnamuutujatest:

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

Arhitektuuri kirjeldamine, et koostada versiooni staatika veebilehe jaoks, on kõigi vajalike meie jaoks juhtumite puhul sama (sealhulgas juureversiooni genereerimine ja versioon dev-kontuurile). Seetõttu paneme selle eraldi plokki määrata — edaspidiseks korduvkasutamiseks kasutades include. Malli edastame järgmised argumendid:

• Versioon — genereeritud versioon (sildi nimi);
• Kanal — värskenduste kanali nime, mille jaoks artefakt genereeritakse;
• Commit — commit-i hash, kui artefakt genereeritakse review-commit-i jaoks;
• kontekst.

Artefakti malli kirjeldus

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

Artefakti nimetus peab olema ainulaadne. Selle saavutamiseks saame näiteks lisada kanali nime (muutuja väärtus .Channel) artefakti nime suffiksina: artifact: doc-{{ .Channel }}. Kuid tuleb mõista, et artefaktide importimisel tuleb viidata sama nimetusele.

Artefakti kirjeldamisel kasutatakse sellist võimalust nagu werf, nimelt mounting. Mountimisega, mis määrab teeninduskausta build_dir , saab säilitada Jekylli vahemälu pipeline'i käivituste vahel, mis kiirendab uuesti koostamist oluliselt.

Te võisite samuti märgata faili releases.yml — see on YAML-fail, mis sisaldab andmeid väljaanne kohta ja mida küsitakse github.com (artefakt, mis saadakse pipeline'i töö käigus). See on vajalik saidi koostamisel, kuid artikli kontekstis on see meie jaoks huvitav, kuna selle seisund mõjutab ainult ühe artefakti uuesti koostamist — juurversiooni saidi artefakti (teistes artefaktides ei ole see vajalik).

See on teostatud tingimusliku operaatori if Go-mallide ja konstruktsiooni {{ $Root.Files.Get "releases.yml" | sha256sum }} etapis faasis. See töötab järgmiselt: juurversiooni artefakti koostamisel (muutuja .Channel 为 root) faili räsiväärtus releases.yml mõjutab kogu etapi signatuuri, kuna see on osa Ansible ülesande nimest (parameeter name). Seega, kui muudame sisu faile releases.yml , vastav artefakt saab uuesti ehitatud.

Pange tähele ka tööd välise reposiga. Artefakti pildile repozitooriumist werf, lisatakse ainult kataloog /docs, kus sõltuvalt edastatud parameetritest lisatakse andmed kohe vajaliku sildi või review-commit'i kohta.

Kui soovite kasutada artefakti mallina edastatud versioonide kanalite ja väljalaskete kirjelduste genereerimiseks, korraldame tsükli muutuja .WerfVersions ühes werf.yaml:

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

Kuna tsükkel genereerib mitmeid artefakte (loodame seda), tuleb arvesse võtta nende vahel olevat eraldajat — järjestus --- (konfiguratsioonifaili süntaksist vt dokumentatsioonis). Nagu eelnevalt kokku leppisime, edastame malle kutsumisel versiooni, URL-i ja juurkonteksti parameetrid.

Sarnaselt, kuid juba ilma tsüklita, kutsume artefakti malli "erijuhtumite" jaoks: juurversiooni ja samuti review-commit'i versiooni jaoks:

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

Pange tähele, et ülevaate commit'i artefakt kogutakse ainult siis, kui muutuja .WerfReviewCommit.

Artefaktid on valmis — aeg importimiseks!

Lõplik pilt, mis on mõeldud töötama Kubernetes'is, on tavaline NGINX, kuhu on lisatud serveri konfiguratsioonifail nginx.conf ja staatika artefaktidest. Lisaks põhiversiooni artefaktile peame kordama tsüklit muutuja .WerfVersions ümber importimisel kanalite ja väljaannete artefaktide jaoks + järgima artefaktide nimetamisseisu, mille me varem kokku leppisime. Kuna iga artefakt salvestab saidi versioonid kahes keeles, importime need kohtadesse, mida on ette nähtud konfiguratsioonis.

Werf-doc lõpppildi kirjeldus

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Seadistamine /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 -}}

Täiendav pilt, mis käivitatakse koos peamisega dev-kontuuris, sisaldab ainult kahte versiooni veebisaidist: versiooni ülevaate commitist ja peamise versiooni (seal on ühised ressursid ja, kui mäletate, andmed väljaandmistest). Seega erineb täiendav pilt peamisest ainult impordi sektsiooni poolest (no ja, loomulikult nime poolest):

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

Nagu juba eespool mainitud, genereeritakse review-commit'i artefakt ainult siis, kui keskkonna muutuja on seadistatud REVIEW_SHA. Werf-dev pilti oleks võinud üldse mitte genereerida, kui keskkonna muutujat ei ole REVIEW_SHA, kuid selleks, et poliitikate kohaselt puhastamine Docker-pilte werf’is, töötaks werf-dev'i pilt, jätame selle kogumise vaid põhiversiooni artefaktiga (nii või teisiti on see juba kokku pandud), et lihtsustada pipeline'i struktuuri.

Kogumine on valmis! Liigume edasi CI/CD ja oluliste nüansside juurde.

Pipeline GitLab CI-s ja dünaamilise kogumise eripära

Kogumise käivitamisel peame seadistama keskkonna muutujad, mida kasutatakse werf.yaml. See ei puuduta muutujaid REVIEW_SHA, mille seadistame GitHub'i hook'i kaudu pipeline'i käivitamisel.

Vajalikud välised andmed viime Bash-skripti generate_artifacts, mis genereerib kaks GitLab pipeline'i artefakti:

• fail releases.yml väljaande andmetega,
• fail common_envs.sh, sisaldav keskkonnamuutujaid eksportimiseks.

Faili sisu generate_artifacts leiate meie näidiste hoidlast. Andmete saamine ei ole artikli teema, kuid fail common_envs.sh on meile oluline, sest sellel sõltub werf'i töö. Näide selle sisust:

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'

Seda skripti saab kasutada näiteks Bash-funktsiooni abil source.

Ja nüüd kõige huvitavam. Et nii ehitus kui ka rakenduse juurutamine toimiksid õigesti, on vajalik tagada, et werf.yaml oleks samad vähemalt ühe pipeline'i raames. Kui seda tingimust ei täideta, siis on werf'i arvutatud etappide allkirjad, mis on vajalikud ehitamiseks ja näiteks juurutamiseks, erinevad. See põhjustab juurutamisviga, kuna vajalik juurutamispilt puudub.

Teisisõnu, kui saidi pildi ehitamise ajal on versioonide ja väljalasketeave sama, aga juurutamise hetkel tuleb välja uus versioon ning keskkonnamuutujad omavad teisi väärtusi, siis juurutamine ebaõnnestub: uus versioon ei ole veel kokku pandud.

Kui genereerimine werf.yaml sõltub välistest andmetest (nt, kehtivate versioonide nimekirjast, nagu meie puhul), seega peavad sellised andmed olema fikseeritud pipeline'i raames. See on eriti oluline, kui välistingimused muutuvad üsna tihti.

Me hakkame saama ja fikseerima välistandmeid pipeline'i esimeses etapis GitLabis (Prebuild) ja edastama need edasi GitLab CI artefakti. See võimaldab käivitada ja uuesti käivitada pipeline'i ülesandeid (konstruktsioon, paigaldamine, puhastus) sama konfiguratsiooniga werf.yaml.

Etapi sisu Prebuild faile .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

Fikseerides välistanded artefakis, saab teostada konstruktsiooni ja paigaldamist, kasutades GitLab CI standardseid etappe: Build ja Deploy. Pipeline'i käivitame me GitHubi repository'st werf (st. kui muudatused tehakse GitHubi repository's). Andmed nende jaoks saab võtta GitLabi projekti omadustest jaotisest CI / CD Settings -> Pipeline triggers, ja seejärel loome GitHubis vastava Webhook'i (Settings -> Webhooks).

Konstruktsiooni etapp näeb välja järgmine:

Ehita:
  etapp: ehita
  skript:
    - tüüp multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - tüüp werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  välja arvatud:
    refs:
      - ajakavad
  sõltuvused:
    - Eelkontroll

GitLab lisab ehitusetappi kaks artefakti eelkontrollist Prebuild, nii et eksportime muutujaid ettevalmistatud sisendandmetega, kasutades konstruktsiooni source common_envs.sh. Käivitame ehitusetapi igasugustes olukordades, välja arvatud ajakava alusel. Ajakava alusel käivitatakse meil puhtuse tööprotsess — sel juhul pole ehitust vaja teostada.

Deployment-etapis kirjeldame kahte ülesannet - eraldi ümbritsemiseks production- ja dev-kontuuridele, kasutades YAML-malli:

.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

Ülesanded erinevad sisuliselt ainult klastrikonteksti määramise poolest, kuhu werf peab deploy’d tegema (WERF_KUBE_CONTEXT), ja keskkonna muutujate seadistamise poolest (environment.name ja environment.url), mida kasutatakse seejärel Helm-chart'ide mallides. Mallide sisu ei too, kuna seal pole midagi huvitavat käsitletud teema jaoks, aga võite need leida artikli reposti.

Viimane puudutus

Kuna werf värskendused ilmuvad üsna tihti, siis uusi pilte luuakse sageli ning Docker Registry kasvab pidevalt. Seetõttu on oluline seadistada automaatne piltide puhastamine poliitikate järgi. See on väga lihtne.

Teostamiseks on vajalik:

• Lisa puhastamise etapp .gitlab-ci.yml;
• Lisa puhastamisülesande regulaarne täitmine;
• Seadista keskkonnamuutus kirjutamise pääsupiletiga.

Lisame puhastamise etapi .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

Peaaegu kõik see on juba varem nähtud — puhastamiseks tuleb Docker Registry'sse eelnevalt autentida pääsupiletiga, millel on õigused piltide kustutamiseks Docker Registry's (automaatsetele GitLabi CI tööde väljastatud pääsupiletitel ei ole selliseid õigusi). Pääsupilet tuleb GitLabis eelnevalt luua ja selle väärtus keskkonnamuutujas määrata. WERF_IMAGES_CLEANUP_PASSWORD projekt (CI/CD Settings -> Variables).

Puhastamisülesande lisamine vajaliku ajakava järgi toimub CI/CD ->
Ajakavad.

See on kõik: projekt Docker Registry's ei kasva enam pidevalt kasutamata piltide tõttu.

Praktilise osa lõpetuseks tuletan meelde, et täielikud loetelud artiklist on saadaval Git:

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

Tulemus

1. Oleme saanud loogilise kogumise struktuuri: üks artefakt ühe versiooni kohta.
2. Kogumine on universaalne ega nõua käsitsi muudatusi uute werf versioonide ilmumisel: dokumentatsioon veebis uuendatakse automaatselt.
3. Kogutakse kaks pilti erinevate kontuuride jaoks.
4. Töötab kiiresti, kuna kasutada maksimaalselt vahemälu — uue werf versiooni ilmumisel või GitHubi hook'i aktiveerimisel review-commit'i jaoks — uuendatakse ainult vastava artefakti, mille versioon on muutunud,.
5. Ei pea muretsema kasutamata piltide eemaldamise pärast: werf'i poliitikate järgi puhastamine hoiab Docker Registrys korras.

Järeldused

• Werf'i kasutamine võimaldab kogumisel töötada kiiresti, tänu nii kogumise enda kui ka väliste hoidlate töö käigus toimuvatele vahemäludele.
• Töötamine väliste Git-hoidlate kaudu vabastab vajadusest kloonida hoidlat iga kord täielikult või leiutada jalgratast keeruka optimeerimise loogikaga. Werf kasutab vahemälu ja teeb kloonimist ainult kord, edaspidi kasutab fetch ja ainult vajadusel.
• Go-mallide kasutamise võimalus kogumise konfiguratsioonifailis werf.yaml võimaldab kirjeldada kogumist, mille tulemus sõltub välistest andmetest.
• Montaažide kasutamine werfis kiirendab oluliselt artefaktide kogumist — tänu kettale, mis on kõigi pipeline'ide jaoks ühine.
• werf võimaldab lihtsalt seadistada puhastust, mis on eriti oluline dünaamilise kogumise korral.

P.S.

Lugege ka meie blogist:

• «Käivitamine käskude protsessis uue rakenduse versiooni toimetamisel Kubernetesesse»;
• «Ühesuguste mikroteenuste kogumine ja juurutamine werfi ja GitLab CI-ga.»;
• «Werfi kasutamine keerukate Helm-chart'ide välja toomiseks»;
• «Esitleme werf 1.0 stable: mis on GitOps'i, staatuse ja plaanide seos».

Allikas: habr.com