Dynamisk sammansättning och distribution av Docker-avbildningar med werf med exemplet på en versionerad dokumentationswebbplats

Vi har redan pratat om vårt GitOps-verktyg mer än en gång. werf, och den här gången vill vi dela med oss ​​av vår erfarenhet av att montera platsen med dokumentationen av själva projektet - werf.io (dess ryska version är en.werf.io). Detta är en vanlig statisk plats, men dess sammansättning är intressant eftersom den är byggd med ett dynamiskt antal artefakter.

Gå in på nyanserna i webbplatsstrukturen: generera en gemensam meny för alla versioner, sidor med information om utgåvor, etc. - vi kommer inte. Låt oss istället fokusera på problemen och funktionerna i dynamisk montering och lite på de medföljande CI/CD-processerna.

Introduktion: hur sajten fungerar

Till att börja med lagras werf-dokumentation tillsammans med dess kod. Detta ställer vissa utvecklingskrav som i allmänhet ligger utanför ramen för denna artikel, men åtminstone kan man säga att:

• Nya werf-funktioner bör inte släppas utan uppdatering av dokumentationen och omvänt innebär alla ändringar i dokumentationen att en ny version av werf släpps;
• Projektet har en ganska intensiv utveckling: nya versioner kan släppas flera gånger om dagen;
• Alla manuella åtgärder för att distribuera en webbplats med en ny version av dokumentationen är åtminstone tråkiga;
• Projektet har ett semantiskt synsätt versionshantering, med 5 stabilitetskanaler. Releaseprocessen involverar sekventiell passage av versioner genom kanaler för att öka stabiliteten: från alfa till stenfast;
• Webbplatsen har en ryskspråkig version, som "lever och utvecklas" (dvs vars innehåll uppdateras) parallellt med huvudversionen (dvs engelskspråkig).

För att dölja allt detta "inre kök" för användaren, erbjuda honom något som "bara fungerar", gjorde vi separat werf installations- och uppdateringsverktyg - Är multiwerf. Du behöver bara ange releasenummer och stabilitetskanalen som du är redo att använda, så kommer multiwerf att kontrollera om det finns en ny version på kanalen och ladda ner den om det behövs.

I versionsvalmenyn på webbplatsen finns de senaste versionerna av werf tillgängliga i varje kanal. Som standard, efter adress werf.io/documentation versionen av den mest stabila kanalen för den senaste utgåvan öppnas - den indexeras också av sökmotorer. Dokumentation för kanalen finns på separata adresser (t.ex. werf.io/v1.0-beta/documentation för betaversion 1.0).

Sammanlagt har webbplatsen följande versioner tillgängliga:

1. root (öppnas som standard),
2. för varje aktiv uppdateringskanal för varje utgåva (till exempel, werf.io/v1.0-beta).

För att generera en specifik version av en webbplats räcker det i allmänhet att kompilera den med hjälp av Jekyllgenom att köra i katalogen /docs werf repository motsvarande kommando (jekyll build), efter att ha bytt till Git-taggen för den nödvändiga versionen.

Det återstår bara att tillägga:

• själva verktyget (werf) används för montering;
• CI/CD-processer är byggda på basis av GitLab CI;
• och allt detta körs naturligtvis i Kubernetes.

uppgifter

Låt oss nu formulera uppgifter som tar hänsyn till alla beskrivna detaljer:

1. Efter att ha ändrat werf-versionen på valfri uppdateringskanal dokumentationen på webbplatsen bör uppdateras automatiskt.
2. För utveckling behöver man kunna ibland visa förhandsversioner av webbplatsen.

Webbplatsen måste kompileras om efter att ha ändrat versionen på valfri kanal från motsvarande Git-taggar, men i processen att bygga bilden kommer vi att få följande funktioner:

• Eftersom listan över versioner på kanaler ändras är det bara nödvändigt att bygga om dokumentationen för kanaler där versionen har ändrats. Att bygga om allt igen är trots allt inte särskilt trevligt.
• Uppsättningen av kanaler för releaser kan ändras. Vid någon tidpunkt, till exempel, kanske det inte finns en version på kanalerna som är mer stabil än 1.1-versionen med tidig åtkomst, men med tiden kommer de att dyka upp - i det här fallet, borde du inte ändra monteringen manuellt?

Det visar sig att montering beror på att extern data ändras.

genomförande

Att välja ett tillvägagångssätt

Alternativt kan du köra varje version som krävs som en separat pod i Kubernetes. Det här alternativet innebär ett större antal objekt i klustret, vilket kommer att växa med ökningen av antalet stabila werfsläpp. Och detta innebär i sin tur mer komplext underhåll: varje version har sin egen HTTP-server och med en liten belastning. Detta medför naturligtvis också större resurskostnader.

Vi tog samma väg samla alla nödvändiga versioner i en bild. Den kompilerade statistiken för alla versioner av webbplatsen finns i en container med NGINX, och trafik till motsvarande Deployment kommer via NGINX Ingress. En enkel struktur - en tillståndslös applikation - gör att du enkelt kan skala Deployment (beroende på belastningen) med Kubernetes själv.

För att vara mer exakt samlar vi in ​​två bilder: en för produktionskretsen, den andra är en extra för utvecklingskretsen. Tilläggsbilden används (lanseras) endast på dev-kretsen tillsammans med den huvudsakliga och innehåller versionen av webbplatsen från gransknings-commit, och routing mellan dem utförs med hjälp av Ingress-resurser.

werf vs git klon och artefakter

Som redan nämnts, för att generera webbplatsstatik för en specifik version av dokumentationen, måste du bygga genom att byta till lämplig repository-tagg. Du kan också göra detta genom att klona förvaret varje gång du bygger, välja lämpliga taggar från en lista. Detta är dock en ganska resurskrävande operation och kräver dessutom att man skriver icke-triviala instruktioner... En annan allvarlig nackdel är att med detta tillvägagångssätt finns det inget sätt att cache något under montering.

Här kommer själva werfverktyget till vår hjälp och implementerar smart cachelagring och låter dig använda externa förråd. Att använda werf för att lägga till kod från förvaret kommer att påskynda bygget avsevärt, eftersom werf klonar i princip förvaret en gång och körs sedan endast fetch om nödvändigt. Dessutom, när vi lägger till data från förvaret, kan vi bara välja de nödvändiga katalogerna (i vårt fall är detta katalogen docs), vilket avsevärt kommer att minska mängden tillagd data.

Eftersom Jekyll är ett verktyg designat för att kompilera statisk data och inte behövs i den slutliga bilden, skulle det vara logiskt att kompilera i werf artefakt, och in i den slutliga bilden importera endast kompileringsresultatet.

Vi skriver werf.yaml

Så vi bestämde att vi skulle kompilera varje version i en separat werfartefakt. Men vi vi vet inte hur många av dessa artefakter det kommer att finnas under monteringen, så vi kan inte skriva en fast byggkonfiguration (strängt taget kan vi fortfarande, men det kommer inte att vara helt effektivt).

werf låter dig använda Gå mallar i din konfigurationsfil (werf.yaml), och detta gör det möjligt generera konfiguration i farten beroende på extern data (vad du behöver!). Extern data i vårt fall är information om versioner och utgåvor, på grundval av vilken vi samlar in det erforderliga antalet artefakter och som ett resultat får vi två bilder: werf-doc и werf-dev att köra på olika kretsar.

Extern data skickas genom miljövariabler. Här är deras sammansättning:

• RELEASES — en rad med en lista över utgåvor och motsvarande aktuella version av werf, i form av en mellanslagsseparerad värdelista i formatet <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Exempel: 1.0%v1.0.4-beta.20
• CHANNELS — en rad med en lista över kanaler och motsvarande aktuella version av werf, i form av en mellanslagsseparerad värdelista i formatet <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Exempel: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — werf version som ska visas som standard på webbplatsen (det är inte alltid nödvändigt att visa dokumentation med det högsta releasenumret). Exempel: v1.0.4-beta.20
• REVIEW_SHA — hash för granskningsåtagandet från vilket du behöver bygga versionen för testslingan.

Dessa variabler kommer att fyllas i i GitLab CI-pipeline, och hur exakt skrivs nedan.

Först av allt, för bekvämlighets skull, definierar vi in werf.yaml Gå till mallvariabler, tilldela dem värden från miljövariabler:

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

Beskrivningen av artefakten för att kompilera den statiska versionen av webbplatsen är i allmänhet densamma för alla fall vi behöver (inklusive generering av rotversionen, såväl som versionen för dev-kretsen). Därför kommer vi att flytta det till ett separat block med hjälp av funktionen define - för efterföljande återanvändning include. Vi skickar följande argument till mallen:

• Version — genererad version (taggnamn);
• Channel — Namnet på uppdateringskanalen för vilken artefakten genereras.
• Commit — commit hash, om artefakten genereras för en gransknings commit;
• sammanhang.

Beskrivning av artefaktmall

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

Artefaktens namn måste vara unikt. Vi kan till exempel uppnå detta genom att lägga till kanalnamnet (variabelns värde .Channel) som ett suffix till namnet på artefakten: artifact: doc-{{ .Channel }}. Men du måste förstå att när du importerar från artefakter måste du referera till samma namn.

När man beskriver en artefakt används följande werf-funktion: montering. Montering som indikerar servicekatalogen build_dir låter dig spara Jekyll-cachen mellan pipelinekörningar, vilket påskyndar återmonteringen avsevärt.

Du kanske också har märkt användningen av filen releases.yml är en YAML-fil med utgivningsdata som begärts från github.com (en artefakt som erhålls vid exekvering av en pipeline). Det behövs när man sammanställer webbplatsen, men i samband med artikeln är det intressant för oss eftersom det beror på dess tillstånd återmontering av endast en artefakt — en artefakt av webbplatsens rotversion (den behövs inte i andra artefakter).

Detta implementeras med hjälp av det villkorade uttalandet if Gå till mallar och mönster {{ $Root.Files.Get "releases.yml" | sha256sum }} i scenen etapper. Det fungerar enligt följande: när man bygger en artefakt för rotversionen (variabel .Channel är lika med root) filhash releases.yml påverkar signaturen för hela scenen, eftersom den är en del av namnet på Ansible-uppgiften (parameter name). Alltså när man byter innehåll fil releases.yml motsvarande artefakt kommer att återmonteras.

Var också uppmärksam på att arbeta med ett externt arkiv. I bilden av en artefakt från werf förvaret, endast katalogen läggs till /docs, och beroende på de angivna parametrarna, läggs data för den nödvändiga taggen eller granskningsbekräftelsen till omedelbart.

För att använda artefaktmallen för att generera en beskrivning av artefakten för de överförda versionerna av kanaler och releaser, organiserar vi en loop på variabeln .WerfVersions в werf.yaml:

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

Därför att slingan kommer att generera flera artefakter (vi hoppas det), det är nödvändigt att ta hänsyn till separatorn mellan dem - sekvensen --- (För mer information om konfigurationsfilsyntax, se dokumentation). Som definierats tidigare, när vi anropar en mall i en loop, skickar vi versionsparametrarna, URL och rotkontext.

På liknande sätt, men utan en loop, kallar vi artefaktmallen för "speciella fall": för rotversionen, såväl som versionen från granskningen 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 }}

Observera att artefakten för granskningsåtagandet endast kommer att byggas om variabeln är inställd .WerfReviewCommit.

Artefakterna är klara - det är dags att börja importera!

Den slutliga bilden, designad för att köras på Kubernetes, är en vanlig NGINX med en serverkonfigurationsfil tillagd nginx.conf och statisk från artefakter. Förutom artefakten av rotversionen av webbplatsen måste vi upprepa slingan på variabeln .WerfVersions för att importera artefakter av kanal- och releaseversioner + följ artefaktnamnsregeln som vi antog tidigare. Eftersom varje artefakt lagrar versioner av webbplatsen för två språk, importerar vi dem till de platser som tillhandahålls av konfigurationen.

Beskrivning av den slutliga bilden 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 -}}

Tilläggsbilden, som, tillsammans med den huvudsakliga, lanseras på dev-kretsen, innehåller bara två versioner av webbplatsen: versionen från gransknings-commit och rotversionen av webbplatsen (det finns allmänna tillgångar och, om du kommer ihåg , släpp data). Således kommer den extra bilden att skilja sig från den huvudsakliga endast i importsektionen (och, naturligtvis, i namnet):

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

Som nämnts ovan kommer artefakten för granskningsbekräftelsen att genereras endast när den inställda miljövariabeln körs REVIEW_SHA. Det skulle vara möjligt att inte generera werf-dev-bilden alls om det inte finns någon miljövariabel REVIEW_SHA, men för att städning enligt policyer Docker-bilder i werf fungerade för werf-dev-bilden, vi kommer att låta den byggas endast med artefakten för rotversionen (den är redan byggd i alla fall), för att förenkla pipelinestrukturen.

Monteringen är klar! Låt oss gå vidare till CI/CD och viktiga nyanser.

Pipeline i GitLab CI och funktioner för dynamiskt bygge

När vi kör bygget måste vi ställa in de miljövariabler som används i werf.yaml. Detta gäller inte för variabeln REVIEW_SHA, som vi ställer in när vi anropar pipeline från GitHub-kroken.

Vi kommer att generera nödvändig extern data i ett Bash-skript generate_artifacts, som kommer att generera två GitLab pipeline-artefakter:

• файл releases.yml med releasedata,
• файл common_envs.sh, som innehåller de miljövariabler som ska exporteras.

Filens innehåll generate_artifacts hittar du i vår arkiv med exempel. Att ta emot själva data är inte föremålet för artikeln, utan filen common_envs.sh är viktigt för oss, eftersom werfs arbete beror på det. Ett exempel på dess innehåll:

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'

Du kan använda utdata från ett sådant skript, till exempel genom att använda Bash-funktionen source.

Nu kommer den roliga delen. För att både konstruktionen och driftsättningen av applikationen ska fungera korrekt är det nödvändigt att säkerställa det werf.yaml det var det samma åtminstone inom en pipeline. Om detta villkor inte är uppfyllt, kommer signaturerna för de steg som werf beräknar under montering och till exempel driftsättning att vara annorlunda. Detta kommer att leda till ett distributionsfel, eftersom... bilden som krävs för distribution kommer att saknas.

Med andra ord, om informationen om utgåvor och versioner är densamma under monteringen av webbplatsbilden, och vid tidpunkten för implementeringen släpps en ny version och miljövariablerna har olika värden, kommer distributionen att misslyckas med ett fel: trots allt har artefakten av den nya versionen ännu inte byggts.

Om generation werf.yaml beror på externa data (till exempel en lista över aktuella versioner, som i vårt fall), då bör sammansättningen och värdena för sådana data registreras i pipelinen. Detta är särskilt viktigt om externa parametrar ändras ganska ofta.

Vi kommer ta emot och spela in extern data i det första steget av pipelinen i GitLab (Förbyggd) och överför dem vidare i formuläret GitLab CI-artefakt. Detta gör att du kan köra och starta om pipeline-jobb (bygga, distribuera, städa) med samma konfiguration i werf.yaml.

Scenens innehåll Förbyggd fil .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

Efter att ha fångat externa data i artefakten, kan du bygga och distribuera med hjälp av standard GitLab CI pipeline-steg: Bygg och distribuera. Vi lanserar själva pipelinen med hjälp av krokar från werf GitHub-förvaret (dvs när det finns ändringar i GitHub-förvaret). Data för dem kan hittas i GitLab-projektets egenskaper i avsnittet CI/CD-inställningar -> Pipeline-utlösare, och skapa sedan motsvarande Webhook i GitHub (Inställningar -> Webhooks).

Byggstadiet kommer att se ut så här:

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 kommer att lägga till två artefakter från scenen till byggstadiet Förbyggd, så vi exporterar variabler med förberedda indata med hjälp av konstruktionen source common_envs.sh. Vi påbörjar byggskedet i alla fall, förutom att lansera pipelinen enligt ett schema. Enligt schemat kommer vi att köra en pipeline för rengöring - i det här fallet behöver vi inte utföra montering.

I distributionsstadiet kommer vi att beskriva två uppgifter - separat för distribution till produktions- och dev-kretsar, med hjälp av en YAML-mall:

.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

Uppgifterna skiljer sig i huvudsak endast genom att ange i vilket klusterkontext werf ska utföra distributionen (WERF_KUBE_CONTEXT), och ställer in loopmiljövariablerna (environment.name и environment.url), som sedan används i Helm-diagrammallar. Vi kommer inte att tillhandahålla innehållet i mallarna, eftersom... det finns inget intressant där för ämnet i fråga, men du kan hitta dem i arkiv för artikeln.

Slutlig touch

Eftersom werf-versioner släpps ganska ofta, kommer nya bilder att byggas ofta, och Docker Registry kommer ständigt att växa. Därför är det absolut nödvändigt att konfigurera automatisk bildrensning baserat på policyer. Det är väldigt lätt att göra.

För att implementera behöver du:

• Lägg till ett rengöringssteg till .gitlab-ci.yml;
• Lägg till periodisk utförande av en rengöringsuppgift;
• Ställ in en miljövariabel med en skrivåtkomsttoken.

Lägga till ett rengöringssteg till .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

Vi har redan sett nästan allt detta lite högre - bara för att rengöra det måste du först logga in på Docker Registry med en token som har rättigheter att ta bort bilder i Docker Registry (den automatiskt utfärdade GitLab CI-uppgiftstoken gör det inte har sådana rättigheter). Token måste skapas i GitLab i förväg och dess värde måste anges i miljövariabeln WERF_IMAGES_CLEANUP_PASSWORD projektet (CI/CD-inställningar -> Variabler).

Lägga till en städuppgift med önskat schema görs i CI/CD ->
Scheman.

Det är allt: ett projekt i Docker Registry kommer inte längre att ständigt växa från oanvända bilder.

I slutet av den praktiska delen, låt mig påminna dig om att fullständiga listor från artikeln finns tillgängliga i gå:

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

Resultat

1. Vi fick en logisk monteringsstruktur: en artefakt per version.
2. Monteringen är universell och kräver inga manuella ändringar när nya versioner av werf släpps: dokumentationen på webbplatsen uppdateras automatiskt.
3. Två bilder är sammansatta för olika konturer.
4. Det fungerar snabbt, eftersom Caching används så mycket som möjligt - när en ny version av werf släpps eller en GitHub-hook anropas för en granskning, byggs endast motsvarande artefakt med den ändrade versionen om.
5. Du behöver inte tänka på att ta bort oanvända bilder: rengöring enligt werf-policyer kommer att hålla ordning på Docker-registret.

Resultat

• Genom att använda werf kan sammansättningen fungera snabbt på grund av cachning av både själva sammansättningen och cachning när man arbetar med externa repositories.
• Att arbeta med externa Git-förråd eliminerar behovet av att klona hela förvaret varje gång eller återuppfinna hjulet med knepig optimeringslogik. werf använder en cache och gör kloningen bara en gång och använder sedan fetch och endast när det behövs.
• Möjlighet att använda Go-mallar i byggkonfigurationsfilen werf.yaml låter dig beskriva en sammansättning vars resultat beror på externa data.
• Att använda mount in werf snabbar upp insamlingen av artefakter avsevärt - på grund av cachen, som är gemensam för alla pipelines.
• werf gör det enkelt att konfigurera rengöring, vilket är särskilt viktigt när man bygger dynamiskt.

PS

Läs även på vår blogg:

• «Kör kommandon samtidigt som en ny programversion levereras till Kubernetes";
• «Bygg och distribuera mikrotjänster av samma typ med werf och GitLab CI";
• «Använder werf för att rulla ut komplexa Helm-diagram";
• «Vi introducerar werf 1.0 stabil: vad har GitOps med det att göra, status och planer".

Källa: will.com