ProHoster > Blog > uprava > Dinamička montaža i implementacija Docker slika s werf-om na primjeru verzionirane dokumentacijske stranice

Dinamička montaža i implementacija Docker slika s werf-om na primjeru verzionirane dokumentacijske stranice

Već smo više puta pričali o našem alatu GitOps. werf, a ovim putem želimo podijeliti naše iskustvo u montaži stranice uz dokumentaciju samog projekta - werf.io (njegova ruska verzija je hr.werf.io). Ovo je obično statično mjesto, ali njegov sklop je zanimljiv po tome što je izgrađen pomoću dinamičkog broja artefakata.

Dinamička montaža i implementacija Docker slika s werf-om na primjeru verzionirane dokumentacijske stranice

Idite u nijanse strukture web stranice: generiranje zajedničkog izbornika za sve verzije, stranice s informacijama o izdanjima itd. - nećemo. Umjesto toga, usredotočimo se na probleme i značajke dinamičkog sklapanja i malo na popratne CI/CD procese.

Uvod: kako stranica radi

Za početak, werf dokumentacija je pohranjena zajedno sa svojim kodom. Ovo nameće određene razvojne zahtjeve koji su općenito izvan opsega ovog članka, ali se može reći da su barem:

  • Nove werf funkcije ne bi trebale biti izdane bez ažuriranja dokumentacije i, obrnuto, sve promjene u dokumentaciji podrazumijevaju izdavanje nove verzije werf-a;
  • Projekt ima prilično intenzivan razvoj: nove verzije mogu biti objavljene nekoliko puta dnevno;
  • Sve ručne operacije za postavljanje stranice s novom verzijom dokumentacije u najmanju su ruku zamorne;
  • Projekt usvaja semantički pristup verziranje, s 5 kanala stabilnosti. Proces izdavanja uključuje sekvencijalno prolaženje verzija kroz kanale kako bi se povećala stabilnost: od alfa do čvrstog kao kamen;
  • Stranica ima verziju na ruskom jeziku, koja "živi i razvija se" (tj. čiji se sadržaj ažurira) paralelno s glavnom (tj. verzijom na engleskom jeziku).

Da bismo sakrili svu tu “unutarnju kuhinju” od korisnika, nudeći mu nešto što “samo radi”, mi smo to i učinili odvojeni werf alat za instalaciju i ažuriranje - Je multiwerf. Vi samo trebate navesti broj izdanja i kanal stabilnosti koji ste spremni koristiti, a multiwerf će provjeriti postoji li nova verzija na kanalu i preuzeti je ako je potrebno.

U izborniku za odabir verzije na web stranici, najnovije verzije werf-a dostupne su na svakom kanalu. Standardno, po adresi werf.io/dokumentacija otvara se verzija najstabilnijeg kanala za najnovije izdanje - također ga indeksiraju tražilice. Dokumentacija za kanal dostupna je na posebnim adresama (npr. werf.io/v1.0-beta/dokumentacija za beta izdanje 1.0).

Ukupno, stranica ima sljedeće dostupne verzije:

  1. root (otvara se prema zadanim postavkama),
  2. za svaki aktivni kanal ažuriranja svakog izdanja (na primjer, werf.io/v1.0-beta).

Općenito, za generiranje određene verzije web-mjesta dovoljno ju je kompajlirati pomoću Jekyllpokretanjem u imeniku /docs werf repozitorij odgovarajuća naredba (jekyll build), nakon prelaska na Git oznaku potrebne verzije.

Ostaje samo dodati da:

  • sam pomoćni program (werf) koristi se za montažu;
  • CI/CD procesi izgrađeni su na temelju GitLab CI;
  • i sve to, naravno, radi u Kubernetesu.

zadaci

Sada formulirajmo zadatke koji uzimaju u obzir sve opisane specifičnosti:

  1. Nakon promjene werf verzije na bilo kojem kanalu ažuriranja dokumentacija na stranici trebala bi se automatski ažurirati.
  2. Za razvoj treba ponekad moći pregledajte verzije stranice.

Stranica se mora ponovno kompajlirati nakon promjene verzije na bilo kojem kanalu iz odgovarajućih Git oznaka, ali u procesu izgradnje slike dobit ćemo sljedeće značajke:

  • Budući da se lista verzija na kanalima mijenja, potrebno je samo obnoviti dokumentaciju za kanale kod kojih je verzija promijenjena. Uostalom, nije baš lijepo sve ponovno graditi.
  • Skup kanala za izdanja može se promijeniti. U nekom trenutku, na primjer, možda neće biti stabilnije verzije na kanalima od izdanja s ranim pristupom 1.1, ali s vremenom će se pojaviti - u ovom slučaju, ne biste li trebali ručno promijeniti sklop?

Ispada da sklapanje ovisi o promjeni vanjskih podataka.

Provedba

Odabir pristupa

Alternativno, svaku potrebnu verziju možete pokrenuti kao zaseban modul u Kubernetesu. Ova opcija podrazumijeva veći broj objekata u klasteru, koji će rasti s povećanjem broja stabilnih werf izdanja. A to zauzvrat podrazumijeva složenije održavanje: svaka verzija ima vlastiti HTTP poslužitelj i to s malim opterećenjem. Naravno, to podrazumijeva i veće troškove resursa.

Krenuli smo istim putem sastavljanje svih potrebnih verzija u jednoj slici. Kompajlirana statika svih verzija web-mjesta nalazi se u spremniku s NGINX-om, a promet do odgovarajućeg Deploymenta dolazi kroz NGINX Ingress. Jednostavna struktura - aplikacija bez stanja - omogućuje vam jednostavno skaliranje implementacije (ovisno o opterećenju) pomoću samog Kubernetesa.

Da budemo precizniji, prikupljamo dvije slike: jednu za proizvodni krug, a druga je dodatna za razvojni krug. Dodatna slika se koristi (pokreće) samo na dev krugu zajedno s glavnom i sadrži verziju stranice iz recenzije, a usmjeravanje između njih se izvodi pomoću Ingress resursa.

werf vs git klon i artefakti

Kao što je već spomenuto, da biste generirali statiku web-mjesta za određenu verziju dokumentacije, morate izgraditi prebacivanjem na odgovarajuću oznaku repozitorija. To također možete učiniti kloniranjem repozitorija svaki put kada gradite, odabirom odgovarajućih oznaka s popisa. Međutim, ovo je prilično resursno intenzivna operacija i, štoviše, zahtijeva pisanje netrivijalnih uputa... Još jedan ozbiljan nedostatak je da s ovim pristupom ne postoji način da se nešto predmemorira tijekom sklapanja.

Ovdje nam u pomoć dolazi sam uslužni program werf, implementirajući pametno predmemoriranje i dopuštajući vam korištenje vanjska spremišta. Korištenje werf-a za dodavanje koda iz repozitorija značajno će ubrzati izgradnju, jer werf u biti jednom klonira repozitorij i zatim ga izvršava samo fetch ako je potrebno. Osim toga, kada dodajemo podatke iz repozitorija, možemo odabrati samo potrebne direktorije (u našem slučaju to je direktorij docs), što će znatno smanjiti količinu dodanih podataka.

Budući da je Jekyll alat dizajniran za kompajliranje statičkih podataka i nije potreban u konačnoj slici, bilo bi logično kompilirati u werf artefakt, i u konačnu sliku uvesti samo rezultat kompilacije.

Pišemo werf.yaml

Stoga smo odlučili svaku verziju sastaviti u poseban werf artefakt. Međutim mi ne znamo koliko će ovih artefakata biti tijekom sastavljanja, tako da ne možemo napisati fiksnu konfiguraciju izgradnje (strogo govoreći, još uvijek možemo, ali neće biti potpuno učinkovita).

werf vam omogućuje korištenje Go predlošci u vašoj konfiguracijskoj datoteci (werf.yaml), a to ga čini mogućim generirajte konfiguraciju u hodu ovisno o vanjskim podacima (što trebate!). Vanjski podaci u našem slučaju su informacije o verzijama i izdanjima, na temelju kojih prikupljamo potreban broj artefakata i kao rezultat dobivamo dvije slike: werf-doc и werf-dev za rad na različitim krugovima.

Vanjski podaci se prosljeđuju kroz varijable okoline. Evo njihovog sastava:

  • RELEASES — redak s popisom izdanja i odgovarajućom trenutnom verzijom werf-a, u obliku popisa vrijednosti odvojenih razmakom u formatu <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>, Primjer: 1.0%v1.0.4-beta.20
  • CHANNELS — redak s popisom kanala i odgovarajućom trenutnom verzijom werf-a, u obliku popisa vrijednosti odvojenih razmakom u formatu <КАНАЛ>%<НОМЕР_ВЕРСИИ>, Primjer: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — verzija izdanja werf-a koja će se prema zadanim postavkama prikazivati ​​na web-mjestu (nije uvijek potrebno prikazati dokumentaciju prema najvećem broju izdanja). Primjer: v1.0.4-beta.20
  • REVIEW_SHA — hash obveze pregleda iz koje trebate izgraditi verziju za testnu petlju.

Ove varijable će se popunjavati u GitLab CI pipeline-u, a kako točno piše u nastavku.

Prije svega, radi praktičnosti, definiramo in werf.yaml Idi na varijable predloška, ​​dodjeljujući im vrijednosti iz varijabli okruženja:

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

Opis artefakta za kompajliranje statičke verzije stranice općenito je isti za sve slučajeve koji su nam potrebni (uključujući generiranje korijenske verzije, kao i verziju za razvojni sklop). Stoga ćemo ga pomoću funkcije premjestiti u zaseban blok define - za kasniju ponovnu uporabu include. Predlošku ćemo proslijediti sljedeće argumente:

  • Version — generirana verzija (ime oznake);
  • Channel — naziv kanala ažuriranja za koji je artefakt generiran;
  • Commit — hash potvrde, ako je artefakt generiran za potvrdu pregleda;
  • kontekst.

Opis predloška 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 }}

Naziv artefakta mora biti jedinstven. To možemo postići npr. dodavanjem naziva kanala (vrijednost varijable .Channel) kao sufiks na ime artefakta: artifact: doc-{{ .Channel }}. Ali morate razumjeti da ćete se pri uvozu iz artefakata morati pozivati ​​na ista imena.

Kada se opisuje artefakt, koristi se sljedeća značajka werf: montiranje. Montaža s naznakom servisnog imenika build_dir omogućuje vam spremanje Jekyll predmemorije između pokretanja cjevovoda, što značajno ubrzava ponovno sastavljanje.

Možda ste također primijetili korištenje datoteke releases.yml je YAML datoteka sa zatraženim podacima o izdanju github.com (artefakt dobiven prilikom izvođenja cjevovoda). Potreban je prilikom sastavljanja stranice, ali u kontekstu članka nam je zanimljiv jer ovisi o njegovom stanju ponovno sastavljanje samo jednog artefakta — artefakt korijenske verzije stranice (nije potreban u drugim artefaktima).

Ovo se provodi korištenjem uvjetne naredbe if Go predlošci i dizajni {{ $Root.Files.Get "releases.yml" | sha256sum }} u fazi etape. Radi na sljedeći način: prilikom izgradnje artefakta za korijensku verziju (varijabla .Channel jednak je root) hash datoteke releases.yml utječe na potpis cijele faze, jer je dio naziva zadatka Ansible (parametar name). Dakle, prilikom mijenjanja sadržaj datoteka releases.yml odgovarajući artefakt će se ponovno sastaviti.

Također obratite pozornost na rad s vanjskim spremištem. Na slici artefakta iz werf spremište, dodaje se samo imenik /docs, a ovisno o proslijeđenim parametrima, odmah se dodaju podaci tražene oznake ili pregleda.

Za korištenje predloška artefakta za generiranje opisa artefakta prenesenih verzija kanala i izdanja, organiziramo petlju na varijabli .WerfVersions в werf.yaml:

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

Jer petlja će generirati nekoliko artefakata (nadamo se), potrebno je uzeti u obzir separator između njih - niz --- (Za više informacija o sintaksi konfiguracijske datoteke pogledajte dokumentacija). Kao što je ranije definirano, prilikom pozivanja predloška u petlji, prosljeđujemo parametre verzije, URL i korijenski kontekst.

Slično, ali bez petlje, nazivamo predložak artefakta za "posebne slučajeve": za korijensku verziju, kao i verziju iz pregledavanja:

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

Imajte na umu da će se artefakt za uvrgnuće pregleda izgraditi samo ako je varijabla postavljena .WerfReviewCommit.

Artefakti su spremni - vrijeme je za početak uvoza!

Konačna slika, dizajnirana za rad na Kubernetesu, obični je NGINX s dodanom konfiguracijskom datotekom poslužitelja nginx.conf i statičnost od artefakata. Osim artefakta korijenske verzije stranice, moramo ponoviti petlju na varijabli .WerfVersions za uvoz artefakata kanala i verzija izdanja + slijedite pravilo imenovanja artefakata koje smo ranije usvojili. Budući da svaki artefakt pohranjuje verzije stranice za dva jezika, uvozimo ih na mjesta predviđena konfiguracijom.

Opis konač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, koja se zajedno s glavnom pokreće na razvojnom krugu, sadrži samo dvije verzije web-mjesta: verziju iz recenzije i korijensku verziju web-mjesta (postoje opća sredstva i, ako se sjećate , podaci o izdanju). Dakle, dodatna slika će se razlikovati od glavne samo u odjeljku za uvoz (i, naravno, u nazivu):

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

Kao što je gore navedeno, artefakt za uvrđivanje pregleda bit će generiran samo kada se pokrene postavljena varijabla okruženja REVIEW_SHA. Bilo bi moguće uopće ne generirati werf-dev sliku ako ne postoji varijabla okruženja REVIEW_SHA, ali kako bi čišćenje po politikama Docker slike u werf-u radile su za werf-dev sliku, ostavit ćemo je da se izgradi samo s artefaktom korijenske verzije (ona je ionako već izgrađena), kako bismo pojednostavili strukturu cjevovoda.

Skupština je spremna! Prijeđimo na CI/CD i važne nijanse.

Cjevovod u GitLab CI i značajke dinamičke izgradnje

Prilikom pokretanja izgradnje moramo postaviti varijable okruženja koje se koriste u werf.yaml. Ovo se ne odnosi na varijablu REVIEW_SHA, koju ćemo postaviti prilikom pozivanja cjevovoda iz GitHub kuke.

Generirati ćemo potrebne vanjske podatke u Bash skripti generate_artifacts, koji će generirati dva GitLab artefakta cjevovoda:

  • datoteku releases.yml s podacima o izdanju,
  • datoteku common_envs.sh, koji sadrži varijable okruženja koje treba izvesti.

Sadržaj datoteke generate_artifacts naći ćete u našem spremišta s primjerima. Samo primanje podataka nije tema članka, već datoteke common_envs.sh važno nam je, jer o tome ovisi rad werfa. Primjer njegovog sadržaja:

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'

Možete koristiti izlaz takve skripte, na primjer, pomoću funkcije Bash source.

Sada dolazi zabavni dio. Kako bi i izgradnja i implementacija aplikacije radili ispravno, potrebno je to osigurati werf.yaml to je bio isto barem unutar jednog cjevovoda. Ako ovaj uvjet nije ispunjen, tada će potpisi faza koje werf izračunava tijekom sastavljanja i, na primjer, postavljanja biti drugačiji. To će dovesti do pogreške u implementaciji jer... slika potrebna za implementaciju će nedostajati.

Drugim riječima, ako su tijekom sastavljanja slike web-mjesta informacije o izdanjima i verzijama iste, au vrijeme implementacije nova verzija je objavljena i varijable okoline imaju različite vrijednosti, tada implementacija neće uspjeti uz pogrešku: uostalom, artefakt nove verzije još nije izgrađen.

Ako generacija werf.yaml ovisi o vanjskim podacima (na primjer, popis trenutnih verzija, kao u našem slučaju), tada sastav i vrijednosti takvih podataka trebaju biti zabilježeni unutar cjevovoda. Ovo je osobito važno ako se vanjski parametri često mijenjaju.

Hoćemo primati i snimati vanjske podatke u prvoj fazi cjevovoda u GitLabu (Predizgradnja) i prenesite ih dalje u obrascu GitLab CI artefakt. To će vam omogućiti pokretanje i ponovno pokretanje poslova cjevovoda (izgradnja, implementacija, čišćenje) s istom konfiguracijom u werf.yaml.

Sadržaj pozornice Predizgradnja datoteka .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

Nakon što ste uhvatili vanjske podatke u artefakt, možete izgraditi i implementirati koristeći standardne GitLab CI faze cjevovoda: Izrada i implementacija. Sam cjevovod pokrećemo pomoću zakačica iz werf GitHub repozitorija (tj. kada postoje promjene u GitHub repozitoriju). Podaci za njih mogu se pronaći u svojstvima GitLab projekta u odjeljku CI/CD postavke -> Okidači cjevovoda, a zatim izradite odgovarajući Webhook u GitHubu (Postavke -> Webhookovi).

Faza izgradnje će izgledati ovako:

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 će dodati dva artefakta iz faze u fazu izrade Predizgradnja, pa eksportiramo varijable s pripremljenim ulaznim podacima pomoću konstrukcije source common_envs.sh. Počinjemo fazu izgradnje u svim slučajevima, osim puštanja cjevovoda prema rasporedu. Prema rasporedu, provest ćemo cjevovod za čišćenje - u ovom slučaju nema potrebe za izvođenjem montaže.

U fazi implementacije, opisat ćemo dva zadatka - zasebno za implementaciju u proizvodne i razvojne krugove, koristeći YAML predložak:

.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

Zadaci se u biti razlikuju samo u naznaci konteksta klastera u koji werf treba izvršiti implementaciju (WERF_KUBE_CONTEXT), i postavljanje varijabli okoline petlje (environment.name и environment.url), koji se zatim koriste u Helmovim predlošcima grafikona. Nećemo dati sadržaj predložaka, jer... tamo nema ništa zanimljivo za dotičnu temu, ali ih možete naći u spremišta za članak.

Završni dodir

Budući da se verzije werf-a objavljuju prilično često, nove slike će se često graditi, a Docker registar će stalno rasti. Stoga je nužno konfigurirati automatsko čišćenje slike na temelju pravila. Vrlo je jednostavno za napraviti.

Za implementaciju trebat će vam:

  • Dodajte korak čišćenja u .gitlab-ci.yml;
  • Dodajte periodično izvršavanje zadatka čišćenja;
  • Postavite varijablu okoline s tokenom pristupa za pisanje.

Dodavanje faze č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

Već smo vidjeli gotovo sve ovo malo više - samo da biste to očistili morate se prvo prijaviti u Docker registar s tokenom koji ima prava brisanja slika u Docker registru (automatski izdani GitLab CI token zadatka ne imaju takva prava). Token mora biti kreiran u GitLabu unaprijed, a njegova vrijednost mora biti navedena u varijabli okruženja WERF_IMAGES_CLEANUP_PASSWORD projekt (Postavke CI/CD -> Varijable).

Dodavanje zadatka čišćenja sa potrebnim rasporedom se vrši u CI/CD ->
Raspored.

To je to: projekt u Docker registru više neće stalno rasti iz neiskorištenih slika.

Na kraju praktičnog dijela, podsjetit ću vas da su potpuni popisi iz članka dostupni u ići:

Rezultirati

  1. Dobili smo logičnu strukturu sklopa: jedan artefakt po verziji.
  2. Sklop je univerzalan i ne zahtijeva ručne izmjene kada se objave nove verzije werf-a: dokumentacija na web stranici automatski se ažurira.
  3. Dvije slike su sastavljene za različite konture.
  4. Djeluje brzo, jer Predmemoriranje se koristi što je više moguće - kada se izda nova verzija werf-a ili se GitHub kuka pozove za pregled, ponovno se gradi samo odgovarajući artefakt s promijenjenom verzijom.
  5. Nema potrebe razmišljati o brisanju neiskorištenih slika: čišćenje u skladu s werf pravilima održavat će Docker registar u redu.

Zaključci

  • Korištenje werf-a omogućuje sklopu da radi brzo zbog predmemoriranja samog sklopa i predmemoriranja pri radu s vanjskim spremištima.
  • Rad s vanjskim Git spremištima eliminira potrebu za kloniranjem cijelog spremišta svaki put ili ponovnom izmišljanju kotača pomoću lukave optimizacijske logike. werf koristi predmemoriju i radi kloniranje samo jednom, a zatim koristi fetch i to samo kad je potrebno.
  • Mogućnost korištenja Go predložaka u konfiguracijskoj datoteci izrade werf.yaml omogućuje vam da opišete sklop čiji rezultat ovisi o vanjskim podacima.
  • Korištenje mount u werf-u značajno ubrzava prikupljanje artefakata - zbog predmemorije, koja je zajednička svim cjevovodima.
  • werf olakšava konfiguriranje čišćenja, što je posebno važno kod dinamičke izgradnje.

PS

Pročitajte i na našem blogu:

Izvor: www.habr.com

Dodajte komentar