Dünaamiline Docker-piltide koostamine ja deployimine werf'i abil versioonitud dokumentatsiooni saidi näitel

Oleme juba korduvalt rääkinud oma GitOps-tööriistast werf, kuid seekord soovime jagada kogemusi projekti dokumentatsiooniga saidi koostamisest — werf.io (tema venekeelne versioon — ru.werf.io). See on tavaline staatiline sait, kuid selle kogumine on huvitav, kuna see on üles ehitatud dünaamilise arvu artefaktide kasutamisega.

Saidistruktuuri nüanssidele: kõigi versioonide jaoks ühtse menüü genereerimine, väljalaskeinfo lehed jne — ei hakka laskuma. Selle asemel keskendume dünaamilise kogumise küsimustele ja omadustele ning veidi ka sellega seotud CI/CD protsessidele.

Sissejuhatus: kuidas sait töötab

Alustame sellest, et dokumentatsioon werf'i kohta hoitakse koos tema koodiga. See seab arendusele teatud nõuded, mis ületavad käesoleva artikli raame, kuid vähemalt võib öelda, et:

• Uued werf'i funktsioonid ei tohi ilmuda ilma dokumentatsiooni värskendamiseta ja vastupidi, dokumentatsiooni muutused eeldavad uue werf'i versiooni väljalaskmist;
• Projektis on üsna intensiivne arendus: uusi versioone võib tulla mitu korda päevas;
• Käigu kaudu uue dokumentatsiooni versiooniga saidi juurutamiseks manuaalsed toimingud on vähemalt väsitavad;
• Projektis on vastu võetud semantilise lähenemisega versioonihalduse, viie stabiilsuskanaliga. Väljalaskeprotsess hõlmab versioonide järjestikust läbimist kanalite kaudu stabiilsuse tõstmise järjekorras: alphas kuni rock-solid;
• Saidil on venekeelne versioon, mis "elab ja areneb" (st mille sisu uuendatakse) paralleelselt põhiversiooniga (st ingliskeelse versiooniga).

Kuna peame kasutajalt kogu selle "sisemise köögi" varjama, pakkudes talle lihtsalt toimivat lahendust, oleme teinud eraldi installi ja värskendamise tööriista werf'i jaoks — see on multiwerf. Piisab ainult vabastamisnumbrist ja stabiilsuskanali valimisest, mida olete valmis kasutama, ja multiwerf kontrollib, kas kanalil on uus versioon ja laadib selle vajadusel alla.

Saitide versioonide valimise menüüs on saadaval viimased werf'i versioonid igas kanalis. Vaikimisi avatakse aadressil werf.io/documentation kõige stabiilsema kanali versioon viimasele väljaandele — samuti indekseeritakse see otsingumootorites. Kanalite dokumentatsioon on saadaval eraldi aadressidel (näiteks, werf.io/v1.0-beta/documentation beta väljaande 1.0 jaoks).

Kokkuvõttes on saidil saadaval järgmised versioonid:

1. juure (avajalik),
2. iga aktiivse värskenduse kanali jaoks iga versiooni jaoks (näiteks, werf.io/v1.0-beta).

Spetsiifilise veebilehe versiooni genereerimiseks piisab üldjuhul selle kompileerimise tegemisest Jekyll, käivitades vastava käsu kataloogis /docs werf'i hoidlas (jekyll build), enne kui vahetate vajalikule versioonile Git-sildi.

Olgu lisatud, et:

• kompileerimisel kasutatakse ise utiliiti (werf);
• CI/CD protsessid on rajatud GitLab CI peale;
• ja see kõik töötab muidugi Kuberneteses.

Ülesanded

Formuleerime nüüd ülesanded, arvestades kogu kirjeldatud spetsiifikat:

1. Pärast werf'i versiooni vahetamist igal värskenduste kanalil dokumendid veebilehe peal peavad automaatselt uuenduma.
2. Arenduseks peab olema võimalus aeg-ajalt vaadata veebilehe eelvaateid.

Veebilehe ümberkompileerimine peab toimuma pärast versiooni vahetamist igal kanalil vastavatelt Git-siltidelt, kuid pildi koostamise protsessis saame järgmised omadused:

• Kuna versioonide loetelu kanalites muutub, tuleb ümberkompileerimise teha ainult nende dokumentide jaoks, kus versioon on muutunud. Lõppude lõpuks ei ole ilus kõike uuesti kokku panna.
• Vabade versioonide komplekt võib muutuda. Teatud hetkel võib näiteks mitte olla versiooni stabiilsemates kanalites, nagu varakult juurdepääs 1.1, kuid aja jooksul need ilmuvad — ei ole ju mõtet sellisel juhul kogumist käsitsi muuta?

Selgub, et kompileerimine sõltub muutuvaid väliseid andmeid.

Rakendamine

Lähenemisviisi valik

Alternatiivina võib iga vajaliku versiooni käivitada eraldi pod'ina Kuberneteses. Selline lahendus hõlmab suuremat objekti arvu klastris, mis kasvab koos wersi stabiilsete väljaannetega. Ja see omakorda toob kaasa keerukama hoolduse: igal versioonil on oma HTTP-server, kuid väikese koormusega. Muidugi toob see endaga rohkem ressursikulu.

Me läksime teed kõigi vajalike versioonide kokku kompileerimise ühe pildina. Kõikide veebilehe versioonide kompileeritud staatika asub NGINX konteineris ja vastav liiklus jõuab vastava rakenduse kaudu NGINX Ingress'i. Lihtne struktuur — stateless-rakendus — võimaldab kergesti skaleerida rakendust (sõltuvalt koormusest) Kubernetes'i enda vahenditega.

Kui olla täpsem, siis kogume kaks pilti: üks production-joone jaoks, teine — lisaks, dev-joone jaoks. Täiendavat pilti kasutatakse (käivitatakse) ainult dev-joonel koos põhiga ning see sisaldab veebilehe versiooni ülevaate commit'ist, samas kui suunamine nende vahel toimub Ingress-resursside kaudu.

werf vs git clone ja artefaktid

Nagu juba mainitud, et genereerida veebilehe staatika konkreetse dokumentatsiooni versiooni jaoks, tuleb teha ülesehitus, lülitudes vastavasse repositooriumi silti. Seda oleks võimalik teha ka repositooriumi kloonimise teel iga kord ülesehitamise ajal, valides sobivad sildid loendist. Siiski on see üsna ressursimahukas tegevus ning nõuab keerukate juhiste kirjutamist... Teine tõsine miinus on see, et sellisel lähenemisel pole võimalik midagi ülesehitamise ajal vahemällu salvestada.

Siin tuleb meile appi itse utiliit werf, mis rakendab nutikat vahemällu salvestamist ja võimaldab kasutada välishoidlaid. Werfi kasutamine koodi lisamiseks repositooriumist kiirendab ülesehitust märgatavalt, kuna werf kloonib repositooriumi põhimõtteliselt ühe korra ja seejärel teeb ta seda fetch vajadusel. Lisaks, andmete lisamisel repositooriumist saame valida ainult vajalikud kataloogid (meie puhul on see kataloog docs), mis vähendab oluliselt lisatavate andmete hulka.

Kuna Jekyll on tööriist staatika kompileerimiseks ja pole vajalik lõpppildis, oleks mõistlik teostada kompileerimine werf artefaktis, ja lõpppildisse importida ainult kompileerimise tulemus..

Kirjutame werf.yaml

Nii et oleme otsustanud, et kompileerime iga versiooni eraldi werf artefakti. Kuid me ei tea, kui palju neist artefaktidest ülesehitamise ajal tuleb, seetõttu ei saa me kirjutada fikseeritud ülesehituse konfiguratsiooni (tegelikult saame, aga see pole kuigi efektiivne).

werf võimaldab kasutada Go-malle oma konfiguratsioonifailis (werf.yaml), mis annab võimaluse luua konfi "režiimis" sõltuvalt välistest andmetest (just seda, mida vajame!). Välistena esindavad meie puhul versioonide ja väljaannete teave, mille põhjal koondame vajaliku arvu artefakte ja saame tulemuseks kaks pilti: werf-doc ja werf-dev erinevatel joonetel käivitamiseks.

Välised andmed edastatakse keskkonna muutujate kaudu. Nende koostis on järgmine:

• RELEASES — rida vabastuste loendist ja vastava versiooni werf'i praegusest versioonist, loendina koos väärtuste vahelise tühikuga formaadis %. Näidis: 1.0%v1.0.4-beta.20
• CHANNELS — rida kanalite loendist ja vastava versiooni werf'i praegusest versioonist, loendina koos väärtuste vahelise tühikuga formaadis %. Näidis: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — werf'i versioon, mis kuvatakse vaikimisi veebilehel (ei ole alati vajalik kuvada dokumentatsiooni kõrgeima versiooni järgi). Näide: v1.0.4-beta.20
• REVIEW_SHA — review-commit'i hash, millest tuleb genereerida versioon testimise kontuurile.

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

Esmalt, mugavuse huvides, määrame werf.yaml Go-muutujate, andes neile väärtused keskkonna muutujatest:

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

Artefaktiloend versiooni staatikas on peaaegu kõigis vajalikutes juhtudel (sealhulgas, juureversiooni ja dev-kontuuride versioonide genereerimisel) sama. Seetõttu toome selle eraldi plokki funktsiooni kaudu define — edasise uuesti kasutamise võimaldamiseks include. Mallile edastame järgmised argumendid:

• Version — genereeritud versioon (sildi nimi);
• Kanal — uuenduste kanali nimi, 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 }}

Artefaktil peab olema ainulaadne. Selle saavutamiseks saame näiteks lisada kanali nime (muutuja .Channel) artefakti nime sufiksina: artifact: doc-{{ .Channel }}. Kuid tuleb mõista, et artefaktid importimisel tuleb viidata samadele nimedele.

Artefakti kirjelduseks kasutatakse werf'i funktsiooni mounting. Määrates teenuse kausta build_dir , saab Jekyll'i cache'i säilitada pipeline'ide käivituste vahel, mis kiirendab oluliselt uuesti koostamist..

Samuti võisite märgata faili releases.yml — see on YAML-fail, mis sisaldab andmeid versioonide kohta, mis pärinevad github.com (artefakt, mis saadakse pipeline'i käivitamise käigus). See on vajalik saidi koostamisel, aga artiklis on meie jaoks see huvitav, et selle seisund mõjutab ainult ühe artefakti uuesti koostamist — artefakti, mis on peamise versiooni sait (muid esemeid ei ole vaja).

See on realiseeritud tingimuslikku operaatorit kasutades if Go-mallid ja konstruktsioon {{ $Root.Files.Get "releases.yml" | sha256sum }} staadiumis etapp. See how it works: during the assembly of the artifact for the root version (variable .Channel võrdne root) the file hash releases.yml affects the signature of the entire stage, as it is a component of the Ansible task name (parameter nimi). Thus, when changing the content failist releases.yml the corresponding artifact will be rebuilt.

Also note the work with the external repository. In the artifact image from the werf repository, only the directory /docsis added, depending on the provided parameters, the data of the required tag or review commit is added.

To use the artifact template for generating descriptions of the artifact for the given versions of channels and releases, we organize a loop over the variable .WerfVersions ja werf.yaml:

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

Since the loop will generate several artifacts (we hope for this), we need to consider the separator between them — the sequence --- (for more details on the configuration file syntax see dokumentatsioon). As established earlier, when calling the template in the loop, we pass the parameters of the version, URL, and root context.

Similarly, but without a loop, we call the artifact template for 'special cases': for the root version, as well as for the version from the 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 }}

Note that the artifact for the review commit will only be assembled if the variable is set .WerfReviewCommit.

The artifacts are ready — it's time to tackle the import!

The final image intended for deployment in Kubernetes is a regular NGINX, into which a server configuration file nginx.conf and static files from the artifacts are added. In addition to the root version artifact of the site, we need to repeat the loop over the variable .WerfVersions for importing the artifacts of the channel and release versions + adhere to the naming rule for artifacts, which we accepted earlier. Since each artifact stores site versions for two languages, we import them into the locations provided by the configuration.

Description of the final image 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 -}}

Lisandväljund, mis koos põhimõttelisega käivitatakse dev-kontuuris, sisaldab ainult kahte versiooni veebilehest: versiooni review-kohustusest ja veebilehe juurveebiversioon (seal on ühised varad ja, kui mäletate, andmed versioonide kohta). Seega erineb lisandväljund põhimõttelisest ainult importimise sektsiooni poolest (ja loomulikult nimest):

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 tähele pandud, genereeritakse review-kohustuse artefakt ainult siis, kui on seadistatud keskkonnamuutuja REVIEW_SHA. Üldiselt ei oleks werf-dev väljundi genereerimist üldse vaja, kui keskkonnamuutujat pole REVIEW_SHA, kuid selleks, et poliitikat mööda koristamine Docker-väljundites werfis töötaks werf-dev-i puhul, jätame selle toimetama ainult juurveebiversiooni artefaktiga (niikuinii on see juba koostatud), et lihtsustada torustiku struktuuri.

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

Torustik GitLab CI-s ja dünaamilise koostamise eripärad

Koostamise käivitamisel peame seadistama keskkonnamuutujad, mida kasutatakse werf.yaml. See ei hõlma muutujaid REVIEW_SHA, mille seadistame torustiku käivitamisel GitHubi kettast.

Vajaduste väliste andmete genereerimise viime Bash-skriptisse generate_artifacts, mis genereerib kaks artefakti GitLabi torustikus:

• fail releases.yml versioonide andmetega,
• fail common_envs.sh, mis sisaldab ekspordiks mõeldud keskkonnamuutujaid.

Faili sisu generate_artifacts leiate meie näidisveebide repos. Andmete hankimine ei ole artikli teema, kuid fail common_envs.sh on meie jaoks oluline, kuna see mõjutab werfi tööd. Näidis tema 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 väljundit saab kasutada näiteks Bash-funktsiooni kaudu source.

Ja nüüd kõige huvitavam osa. Et nii rakenduse koostamine kui ka juurutamine töötaksid õigesti, on hädavajalik tagada, et werf.yaml oli on ühesugune vähemalt ühes pipeline'is. Kui seda tingimust ei täideta, siis kudu stages'i allkirjad, mida werf koostamisel ja näiteks juurutamisel arvutab, on erinevad. See toob kaasa juurutusvea, kuna vajalik juurutamiseks mõeldud pilt puudub.

Teisisõnu, kui saidi pildi koostamise ajal on väljaannete ja versioonide teave üks, kuid juurutamise hetkel ilmub uus versioon ja keskkonna muutujatel on muud väärtused, siis juurutus ebaõnnestub: uus versioon pole veel koostatud.

Kui genereerimine werf.yaml sõltub välistest andmetest (näiteks kehtivate versioonide nimekirjast, nagu meie puhul), siis selliste andmete koosseis ja väärtused peavad olema fikseeritud pipeline'i raames. See on eriti oluline, kui välised parameetrid muutuvad üsna sageli.

Me saame väliseid andmeid hankida ja fikseerida pipeline'i esimeses etapis GitLabis (Prebuild) ja edastame need edasi GitLab CI arhiivina. See võimaldab käivitada ja uuesti käivitada pipeline'i ülesandeid (koostamine, juurutamine, puhastamine) sama konfiguratsiooni alusel werf.yaml.

Etapi sisu Prebuild failist .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älised andmed arhivaidina, saab läbi viia koostamise ja juurutamise kasutades GitLab CI standardseid etappe: Build ja Deploy. Me käivitame pipeline'i GitHubi werfi repositooriumi hüdrofooride kaudu (st. muudatuste korral GitHubis). Nende jaoks saab andmeid võtta GitLab projekti seadete alt, andmeosa CI / CD seadistused -> Pipeline'i käivitajad, seejärel loome GitHubis vastava Webhook'i (Settings -> Webhooks).

Koostamisetapp näeb välja järgmine:

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 lisab koostamisetappi kaks arhivaati eelnevalt staadiumist Prebuild, nii et eksporteerime muutujad ettevalmistatud sisendandmete kaudu source common_envs.sh. Käivitame kogumise etappi kõigis olukordades, välja arvatud ajastatud torujuhtme käivitamise puhul. Ajakava alusel käivitatakse meil torujuhe puhastamiseks — sel juhul ei ole kogumine vajalik.

Deployimise etapis kirjeldame kahte ülesannet — eraldi production- ja dev-kontuuride deployimiseks, kasutades YAML-malli:

.base_deploy: &base_deploy
  etapp: deploy
  skript:
    - 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
  sõltuvused:
    - Eelnevalt ehitatud
  välja arvatud:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  muutujad:
    WERF_KUBE_CONTEXT: prod
  keskkond:
    nimi: production
    url: werf.io
  ainult:
    refs:
      - master
  välja arvatud:
    muutujad:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  muutujad:
    WERF_KUBE_CONTEXT: dev
  keskkond:
    nimi: test
    url: werf.test.flant.com
  välja arvatud:
    refs:
      - schedules
  ainult:
    muutujad:
      - $REVIEW_SHA

Ülesanded erinevad põhimõtteliselt ainult klastrikonteksti määramise poolest, kuhu werf peaks deployima (WERF_KUBE_CONTEXT), ja keskkonna muutujate määramise (environment.name ja environment.url), mis seejärel kasutatakse Helm-uudiste mallides. Mallide sisu ei hakka tooma, kuna seal ei ole meie arutatud teema jaoks midagi huvitavat, kuid neid saate leida artikli hoidlast.

Lõppviimistlus

Kuna werfi versioonid ilmuvad üsna tihti, ilmuvad ka uued pildid tihti ning Docker Registry suureneb pidevalt. Seetõttu on kohustuslik konfigureerida piltide automaatne puhastamine poliitikate järgi. Seda on väga lihtne teha.

Rakendamiseks on vajalik:

• Lisada puhastamise etapp .gitlab-ci.yml;
• Lisada puhastamise ülesande perioodiline täitmine;
• Seada keskkonnamuutuja kirjutamiseks oma juurdepääsu tokeniga.

Lisame puhastamise etapi .gitlab-ci.yml:

Cleanup:
  etapp: cleanup
  skript:
    - 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
  ainult:
    refs:
      - schedules

Peaaegu kõik, mida me juba varem nägime — puhastamiseks tuleb eelnevalt Docker Registry'sse autoriseeruda tokeniga, mis omab õigusi piltide kustutamiseks Docker Registry's (automaatsetelt genereeritud tokenitel, mis on GitLabi CI ülesannete jaoks välja antud, selliseid õigusi ei ole). Token tuleb eelnevalt GitLabis registreerida ja selle väärtus määrata keskkonnamuutujas WERF_IMAGES_CLEANUP_PASSWORD projekti (CI/CD seadistused -> Muutujad).

Puhastamise ülesande lisamine vajaliku ajastusega toimub CI/CD ->
Ajakavad.

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

Praktika lõpus meenutan, et artikli täielikud nimekirjad on saadaval Git:

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

Tulemus

1. Meil on loogiline ehitusstruktuur: üks artefakt ühe versiooni jaoks.
2. Kogumine on universaalne ja ei vaja käsitsi muudatusi uute werf versioonide väljalaskmisel: dokumentatsioon veebilehel värskendatakse automaatselt.
3. Kogutakse kaks pilti erinevate kontuuride jaoks.
4. Töötab kiiresti, kuna maksimaalselt kasutatakse vahemälu — uue werf versiooni väljalaskmisel või GitHub hook'i kutsumise ajal review-commit'i jaoks — toimub ainult vastava artefakti ümberkoostmine muudetud versiooniga.
5. Ei pea muretsema kasutamata piltide eemaldamise pärast: werf poliitikate järgi puhastamine toetab korda Docker Registry's.

Järeldused

• Werf'i kasutamine võimaldab kogemisel töötada kiiresti, tänu nii koondamise vahemälule kui ka väliste hoidlate töö käigus toimuvatele vahemäludele.
• Töötamine väliste Git-hoidlate puhul vabastab vajadusest kloonida hoidlat iga kord täielikult või leiutada ratast nutika optimeerimisloogikaga. werf kasutab vahemälu ja kloonib ainult ühe korra ning seejärel kasutab fetch ja ainult vajadusel.
• Go-mallide kasutamise võimalus ehituskonfiguratsiooni failis werf.yaml võimaldab kirjeldada ehitamist, mille tulemus sõltub välistest andmetest.
• Werf'i mountimist kasutamine kiirendab oluliselt artefaktide kogumist — tänu vahemälule, mis on ühine kõigi pipeline'ide jaoks.
• Werf lihtsustab puhastamise seadistamist, mis on eriti oluline dünaamilise kogumise korral.

P.S.

Lugege ka meie blogist:

• «Käsu käivitamine rakenduse uue versiooni tarnimise protsessis Kubernetes'i»;
• «Ühtsete mikroteenuste ehitamine ja juurutamine werf'i ja GitLab CI abil»;
• «werf-i kasutamine keerukate Helm-chartide jaoks»;
• «Esitleme werf 1.0 stabiilset versiooni: mis on GitOps, olek ja plaanid».

Allikas: habr.com