Avemu digià parlatu di u nostru strumentu GitOps più di una volta. , è sta volta vulemu sparte a nostra sperienza in l'assemblea di u situ cù a documentazione di u prugettu stessu - (a so versione russa hè ). Questu hè un situ staticu ordinariu, ma a so assemblea hè interessante in quantu hè custruitu cù un numeru dinamicu di artefatti.
Andate in i sfumaturi di a struttura di u situ: generà un menu cumuni per tutte e versioni, pagine cù infurmazioni nantu à e versioni, etc. - ùn avemu micca. Invece, concentremu nantu à i prublemi è e caratteristiche di l'assemblea dinamica è un pocu nantu à i prucessi CI / CD accumpagnati.
Introduzione: cumu funziona u situ
Per principià, a documentazione werf hè almacenata cù u so codice. Questu impone certi esigenze di sviluppu chì sò generalmente fora di u scopu di stu articulu, ma à u minimu si pò dì chì:
- Nuvelle funzioni di werf ùn deve esse liberate senza aghjurnà a documentazione è, à u cuntrariu, ogni cambiamentu in a documentazione implica a liberazione di una nova versione di werf;
- U prughjettu hà un sviluppu abbastanza intensu: e novi versioni ponu esse liberati parechje volte à ghjornu;
- Ogni operazione manuale per implementà un situ cù una nova versione di documentazione sò almenu tedious;
- U prugettu adopra un approcciu semanticu , cù 5 canali di stabilità. U prucessu di liberazione implica u passaghju sequenziale di versioni attraversu i canali in ordine di crescente stabilità: da l'alfa à a roccia solida;
- U situ hà una versione in lingua russa, chì "vive è si sviluppa" (vale à dì, u cuntenutu di quale hè aghjurnatu) in parallelu cù a versione principale (vale à dì, in lingua inglese).
Per ammuccià tutta questa "cucina interna" da l'utilizatori, offrendu qualcosa chì "funciona solu", avemu fattu installazione separata di werf è strumentu d'aghjurnamentu Is . Solu bisognu di specificà u numeru di liberazione è u canali di stabilità chì site prontu à utilizà, è multiwerf verificarà s'ellu ci hè una nova versione in u canali è scaricallu se ne necessariu.
In u menù di selezzione di versione in u situ web, l'ultime versioni di werf sò dispunibili in ogni canali. Per automaticamente, per indirizzu a versione di u canale più stabile per l'ultima liberazione apre - hè ancu indexatu da i mutori di ricerca. A documentazione per u canali hè dispunibule in indirizzi separati (per esempiu, per a versione beta 1.0).
In tuttu, u situ hà e seguenti versioni dispunibili:
- root (apre per difettu),
- per ogni canale di aghjurnamentu attivu di ogni versione (per esempiu, ).
Per generà una versione specifica di un situ, in generale, hè abbastanza per compilà cù l'usu eseguendu in u cartulare /docs repository werf cumanda currispondente (jekyll build), dopu avè cambiatu à u tag Git di a versione necessaria.
Resta solu à aghjunghje chì:
- l'utilità stessu (werf) hè aduprata per l'assemblea;
- I prucessi CI/CD sò custruiti nantu à a basa di GitLab CI;
- è tuttu questu, sicuru, corre in Kubernetes.
fatti
Avà formulemu i travaglii chì piglianu in contu tutte e specifiche descritte:
- Dopu avè cambiatu a versione werf in ogni canale di aghjurnamentu a documentazione nantu à u situ deve esse aghjurnata automaticamente.
- Per u sviluppu avete bisognu di pudè qualchì volta vede versioni in anteprima di u situ.
U situ deve esse recompilatu dopu avè cambiatu a versione in ogni canale da e tags Git currispondenti, ma in u prucessu di custruisce l'imaghjini, uttene e seguenti caratteristiche:
- Siccomu a lista di versioni nantu à i canali cambia, hè solu necessariu di ricustruisce a documentazione per i canali induve a versione hè cambiata. Dopu tuttu, ricustruisce tuttu di novu ùn hè micca assai bellu.
- L'inseme di canali per e versioni pò cambià. À un certu puntu in u tempu, per esempiu, ùn pò esse micca una versione nantu à i canali più stabile chì a versione 1.1 d'accessu anticipatu, ma cù u tempu apparisceranu - in questu casu, ùn deve micca cambià l'assemblea manualmente?
Questu hè chì assemblea dipende di cambià dati esterni.
Реализация
Scelta di un approcciu
In alternativa, pudete eseguisce ogni versione necessaria cum'è un pod separatu in Kubernetes. Questa opzione implica un nùmeru più grande d'uggetti in u cluster, chì cresce cù l'aumentu di u nùmeru di liberazioni stabili di werf. È questu, à u turnu, implica un mantenimentu più cumplessu: ogni versione hà u so servitore HTTP, è cù una piccula carica. Di sicuru, questu implica ancu più costi di risorse.
Avemu pigliatu a stessa strada assemblendu tutte e versioni necessarii in una maghjina. L'statics compilati di tutte e versioni di u situ sò situati in un cuntainer cù NGINX, è u trafficu à u Deployment currispundente vene da NGINX Ingress. Una struttura simplice - una applicazione senza statu - vi permette di scala facilmente u Deployment (secondu a carica) cù Kubernetes stessu.
Per esse più precisi, cullighjemu duie imagine: una per u circuitu di produzzione, u sicondu hè un supplementu per u circuitu dev. L'imaghjini supplementari hè utilizatu (lanciatu) solu nantu à u circuitu di dev inseme cù u principale è cuntene a versione di u situ da u cumitatu di rivisione, è u routing trà elli hè realizatu utilizendu risorse Ingress.
werf vs git clone è artefatti
Comu dighjà dettu, per generà statiche di u situ per una versione specifica di a ducumentazione, avete bisognu di custruisce cambiendu à u tag di repository appropritatu. Pudete ancu fà questu clonendu u repositoriu ogni volta chì custruisce, selezziunate e tags appropritate da una lista. In ogni casu, questu hè un funziunamentu piuttostu intensivu di risorse è, in più, hè bisognu di scrive struzzioni micca trivial... Un altru svantaghju seriu hè chì cù questu approcciu ùn ci hè manera di cache qualcosa durante l'assemblea.
Quì l'utilità werf stessu vene à u nostru aiutu, implementendu cache intelligente è vi permette di aduprà . Utilizà werf per aghjunghje u codice da u repositoriu accelerà significativamente a custruzione, perchè werf essenzialmente clona u repository una volta è poi eseguisce solu fetch se ne necessariu. Inoltre, quandu aghjunghjenu dati da u repository, pudemu selezziunate solu i repertorii necessarii (in u nostru casu questu hè u repertoriu). docs), chì riducerà significativamente a quantità di dati aghjuntu.
Siccomu Jekyll hè un strumentu cuncepitu per cumpilà dati statici è ùn hè micca necessariu in l'imaghjini finali, saria logicu cumpilà in , è in l'imaghjini finali impurtà solu u risultatu di compilazione.
Scrivemu werf.yaml
Dunque, avemu decisu chì compilemu ogni versione in un artefattu werf separatu. Tuttavia noi ùn sapemu quantu di sti artefatti ci saranu durante l'assemblea, cusì ùn pudemu micca scrive una cunfigurazione di custruzzione fissa (strictamente parlante, pudemu sempre, ma ùn serà micca sanu efficace).
werf permette di utilizà in u vostru schedariu di cunfigurazione (werf.yaml), è questu hè pussibule generà a cunfigurazione nantu à a mosca sicondu i dati esterni (ciò chì avete bisognu!). I dati esterni in u nostru casu sò infurmazioni nantu à e versioni è e versioni, nantu à a basa di quale raccogliemu u numeru necessariu di artefatti è, in u risultatu, uttene duie imagine: werf-doc и werf-dev per correre in diversi circuiti.
I dati esterni sò passati per variabili di l'ambiente. Eccu a so cumpusizioni:
-
RELEASES- una linea cù una lista di versioni è a versione attuale currispundente di werf, in forma di una lista di valori separati da spazii in u formatu<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Un esempiu:1.0%v1.0.4-beta.20 -
CHANNELS- una linea cù una lista di canali è a versione attuale currispondente di werf, in forma di una lista di valori separati da spazii in u formatu<КАНАЛ>%<НОМЕР_ВЕРСИИ>. Un esempiu:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION- a versione di liberazione werf per esse visualizata per difettu nantu à u situ (ùn hè micca sempre necessariu di visualizà a documentazione cù u numeru di liberazione più altu). Esempiu:v1.0.4-beta.20 -
REVIEW_SHA- hash of the review commit da quale avete bisognu di custruisce a versione per u ciclu di prova.
Queste variàbili saranu riempite in u pipeline GitLab CI, è cumu esattamente hè scrittu quì sottu.
Prima di tuttu, per comodità, avemu definitu in werf.yaml Vai a variabili di mudellu, assignendu valori da e variabili di l'ambiente:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}
A descrizzione di l'artefattu per a compilazione di a versione statica di u situ hè in generale a listessa per tutti i casi chì avemu bisognu (cumprese a generazione di a versione radicali, è ancu a versione per u circuitu dev). Dunque, avemu da spustà in un bloccu separatu cù a funzione define - per l'utilizazione successiva include. Passemu i seguenti argumenti à u mudellu:
-
Version- versione generata (nome tag); -
Channel- u nome di u canali di aghjurnamentu per quale l'artefattu hè generatu; -
Commit- commit hash, se l'artefattu hè generatu per un commit di rivisione; - cuntestu.
Artifact Template Description
{{- 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 }}
U nome di l'artefattu deve esse unicu. Pudemu ottene questu, per esempiu, aghjunghjendu u nome di u canali (u valore di a variàbile .Channel) cum'è suffissu à u nome di l'artefattu: artifact: doc-{{ .Channel }}. Ma avete bisognu di capisce chì quandu importate da artefatti, avete bisognu di riferite à i stessi nomi.
Quandu si descrive un artefattu, a seguente funzione werf hè aduprata: . Muntamentu chì indica u cartulare di serviziu build_dir permette di salvà a cache di Jekyll trà e corse di pipeline, chì accelerà significativamente a riunione.
Pudete ancu avè nutatu l'usu di u schedariu releases.yml hè un schedariu YAML cù i dati di liberazione dumandati da (un artefattu ottenutu quandu eseguisce un pipeline). Hè necessariu quandu compilate u situ, ma in u cuntestu di l'articulu hè interessante per noi perchè dipende di u so statu. riassemblamentu di un solu artefattu - un artefattu di a versione radicali di u situ (ùn hè micca necessariu in altri artefatti).
Questu hè implementatu cù a dichjarazione cundizionale if Vai mudelli è disinni {{ $Root.Files.Get "releases.yml" | sha256sum }} in scena . Funziona cusì: quandu custruisce un artefattu per a versione root (variable .Channel uguali à root) file hash releases.yml afecta a firma di tutta a tappa, postu chì face parte di u nome di u compitu Ansible (parametru name). Cusì, quandu cambiassi cuntenutu schedariu releases.yml l'artefattu currispundente serà riunitu.
Per piacè fate ancu attenzione à travaglià cù un repositoriu esternu. In l'imaghjini di un artefattu da , solu u cartulare hè aghjuntu /docs, è sicondu i paràmetri passati, i dati di u tag necessariu o cummittente di rivisione hè aghjuntu immediatamente.
Per utilizà u mudellu di l'artefattu per generà una descrizzione di l'artefattu di e versioni trasferiti di i canali è e versioni, urganizemu un ciclu nantu à a variabile. .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}
Perchè u ciclu generarà parechji artefatti (esperemu cusì), hè necessariu di piglià in contu u separatore trà elli - a sequenza --- (Per più infurmazione nantu à a sintassi di u schedariu di cunfigurazione, vede ). Comu definitu prima, quandu chjamate un mudellu in un ciclu, passemu i paràmetri di a versione, l'URL è u cuntestu radicali.
In listessu modu, ma senza un ciclu, chjamemu u mudellu di l'artefattu per "casi spiciali": per a versione radicali, è ancu a versione da u cumitatu di rivisione:
{{ 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 }}
Per piacè nutate chì l'artefattu per l'impegnu di rivisione serà custruitu solu se a variàbile hè stabilita .WerfReviewCommit.
L'artefatti sò pronti - hè ora di cumincià à impurtà!
L'imaghjini finali, cuncepitu per eseguisce in Kubernetes, hè un NGINX regulare cù un schedariu di cunfigurazione di u servitore aghjuntu nginx.conf è statica da artefatti. In più di l'artefattu di a versione radicali di u situ, avemu bisognu di ripetiri u ciclu nantu à a variàbile .WerfVersions per impurtà artefatti di e versioni di canali è liberate + seguite a regula di denominazione di l'artefatti chì avemu aduttatu prima. Siccomu ogni artefattu guarda versioni di u situ per duie lingue, l'impurtamu in i lochi furniti da a cunfigurazione.
Descrizzione di l'imaghjini finali 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 -}}L'imaghjini supplementari, chì, inseme cù u principale, hè lanciatu nantu à u circuitu di dev, cuntene solu duie versioni di u situ: a versione da u cumitatu di rivisione è a versione radicali di u situ (ci sò assi generali è, se vi ricordate). , dati di liberazione). Cusì, l'imaghjini supplementari differiscerà da u principale solu in a seccione di impurtazione (è, sicuru, in u nome):
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 }}
Comu nutatu sopra, l'artefattu per l'impegnu di rivisione serà generatu solu quandu a variabile di l'ambienti stabilita hè eseguita REVIEW_SHA. Saria pussibile micca generà l'imaghjini werf-dev in tuttu s'ellu ùn ci hè micca una variabile d'ambiente REVIEW_SHA, ma per fà L'imaghjini di Docker in werf anu travagliatu per l'imaghjini werf-dev, l'avemu da esse custruitu solu cù l'artefattu di a versione root (hè digià custruitu in ogni modu), per simplificà a struttura di pipeline.
L'assemblea hè pronta ! Passemu à CI/CD è sfumature impurtanti.
Pipeline in GitLab CI è caratteristiche di a creazione dinamica
Quandu eseguite a custruzione, avemu bisognu di stabilisce e variabili di l'ambiente utilizati in werf.yaml. Questu ùn hè micca applicatu à a variabile REVIEW_SHA, chì avemu da stabilisce quandu chjamate pipeline da u ganciu GitHub.
Generemu i dati esterni necessarii in un script Bash generate_artifacts, chì genererà dui artefatti di pipeline GitLab:
- schedariu
releases.ymlcù dati di liberazione, - schedariu
common_envs.sh, chì cuntene e variabili di l'ambiente da esse esportatu.
cuntenutu di u schedariu generate_artifacts truverete in u nostru . Riceve i dati stessu ùn hè micca u sughjettu di l'articulu, ma u schedariu common_envs.sh hè impurtante per noi, perchè u travagliu di werf ne dipende. Un esempiu di u so cuntenutu:
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'
Pudete utilizà l'output di un tali script, per esempiu, utilizendu a funzione Bash source.
Avà vene a parte divertente. Per chì sia a custruzzione sia a implementazione di l'applicazione per travaglià bè, hè necessariu di assicurà chì werf.yaml era u listessu almenu in una pipeline. Se sta cundizione ùn hè micca scontru, allora i signuri di e tappe chì werf calcula durante l'assemblea è, per esempiu, a distribuzione, seranu diffirenti. Questu porta à un errore di implementazione, perchè ... l'imaghjina necessaria per a distribuzione serà mancante.
In altri palori, se durante l'assemblea di l'imaghjini di u situ l'infurmazioni nantu à e versioni è e versioni hè a stessa, è à u mumentu di a implementazione una nova versione hè liberata è e variabili di l'ambienti anu valori diffirenti, allora a implementazione falla cun un errore: Dopu tuttu, l'artefattu di a nova versione ùn hè ancu statu custruitu.
Sè generazione werf.yaml dipende di dati esterni (per esempiu, una lista di versioni currenti, cum'è in u nostru casu), allura a cumpusizioni è i valori di tali dati deve esse arregistrati in u pipeline. Questu hè particularmente impurtante se i paràmetri esterni cambianu abbastanza spessu.
Faceremu riceve è arregistrà dati esterni à a prima tappa di u pipeline in GitLab (Precustruisce) è li trasmette in più in a forma GitLab CI artefact. Questu vi permetterà di eseguisce è riavvia i travaglii di pipeline (custruisce, implementà, pulizia) cù a stessa cunfigurazione in werf.yaml.
Cuntinutu di u stadiu Precustruisce schedariu .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 weekDopu avè catturatu i dati esterni in l'artefattu, pudete custruisce è implementà aduprendu e fasi standard di pipeline GitLab CI: Custruite è Deploy. Lancemu u pipeline stessu utilizendu ganci da u repository werf GitHub (vale à dì, quandu ci sò cambiamenti in u repository GitHub). I dati per elli ponu esse truvati in e proprietà di u prughjettu GitLab in a sezione Impostazioni CI/CD -> Pipeline triggers, è dopu crea u Webhook currispundente in GitHub (Settings -> Webhooks).
A fase di custruzzione serà cusì:
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 aghjunghjera dui artefatti da u stadiu à u stadiu di custruzzione Precustruisce, cusì esportemu variabili cù dati di input preparati utilizendu a custruzzione source common_envs.sh. Cuminciamu a tappa di custruzzione in tutti i casi, eccettu per lancià u pipeline secondu un calendariu. Sicondu u calendariu, correremu un pipeline per a pulizia - in questu casu ùn ci hè bisognu di fà assemblea.
À a fase di implementazione, descriveremu dui compiti - separatamente per l'implementazione à i circuiti di produzzione è di sviluppu, utilizendu un mudellu YAML:
.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
I travaglii sò essenzialmente diffirenti solu in l'indicazione di u cuntestu di cluster in quale werf duverà eseguisce a implementazione (WERF_KUBE_CONTEXT), è stabilisce e variabili di l'ambiente di loop (environment.name и environment.url), chì sò allora utilizati in mudelli di chart Helm. Ùn furniremu micca u cuntenutu di i mudelli, perchè ... ùn ci hè nunda di interessante per u tema in quistione, ma pudete truvà in .
Toccu finale
Siccomu e versioni di werf sò liberati abbastanza spessu, e novi imagine seranu custruiti spessu, è u Docker Registry crescerà constantemente. Dunque, hè imperativu di cunfigurà a pulizia automatica di l'imagine basatu nantu à e pulitiche. Hè assai faciule da fà.
Per implementà avete bisognu di:
- Aghjunghjite un passu di pulizia
.gitlab-ci.yml; - Aghjunghjite l'esecuzione periodica di un compitu di pulizia;
- Configurate una variabile d'ambiente cù un token d'accessu di scrittura.
Aghjunghjendu una tappa di pulizia à .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
Avemu digià vistu quasi tuttu questu un pocu più altu - solu per pulizziari hè bisognu di prima login in u Docker Registry cun un token chì hà i diritti per sguassà l'imaghjini in u Docker Registry (u token di compitu GitLab CI emessu automaticamente ùn hè micca avè tali diritti). U token deve esse creatu in GitLab in anticipu è u so valore deve esse specificatu in a variabile d'ambiente WERF_IMAGES_CLEANUP_PASSWORD u prughjettu (Impostazioni CI/CD -> Variabili).
Aghjunghjendu un compitu di pulizia cù u calendariu necessariu hè fattu in CI/CD ->
Pianifiche.
Hè cusì: un prughjettu in u Docker Registru ùn cresce più constantemente da l'imaghjini inutilizati.
À a fine di a parte pratica, lasciami ricurdà chì e liste complete di l'articulu sò dispunibili in :
- ;
- .
risultatu
- Avemu ricevutu una struttura di assemblea logica: un artefattu per versione.
- L'assemblea hè universale è ùn hà micca bisognu di cambiamenti manuali quandu sò liberati novi versioni di werf: a documentazione nantu à u situ web hè aghjurnata automaticamente.
- Dui imagine sò assemblati per diverse contorni.
- Funziona rapidamente, perchè A caching hè utilizata quant'è pussibule - quandu una nova versione di werf hè liberata o un ganciu GitHub hè chjamatu per un impegnu di rivisione, solu l'artefattu currispundente cù a versione cambiata hè ricustruita.
- Ùn ci hè bisognu di pensà à sguassà l'imaghjini inutilizate: a pulizia secondu e pulitiche werf mantene u Docker Registry in ordine.
scuperti
- L'usu di werf permette à l'assemblea di travaglià rapidamente per via di u caching di l'assemblea stessu è di u caching quandu travaglia cù repositori esterni.
- U travagliu cù repositori Git esterni elimina a necessità di clonà tuttu u repositoriu ogni volta o reinventà a rota cù una logica di ottimisazione complicata. werf usa una cache è face a clonazione solu una volta, è poi usa
fetchè solu quandu hè necessariu. - Capacità di utilizà mudelli Go in u schedariu di cunfigurazione di custruisce
werf.yamlpermette di discrìviri un assemblea chì u risultatu dipende di dati esterni. - L'usu di mount in werf accelera significativamente a cullizzioni di artefatti - per via di u cache, chì hè cumunu à tutti i pipelines.
- werf facilita a cunfigurazione di a pulizia, chì hè particularmente impurtante quandu si custruisce dinamicamente.
PS
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com