Dockeri kujutiste dünaamiline kokkupanek ja juurutamine werf-iga, kasutades versioonitud dokumentatsiooni saidi näidet

Oleme oma GitOps tööriistast juba mitu korda rääkinud. werf, ja seekord tahaksime jagada kogemust veebisaidi kokkupanekust koos projekti enda dokumentatsiooniga - werf.io (selle venekeelne versioon on ru.werf.io). See on tavaline staatiline sait, kuid selle kokkupanek on huvitav selle poolest, et see on ehitatud dünaamilise hulga artefaktide abil.

Me ei süvene saidi struktuuri nüanssidesse: kõigi versioonide jaoks ühise menüü genereerimisse, versioonide kohta käiva teabelehe loomisesse jne. Selle asemel keskendume dünaamilise assembleri probleemidele ja funktsioonidele ning veidi ka sellega kaasnevatele CI/CD protsessidele.

Sissejuhatus: Kuidas sait töötab

Alustame sellest, et WERF-i dokumentatsioon salvestatakse koos selle koodiga. See seab arendusele teatud nõuded, mis üldiselt jäävad selle artikli raamidest välja, aga vähemalt saame öelda, et:

• Uusi Werf-funktsioone ei tohiks avaldada ilma dokumentatsiooni uuendamata ja vastupidi, kõik muudatused dokumentatsioonis tähendavad Werf-i uue versiooni avaldamist;
• Projektil on üsna intensiivne arendustegevus: uusi versioone saab välja anda mitu korda päevas;
• Kõik käsitsi tehtavad toimingud saidi juurutamiseks uue dokumentatsiooniversiooniga on vähemalt tüütud;
• Projekt kasutab semantilist lähenemist versioonide koostamine, 5 stabiilsuskanaliga. Väljalaskeprotsess hõlmab versioonide järjestikust läbimist kanalite kaudu stabiilsuse suurenemise järjekorras: alfast kivikõvaks;
• Saidil on venekeelne versioon, mis „elab ja areneb” (st mille sisu uueneb) paralleelselt põhiversiooniga (st ingliskeelsega).

Et varjata kogu seda „sisemist tööd“ kasutaja eest ja pakkuda talle midagi, mis „lihtsalt töötab“, tegime eraldi tööriist Werfi installimiseks ja värskendamiseks - Kas multiwerfSa pead lihtsalt määrama väljalaske numbri ja stabiilsuskanali, mida oled valmis kasutama, ning multiwerf kontrollib, kas kanalil on uus versioon ja vajadusel laadib selle alla.

Werfi uusimad versioonid on saadaval iga kanali versioonivaliku menüüs saidil. Vaikimisi aadressil werf.io/dokumentatsioon avatakse uusima versiooni kõige stabiilsem kanaliversioon – seda indekseerivad ka otsingumootorid. Kanali dokumentatsioon on saadaval eraldi aadressidel (näiteks werf.io/v1.0-beta/dokumentatsioon beetaversiooni 1.0 jaoks).

Kokku on saidil saadaval järgmised versioonid:

1. root (avaneb vaikimisi),
2. iga väljalaske iga aktiivse uuenduskanali kohta (nt werf.io/v1.0-beta).

Saidi konkreetse versiooni genereerimiseks piisab üldiselt selle kompileerimisest, kasutades Jekyll, töötab kataloogis /docs werf hoidla vastav käsk (jekyll build), olles eelnevalt vajaliku versiooni Git-sildile lülitunud.

Jääb üle vaid lisada, et:

• montaažiks kasutatakse utiliiti ennast (werf);
• CI/CD protsessid on üles ehitatud GitLab CI baasil;
• ja kõik see töötab muidugi Kuberneteses.

ülesanded

Nüüd sõnastame ülesanded, mis võtavad arvesse kõiki kirjeldatud eripärasid:

1. Pärast Werf-versiooni muutmist mis tahes uuenduskanalil saidi dokumentatsioon peaks automaatselt uuenema.
2. Arenemiseks pead sa vahel suutma vaata saidi eelvaateid.

Saidi uuesti kompileerimine tuleb läbi viia pärast mis tahes kanali versiooni muutmist vastavatest Giti siltidest, kuid pildi kokkupaneku käigus saame järgmised funktsioonid:

• Kuna kanalite versioonide loend muutub, on vaja dokumentatsioon uuesti luua ainult nende kanalite jaoks, kus versioon on muutunud. Lõppude lõpuks pole kõige nullist uuesti loomine eriti ilus.
• Väljalasete kanalite komplekt võib muutuda. Näiteks ei pruugi mingil ajahetkel olla kanalites versiooni, mis oleks stabiilsem kui varajase juurdepääsuga 1.1 väljalase, kuid need ilmuvad aja jooksul – sel juhul ei saa järku käsitsi muuta, eks?

Selgub, et assamblee sõltub väliste andmete muutmisest.

Реализация

Lähenemisviisi valimine

Teise võimalusena saate iga vajaliku versiooni käivitada eraldi podina Kuberneteses. See valik tähendab klastris suuremat objektide arvu, mis kasvab koos stabiilsete WERF-versioonide arvu suurenemisega. Ja see omakorda tähendab keerukamat hooldust: igal versioonil on oma HTTP-server väikese koormusega. Loomulikult toob see kaasa ka suuremad ressursikulud.

Me läksime sama teed kõigi vajalike versioonide järgud ühes pildisSaidi kõigi versioonide kompileeritud staatika asub NGINX-iga konteineris ja liiklus vastavasse juurutusse tuleb NGINX Ingressi kaudu. Lihtne struktuur – olekuteta rakendus – võimaldab teil juurutust (sõltuvalt koormusest) Kubernetes'i enda abil hõlpsalt skaleerida.

Täpsemalt öeldes ehitame kaks pilti: ühe tootmisahela jaoks ja teise arendusahela jaoks. Lisapilti kasutatakse (käitatakse) ainult arendusahelas koos põhipildiga ning see sisaldab saidi versiooni ülevaate commit'ist ja nende vaheline marsruutimine toimub Ingress-ressursside abil.

Werf vs Git kloon ja artefaktid

Nagu mainitud, peate dokumentatsiooni konkreetse versiooni saidi staatiliste andmete genereerimiseks ehitama, lülitudes vastavale repositooriumi sildile. Seda saab teha ka repositooriumi iga ehitamise ajal kloonides, valides loendist vastavad sildid. See on aga üsna ressursimahukas toiming ja nõuab lisaks mittetriviaalsete juhiste kirjutamist... Teine tõsine puudus on see, et selle lähenemisviisi korral pole ehitamise ajal võimalik midagi vahemällu salvestada.

Siin tuleb meile appi Werfi utiliit ise, rakendades nutikas vahemällu salvestamine ja võimaldab teil kasutada välised repositooriumid. Repositooriumist koodi lisamine funktsiooniga werf kiirendab oluliselt ehitust, kuna werf kloonib repositooriumi sisuliselt üks kord ja seejärel käivitub ainult fetch vajadusel. Lisaks saame hoidlast andmeid lisades valida ainult vajalikud kataloogid (meie puhul on see kataloog docs), mis vähendab oluliselt lisatavate andmete hulka.

Kuna Jekyll on staatiliste failide kompileerimiseks loodud tööriist ja seda pole lõplikus pildis vaja, oleks loogiline see kompileerida artefakti werfja lõplikul pildil impordi ainult kompileerimise tulemus.

Me kirjutame werf.yaml

Seega otsustasime iga versiooni koostada eraldi Werf-artefaktina. Siiski me me ei tea, kui palju neid esemeid kokkupaneku ajal tekib, seega me ei saa kirjutada fikseeritud ehituskonfiguratsiooni (rangelt võttes saame, aga see poleks eriti efektiivne).

werf võimaldab teil kasutada Mine mallidele oma konfiguratsioonifailis (werf.yaml) ja see teeb võimalikuks genereeri konfiguratsioon "lennult" sõltuvalt välisandmetest (mida me vajame!). Meie puhul on välisandmed teave versioonide ja väljalasete kohta, mille põhjal kogume vajaliku arvu esemeid ja saame tulemuseks kaks pilti: werf-doc и werf-dev erinevate vooluringide käivitamiseks.

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

• RELEASES — rida väljalasete loendi ja vastava WERFi praeguse versiooniga, mis on tühikutega eraldatud väärtuste loend kujul <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Näide: 1.0%v1.0.4-beta.20
• CHANNELS — rida kanalite loendi ja vastava WERFi praeguse versiooniga, mis on tühikutega eraldatud väärtuste loendi kujul vormingus <КАНАЛ>%<НОМЕР_ВЕРСИИ>... Näide: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — werf väljalaske versiooni kuvamine saidil vaikimisi (dokumentatsiooni kuvamine suurima väljalaske numbri järgi pole alati vajalik). Näide: v1.0.4-beta.20
• REVIEW_SHA — ülevaatuse commit'i räsi, millest testringi versioon tuleks ehitada.

Need muutujad täidetakse GitLabi CI torujuhtmes ja täpset kirjeldust leiate allpool.

Esiteks, mugavuse huvides, määratleme werf.yaml Mine mallimuutujatele, määrates neile keskkonnamuutujate väärtused:

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

Saidi staatilise versiooni kompileerimise artefakti kirjeldus on üldiselt kõigil vajalikel juhtudel sama (sh nii juurversiooni kui ka dev-contouri versiooni genereerimine). Seetõttu viime selle funktsiooni abil eraldi plokki. define — hilisemaks taaskasutamiseks abiga includeEdastame mallile järgmised argumendid:

• Version — genereeritud versioon (sildi nimi);
• Channel — uuenduskanali nimi, mille jaoks artefakt genereeritakse;
• Commit — commit hash, kui artefakt genereeritakse ülevaatuse 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 nimi peab olema unikaalne. Selle saavutamiseks võime näiteks lisada kanali nime (muutuja väärtus .Channel) artefakti nime järelliitena: artifact: doc-{{ .Channel }}Kuid peate mõistma, et artefaktidest importimisel peate viitama samadele nimedele.

Artefakti kirjeldamisel kasutatakse järgmist werf-tunnust: paigaldusPaigaldamine määratud teenusekataloogiga. build_dir võimaldab teil säilitada Jekylli vahemälu torujuhtme käivitamiste vahel, mis kiirendab oluliselt kokkupanekut.

Võib-olla olete märganud ka faili kasutamist releases.yml — on YAML-fail, mille väljalaskeandmeid on taotletud Github.com (torujuhtme käivitamisel saadud artefakt). Seda on vaja saidi kompileerimisel, kuid artikli kontekstis on see meile huvitav, kuna selle olek sõltub ainult ühe artefakti uuesti kokkupanek — saidi juurversiooni artefakt (seda pole teistes artefaktides vaja).

See rakendatakse tingimusliku operaatori abil. if Mine mallidele ja konstruktsioonidele {{ $Root.Files.Get "releases.yml" | sha256sum }} etapis etapidSee toimib nii: juurversiooni artefakti loomisel (muutuja .Channel võrdub root) faili räsi releases.yml mõjutab kogu etapi signatuuri, kuna see on Ansible'i ülesande nime komponent (parameeter name). Seega, kui muutute sisu faili releases.yml vastav artefakt pannakse uuesti kokku.

Palun pöörake tähelepanu ka välise hoidlaga töötamisele. Artefakti pildil saidilt Werf-hoidlad, lisatakse ainult kataloog /docsja olenevalt edastatud parameetritest lisatakse koheselt vajaliku sildi või ülevaate commit'i andmed.

Artefakti malli kasutamiseks ülekantud kanali versioonide ja väljalasete artefakti kirjelduse genereerimiseks korraldame tsükli muutujate kaupa .WerfVersions в werf.yaml:

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

Kuna tsükkel genereerib mitu artefakti (loodame nii), on vaja arvestada nende eraldajaga - järjestus --- (lisateavet konfiguratsioonifaili süntaksi kohta leiate jaotisest dokumentatsioon). Nagu me varem defineerisime, edastame tsüklis malli kutsumisel versiooniparameetrid, URL-i ja juurkonteksti.

Samamoodi, aga ilma tsüklita, nimetame artefakti malli "erilisteks juhtudeks": nii juurversiooni kui ka ülevaatuse 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 }}

Pane tähele, et ülevaatuse kinnituse artefakt luuakse ainult siis, kui muutuja on seatud. .WerfReviewCommit.

Artefaktid on valmis – aeg importima hakata!

Kuberneteses töötamiseks mõeldud lõplik pilt on tavaline NGINX, millele on lisatud serveri konfiguratsioonifail. nginx.conf ja staatika artefaktidest. Lisaks saidi juurversiooni artefaktile peame tsüklit kordama ka muutuja kaupa .WerfVersions Kanali ja väljalaskeversiooni artefaktide importimiseks + järgige varem vastu võetud artefaktide nimetamise reeglit. Kuna iga artefakt salvestab saidi versioonid kahes keeles, impordime need konfiguratsioonis etteantud asukohtadesse.

Lõpliku werf-doc pildi kirjeldus

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

Lisapilt, mis käivitatakse arendusringkonnas koos põhipildiga, sisaldab ainult kahte saidi versiooni: ülevaatemuudatuse versiooni ja saidi juurversiooni (see sisaldab ühiseid ressursse ja, kui mäletate, siis ka väljalaskeandmeid). Seega erineb lisapilt põhipildist ainult impordiosa (ja muidugi 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 eespool märgitud, genereeritakse ülevaatuse kinnituse artefakt ainult keskkonnamuutuja set käivitamisel. REVIEW_SHAKui keskkonnamuutujat pole, oleks võimalik werf-dev-kujutist üldse mitte genereerida. REVIEW_SHA, aga selleks, et koristamine eeskirjade järgi Werf-i Dockeri kujutised toimisid werf-dev kujutise puhul, jätame selle ehitamiseks ainult juurversiooni artefakti (see on niikuinii juba ehitatud), et lihtsustada torujuhtme struktuuri.

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

GitLabi CI torujuhe ja dünaamilise ehituse funktsioonid

Ehituse käivitamisel peame määrama keskkonnamuutujad, mida kasutatakse werf.yamlSee ei kehti muutuja REVIEW_SHA kohta, mille me määrame torujuhtme kutsumisel GitHubi konksu kaudu.

Vajalike väliste andmete moodustamise viime üle Bash-skripti. generate_artifacts, mis genereerib kaks GitLabi torujuhtme artefakti:

• faili releases.yml koos väljalaskeandmetega
• faili common_envs.sh, mis sisaldab eksporditavaid keskkonnamuutujaid.

Faili sisu generate_artifacts leiad meie näidetega repositooriumidAndmete kogumine ise ei ole artikli teema, vaid fail. common_envs.sh on meile oluline, kuna sellest sõltub Werfi toimimine. 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'

Sellise skripti väljundit saab kasutada näiteks Bash-funktsiooni abil. source.

Nüüd tuleb kõige huvitavam osa. Selleks, et nii rakenduse kokkupanek kui ka juurutamine toimiksid korrektselt, on vaja veenduda, et werf.yaml oli sama vähemalt ühe torujuhtme seesKui see tingimus ei ole täidetud, siis on Werfi poolt assembleri ja näiteks juurutamise ajal arvutatud etapi signatuurid erinevad. See viib juurutamisveani, kuna juurutamiseks vajalik kujutis puudub.

Teisisõnu, kui saidi kujutise kokkupaneku ajal on teave väljaannete ja versioonide kohta sama ning juurutamise ajal avaldatakse uus versioon ja keskkonnamuutujatel on erinevad väärtused, siis lõpeb juurutamine veaga: uue versiooni artefakti pole ju veel kokku pandud.

Kui põlvkond werf.yaml sõltub välistest andmetest (näiteks praeguste versioonide loendist, nagu meie puhul), siis tuleks selliste andmete koostis ja väärtused torujuhtmes registreerida. See on eriti oluline, kui välised parameetrid muutuvad üsna sageli.

Me saame väliste andmete vastuvõtmine ja salvestamine GitLabi torujuhtme esimeses etapis (Eelnevalt koostatud) ja edastage need edasi kujul GitLabi CI artefaktidSee võimaldab teil sama konfiguratsiooniga käivitada ja taaskäivitada torujuhtme ülesandeid (ehita, juurutada, puhastada). werf.yaml.

Lava sisu Eelnevalt koostatud faili .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

Kui artefaktis on fikseeritud välised andmed, saate selle luua ja juurutada GitLabi CI torujuhtme standardsete etappide abil: loomine ja juurutamine. Torujuhtme ise käivitame Werfi GitHubi repositooriumi konksude abil (st kui GitHubi repositooriumis on muudatusi). Nende andmed saab võtta GitLabi projekti omadustest jaotises CI/CD seaded -> Pipeline'i päästikudja seejärel looge vastav veebikonks GitHubis (Seaded -> Veebikonksud).

Ehitusetapp näeb välja selline:

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 ehitusetapile kaks etapi artefakti Eelnevalt koostatud, seega ekspordime muutujad ettevalmistatud sisendandmetega konstruktsiooni abil source common_envs.shKäivitame ehitusetapi kõigil juhtudel, välja arvatud torujuhtme käivitamine vastavalt ajakavale. Graafiku kohaselt käivitame torujuhtme puhastamiseks – sel juhul pole ehitust vaja teostada.

Juurutamisetapis kirjeldame kahte ülesannet – eraldi juurutamiseks tootmis- ja arendusringkondadesse, 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 põhimõtteliselt ainult klastri konteksti näitamise poolest, kuhu Werf peaks juurutamise teostama (WERF_KUBE_CONTEXT) ja kontuuri keskkonnamuutujate määramine (environment.name и environment.url), mida seejärel kasutatakse Helmi diagrammimallides. Me ei avalda mallide sisu, kuna vaadeldava teema kohta pole seal midagi huvitavat, kuid need leiate siit artikli repositooriumid.

Lõplik puudutus

Kuna WERF-i versioone avaldatakse üsna tihti, luuakse sageli uusi kujutisi ja Dockeri register kasvab pidevalt. Seetõttu on vaja seadistada automaatne kujutiste puhastamine poliitikate abil. Seda on väga lihtne teha.

Rakendamiseks vajate:

• Lisage puhastusetapp .gitlab-ci.yml;
• Lisage puhastusülesande perioodiline täitmine;
• Seadistage keskkonnamuutuja kirjutamisõigusega tunnusega.

Lisa puhastusetapp .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

Oleme peaaegu kõike seda eespool juba näinud – ainult et selle puhastamiseks peate esmalt Docker Registrysse sisse logima tokeniga, millel on õigused Docker Registrys pilte kustutada (GitLab CI ülesande automaatselt väljastatud tokenil selliseid õigusi pole). Token tuleb GitLabis eelnevalt luua ja selle väärtus tuleb keskkonnamuutujas määrata. WERF_IMAGES_CLEANUP_PASSWORD projekti (CI/CD seaded -> Muutujad).

Nõutava ajakavaga puhastusülesande lisamine toimub CI/CD ->
Kavad.

See on kõik: teie Dockeri registriprojekt ei kasva enam pidevalt kasutamata piltidest.

Praktilise osa lõpetuseks tahaksin teile meelde tuletada, et artikli täielikud loetelud on saadaval aadressil Git:

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

Tulemus

1. Saime loogilise assamblee struktuuri: üks artefakt versiooni kohta.
2. Assamblee on universaalne ega vaja Werfi uute versioonide väljaandmisel käsitsi muudatusi: saidi dokumentatsioon uueneb automaatselt.
3. Erinevate kontuuride jaoks kogutakse kaks pilti.
4. See toimib kiiresti, kuna vahemällu salvestamist kasutatakse maksimaalselt – kui avaldatakse uus werfi versioon või kutsutakse GitHubi konksu ülevaatuse commit'iks, luuakse uuesti ainult vastav artefakt koos muudetud versiooniga.
5. Pole vaja muretseda kasutamata piltide kustutamise pärast: Werfi poliitikapõhine puhastus hoiab teie Dockeri registri korras.

Järeldused

• Werfi kasutamine võimaldab ehitusel kiiresti töötada tänu nii ehituse enda kui ka väliste repositooriumidega töötamise vahemällu salvestamisele.
• Väliste Giti repositooriumidega töötamine välistab vajaduse repositooriumi iga kord täielikult kloonida või keerulise optimeerimisloogika abil jalgratast leiutada. Werf kasutab vahemälu ja kloonib ainult üks kord ning seejärel kasutab fetch ja ainult siis, kui see on hädavajalik.
• Võimalus kasutada Go malle ehituskonfiguratsioonifailis werf.yaml võimaldab kirjeldada assambleed, mille tulemus sõltub välistest andmetest.
• Werfis paigaldamise kasutamine kiirendab oluliselt artefaktide kogumist - tänu vahemälule, mis on kõigile torujuhtmetele ühine.
• werf teeb puhastamise seadistamise lihtsaks, mis on eriti oluline dünaamiliste versioonide puhul.

PS

Loe ka meie blogist:

• «Käskude käivitamine uue rakenduse väljalaske ajal Kuberneteses";
• «Ehitage ja juurutage werfi ja GitLab CI-ga sama tüüpi mikroteenuseid";
• «werfi kasutamine keeruliste Helmi diagrammide väljarullimiseks";
• «Tutvustame werf 1.0 stabiilset: mis on GitOpsil sellega pistmist, olek ja plaanid'.

Allikas: www.habr.com