ProHoster > Blog > Uprava > Dinamično sestavljanje in uvajanje slik Docker z werf na primeru dokumentacijskega mesta z različicami

Dinamično sestavljanje in uvajanje slik Docker z werf na primeru dokumentacijskega mesta z različicami

Več kot enkrat smo že govorili o našem orodju GitOps. werf, tokrat pa bi radi delili naše izkušnje pri sestavljanju strani z dokumentacijo samega projekta - werf.io (njegova ruska različica je en.werf.io). To je običajno statično spletno mesto, vendar je njegova sestava zanimiva, ker je zgrajena z uporabo dinamičnega števila artefaktov.

Dinamično sestavljanje in uvajanje slik Docker z werf na primeru dokumentacijskega mesta z različicami

Pojdite v nianse strukture spletnega mesta: ustvarjanje skupnega menija za vse različice, strani z informacijami o izdajah itd. - ne bomo. Namesto tega se osredotočimo na težave in značilnosti dinamičnega sestavljanja in malo na spremljajoče procese CI/CD.

Uvod: kako spletno mesto deluje

Za začetek je dokumentacija werf shranjena skupaj z njegovo kodo. To nalaga določene razvojne zahteve, ki na splošno presegajo področje uporabe tega članka, vendar je mogoče reči vsaj naslednje:

  • Nove funkcije werf ne smejo biti izdane brez posodobitve dokumentacije in nasprotno, kakršne koli spremembe v dokumentaciji pomenijo izdajo nove različice werf;
  • Projekt ima dokaj intenziven razvoj: nove različice se lahko izdajo večkrat na dan;
  • Vse ročne operacije za namestitev mesta z novo različico dokumentacije so vsaj dolgočasne;
  • Projekt sprejme semantični pristop različic, s 5 kanali stabilnosti. Postopek izdaje vključuje zaporedno prehajanje različic skozi kanale v vrstnem redu naraščajoče stabilnosti: od alfa do trdne kot skala;
  • Spletno mesto ima različico v ruskem jeziku, ki "živi in ​​se razvija" (tj. vsebina se posodablja) vzporedno z glavno (tj. angleško-jezično) različico.

Da bi uporabniku skrili vso to »notranjo kuhinjo« in mu ponudili nekaj, kar »samo deluje«, smo to storili ločeno orodje za namestitev in posodobitev werf - Je multiwerf. Samo določiti morate številko izdaje in kanal stabilnosti, ki ste ga pripravljeni uporabiti, in multiwerf bo preveril, ali je na kanalu nova različica, in jo po potrebi prenesel.

V meniju za izbiro različice na spletnem mestu so najnovejše različice werf na voljo v vsakem kanalu. Privzeto po naslovu werf.io/dokumentacija odpre se različica najbolj stabilnega kanala za zadnjo izdajo - indeksirajo ga tudi iskalniki. Dokumentacija za kanal je na voljo na ločenih naslovih (npr. werf.io/v1.0-beta/documentation za izdajo beta 1.0).

Spletno mesto ima na voljo naslednje različice:

  1. root (privzeto se odpre),
  2. za vsak aktivni kanal posodobitve vsake izdaje (npr. werf.io/v1.0-beta).

Za ustvarjanje določene različice spletnega mesta je na splošno dovolj, da jo prevedete z uporabo Jekyllz izvajanjem v imeniku /docs ustrezen ukaz repozitorija werf (jekyll build), potem ko preklopite na oznako Git zahtevane različice.

Ostaja samo dodati, da:

  • sam pripomoček (werf) se uporablja za montažo;
  • CI/CD procesi so zgrajeni na podlagi GitLab CI;
  • in vse to seveda teče v Kubernetesu.

naloge

Sedaj pa oblikujmo naloge, ki upoštevajo vse opisane posebnosti:

  1. Po spremembi različice werf na katerem koli kanalu za posodobitev dokumentacija na spletnem mestu mora biti samodejno posodobljena.
  2. Za razvoj moraš včasih biti sposoben ogled predoglednih različic spletnega mesta.

Spletno mesto je treba znova prevesti po spremembi različice na katerem koli kanalu iz ustreznih oznak Git, vendar bomo v procesu gradnje slike dobili naslednje funkcije:

  • Ker se seznam verzij na kanalih spreminja, je treba dokumentacijo obnoviti le za kanale, kjer se je različica spremenila. Konec koncev, ponovno graditi vse ni zelo lepo.
  • Nabor kanalov za izdaje se lahko spremeni. V nekem trenutku na primer na kanalih morda ne bo različice, stabilnejše od izdaje zgodnjega dostopa 1.1, vendar se bodo sčasoma pojavile - ali v tem primeru ne bi morali spremeniti sklopa ročno?

Izkazalo se je, da montaža je odvisna od spreminjanja zunanjih podatkov.

Реализация

Izbira pristopa

Druga možnost je, da vsako zahtevano različico izvajate kot ločen pod v Kubernetesu. Ta možnost pomeni večje število objektov v gruči, ki bo raslo z večanjem števila stabilnih izdaj werf. In to posledično pomeni bolj zapleteno vzdrževanje: vsaka različica ima svoj strežnik HTTP in z majhno obremenitvijo. Seveda to potegne za seboj tudi večje stroške sredstev.

Ubrali smo isto pot sestavljanje vseh potrebnih različic v eno sliko. Zbrana statika vseh različic spletnega mesta se nahaja v vsebniku z NGINX, promet do ustrezne uvedbe pa prihaja prek NGINX Ingress. Preprosta struktura – aplikacija brez stanja – vam omogoča enostavno prilagajanje uvajanja (odvisno od obremenitve) s samim Kubernetesom.

Če smo natančnejši, zbiramo dve sliki: eno za proizvodno vezje, drugo pa je dodatno za razvijalsko vezje. Dodatna slika se uporablja (zažene) samo v razvijalskem vezju skupaj z glavno in vsebuje različico mesta iz objave pregleda, usmerjanje med njima pa se izvaja z uporabo virov Ingress.

werf vs git klon in artefakti

Kot že omenjeno, morate za ustvarjanje statike spletnega mesta za določeno različico dokumentacije graditi s preklopom na ustrezno oznako skladišča. To lahko storite tudi tako, da repozitorij klonirate vsakič, ko gradite, in s seznama izberete ustrezne oznake. Vendar je to operacija, ki zahteva precej virov in poleg tega zahteva pisanje netrivialnih navodil ... Druga resna pomanjkljivost je, da s tem pristopom ni možnosti, da bi nekaj predpomnili med sestavljanjem.

Tu nam na pomoč priskoči sam pripomoček werf, ki izvaja pametno predpomnjenje in vam omogoča uporabo zunanji repozitoriji. Uporaba werf za dodajanje kode iz repozitorija bo znatno pospešila gradnjo, ker werf v bistvu enkrat klonira repozitorij in ga nato izvede Samo fetch če je potrebno. Poleg tega lahko pri dodajanju podatkov iz repozitorija izberemo samo potrebne imenike (v našem primeru je to imenik docs), kar bo bistveno zmanjšalo količino dodanih podatkov.

Ker je Jekyll orodje namenjeno prevajanju statičnih podatkov in ni potrebno v končni sliki, bi bilo logično prevesti v werf artefakt, in v končno sliko uvozi samo rezultat prevajanja.

Pišemo werf.yaml

Zato smo se odločili, da bomo vsako različico prevedli v ločen artefakt werf. Vendar mi ne vemo, koliko teh artefaktov bo med sestavljanjem, zato ne moremo napisati konfiguracije fiksne gradnje (strogo gledano še vedno lahko, vendar ne bo povsem učinkovito).

werf vam omogoča uporabo Go šablone v vaši konfiguracijski datoteki (werf.yaml), in to omogoča ustvarite konfiguracijo sproti odvisno od zunanjih podatkov (kar potrebujete!). Zunanji podatki so v našem primeru informacije o različicah in izdajah, na podlagi katerih zberemo potrebno število artefaktov in kot rezultat dobimo dve sliki: werf-doc и werf-dev za delovanje na različnih tokokrogih.

Zunanji podatki se prenašajo prek spremenljivk okolja. Tukaj je njihova sestava:

  • RELEASES — vrstica s seznamom izdaj in ustrezno trenutno različico werf v obliki s presledki ločenega seznama vrednosti v formatu <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Primer: 1.0%v1.0.4-beta.20
  • CHANNELS — vrstica s seznamom kanalov in ustrezno trenutno različico werf v obliki s presledki ločenega seznama vrednosti v formatu <КАНАЛ>%<НОМЕР_ВЕРСИИ>... Primer: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — različica izdaje werf, ki bo privzeto prikazana na spletnem mestu (ni nujno, da je dokumentacija vedno prikazana z najvišjo številko izdaje). primer: v1.0.4-beta.20
  • REVIEW_SHA — zgoščena vrednost potrditve pregleda, iz katere morate sestaviti različico za preskusno zanko.

Te spremenljivke bodo zapolnjene v cevovodu GitLab CI, kako natančno pa je napisano spodaj.

Najprej za udobje definiramo v werf.yaml Pojdite na spremenljivke predloge in jim dodelite vrednosti iz spremenljivk okolja:

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

Opis artefakta za prevajanje statične različice mesta je na splošno enak za vse primere, ki jih potrebujemo (vključno z generiranjem korenske različice in različice za razvijalsko vezje). Zato ga bomo s funkcijo premaknili v ločen blok define - za kasnejšo ponovno uporabo include. V predlogo bomo posredovali naslednje argumente:

  • Version — generirana različica (ime oznake);
  • Channel — ime kanala za posodobitev, za katerega je ustvarjen artefakt;
  • Commit — razpršitev potrditve, če je artefakt ustvarjen za objavo pregleda;
  • kontekstu.

Opis predloge artefakta

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

Ime artefakta mora biti edinstveno. To lahko dosežemo na primer z dodajanjem imena kanala (vrednost spremenljivke .Channel) kot pripona k imenu artefakta: artifact: doc-{{ .Channel }}. Vendar morate razumeti, da se boste morali pri uvozu iz artefaktov sklicevati na ista imena.

Pri opisovanju artefakta se uporablja naslednja značilnost werf: montaža. Montaža z navedbo storitvenega imenika build_dir omogoča shranjevanje predpomnilnika Jekyll med zagonom cevovoda, kar znatno pospeši ponovno sestavljanje.

Morda ste opazili tudi uporabo datoteke releases.yml je datoteka YAML s podatki o izdaji, zahtevanimi od Github.com (artefakt, pridobljen pri izvajanju cevovoda). Potreben je pri sestavljanju spletnega mesta, v kontekstu članka pa nam je zanimiv, ker je odvisen od njegovega stanja ponovno sestavljanje samo enega artefakta — artefakt korenske različice mesta (ni potreben v drugih artefaktih).

To se izvaja s pogojnim stavkom if Go predloge in dizajni {{ $Root.Files.Get "releases.yml" | sha256sum }} v fazi obdobja. Deluje na naslednji način: pri gradnji artefakta za korensko različico (spremenljivka .Channel je enako root) hash datoteke releases.yml vpliva na podpis celotne stopnje, saj je del imena opravila Ansible (parameter name). Tako pri menjavi vsebino mapa releases.yml ustrezen artefakt bo ponovno sestavljen.

Prosimo, bodite pozorni tudi na delo z zunanjim repozitorijem. V podobi artefakta iz werf repozitorij, je dodan samo imenik /docs, glede na posredovane parametre pa se takoj dodajo podatki zahtevane oznake ali potrditve pregleda.

Za uporabo predloge artefakta za ustvarjanje opisa artefakta prenesenih različic kanalov in izdaj organiziramo zanko na spremenljivki .WerfVersions в werf.yaml:

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

Ker bo zanka ustvarila več artefaktov (upamo), da je treba upoštevati ločilo med njimi - zaporedje --- (Za več informacij o sintaksi konfiguracijske datoteke glejte dokumentacijo). Kot je definirano prej, pri klicu predloge v zanki posredujemo parametre različice, URL in korenski kontekst.

Podobno, vendar brez zanke, pokličemo predlogo artefakta za "posebne primere": za korensko različico in različico iz potrditve pregleda:

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

Upoštevajte, da bo artefakt za objavo pregleda zgrajen le, če je spremenljivka nastavljena .WerfReviewCommit.

Artefakti so pripravljeni - čas je, da začnete uvažati!

Končna slika, zasnovana za delovanje v Kubernetesu, je običajni NGINX z dodano konfiguracijsko datoteko strežnika nginx.conf in statiko zaradi artefaktov. Poleg artefakta korenske različice spletnega mesta moramo ponoviti zanko na spremenljivki .WerfVersions za uvoz artefaktov različic kanala in izdaje + sledite pravilu o poimenovanju artefaktov, ki smo ga sprejeli prej. Ker vsak artefakt shranjuje različice mesta za dva jezika, jih uvozimo na mesta, ki jih ponuja konfiguracija.

Opis končne slike 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 -}}

Dodatna slika, ki se skupaj z glavno zažene v razvijalskem vezju, vsebuje le dve različici spletnega mesta: različico iz objave pregleda in korensko različico spletnega mesta (obstajajo splošna sredstva in, če se spomnite , podatki o izdaji). Tako se bo dodatna slika od glavne razlikovala le v razdelku za uvoz (in seveda v imenu):

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

Kot je navedeno zgoraj, bo artefakt za objavo pregleda ustvarjen samo, ko se zažene nastavljena spremenljivka okolja REVIEW_SHA. Možno bi bilo, da slike werf-dev sploh ne bi ustvarili, če ni spremenljivke okolja REVIEW_SHA, ampak da bi čiščenje po pravilnikih Docker slike v werf so delovale za sliko werf-dev, pustili jo bomo zgraditi samo z artefaktom korenske različice (ta je tako ali tako že zgrajena), da poenostavimo strukturo cevovoda.

Sestava je pripravljena! Preidimo na CI/CD in pomembne nianse.

Cevovod v GitLab CI in značilnosti dinamične gradnje

Pri izvajanju gradnje moramo nastaviti uporabljene spremenljivke okolja werf.yaml. To ne velja za spremenljivko REVIEW_SHA, ki jo bomo nastavili pri klicu cevovoda iz kljuke GitHub.

Potrebne zunanje podatke bomo ustvarili v skriptu Bash generate_artifacts, ki bo ustvaril dva artefakta cevovoda GitLab:

  • datoteko releases.yml s podatki o izdaji,
  • datoteko common_envs.sh, ki vsebuje spremenljivke okolja za izvoz.

Vsebina datoteke generate_artifacts boste našli v naši repozitorije s primeri. Prejemanje podatkov samo po sebi ni tema članka, ampak datoteka common_envs.sh je za nas pomembna, saj delo werf je odvisno od tega. Primer njegove vsebine:

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'

Izhod takega skripta lahko uporabite na primer s funkcijo Bash source.

Zdaj prihaja zabavni del. Da bi izdelava in uvedba aplikacije delovali pravilno, je treba zagotoviti, da werf.yaml je bil enako vsaj znotraj enega cevovoda. Če ta pogoj ni izpolnjen, bodo podpisi stopenj, ki jih werf izračuna med sestavljanjem in na primer razmestitvijo, drugačni. To bo povzročilo napako pri uvajanju, ker... slika, ki je potrebna za namestitev, bo manjkala.

Z drugimi besedami, če so med sestavljanjem slike spletnega mesta informacije o izdajah in različicah enake, v času uvajanja pa je izdana nova različica in imajo spremenljivke okolja drugačne vrednosti, potem uvedba ne bo uspela z napako: navsezadnje artefakt nove različice še ni bil zgrajen.

Če generacija werf.yaml odvisno od zunanjih podatkov (na primer seznam trenutnih različic, kot v našem primeru), potem je treba sestavo in vrednosti takih podatkov zabeležiti v cevovodu. To je še posebej pomembno, če se zunanji parametri precej pogosto spreminjajo.

Bomo sprejemanje in snemanje zunanjih podatkov na prvi stopnji cevovoda v GitLabu (Prebuild) in jih posredujte naprej v obrazcu GitLab CI artefakt. To vam bo omogočilo zagon in ponovni zagon nalog cevovoda (gradnja, uvajanje, čiščenje) z isto konfiguracijo v werf.yaml.

Vsebina odra Prebuild mapa .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

Ko zajamete zunanje podatke v artefaktu, lahko zgradite in uvedete s standardnimi stopnjami cevovoda GitLab CI: Build and Deploy. Sam cevovod zaženemo s pomočjo kavljev iz repozitorija werf GitHub (tj. ko pride do sprememb v repozitoriju GitHub). Podatke zanje najdete v lastnostih projekta GitLab v razdelku Nastavitve CI/CD -> Sprožilci cevovodain nato ustvarite ustrezen Webhook v GitHubu (Nastavitve -> Webhooks).

Faza gradnje bo videti takole:

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 bo dodal dva artefakta iz stopnje v stopnjo gradnje Prebuild, zato s konstruktom izvozimo spremenljivke s pripravljenimi vhodnimi podatki source common_envs.sh. Gradbeno fazo začnemo v vseh primerih, razen za zagon plinovoda po načrtu. Po terminskem planu bomo speljali cevovod za čiščenje – v tem primeru ni potrebe po izvedbi montaže.

Na stopnji uvajanja bomo opisali dve nalogi - ločeno za uvajanje v proizvodna in razvijalska vezja, z uporabo predloge 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

Naloge se v bistvu razlikujejo le v navedbi konteksta gruče, v katerega naj werf izvede namestitev (WERF_KUBE_CONTEXT) in nastavitev spremenljivk okolja zanke (environment.name и environment.url), ki se nato uporabijo v predlogah grafikonov Helm. Vsebine predlog ne bomo posredovali, ker... tam ni nič zanimivega za zadevno temo, vendar jih lahko najdete v repozitorije za članek.

Zadnji dotik

Ker se različice werf izdajajo precej pogosto, se bodo nove slike gradile pogosto, register Docker pa se bo nenehno povečeval. Zato je nujno konfigurirati samodejno čiščenje slike na podlagi pravilnikov. To je zelo enostavno narediti.

Za izvedbo boste potrebovali:

  • Dodajte korak čiščenja .gitlab-ci.yml;
  • Dodajte periodično izvajanje naloge čiščenja;
  • Nastavite spremenljivko okolja z žetonom dostopa za pisanje.

Dodajanje stopnje čiščenja .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

Skoraj vse to smo že videli malo višje - le za čiščenje se morate najprej prijaviti v register Docker Registry z žetonom, ki ima pravice do brisanja slik v registru Docker (samodejno izdani žeton opravil GitLab CI ne imajo take pravice). Žeton mora biti vnaprej ustvarjen v GitLabu, njegova vrednost pa mora biti navedena v spremenljivki okolja WERF_IMAGES_CLEANUP_PASSWORD projekt (Nastavitve CI/CD -> Spremenljivke).

Dodajanje opravila čiščenja z zahtevanim urnikom se izvede v CI/CD ->
Razporedi.

To je to: projekt v registru Docker ne bo več nenehno rasel iz neuporabljenih slik.

Na koncu praktičnega dela naj vas spomnim, da so celotni seznami iz članka na voljo v git:

Rezultat

  1. Prejeli smo logično strukturo sestavljanja: en artefakt na različico.
  2. Sklop je univerzalen in ne zahteva ročnih sprememb, ko so izdane nove različice werf: dokumentacija na spletnem mestu se samodejno posodablja.
  3. Dve sliki sta sestavljeni za različne konture.
  4. Deluje hitro, saj Predpomnjenje se uporablja v največji možni meri – ko je izdana nova različica werf ali je klicana kljuka GitHub za objavo pregleda, se znova zgradi le ustrezen artefakt s spremenjeno različico.
  5. Ni vam treba razmišljati o brisanju neuporabljenih slik: čiščenje v skladu s pravilniki werf bo ohranilo red v registru Docker.

Ugotovitve

  • Uporaba werf omogoča hitro delovanje sklopa zaradi predpomnjenja samega sklopa in predpomnjenja pri delu z zunanjimi repozitoriji.
  • Delo z zunanjimi repozitoriji Git odpravlja potrebo po vsakokratnem kloniranju celotnega repozitorija ali ponovnem izumljanju kolesa z zapleteno logiko optimizacije. werf uporablja predpomnilnik in izvede kloniranje samo enkrat, nato pa uporabi fetch in samo takrat, ko je potrebno.
  • Možnost uporabe predlog Go v konfiguracijski datoteki gradnje werf.yaml vam omogoča, da opišete sklop, katerega rezultat je odvisen od zunanjih podatkov.
  • Uporaba mount v werf bistveno pospeši zbiranje artefaktov - zaradi predpomnilnika, ki je skupen vsem cevovodom.
  • werf olajša konfiguracijo čiščenja, kar je še posebej pomembno pri dinamični gradnji.

PS

Preberite tudi na našem blogu:

Vir: www.habr.com

Dodaj komentar