Már többször beszéltünk a GitOps-eszközünkről , ebben az alkalomban pedig a projekt saját dokumentációjával készült weboldal összeállításának tapasztalatait szeretnénk megosztani — (orosz nyelvű verziója — ). Ez egy szokványos statikus weboldal, azonban az összeállítása érdekes, mert dinamikus számú artefaktum felhasználásával készült.
Nem részleteznénk a weboldal struktúrájának árnyalatait: a közös menü generálása minden verzióhoz, a kiadásokkal kapcsolatos információs oldalak stb. — ehelyett a dinamikus összeállítás kérdéseire és sajátos folyamataira, valamint a CI/CD digitális folyamataira koncentráljunk.
Bevezetés: hogyan működik a weboldal
Kezdjük azzal, hogy a werf dokumentáció együtt tárolódik a kódjával. Ez bizonyos követelményeket támaszt a fejlesztés irányában, amelyek túlnyúlnak a jelen cikk keretein, de legalább annyit elmondhatunk, hogy:
- A werf új funkcióinak kiadása dokumentáció frissítése nélkül nem megengedett, és fordítva, bármilyen változtatás a dokumentáción új werf verzió kiadását vonja magával;
- A projekt fejlődése meglehetősen intenzív: új verziók naponta többször is megjelenhetnek;
- Bármely kézi művelet a weboldal kiadására új dokumentációval legalább fárasztó;
- A projektben szemantikus alkalmaznak, 5 stabilitási csatornával. A kiadási folyamat a verziók fokozatos áthaladását jelenti a csatornákon a stabilitás növekedésének érdekében: alpha-tól a rock-solid-ig;
- A weboldalnak van orosz nyelvű verziója, amely „él és fejlődik” (azaz a tartalma frissül) párhuzamosan az alap (azaz angol nyelvű) verzióval.
Hogy eltitkoljuk a felhasználó elől ezt a „belső munkát”, felajánlva neki azt, ami „egyszerűen működik”, létrehoztunk külön eszközt a werf telepítésére és frissítésére — ez . Elég megadni a kiadás számát és azt a stabilitási csatornát, amelyet hajlandó vagy használni, a multiwerf pedig ellenőrzi, van-e új verzió a csatornán, és szükség esetén letölti azt.
A weboldalon verzióválasztási menüben a werf legutóbbi verziói elérhetők minden csatornában. Alapértelmezetten a következő címen a legstabilabb csatorna legutóbbi kiadásának verziója nyílik meg — ez az, ami keresőmotorok által is indexelve van. A dokumentáció a csatorna külön címeken is elérhető (például az 1.0 beta kiadás számára).
Összességében a weboldal a következő verziókban érhető el:
- alapértelmezett (automatikusan nyílik meg),
- minden aktív frissítési csatornára minden verzió esetén (például, ).
A weboldal konkrét verziójának generálásához általában elegendő a eszközeivel való fordítás, amelyet a /docs werf tárolójának megfelelő parancsával indíthatunk el (jekyll build), először a szükséges verzió Git-címkéjére váltva.
Csupán annyit kell hozzátenni, hogy:
- a fordításhoz a maga utilitása (werf) használatos;
- A CI/CD folyamatok a GitLab CI alapjain épülnek;
- és mindez természetesen Kubernetesben működik.
Feladatok
Most fogalmazzuk meg a feladatokat, figyelembe véve a fent leírt specifikációt:
- A werf verziójának bármely frissítési csatornára váltásakor a weboldal dokumentációnak automatikusan frissülnie kell.
- A fejlesztéshez szükséges, hogy néha előzetes verziókat tekintsünk meg a weboldalon.
A weboldal újbóli lefordítása szükséges bármely verziócsatorna Git-címkéjének váltása után, de a kép buildelése során a következő jellemzők merülnek fel:
- Mivel a csatornákon a verziók listája változik, csak azokat a dokumentációkat kell újraépíteni, ahol a verzió megváltozott. Hiszen az összes újbóli építés nem túl szép.
- A kiadások csatornáinak készlete is változhat. Egy pillanatban például nem lehet verzió az egyes early-access kiadások stabil csatornáin, de idővel ezek megjelennek — ebben az esetben nem kellene manuálisan megváltoztatni az építést?
Ezért a az építés változó külső adatoktól függ.
Megvalósítás
Megközelítés választása
Alternatívaként minden szükséges verziót indíthatunk külön pod-ként a Kubernetesben. Ez a megoldás több objektumot feltételez a klaszterben, amely a werf stabil kiadásainak számának növekedésével növekedni fog. Ez pedig bonyolultabb karbantartást jelent: minden verzió saját HTTP szerverével rendelkezik, és ez csak kis terhelés mellett zajlik. Természetesen ez nagyobb erőforrásigényekkel jár.
Mi azonban az utat választottuk az összes szükséges verzió egy képen belüli összerakásához. Az összegyűjtött statikus összes verziót egy NGINX konténer tartalmazza, és a forgalom az adott Deploymenthez az NGINX Ingress-en keresztül érkezik. Az egyszerű struktúra — státusztalan alkalmazás — lehetővé teszi a Deployment könnyű skálázását (a terhelés függvényében) a Kubernetes eszközeivel.
Ha pontosabbak legyünk, két képet készítünk: egyet a production környezethez, egy másikat pedig a fejlesztéshez. A második kép csak a fejlesztési környezetben használandó a főképpel együtt, és a review-commit verzióját tartalmazza, a két verzió közötti irányítást pedig Ingress erőforrásokkal végezzük.
werf vs git clone és artefaktumok
Ahogy már említettük, ahhoz, hogy statikus weboldalt generáljunk egy adott dokumentációs verzióhoz, le kell fordítani a megfelelő repo tagre váltva. Ezt meg lehetne tenni úgy is, hogy minden buildnél klónozzuk a repót, választva a megfelelő tageket a listából. Azonban ez egy meglehetősen erőforrás-igényes művelet, és ráadásul összetett utasítások írását igényli… Egy másik jelentős hátrány, hogy ezzel a megközelítéssel nincsen lehetőség cache-elésre a build során.
Itt segítségünkre siet a werf eszköz, amely megvalósítja intelligens cache-elést és lehetővé teszi . A werf használata a kód repóból való hozzáadására jelentősen felgyorsítja a buildet, mivel a werf alapvetően egyszer klónozza a repót, majd szükség esetén végrehajtja a a fő DB példányhoz fetch-t . Továbbá, amikor adatokat adunk hozzá a repóból, csak a szükséges könyvtárakat választhatjuk ki (a mi esetünkben ez a docs), ami jelentősen csökkenti a hozzáadott adatok mennyiségét.
Mivel a Jekyll egy statikus fordításra készült eszköz, és nem szükséges a végső képen, logikus lenne a fordítást a , a végső képhez pedig csak a fordítás eredményét importálni. Írjuk meg a werf.yaml-t.
Tehát eldöntöttük, hogy minden verziót külön werf artefaktumban fogunk fordítani. Azonban
nem tudjuk, hány artefaktum lesz a build során , ezért nem tudunk fix build konfigurációt írni (szigorúan véve tudunk, de ez nem lenne teljesen hatékony).A werf lehetővé teszi a
Go sablonok használatát ), és ez lehetőséget ad arra, hogywerf.yamla configot "futás közben" generáljuk külső adatok alapján (ez az, amire szükség van!). Külső adatok jelen esetben a verziók és kiadások információja, amely alapján az szükséges számú artefaktumot összegyűjtjük, és végül két képet kapunk: werf-doc werf-dev és werf-dev különböző kontúrokon történő indításhoz.
A külső adatok környezeti változókon keresztül kerülnek átadásra. Az összetevőik a következők:
-
KIADÁSOK— a kiadások listáját tartalmazó sor, valamint a megfelelő aktuális verziója a werf-nek, szóközök által elválasztott értékek listájaként formátumban%. Példa:1.0%v1.0.4-beta.20 -
CSATORNÁK— a csatornák listáját tartalmazó sor, valamint a megfelelő aktuális verziója a werf-nek, szóközök által elválasztott értékek listájaként formátumban%. Példa:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
GYÖK_VERSIÓ— a werf kiadás verziója, amely alapértelmezés szerint a webhelyen jelenik meg (nem mindig szükséges a legmagasabb kiadási szám dokumentációjának megjelenítése). Példa:v1.0.4-beta.20 -
VÉLEMÉNY_SHA— a review-commit hash, amelyből az adott verziót össze kell állítani a teszt kontúrnál.
Ezeket a változókat a GitLab CI pipeline-ban fogják kitölteni, az, hogy miként — az alább olvasható.
Első lépésként, a kényelem érdekében, meghatározzuk a werf.yaml Go sablon változókat, értékeket rendelve hozzájuk a környezeti változókból:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} A statikus verzió ar artefaktum leírása gyakorlatilag azonos minden szükséges esetben (beleértve a gyökér verzió generálását, valamint a dev kontúrt is). Ezért külön blokkba helyezzük a define — a későbbi újrahasználás céllal include. A sablonnak a következő argumentumokat fogjuk átadni:
-
Verzió— a generált verzió (címke neve); -
Csatorna— a frissítési csatorna neve, amelyhez az artefaktumot generálják; -
Commit— a commit hash, ha az artefaktum review commitra lett generálva; - környezet.
Az artefaktum sablon leírása
{{- 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/hu_site/
- file:
dest: /app/docs/pages_hu/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/_hu_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_hu.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 }} A dokumentum artefaktumának egyedinek kell lennie. Ezt elérhetjük például a csatorna nevének hozzáadásával (a változó értéke .Channel) az artefaktum nevéhez: artifact: doc-{{ .Channel }}. Fontos megérteni, hogy az artefaktumok importálásakor hasonló nevekre kell hivatkozni.
Az artefaktum leírásához a werf lehetőségei között szerepel a . A mountálás a következő szolgáltatási könyvtár megadásával build_dir lehetővé teszi a Jekyll gyorsítótárának megőrzését a pipeline indításai között, ami jelentősen felgyorsítja a rebuild folyamatot..
Azt is észlelhette, hogy a releases.yml fájl használatáról van szó — ez egy YAML fájl, amely a kiadásokról szóló adatokat tartalmaz és eza (Az artefaktum, amely a pipeline futtatása során keletkezik). Szükséges a weboldal fordításához, de a cikk szempontjából releváns, hogy az állapota alapján csak egy artefaktum újraépítése — a gyökérverzió weboldalának artefaktuma (más artefaktumoknál nincs szükség rá).
Ez a logikai operátor segítségével valósul meg, if Go sablonok {{ $Root.Files.Get "releases.yml" | sha256sum }} a szakaszban . Ez így működik: amikor egy artefaktumot készítünk a gyökérverzióhoz (változó .Channel egyenlő , felhasználó nevében fut, mivel alapvető rendszerbeállításokat módosítanak, de a WordPress közvetlenül egy normál felhasználóként működik.) a fájl hash-e releases.yml hatással van az egész szakasz aláírására, mivel ez képezi az Ansible-feladat nevének összetevőjét (paraméter name). Ezért, ha megváltozik a tartalom fájlt releases.yml , a megfelelő artefaktumot újra kell építeni.
Felhívjuk a figyelmet a külső tárolóval való munkára is. Az artefaktum képe a , csak a könyvtárat tölti fel /docs, attól függően, hogy milyen paramétereket adtunk át, hozzáadja a szükséges címkét vagy review-commit adatokat.
Ahhoz, hogy az artefaktum sablonját felhasználhassuk a megadott verziók csatornáinak és kiadásainak leírásának generálásához, ciklust kell szerveznünk a változóval .WerfVersions be. werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Mivel a ciklus több artefaktumot fog generálni (reméljük), figyelembe kell vennünk a közöttük lévő elválasztót — a sorozatot --- (további információ a konfigurációs fájl szintaxisáról található a ). Ahogy korábban meghatároztuk, a ciklusban sablont hívunk meg, ahol átadjuk a verzió, a URL és a gyökérkörnyezet paramétereit.
Hasonlóan, de már ciklus nélkül, meghívjuk az artefaktum sablont „különleges esetekre”: a gyökérverzióhoz és a review-commitból származó verzióhoz:
{{ 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 }} Felhívjuk a figyelmet, hogy a review-commit artefaktuma csak akkor lesz felépítve, ha a változó be van állítva .WerfReviewCommit.
Az artefaktumok elkészültek — itt az idő az importálásra!
A Kubernetes alatt futó végső kép egy általános NGINX, amelyhez konfigurációs fájl került hozzáadásra nginx.conf és statikus fájlok az artefaktumokból. A gyökérverzió artefaktumán kívül újra végre kell hajtanunk a ciklust a .WerfVersions változón a csatornák és kiadások artefaktumainak importálásához + be kell tartanunk az artefaktumok elnevezési szabályát, amelyet korábban fogadtunk el. Mivel minden artefaktum a weboldal verzióit két nyelven tárolja, azokat az előre megadott helyekre kell importálni a konfiguráció szerint.
A werf-doc végső képének leírása
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 -}}A további image, amely a dev-kontúrral együtt indul, csak két verziót tartalmaz: a review-commit verziót és a webhely gyökérverzióját (itt találhatók a közös assetek és, ha emlékszel, a kiadási adatok). Így a további image csak az import szekcióban fog eltérni az alapverziótól (na meg persze a nevétől):
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 }} Ahogyan azt már fentebb említettük, a review-commit műalkotás csak a beállított környezeti változó indításakor fog létrejönni VÉLEMÉNY_SHA. A werf-dev image-et el sem lehetne készíteni, ha a környezeti változó nem létezne VÉLEMÉNY_SHA, de ahhoz, hogy a Docker-alkotásokat a werf esetén dolgozzon a werf-dev image számára, csak az alapverzió műalkotással fogjuk engedni, hogy épüljön (úgyis már összetevődött), hogy egyszerűsítsük a pipeline struktúráját.
Az építés kész! Térjünk át a CI/CD-re és a fontos részletekre.
A GitLab CI pipeline és a dinamikus építés sajátosságai
Az építés elindítása során be kell állítanunk a környezeti változókat, amelyeket werf.yamlhasználnak. Ez nem vonatkozik a REVIEW_SHA változóra, amelyet a GitHub-webhook-ról történő pipeline-hívás során állítunk be.
A szükséges külső adatok előállítását Bash-scriptté emeljük ki generate_artifacts, amely két műalkotást generál a GitLab pipeline-hoz:
- fájl
releases.ymla kiadási adatokkal, - fájl
common_envs.sh, amely környezeti változókat tartalmaz az exportáláshoz.
A fájl tartalma generate_artifacts meg fogjátok találni a . Az adatok megszerzése nem képezi a cikk tárgyát, de a fájl common_envs.sh fontos számunkra, mivel a werf működésétól függ. Példa a tartalmára:
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' A fenti script kimenetét például Bash függvény segítségével használhatjuk. forrás.
Most jön a legérdekesebb rész. Ahhoz, hogy az alkalmazás összeállítása és telepítése helyesen működjön, azt kell biztosítani, hogy werf.yaml ugyanaz legyen legalább egy pipeline keretein belül. Ha ezt a feltételt nem teljesítjük, akkor a werf által az összeállításkor és például a telepítéskor számított szakaszekvenciák különbözni fognak. Ez telepítési hibához vezet, mivel a szükséges telepítési image hiányzik.
Más szavakkal, ha a weboldal image-ának összeállítása során a kiadásokra és verziókra vonatkozó információk azonosak, de a telepítéskor új verzió érkezik és a környezeti változók más értékeket kapnak, akkor a telepítés hibával zárul: hiszen az új verzió artefaktuma még nem készült el.
Ha a generálás werf.yaml külső adatoktól függ (például a aktuális verziók listájától, mint a mi esetünkben), akkor ennek a pipeline keretein belül rögzített összetétele és értékei kell, hogy legyenek. Ez különösen fontos, ha a külső paraméterek elég gyakran változnak.
Mi fogjuk beszerezni és rögzíteni a külső adatokat a pipeline első szakaszában a GitLab-ban (Prebuild) és továbbítjuk őket GitLab CI artefaktumként . Ez lehetővé teszi a pipeline feladatok (összeállítás, telepítés, tisztítás) azonos konfigurációval való indítását és újraindítását.A Prebuild szakasz tartalma: 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 werf.yaml.
Miután rögzítettük a külső adatokat az artefaktumban, az GitLab CI standard pipeline szakaszaival, a Build és Deploy segítségével végezhetjük az összeállítást és telepítést. Magát a pipeline-t a GitHub werf tárolójából érkező hook-ok alapján indítjuk (azaz változások esetén a GitHub tárolóban). Az adatok ezeket a GitLab projekt beállításaiban található adatforrásokból szerezhetjük be, a Prebuild fájlt .gitlab-ci.yml:
CI \/ CD beállítások -> Pipeline trigger-ek, majd létrehozunk a GitHub-ban egy megfelelő Webhook-ot ( Beállítások -> Webhook-okA build szakasz a következőképpen fog kinézni: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).
A GitLab két artefaktumot ad hozzá a build szakaszhoz az
szakaszból, így az előkészített bemeneti adatokkal exportáljuk a változókat. A GitLab hozzáad két artefaktumot az összegyűjtési szakaszhoz Prebuild, így exportáljuk a változókat a felkészített bemeneti adatokkal a konstrukció segítségével source common_envs.sh. A folyamatépítést minden esetben elindítjuk, kivéve a ütemezett pipeline indítását. A ütemezett pipeline a tisztítás végrehajtására fog elindulni — ebben az esetben nem szükséges építést végezni.
A telepítési szakaszban két feladatot fogunk leírni — külön a production és dev környezetekhez, YAML sablon használatával:
.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 A feladatok lényegében csak a klaszter kontextusának megadásában különböznek.WERF_KUBE_CONTEXT), és a környezeti változók beállításában (environment.name és environment.url), amelyek később a Helm diagram sablonokban kerülnek felhasználásra. A sablonok tartalmát nem közöljük, mert az nem érdekes a vizsgált téma szempontjából, de megtalálhatók a .
Végső simítás
Mivel a werf verziók elég gyakran jelennek meg, az új képek is gyakran készülnek, és a Docker Registry folyamatosan nő. Ezért fontos, hogy automatikus tisztítást állítsunk be a képekhez. Ezt nagyon egyszerű beállítani.
A megvalósításhoz szükséges:
- Tisztítási szakasz hozzáadása a
.gitlab-ci.yml; - Tisztítási feladat időszakos végrehajtásának beállítása;
- Környezetváltozó beállítása a hozzáférési tokennel íráshoz.
Tisztítási szakasz hozzáadása a .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
Majdnem mindent már láttunk fenn — a tisztítás előtt be kell jelentkezni a Docker Registry-be egy tokennel, amely jogosultságot ad a képek törlésére a Docker Registry-ben (a GitLab CI által automatikusan kiadott tokenek nem rendelkeznek ilyen jogokkal). A tokent előre be kell állítani a GitLab-ban, és az értékét meg kell adni a környezeti változóban. WERF_IMAGES_CLEANUP_PASSWORD Ez a backend az analitika számára. (CI/CD Settings -> Variables).
A feladat ütemezése a szükséges ütemtervvel a CI/CD ->
Ütemezések.
Minden: a projekt a Docker Registry-ben már nem fog folyamatosan nőni a nem használt képek miatt.
A gyakorlati rész végén emlékeztetnék, hogy a cikkből a teljes listák elérhetőek a :
- ;
- .
Eredmény
- Logikus felépítést kaptunk: egy artefaktum egy verzióra.
- A felépítés univerzális, és nem igényel kézi módosításokat az új werf verziók megjelenésekor: a dokumentáció automatikusan frissül a weboldalon.
- Két képet készítünk különböző kontúrokhoz.
- Gyorsan működik, mivel maximálisan kihasználja a cache-elést — amikor új werf verzió jelenik meg vagy a GitHub hookot hívják meg a review commit miatt — csak a módosított verzióval rendelkező artefaktum újraépítése történik.
- Nem szükséges a nem használt képek eltávolításáról gondoskodni: a werf politikák szerint végzett tisztítás rendben tartja a Docker Registry-t.
Következtetések
- A werf használata lehetővé teszi, hogy a felépítés gyorsan működjön a felépítés és a külső repository-k kezelésének cache-elése révén.
- A külső Git repository-kkal való munka megszabadít minket attól, hogy a repository-t minden alkalommal teljesen klónozzuk, vagy bonyolult optimalizáló logikát találjunk ki. A werf cache-t használ, és csak egyszer klónozza, majd ezt követően csak szükség esetén használja
fetch-tés csak szükség szerint. - A Go-sablonok használatának lehetősége a build konfigurációs fájlban
werf.yamllehetővé teszi, hogy a felépítés olyan eredményt adjon, amely külső adatokatól függ. - A werf-ben alkalmazott mountolás jelentősen felgyorsítja az artefaktumok felépítését — mivel a cache közös lesz az összes pipeline számára.
- A werf lehetővé teszi a könnyű tisztítási beállítást, ami különösen aktuális dinamikus építkezés esetén.
P.S.
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
