Dynamisk sammenstilling og distribusjon av Docker-bilder med werf ved å bruke eksemplet på en versjonert dokumentasjonsside

Vi har allerede snakket om GitOps-verktøyet vårt mer enn én gang. werf, og denne gangen vil vi gjerne dele erfaringen med å sette sammen en nettside med dokumentasjonen av selve prosjektet - werf.io (den russiske versjonen er ru.werf.ioDette er et vanlig statisk nettsted, men sammenstillingen er interessant ved at det er bygget ved hjelp av et dynamisk antall artefakter.

Vi skal ikke gå inn på nyansene i nettstedstrukturen: å generere en felles meny for alle versjoner, en side med informasjon om utgivelser osv. I stedet vil vi fokusere på problemstillingene og funksjonene ved dynamisk montering og litt på de tilhørende CI/CD-prosessene.

Introduksjon: Hvordan nettstedet fungerer

La oss starte med det faktum at werf-dokumentasjon lagres sammen med koden. Dette stiller visse krav til utvikling, som generelt sett er utenfor rammen av denne artikkelen, men i det minste kan vi si at:

• Nye werf-funksjoner bør ikke utgis uten å oppdatere dokumentasjonen, og omvendt innebærer eventuelle endringer i dokumentasjonen utgivelsen av en ny versjon av werf;
• Prosjektet har ganske intensiv utvikling: nye versjoner kan bli utgitt flere ganger om dagen;
• Eventuelle manuelle operasjoner for å distribuere et nettsted med en ny versjon av dokumentasjonen er i det minste kjedelige;
• Prosjektet benytter en semantisk tilnærming versjonering, med 5 stabilitetskanaler. Utgivelsesprosessen innebærer en sekvensiell passasje av versjoner gjennom kanaler i rekkefølge etter økende stabilitet: fra alfa til bunnsolid;
• Nettstedet har en russiskspråklig versjon, som «lever og utvikler seg» (dvs. innholdet oppdateres) parallelt med hovedversjonen (dvs. engelskspråklig).

For å skjule alle disse «indre funksjonene» fra brukeren, og tilby ham noe som «bare fungerer», lagde vi separat verktøy for installasjon og oppdatering av Werf - Er flerwerftDu trenger bare å spesifisere utgivelsesnummeret og stabilitetskanalen du er klar til å bruke, så vil multiwerf sjekke om det finnes en ny versjon på kanalen og laste den ned om nødvendig.

De nyeste versjonene av Werf er tilgjengelige i hver kanal i versjonsvalgmenyen på nettstedet. Som standard, kl. werf.io/dokumentasjon Den mest stabile kanalversjonen for den nyeste utgivelsen åpnes – den indekseres også av søkemotorer. Dokumentasjon for kanalen er tilgjengelig på separate adresser (for eksempel werf.io/v1.0-beta/dokumentasjon for betaversjon 1.0).

Totalt sett har nettstedet følgende versjoner tilgjengelig:

1. root (åpnes som standard),
2. for hver aktive oppdateringskanal i hver utgivelse (f.eks. werf.io/v1.0-beta).

For å generere en spesifikk versjon av et nettsted er det vanligvis tilstrekkelig å kompilere det ved hjelp av Jekyll, kjører i katalogen /docs werf repository tilsvarende kommando (jekyll build), etter å tidligere ha byttet til Git-taggen for den nødvendige versjonen.

Det gjenstår bare å legge til at:

• selve verktøyet (werf) brukes til montering;
• CI/CD-prosesser er bygget på grunnlag av GitLab CI;
• og alt dette kjører selvfølgelig i Kubernetes.

oppgaver

La oss nå formulere oppgavene som tar hensyn til alle de beskrevne detaljene:

1. Etter å ha endret werf-versjonen på en hvilken som helst oppdateringskanal Dokumentasjonen på nettstedet skal oppdateres automatisk.
2. For å utvikle deg må du noen ganger kunne se forhåndsvisninger av nettstedet.

Rekompilering av nettstedet må utføres etter at versjonen på en hvilken som helst kanal er endret fra de tilsvarende Git-taggene, men under prosessen med å sette sammen bildet vil vi få følgende funksjoner:

• Siden listen over versjoner på kanaler endres, er det bare nødvendig å gjenoppbygge dokumentasjonen for kanalene der versjonen har endret seg. Det er tross alt ikke særlig hyggelig å gjenoppbygge alt fra bunnen av.
• Kanalsettet for utgivelser kan endres. På et tidspunkt, for eksempel, kan det hende at det ikke finnes en versjon på kanalene som er mer stabil enn tidligtilgangsutgivelsen 1.1, men de vil dukke opp over tid – du kan ikke endre byggingen manuelt i dette tilfellet, ikke sant?

Det viser seg at Samlingen er avhengig av å endre eksterne data.

implementering

Velge en tilnærming

Alternativt kan du kjøre hver nødvendige versjon som en separat pod i Kubernetes. Dette alternativet innebærer et større antall objekter i klyngen, som vil vokse med økningen i antall stabile werf-utgivelser. Og dette innebærer igjen mer komplekst vedlikehold: hver versjon har sin egen HTTP-server, med liten belastning. Dette medfører selvfølgelig også større ressurskostnader.

Vi gikk samme vei versjoner av alle nødvendige versjoner i ett bildeDen kompilerte statistikken for alle versjoner av nettstedet er i en container med NGINX, og trafikk til den tilsvarende distribusjonen kommer gjennom NGINX Ingress. En enkel struktur – en tilstandsløs applikasjon – lar deg enkelt skalere distribusjonen (avhengig av belastningen) ved hjelp av selve Kubernetes.

For å være mer presis, bygger vi to images: ett for produksjonskretsen, det andre er et tillegg for utviklingskretsen. Det ekstra imaget brukes (kjøres) kun på utviklingskretsen sammen med hovedimaget og inneholder versjonen av nettstedet fra gjennomgangs-commiten, og ruting mellom dem utføres ved hjelp av Ingress-ressurser.

Werf vs. git-klone og artefakter

Som nevnt, for å generere nettstedsstatistikk for en bestemt versjon av dokumentasjonen, må du bygge ved å bytte til den tilsvarende repository-taggen. Du kan også gjøre dette ved å klone repositoriet hver gang du bygger, og velge de tilsvarende taggene fra listen. Dette er imidlertid en ganske ressurskrevende operasjon, og krever i tillegg skriving av ikke-trivielle instruksjoner... En annen alvorlig ulempe er at med denne tilnærmingen er det ingen måte å mellomlagre noe under byggingen.

Her kommer selve werf-verktøyet oss til unnsetning, og implementerer smart mellomlagring og lar deg bruke eksterne arkiverÅ bruke werf til å legge til kode fra et repository vil øke hastigheten på byggingen betraktelig, siden werf i hovedsak kloner repositoryet én gang og deretter kjører. bare fetch om nødvendig. I tillegg, når vi legger til data fra depotet, kan vi bare velge de nødvendige katalogene (i vårt tilfelle er dette katalogen docs), noe som vil redusere mengden ekstra data betydelig.

Siden Jekyll er et verktøy designet for å kompilere statiske filer og ikke er nødvendig i det endelige bildet, ville det være logisk å kompilere i gjenstandswerft, og i det endelige bildet importer bare kompileringsresultatet.

Vi skriver werf.yaml

Så bestemte vi oss for å kompilere hver versjon i et separat werf-artefakt. Men vi Vi vet ikke hvor mange av disse gjenstandene det vil være under monteringen, så vi kan ikke skrive en fast byggekonfigurasjon (strengt tatt kan vi det, men det vil ikke være veldig effektivt).

werf lar deg bruke Gå til maler i konfigurasjonsfilen din (werf.yaml), og dette gjør det mulig generer konfigurasjon "på farten" avhengig av eksterne data (det vi trenger!). I vårt tilfelle er eksterne data informasjon om versjoner og utgivelser, basert på hvilke vi samler inn det nødvendige antallet artefakter og får to bilder som et resultat: werf-doc и werf-dev for start på forskjellige kretser.

Eksterne data sendes gjennom miljøvariabler. Her er sammensetningen deres:

• RELEASES — en linje med en liste over utgivelser og den tilhørende gjeldende versjonen av werf, som en mellomromseparert liste over verdier i formatet <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Eksempel: 1.0%v1.0.4-beta.20
• CHANNELS — en linje med en liste over kanaler og den tilhørende gjeldende versjonen av werf, i form av en mellomromseparert liste over verdier i formatet <КАНАЛ>%<НОМЕР_ВЕРСИИ>... Eksempel: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — werf-utgivelsesversjon som skal vises som standard på nettstedet (det er ikke alltid nødvendig å vise dokumentasjon med det høyeste utgivelsesnummeret). Eksempel: v1.0.4-beta.20
• REVIEW_SHA — hashen til gjennomgangs-commiten som versjonen for testkretsen skal bygges fra.

Disse variablene vil bli fylt ut i GitLab CI-pipelinen, og nøyaktig hvordan er beskrevet nedenfor.

Først av alt, for enkelhets skyld, la oss definere werf.yaml Gå til malvariabler ved å tilordne dem verdier fra miljøvariabler:

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

Beskrivelsen av artefakten for kompilering av den statiske versjonen av nettstedet er generelt den samme for alle tilfellene vi trenger (inkludert generering av rotversjonen, samt versjonen for dev-konturen). Derfor vil vi ta den ut til en egen blokk ved hjelp av funksjonen define — for senere gjenbruk ved hjelp av includeVi sender følgende argumenter til malen:

• Version — den genererte versjonen (tagnavn);
• Channel – navnet på oppdateringskanalen som artefakten genereres for;
• Commit — commit hash, hvis artefaktet genereres for en gjennomgangs-commit;
• kontekst.

Beskrivelse av artefaktmalen

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

Artefaktnavnet må være unikt. Vi kan oppnå dette ved for eksempel å legge til kanalnavnet (variabelverdien .Channel) som et suffiks til artefaktnavnet: artifact: doc-{{ .Channel }}Men du må forstå at når du importerer fra artefakter, må du referere til de samme navnene.

Når man beskriver en artefakt, brukes følgende werf-funksjon: monteringMontering med en spesifisert servicekatalog build_dir lar deg bevare Jekyll-hurtigbufferen mellom pipeline-kjøringer, noe som raskere montering av nytt materiale.

Du har kanskje også lagt merke til bruken av filen releases.yml — er en YAML-fil med utgivelsesdata forespurt fra github.com (en artefakt som innhentes når man kjører en pipeline). Den er nødvendig når man kompilerer et nettsted, men i artikkelens kontekst er den interessant for oss fordi tilstanden avhenger av gjenoppbygging av bare én gjenstand — artefakt fra rotversjonen av nettstedet (den er ikke nødvendig i andre artefakter).

Dette implementeres ved hjelp av den betingede operatoren. if Gå til maler og konstruksjoner {{ $Root.Files.Get "releases.yml" | sha256sum }} i scenen etapperDet fungerer slik: når man bygger en artefakt for rotversjonen (variabel .Channel er lik root) fil-hash releases.yml påvirker signaturen til hele scenen, siden den er en komponent av Ansible-oppgavenavnet (parameter name). Dermed, når du endrer innhold fil releases.yml Den tilhørende artefakten vil bli satt sammen på nytt.

Vær også oppmerksom på å jobbe med et eksternt arkiv. I artefaktbildet fra werf-repositorier, bare katalogen legges til /docs, og avhengig av parameterne som sendes, legges dataene for den nødvendige taggen eller gjennomgangs-commiten umiddelbart til.

For å bruke artefaktmalen til å generere en artefaktbeskrivelse av de overførte kanalversjonene og -utgivelsene, organiserer vi en løkke etter variabel .WerfVersions в werf.yaml:

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

Siden syklusen vil generere flere artefakter (håper vi det), er det nødvendig å ta hensyn til skillet mellom dem - sekvensen --- (for mer informasjon om konfigurasjonsfilsyntaksen, se dokumentasjonSom vi definerte tidligere, sender vi versjonsparametrene, URL-en og rotkonteksten når vi kaller malen i løkken.

På samme måte, men uten syklusen, kaller vi artefaktmalen for «spesialtilfeller»: for rotversjonen, så vel som versjonen fra gjennomgangs-commiten:

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

Merk at artefakten for gjennomgangs-commiten bare vil bli bygget hvis variabelen er satt. .WerfReviewCommit.

Artefaktene er klare – det er på tide å begynne å importere!

Det endelige bildet som er ment å kjøre på Kubernetes er en vanlig NGINX med en serverkonfigurasjonsfil lagt til. nginx.conf og statikk fra artefakter. I tillegg til artefakten til rotversjonen av nettstedet, må vi gjenta syklusen etter variabel .WerfVersions for å importere artefakter for kanal og utgivelsesversjoner + følg regelen for navngivning av artefakter som vi tok i bruk tidligere. Siden hver artefakt lagrer nettstedsversjoner for to språk, importerer vi dem til plasseringene som er oppgitt av konfigurasjonen.

Beskrivelse av det endelige bildet 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 -}}

Det ekstra bildet, som lanseres på utviklerkretsen sammen med hovedbildet, inneholder bare to versjoner av nettstedet: versjonen fra gjennomgangs-commiten og rotversjonen av nettstedet (det inneholder vanlige ressurser og, hvis du husker, utgivelsesdata). Dermed vil det ekstra bildet bare avvike fra hovedbildet i importdelen (og selvfølgelig navnet):

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 nevnt ovenfor, vil artefakten for gjennomgangs-commit bare genereres når den angitte miljøvariabelen kjøres. REVIEW_SHADet ville være mulig å ikke generere werf-dev-avbildningen i det hele tatt hvis det ikke finnes noen miljøvariabel. REVIEW_SHA, men for å rengjøring etter retningslinjer Docker-avbildningene i werf fungerte for werf-dev-avbildningen. Vi lar den bygges kun med rotversjonsartefakten (den er allerede bygget uansett) for å forenkle pipeline-strukturen.

Byggingen er klar! La oss gå videre til CI/CD og viktige nyanser.

Pipeline i GitLab CI og funksjoner for dynamisk bygging

Når vi kjører byggingen, må vi angi miljøvariablene som brukes i werf.yamlDette gjelder ikke for REVIEW_SHA-variabelen, som vi angir når vi kaller pipelinen fra GitHub-kroken.

Vi vil flytte dannelsen av nødvendige eksterne data til et Bash-skript generate_artifacts, som vil generere to GitLab-pipeline-artefakter:

• файл releases.yml med utgivelsesdata,
• файл common_envs.sh, som inneholder miljøvariabler for eksport.

Filinnhold generate_artifacts du finner i vår arkiver med eksemplerSelve datainnsamlingen er ikke temaet for artikkelen, men filen common_envs.sh er viktig for oss, fordi driften av werf avhenger av det. Et eksempel på innholdet:

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'

Utdataene fra et slikt skript kan for eksempel brukes ved å bruke Bash-funksjonen source.

Nå kommer den mest interessante delen. For at både montering og utrulling av applikasjonen skal fungere riktig, er det nødvendig å sørge for at werf.yaml det var det samme minst innenfor én rørledningHvis denne betingelsen ikke er oppfylt, vil stadiumsignaturene som Werf beregner under montering og for eksempel distribusjon, være forskjellige. Dette vil føre til en distribusjonsfeil, siden bildet som kreves for distribusjon vil mangle.

Med andre ord, hvis informasjonen om utgivelser og versjoner er den samme under monteringen av nettstedsbildet, og en ny versjon slippes og miljøvariablene har forskjellige verdier på distribusjonstidspunktet, vil distribusjonen avsluttes med en feil: tross alt er ikke artefakten til den nye versjonen satt sammen ennå.

Hvis generasjon werf.yaml avhenger av eksterne data (for eksempel en liste over gjeldende versjoner, som i vårt tilfelle), bør sammensetningen og verdiene til slike data registreres i pipelinen. Dette er spesielt viktig hvis eksterne parametere endres ganske ofte.

Vi vil motta og registrere eksterne data i den første fasen av pipelinen i GitLab (Forhåndsbygging) og overføre dem videre i form GitLab CI-artefakterDette lar deg kjøre og starte pipeline-oppgaver på nytt (bygge, distribuere, rydde) med samme konfigurasjon i werf.yaml.

Innholdet på scenen Forhåndsbygging 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

Når du har fikset eksterne data i artefaktet, kan du bygge og distribuere ved hjelp av standardtrinnene i GitLab CI-pipelinen: Bygg og distribuer. Vi starter selve pipelinen ved hjelp av kroker fra werf GitHub-repositoriet (dvs. når det er endringer i repositoriet på GitHub). Dataene for dem kan hentes fra GitLab-prosjektegenskapene i seksjonen. CI/CD-innstillinger -> Pipeline-utløsere, og deretter opprette den tilsvarende Webhooken i GitHub (Innstillinger -> Webhooks).

Byggefasen vil se slik ut:

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 vil legge til to artefakter fra scenen til byggefasen Forhåndsbygging, så vi eksporterer variabler med forberedte inndata ved hjelp av konstruksjonen source common_envs.shVi starter byggefasen i alle tilfeller unntatt lansering av rørledningen etter planen. Vi vil lansere rørledningen for rengjøring etter planen – det er ikke nødvendig å utføre byggingen i dette tilfellet.

I utrullingsfasen vil vi beskrive to oppgaver – separat for utrulling til produksjons- og utviklingskretser, ved hjelp av en YAML-mal:

.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

Oppgavene skiller seg i hovedsak bare i angivelsen av klyngekonteksten som werf skal utføre distribusjonen i (WERF_KUBE_CONTEXT), og angi konturmiljøvariablene (environment.name и environment.url), som deretter brukes i Helm-diagrammaler. Vi vil ikke oppgi innholdet i malene, siden det ikke finnes noe interessant for emnet som vurderes, men du kan finne dem i arkiver til artikkelen.

Endelig berøring

Siden werf-versjoner slippes ganske ofte, vil nye images bli bygget ofte, og Docker Registry vil stadig vokse. Derfor er det nødvendig å sette opp automatisk image-rensing etter policyer. Det er veldig enkelt å gjøre.

For implementering trenger du:

• Legg til et rengjøringstrinn til .gitlab-ci.yml;
• Legg til periodisk utførelse av rengjøringsoppgaven;
• Sett opp en miljøvariabel med et skrivetilgangstoken.

Legg til et rengjøringstrinn til .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 allerede sett nesten alt dette ovenfor – bare for å rydde opp i det, må du først logge inn i Docker Registry med et token som har rett til å slette bilder i Docker Registry (det automatisk utstedte tokenet for GitLab CI-oppgaven har ikke slike rettigheter). Tokenet må opprettes i GitLab på forhånd, og verdien må spesifiseres i miljøvariabelen. WERF_IMAGES_CLEANUP_PASSWORD prosjekt (CI/CD-innstillinger -> Variabler).

Legge til en rengjøringsoppgave med den nødvendige tidsplanen gjøres i CI/CD ->
Rutetider.

Det var det: Docker Registry-prosjektet ditt vil ikke lenger stadig vokse fra ubrukte bilder.

Som avslutning på den praktiske delen vil jeg minne deg på at de fullstendige listene fra artikkelen er tilgjengelige i gå:

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

Resultat

1. Vi fikk en logisk monteringsstruktur: én artefakt per versjon.
2. Samlingen er universell og krever ikke manuelle endringer når nye versjoner av Werf slippes: dokumentasjonen på nettstedet oppdateres automatisk.
3. To bilder er samlet inn for forskjellige konturer.
4. Det fungerer raskt fordi mellomlagring brukes i maksimal grad – når en ny versjon av Werf slippes eller en GitHub-krok kalles for en gjennomgangs-commit, gjenoppbygges bare den tilsvarende artefakten med den endrede versjonen.
5. Du trenger ikke å bekymre deg for å slette ubrukte bilder: werf-policybasert opprydding vil holde Docker-registeret ditt ryddig.

Funn

• Bruk av werf lar byggingen jobbe raskt på grunn av mellomlagring av både selve byggingen og mellomlagring når du arbeider med eksterne repositorier.
• Å jobbe med eksterne Git-repositorier eliminerer behovet for å klone repositoriet helt hver gang eller å finne opp hjulet på nytt med vanskelig optimaliseringslogikk. Werf bruker en hurtigbuffer og kloner bare én gang, og bruker deretter fetch og bare når det er nødvendig.
• Mulighet til å bruke Go-maler i byggekonfigurasjonsfilen werf.yaml lar deg beskrive en samling hvis resultat avhenger av eksterne data.
• Bruk av montering i werf øker hastigheten på innsamlingen av artefakter betydelig – på grunn av mellomlagringen, som er felles for alle pipelines.
• werf gjør det enkelt å konfigurere opprydding, noe som er spesielt viktig for dynamiske bygg.

PS

Les også på bloggen vår:

• «Kjøre kommandoer under levering av en ny applikasjonsversjon i Kubernetes";
• «Bygg og distribuer mikrotjenester av samme type med werf og GitLab CI";
• «Bruker werf til å rulle ut komplekse Helm-diagrammer";
• «Vi introduserer werf 1.0 stabil: hva har GitOps med det å gjøre, status og planer'.

Kilde: www.habr.com