Ons het al meer as een keer oor ons GitOps-instrument gepraat , en hierdie keer wil ons graag ons ervaring met die samestelling van die terrein deel met die dokumentasie van die projek self - (die Russiese weergawe daarvan is ). Dit is 'n normale statiese webwerf, maar die bou daarvan is interessant omdat dit gebou is met 'n dinamiese aantal artefakte.
Gaan na die nuanses van die werfstruktuur: genereer 'n gemeenskaplike spyskaart vir alle weergawes, bladsye met inligting oor vrystellings, ens. - ons sal nie. Kom ons fokus eerder op die kwessies en besonderhede van dinamiese samestelling en 'n bietjie op die verwante CI/CD-prosesse.
Inleiding: hoe die webwerf werk
Om mee te begin, word werf-dokumentasie saam met sy kode gestoor. Dit stel sekere ontwikkelingsvereistes wat oor die algemeen buite die bestek van hierdie artikel val, maar ten minste kan gesê word dat:
- Nuwe werfkenmerke moet nie vrygestel word sonder om die dokumentasie by te werk nie en omgekeerd impliseer enige veranderinge in die dokumentasie 'n nuwe weergawe van werf;
- Die projek het 'n redelik intensiewe ontwikkeling: nuwe weergawes kan verskeie kere per dag vrygestel word;
- Enige handhandelinge om 'n webwerf met 'n nuwe weergawe van dokumentasie te ontplooi is ten minste vervelig;
- Die projek het die benadering van semantiek aangeneem , met 5 kanale van stabiliteit. Die vrystellingsproses behels die opeenvolgende deurgang van weergawes deur die kanale in volgorde van toenemende stabiliteit: van alfa tot rotsvas;
- Die webwerf het 'n Russiese taal weergawe wat "leef en ontwikkel" (d.w.s. waarvan die inhoud opgedateer word) parallel met die hoof (d.w.s. Engelstalige) weergawe.
Om al hierdie "binne kombuis" vir die gebruiker weg te steek, om hom iets aan te bied wat "net werk", het ons gedoen aparte werf installasie en opdateringsinstrument - Is . Jy moet net die vrystellingnommer en die stabiliteitskanaal spesifiseer wat jy gereed is om te gebruik, en multiwerf sal kyk of daar 'n nuwe weergawe op die kanaal is en dit aflaai indien nodig.
Die nuutste weergawes van werf in elke kanaal is beskikbaar in die weergawe seleksie kieslys op die webwerf. By verstek, by die weergawe van die mees stabiele kanaal vir die nuutste weergawe word oopgemaak - dit word ook deur soekenjins geïndekseer. Dokumentasie vir die kanaal is beskikbaar by afsonderlike adresse (byvoorbeeld, vir beta-vrystelling 1.0).
In totaal het die webwerf die volgende weergawes beskikbaar:
- root (maak by verstek oop),
- vir elke aktiewe opdateringskanaal van elke vrystelling (byvoorbeeld, ).
Om 'n spesifieke weergawe van die webwerf te genereer, in die algemene geval, is dit genoeg om dit saam te stel met behulp van deur in die gids te hardloop /docs werf repository met die ooreenstemmende opdrag (jekyll build), nadat jy oorgeskakel het na die Git-merker van die vereiste weergawe.
Dit bly net om by te voeg dat:
- die nut self (werf) word vir samestelling gebruik;
- CI/CD-prosesse word bo-op GitLab CI gebou;
- en dit alles werk natuurlik in Kubernetes.
take
Nou formuleer ons take wat al die beskryfde besonderhede in ag neem:
- Na die verandering van werf weergawe op enige opdateringskanaal dokumentasie op die webwerf moet outomaties opgedateer word.
- Vir ontwikkeling moet jy soms kan bekyk werfvoorskoue.
Die hersamestelling van die werf moet uitgevoer word nadat die weergawe op enige kanaal van die ooreenstemmende Git-etikette verander is, maar in die proses om die prent te bou, sal ons die volgende kenmerke kry:
- Aangesien die lys weergawes op kanale verander, is dit net nodig om die dokumentasie te herbou vir kanale waar die weergawe verander het. Om alles weer te herbou is immers nie baie lekker nie.
- Die stel kanale vir vrystellings kan verander. Op 'n sekere tydstip kan daar byvoorbeeld nie 'n weergawe op die kanale wees wat meer stabiel is as die vroeë-toegang 1.1-vrystelling nie, maar met verloop van tyd sal hulle verskyn - in hierdie geval, verander nie die samestelling met die hand nie?
Dit blyk dat samestelling hang af van die verandering van eksterne data.
Implementering
Keuse van benadering
Alternatiewelik kan jy elke vereiste weergawe as 'n aparte peul in Kubernetes laat loop. Hierdie opsie impliseer 'n groter aantal voorwerpe in die cluster, wat sal groei met 'n toename in die aantal stabiele vrystellings van werf. En dit impliseer op sy beurt meer komplekse instandhouding: elke weergawe het sy eie HTTP-bediener, en met 'n klein vrag. Dit bring natuurlik ook hoër hulpbronkoste mee.
Ons het langs die pad gegaan samestelling van alle nodige weergawes in een beeld. Die saamgestelde statistieke van alle weergawes van die webwerf is in 'n houer met NGINX, en verkeer na die ooreenstemmende ontplooiing kom deur NGINX Ingress. 'n Eenvoudige struktuur - 'n staatlose toepassing - maak dit maklik om Ontplooiing te skaal (afhangende van die vrag) deur Kubernetes self te gebruik.
Om meer presies te wees, bou ons twee beelde: een is vir die produksielus, die tweede is 'n bykomende een vir die dev-lus. Die bykomende prent word slegs op die ontwikkelaarlus saam met die hoof een gebruik (bekendgestel) en bevat die weergawe van die webwerf vanaf die hersiening, en roetering tussen hulle word uitgevoer met behulp van Ingress-hulpbronne.
werf vs git kloon en artefakte
Soos reeds genoem, moet jy bou deur oor te skakel na die toepaslike bewaarplekmerker om webwerfstatika vir 'n spesifieke weergawe van die dokumentasie te genereer. U kan dit ook doen deur die bewaarplek te kloneer elke keer as u bou, en die toepaslike etikette uit die lys te kies. Dit is egter 'n taamlik hulpbron-intensiewe operasie en vereis boonop die skryf van nie-triviale instruksies ... Nog 'n ernstige nadeel is dat met hierdie benadering, daar geen manier is om iets tydens die samestelling te kas nie.
Hier kom die werf nut self tot die redding, implementeer slim caching en laat jou toe om te gebruik . Deur werf te gebruik om kode van die bewaarplek by te voeg, sal die bou aansienlik versnel, want werf kloon in wese die bewaarplek een keer en doen dit dan slegs fetch Indien nodig. Daarbenewens, wanneer ons data van die bewaarplek byvoeg, kan ons slegs die nodige gidse kies (in ons geval is dit die gids docs), wat die hoeveelheid bygevoegde data aansienlik sal verminder.
Aangesien Jekyll 'n instrument is wat ontwerp is om statiese data saam te stel en nie in die finale prent nodig is nie, sal dit logies wees om in , en in die finale beeld voer slegs samestellingsresultaat in.
Ons skryf werf.yaml
So, ons het besluit dat ons elke weergawe in 'n aparte werf artefak sal saamstel. Ons het egter ons weet nie hoeveel van hierdie artefakte tydens samestelling sal wees nie, dus kan ons nie 'n vaste boukonfigurasie skryf nie (streng gesproke kan ons, maar dit sal nie baie doeltreffend wees nie).
werf laat jou toe om te gebruik in jou konfigurasie lêer (werf.yaml), wat dit moontlik maak genereer config op die vlieg afhangende van eksterne data (wat jy nodig het!). Eksterne data in ons geval is inligting oor weergawes en vrystellings, op grond waarvan ons die vereiste aantal artefakte versamel en as gevolg hiervan kry ons twee beelde: werf-doc и werf-dev om op verskillende stroombane te hardloop.
Eksterne data word deur omgewingsveranderlikes deurgegee. Hier is hul samestelling:
-
RELEASES- 'n string met 'n lys vrystellings en die ooreenstemmende huidige weergawe van werf, as 'n lys geskei deur 'n spasie waardes in die formaat<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. 'N Voorbeeld:1.0%v1.0.4-beta.20 -
CHANNELS- 'n reël met 'n lys van kanale en die ooreenstemmende huidige weergawe van werf, in die vorm van 'n lys geskei deur 'n spasie van waardes in die formaat<КАНАЛ>%<НОМЕР_ВЕРСИИ>. 'N Voorbeeld:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— weergawe van die werfvrystelling om by verstek op die webwerf te vertoon (dit is nie altyd nodig om dokumentasie met die hoogste vrystellingnommer te vertoon nie). Voorbeeld:v1.0.4-beta.20 -
REVIEW_SHA- hash van die hersiening commit, waaruit u 'n weergawe vir die toetslus moet bou.
Hierdie veranderlikes sal in die GitLab CI-pyplyn ingevul word, en hoe presies word hieronder geskryf.
Eerstens, gerieflikheidshalwe, definieer ons in werf.yaml Gaan sjabloonveranderlikes, ken waardes aan hulle toe vanaf omgewingsveranderlikes:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}
Die beskrywing van die artefak vir die samestelling van die statiese weergawe van die webwerf is oor die algemeen dieselfde vir al die gevalle wat ons benodig (insluitend die generering van die wortelweergawe, sowel as die weergawe vir die dev-kring). Daarom sal ons dit in 'n aparte blok uithaal deur die funksie te gebruik define - vir latere hergebruik include. Ons sal die volgende argumente na die sjabloon deurgee:
-
Version- gegenereerde weergawe (merkernaam); -
Channel— die naam van die opdateringskanaal waarvoor die artefak gegenereer word; -
Commit- pleeg hash, indien die artefak gegenereer word vir 'n hersiening commit; - konteks.
Artefak sjabloon beskrywing
{{- 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 }}
Die artefaknaam moet uniek wees. Ons kan dit byvoorbeeld bereik deur die naam van die kanaal by te voeg (die waarde van die veranderlike .Channel) as 'n artefaknaamagtervoegsel: artifact: doc-{{ .Channel }}. Maar jy moet verstaan dat wanneer jy vanaf artefakte invoer, jy na dieselfde name sal moet verwys.
Wanneer 'n artefak beskryf word, word die volgende werfkenmerk gebruik: . Monteer met diensgids build_dir laat jou toe om die Jekyll-kas tussen pyplynlopies te stoor, wat versnel die hersamestelling aansienlik.
Ook, jy het dalk die gebruik van die lêer opgemerk releases.yml is 'n YAML-lêer met vrystellingsdata van versoek (artefak verkry deur die pyplyn uit te voer). Dit is nodig wanneer die webwerf saamgestel word, maar in die konteks van die artikel is dit vir ons interessant omdat dit afhang van die toestand daarvan om slegs een artefak te herbou — 'n artefak van die wortelweergawe van die webwerf (dit is nie nodig in ander artefakte nie).
Dit word geïmplementeer met behulp van die voorwaardelike operateur if Gaan sjablone en ontwerpe {{ $Root.Files.Get "releases.yml" | sha256sum }} in die verhoog . Dit werk soos volg: wanneer 'n artefak vir die wortelweergawe gebou word (veranderlike .Channel is gelyk aan root) lêer hash releases.yml beïnvloed die handtekening van die hele verhoog, aangesien dit deel is van die naam van die Ansible-werk (parameter name). Dus, wanneer jy verander inhoud lêer releases.yml die ooreenstemmende artefak sal herbou word.
Gee ook aandag aan die werk met 'n eksterne bewaarplek. In die beeld van 'n artefak uit , net die gids word bygevoeg /docs, en afhangende van die geslaagde parameters, word die data van die onmiddellik nodige merker of hersiening commit bygevoeg.
Om die artefak-sjabloon te gebruik om 'n artefakbeskrywing van die ingediende weergawes van kanale en vrystellings te genereer, organiseer ons 'n lus oor die veranderlike .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}
Omdat die lus sal verskeie artefakte genereer (ons hoop so), jy moet die skeiding tussen hulle in ag neem - die volgorde --- (Vir meer inligting oor konfigurasielêersintaksis, sien ). Soos vroeër gedefinieer, wanneer ons die sjabloon in 'n lus oproep, gee ons weergaweparameters, URL en kontekswortel deur.
Net so, maar sonder 'n siklus, noem ons die artefak sjabloon vir "spesiale gevalle": vir die wortel weergawe, sowel as die weergawe van die hersiening 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 }}
Let daarop dat die artefak vir die hersiening commit slegs gebou sal word as die veranderlike gestel is .WerfReviewCommit.
Artefakte is gereed - dit is tyd om te begin invoer!
Die finale prent wat bedoel is om op Kubernetes te loop, is 'n gewone NGINX met 'n bedienerkonfigurasielêer wat daarby gevoeg is. nginx.conf en staties van artefakte. Benewens die artefak van die wortelweergawe van die webwerf, moet ons die lus op die veranderlike herhaal .WerfVersions om kanaal- en weergawe-artefakte in te voer + volg die artefak-benamingsreël wat ons vroeër aangeneem het. Aangesien elke artefak weergawes van die webwerf vir twee tale stoor, voer ons dit in na die plekke wat deur die konfigurasie voorsien word.
Beskrywing van die finale werf-doc beeld
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 -}}Die bykomende prent, wat saam met die hoof een op die dev-kring loop, bevat slegs twee weergawes van die webwerf: die weergawe van die hersiening commit en die wortel weergawe van die webwerf (daar is algemene bates en, as jy onthou, data op vrystellings). Dus, die bykomende beeld sal slegs in die invoerafdeling van die hoof een verskil (en natuurlik in die naam):
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 }}
Soos hierbo genoem, sal die artefak vir die hersiening commit slegs gegenereer word wanneer die omgewingsveranderlike gestel is om te loop REVIEW_SHA. Dit sou moontlik wees om glad nie die werf-dev-beeld te genereer as daar geen omgewingsveranderlike is nie REVIEW_SHA, maar om Docker-beelde in werf het vir die werf-dev-beeld gewerk, ons sal dit net met die root-weergawe-artefak laat bou (dit is in elk geval reeds gebou), om die pyplynstruktuur te vereenvoudig.
Vergadering is gereed! Kom ons gaan aan na CI / CD en belangrike nuanses.
Pyplyn in GitLab CI en kenmerke van dinamiese samestelling
Wanneer die bou uitgevoer word, moet ons die omgewingsveranderlikes instel wat gebruik word in werf.yaml. Dit is nie van toepassing op die REVIEW_SHA-veranderlike nie, wat ons sal stel wanneer ons die pyplyn vanaf die GitHub-haak oproep.
Ons sal die vorming van die nodige eksterne data na die Bash-skrif oordra generate_artifacts, wat twee GitLab pyplyn artefakte sal genereer:
- lêer
releases.ymlmet vrystellingsdata - lêer
common_envs.sh, wat die omgewingsveranderlikes bevat wat uitgevoer moet word.
Lêer inhoud generate_artifacts jy sal vind in ons . Om die data self te kry, is nie die onderwerp van die artikel nie, maar die lêer common_envs.sh belangrik vir ons, want werf hang daarvan af. 'n Voorbeeld van die inhoud daarvan:
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'
Jy kan die uitvoer van so 'n skrif gebruik, byvoorbeeld deur die Bash-funksie te gebruik source.
Nou kom die prettige deel. Ten einde beide die bou en ontplooiing van die toepassing korrek te werk, is dit nodig om te verseker dat werf.yaml dit was dieselfde ten minste binne een pyplyn. Indien hierdie voorwaarde nie nagekom word nie, sal die handtekeninge van die fases wat werf bereken tydens montering en byvoorbeeld ontplooiing anders wees. Dit sal lei tot 'n ontplooiingsfout, want... die prent wat benodig word vir ontplooiing sal ontbreek.
Met ander woorde, as tydens die bou van die werf beeld inligting oor vrystellings en weergawes dieselfde is, en ten tyde van ontplooiing word 'n nuwe weergawe vrygestel en die omgewing veranderlikes het verskillende waardes, dan sal die ontplooiing misluk met 'n fout: na almal, die artefak van die nuwe weergawe is nog nie gebou nie.
As generasie werf.yaml hang af van eksterne data (byvoorbeeld 'n lys van huidige weergawes, soos in ons geval), dan moet die samestelling en waardes van sulke data binne die pyplyn vasgestel word. Dit is veral belangrik as die eksterne parameters redelik gereeld verander.
Ons sal eksterne data te ontvang en reg te stel by die eerste stadium van die pyplyn in GitLab (Voorafgebou) en gee hulle verder in die vorm GitLab CI artefak. Dit sal jou toelaat om pyplyntake (bou, ontplooi, skoonmaak) uit te voer en te herbegin met dieselfde konfigurasie in werf.yaml.
Verhoog inhoud Voorafgebou lêer .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 weekNadat u die eksterne data in die artefak vasgelê het, kan u bou en ontplooi met behulp van die standaard GitLab CI-pyplynstadiums: Bou en ontplooi. Ons begin die pyplyn self deur gebruik te maak van hake van die werf GitHub-bewaarplek (d.w.s. wanneer daar veranderinge in die GitHub-bewaarplek is). Data vir hulle kan gevind word in die GitLab-projek eienskappe in die afdeling CI / CD-instellings -> Pyplyn-snellers, en skep dan die ooreenstemmende Webhook in GitHub (Instellings -> Webhooks).
Die boufase sal soos volg lyk:
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 sal twee artefakte vanaf die verhoog by die boustadium voeg Voorafgebou, dus voer ons voorbereide insetveranderlikes uit met die konstruk source common_envs.sh. Ons begin in alle gevalle met die boufase, behalwe vir die geskeduleerde bekendstelling van die pyplyn. Volgens die skedule sal ons 'n pyplyn laat loop vir skoonmaak - in hierdie geval hoef jy nie te bou nie.
Op die ontplooiingstadium sal ons twee take beskryf - afsonderlik vir ontplooiing na produksie- en ontwikkelingskringe, met behulp van 'n YAML-sjabloon:
.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
Die take verskil in wese slegs deur die klusterkonteks te spesifiseer waarin werf moet ontplooi (WERF_KUBE_CONTEXT), en stel die lus omgewing veranderlikes (environment.name и environment.url), wat dan in Helm-kaartsjablone gebruik word. Ons sal nie die inhoud van die sjablone verskaf nie, want... daar is niks interessants daar vir die betrokke onderwerp nie, maar jy kan dit vind in .
Finale aanraking
Aangesien werf weergawes redelik gereeld vrygestel word, sal nuwe beelde gereeld gebou word, en die Docker Registry sal voortdurend groei. Daarom is dit noodsaaklik om outomatiese skoonmaak van beelde volgens beleide op te stel. Dit is baie maklik om dit te doen.
Implementering sal vereis:
- Voeg 'n skoonmaakstap by
.gitlab-ci.yml; - Voeg periodieke skoonmaak werk uitvoering by;
- Stel 'n omgewingsveranderlike met 'n skryftoegangtoken.
Voeg 'n skoonmaakstadium by .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
Ons het al byna dit alles 'n bietjie hoër gesien - net vir skoonmaak moet jy eers by die Docker Registry aanmeld met 'n teken wat die regte het om beelde in die Docker Registry uit te vee (die outomaties uitgereikte GitLab CI-taaktoken het nie so regte). Die token moet vooraf in GitLab ingevoer word en die waarde daarvan moet in die omgewingsveranderlike gespesifiseer word WERF_IMAGES_CLEANUP_PASSWORD die projek (CI/CD-instellings -> Veranderlikes).
Die byvoeging van 'n skoonmaaktaak met die vereiste skedule word gedoen in CI/CD ->
Bylaes.
Dit is dit: 'n projek in die Docker-register sal nie meer voortdurend uit ongebruikte beelde groei nie.
Aan die einde van die praktiese deel, laat ek jou herinner dat die volledige lyste van die artikel beskikbaar is in :
- ;
- .
Gevolg
- Ons het 'n logiese boustruktuur: een artefak per weergawe.
- Die samestelling is universeel en vereis nie handmatige veranderings wanneer nuwe weergawes van werf vrygestel word nie: die dokumentasie op die webwerf word outomaties opgedateer.
- Twee beelde word saamgestel vir verskillende kontoere.
- Werk vinnig, want caching word tot die maksimum gebruik - wanneer 'n nuwe weergawe van werf vrygestel word of 'n GitHub-haak vir 'n hersiening geroep word - word slegs die ooreenstemmende artefak met die gewysigde weergawe herbou.
- U hoef nie daaraan te dink om ongebruikte beelde uit te vee nie: skoonmaak deur werfbeleide sal die Docker-register in orde hou.
Bevindinge
- Die gebruik van werf laat die samestelling toe om vinnig te werk as gevolg van die kas van beide die samestelling self en kas wanneer daar met eksterne bewaarplekke gewerk word.
- Om met eksterne Git-bewaarplekke te werk, elimineer die behoefte om die bewaarplek elke keer heeltemal te kloon of die wiel weer uit te vind met moeilike optimaliseringslogika. werf gebruik die kas en doen die kloon net een keer en gebruik dan
fetchen net wanneer dit nodig is. - Vermoë om Go-templates in die bou-konfigurasielêer te gebruik
werf.yamllaat jou toe om 'n samestelling te beskryf waarvan die resultaat van eksterne data afhang. - Die gebruik van mount in werf versnel die versameling van artefakte aansienlik - as gevolg van die kas, wat algemeen is vir alle pyplyne.
- werf maak dit maklik om opruiming aan te pas, wat veral waar is vir dinamiese bouwerk.
PS
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com