Docker lemezképek dinamikus összeállítása és üzembe helyezése werf segítségével egy verziózott dokumentációs webhely példáján

A GitOps eszközünkről már nem egyszer beszéltünk. werf, és ezúttal a helyszín összeállításával kapcsolatos tapasztalatainkat szeretnénk megosztani magának a projektnek a dokumentációjával - werf.io (az orosz változata en.werf.io). Ez egy közönséges statikus helyszín, de az összeállítása érdekes, hogy dinamikus számú műtárgy felhasználásával épül fel.

Menjen bele a webhely szerkezetének árnyalataiba: közös menü létrehozása az összes verzióhoz, oldalak a kiadásokkal kapcsolatos információkkal stb. - mi nem. Ehelyett koncentráljunk a dinamikus összeszerelés problémáira és jellemzőire, valamint egy kicsit a kapcsolódó CI/CD folyamatokra.

Bevezetés: hogyan működik az oldal

Kezdetben a werf dokumentáció a kódjával együtt kerül tárolásra. Ez bizonyos fejlesztési követelményeket támaszt, amelyek általában túlmutatnak e cikk hatályán, de legalábbis elmondható, hogy:

• Az új werf funkciókat nem szabad kiadni a dokumentáció frissítése nélkül, és fordítva, a dokumentációban bekövetkezett bármilyen változás a werf új verziójának kiadását vonja maga után;
• A projekt meglehetősen intenzíven fejlődik: naponta többször is megjelenhetnek az új verziók;
• Bármilyen kézi művelet egy webhely új verziójú dokumentációval történő telepítéséhez legalább unalmas;
• A projekt szemantikai megközelítést alkalmaz verziószámítás, 5 stabilitási csatornával. A kiadási folyamat magában foglalja a változatok egymás utáni áthaladását a csatornákon a stabilitás növelése érdekében: az alfa-tól a sziklaszilárdig;
• Az oldalnak van egy orosz nyelvű változata, amely a fő (azaz angol nyelvű) verzióval párhuzamosan „él és fejlődik” (azaz tartalma frissül).

Megtettük, hogy mindezt a „belső konyhát” elrejtse a felhasználó elől, és olyat kínáljunk neki, ami „csak működik”. különálló werf telepítő és frissítő eszköz - Van multiwerf. Csak meg kell adnia a kiadás számát és a stabilitási csatornát, amelyet használatra készen áll, és a multiwerf ellenőrzi, hogy van-e új verzió a csatornán, és szükség esetén letölti.

A weboldal verzióválasztó menüjében minden csatornán elérhetők a werf legújabb verziói. Alapértelmezés szerint cím szerint werf.io/documentation megnyílik a legstabilabb csatorna verziója a legújabb kiadáshoz - a keresőmotorok is indexelik. A csatorna dokumentációja külön címeken érhető el (pl. werf.io/v1.0-beta/documentation 1.0 béta kiadáshoz).

Összességében a webhelyen a következő verziók érhetők el:

1. root (alapértelmezés szerint megnyílik),
2. az egyes kiadások minden aktív frissítési csatornájához (például werf.io/v1.0-beta).

Egy webhely adott verziójának generálásához általában elegendő, ha lefordítja a segítségével Jekylla könyvtárban való futtatással /docs werf repository megfelelő parancs (jekyll build), miután átváltott a kívánt verzió Git címkéjére.

Csak annyit kell hozzátenni, hogy:

• magát a segédprogramot (werf) használják az összeszereléshez;
• A CI/CD folyamatok a GitLab CI-re épülnek;
• és mindez természetesen Kubernetesben fut.

feladatok

Most fogalmazzunk meg olyan feladatokat, amelyek figyelembe veszik a leírt sajátosságokat:

1. Miután megváltoztatta a werf verziót bármelyik frissítési csatornán az oldalon található dokumentációt automatikusan frissíteni kell.
2. A fejlődéshez időnként tudnod kell tekintse meg a webhely előnézeti verzióit.

Az oldalt újra kell fordítani, miután bármelyik csatornán megváltoztattuk a verziót a megfelelő Git címkékből, de a kép felépítése során a következő funkciókat kapjuk:

• Mivel a csatornákon a verziók listája változik, csak azon csatornák dokumentációját kell újraépíteni, ahol a verzió megváltozott. Hiszen mindent újra felépíteni nem túl szép.
• A kiadásokhoz tartozó csatornakészlet változhat. Előfordulhat például, hogy valamikor nem lesz stabilabb verzió a csatornákon, mint a korai hozzáférésű 1.1-es kiadás, de idővel ezek megjelennek – ebben az esetben nem kellene manuálisan módosítani az összeállítást?

Kiderül, hogy Az összeszerelés a külső adatok változásától függ.

Реализация

Megközelítés kiválasztása

Alternatív megoldásként az egyes szükséges verziókat különálló podként is futtathatja a Kubernetesben. Ez a beállítás nagyobb számú objektumot jelent a fürtben, ami a stabil werf-kiadások számának növekedésével fog növekedni. Ez pedig összetettebb karbantartást jelent: minden verziónak saját HTTP-kiszolgálója van, és kis terheléssel. Ez természetesen nagyobb erőforrás-költséggel is jár.

Ugyanazt az utat jártuk be az összes szükséges verzió összeállítása egy képen. A webhely összes verziójának összeállított statikája egy tárolóban található az NGINX-szel, és a megfelelő telepítéshez az NGINX Ingressen keresztül érkezik a forgalom. Egy egyszerű szerkezet – állapot nélküli alkalmazás – lehetővé teszi a központi telepítés (a terheléstől függően) egyszerű méretezését magának a Kubernetesnek a használatával.

Pontosabban két képet gyűjtünk: az egyiket a termelési áramkörhöz, a másodikat pedig a fejlesztői áramkörhöz. A kiegészítő lemezkép csak a fejlesztői áramkörön kerül felhasználásra (indításra) a fővel együtt, és tartalmazza a webhely felülvizsgálati véglegesítésből származó verzióját, és a köztük lévő útválasztás Ingress erőforrások segítségével történik.

werf vs git klón és műtermékek

Amint már említettük, ahhoz, hogy webhelystatisztikát hozzon létre a dokumentáció egy adott verziójához, a megfelelő lerakatcímkére váltva kell létrehoznia. Ezt úgy is megteheti, hogy minden egyes összeállításkor klónozza a tárat, és kiválasztja a megfelelő címkéket egy listából. Ez azonban meglehetősen erőforrás-igényes művelet, ráadásul nem triviális utasítások írását igényli... További komoly hátrány, hogy ezzel a megközelítéssel nincs mód az összeállítás során valami gyorsítótárazására.

Itt maga a werf segédprogram jön a segítségünkre, implementálja intelligens gyorsítótár és lehetővé teszi a használatát külső adattárak. A werf használatával kódot adunk hozzá a tárolóból jelentősen felgyorsítja a felépítést, mert A werf lényegében egyszer klónozza a tárolót, majd végrehajtja csak fetch ha szükséges. Ezenkívül a tárolóból való adatok hozzáadásakor csak a szükséges könyvtárakat tudjuk kiválasztani (esetünkben ez a könyvtár docs), ami jelentősen csökkenti a hozzáadott adatok mennyiségét.

Mivel a Jekyll egy statikus adatok összeállítására tervezett eszköz, és nincs rá szükség a végső képben, logikus lenne a werf műtárgy, és a végső képbe csak az összeállítás eredményét importálja.

Azt írjuk, hogy werf.yaml

Ezért úgy döntöttünk, hogy minden verziót külön werf-termékként fogunk összeállítani. Azonban mi nem tudjuk, hány ilyen műtárgy lesz az összeszerelés során, tehát nem írhatunk fix build konfigurációt (szigorúan véve továbbra is megtehetjük, de nem lesz teljesen hatékony).

werf lehetővé teszi a használatát Ugrás a sablonokhoz a konfigurációs fájlban (werf.yaml), és ez lehetővé teszi menet közben generál konfigurációt külső adatoktól függően (amire van szüksége!). A külső adatok esetünkben a verziókra és kiadásokra vonatkozó információk, amelyek alapján összegyűjtjük a szükséges számú műterméket, és ennek eredményeként két képet kapunk: werf-doc и werf-dev különböző áramkörökön futni.

A külső adatok környezeti változókon keresztül kerülnek továbbításra. Íme az összetételük:

• RELEASES - egy sor a kiadások listájával és a werf megfelelő aktuális verziójával, szóközzel elválasztott értéklista formájában a formátumban <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Példa: 1.0%v1.0.4-beta.20
• CHANNELS - egy sor a csatornák listájával és a werf megfelelő aktuális verziójával, szóközzel elválasztott értéklista formájában a formátumban <КАНАЛ>%<НОМЕР_ВЕРСИИ>... Példa: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — a werf kiadás verziója alapértelmezés szerint megjelenik az oldalon (nem mindig szükséges a dokumentációt a legmagasabb kiadási számmal megjeleníteni). Példa: v1.0.4-beta.20
• REVIEW_SHA — a felülvizsgálati véglegesítés hash-je, amelyből a teszthurok verzióját kell elkészítenie.

Ezek a változók a GitLab CI folyamatban lesznek kitöltve, és hogy pontosan hogyan, az alább olvasható.

Először is a kényelem kedvéért meghatározzuk werf.yaml Menjen a sablonváltozókhoz, és rendeljen hozzá értékeket a környezeti változókból:

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

A webhely statikus verziójának összeállításához szükséges műtermék leírása általában minden szükséges esetben ugyanaz (beleértve a gyökérverzió generálását, valamint a fejlesztői áramkör verzióját). Ezért a függvény segítségével egy külön blokkba helyezzük át define - későbbi újrafelhasználáshoz include. A következő argumentumokat adjuk át a sablonnak:

• Version — generált verzió (címke neve);
• Channel — annak a frissítési csatornának a neve, amelyhez a műterméket előállították;
• Commit — commit hash, ha a műterméket felülvizsgálati véglegesítéshez hozzák létre;
• kontextus.

Műterméksablon leírása

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

A műtermék nevének egyedinek kell lennie. Ezt például a csatorna nevének (a változó értékének) hozzáadásával érhetjük el .Channel) a műtermék nevének utótagjaként: artifact: doc-{{ .Channel }}. De meg kell értenie, hogy a műtermékek importálásakor ugyanazokra a nevekre kell hivatkoznia.

Egy műtermék leírásánál a következő werf funkciót használjuk: beépítési. Szervizkönyvtárat jelző felszerelés build_dir lehetővé teszi a Jekyll gyorsítótár mentését a folyamatok futtatása között, ami jelentősen felgyorsítja az összeszerelést.

Lehet, hogy Ön is észrevette a fájl használatát releases.yml egy YAML fájl a kibocsátási adatokkal github.com (egy csővezeték végrehajtásakor kapott műtermék). Az oldal összeállításakor szükség van rá, de a cikk kapcsán érdekes számunkra, mert állapotától függ csak egy műtárgy összeszerelése — a webhely gyökérverziójának műterméke (más műtermékeknél nincs rá szükség).

Ez a feltételes utasítás segítségével valósul meg if Go sablonok és tervek {{ $Root.Files.Get "releases.yml" | sha256sum }} színpadon szakasz. Ez a következőképpen működik: amikor műterméket készít a gyökérverzióhoz (változó .Channel egyenlő root) fájl hash releases.yml hatással van a teljes szakasz aláírására, mivel az Ansible feladat nevének része (paraméter name). Így váltáskor tartalom fájlt releases.yml a megfelelő műtermék újra össze lesz szerelve.

Kérjük, ügyeljen arra is, hogy külső adattárral dolgozzon. Egy műtárgy képén a werf adattár, csak a könyvtár kerül hozzáadásra /docs, és az átadott paraméterek függvényében azonnal hozzáadódnak a szükséges címke vagy felülvizsgálati véglegesítés adatai.

Ahhoz, hogy a műterméksablont használjuk a csatornák és kiadások átvitt verzióinak műtermékének leírásához, egy hurkot szervezünk a változón .WerfVersions в werf.yaml:

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

Mert a hurok több műterméket fog generálni (reméljük), figyelembe kell venni a köztük lévő elválasztót - a sorrendet --- (A konfigurációs fájl szintaxisával kapcsolatos további információkért lásd: dokumentáció). A korábban meghatározottak szerint, amikor egy sablont hurokban hívunk meg, átadjuk a verzióparamétereket, az URL-t és a gyökérkörnyezetet.

Hasonlóképpen, de ciklus nélkül, a műterméksablont „különleges esetekre” hívjuk: a gyökérverzióhoz, valamint a felülvizsgálati véglegesítésből származó verzióhoz:

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

Kérjük, vegye figyelembe, hogy a felülvizsgálati véglegesítés mellékterméke csak akkor épül fel, ha a változó be van állítva .WerfReviewCommit.

A műtermékek készen állnak – ideje elkezdeni az importálást!

Az utolsó kép, amelyet Kubernetes-en futni terveztek, egy normál NGINX, amelyhez egy kiszolgálókonfigurációs fájl is hozzáadott nginx.conf és statikus műtárgyakból. A webhely gyökérverziójának műtermékén kívül meg kell ismételnünk a ciklust a változón .WerfVersions a csatorna- és kiadásverziók melléktermékeinek importálásához + kövesse a korábban elfogadott műtermék-elnevezési szabályt. Mivel minden melléktermék két nyelven tárolja a webhely verzióit, importáljuk őket a konfiguráció által biztosított helyekre.

A végső kép leírása 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 -}}

A kiegészítő kép, amely a fővel együtt a fejlesztői áramkörön indul el, csak a webhely két verzióját tartalmazza: a felülvizsgálati véglegesítésből származó verziót és a webhely gyökérverzióját (vannak általános eszközök, és ha emlékszel , kiadási adatok). Így a kiegészítő kép csak az import szakaszban (és természetesen a névben) különbözik a főtől:

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

Ahogy fentebb említettük, a felülvizsgálati véglegesítés mellékterméke csak akkor jön létre, ha a beállított környezeti változó fut REVIEW_SHA. Lehetséges lenne egyáltalán nem generálni a werf-dev képet, ha nincs környezeti változó REVIEW_SHA, de annak érdekében szabályzat szerinti takarítás A werf-ben lévő Docker képek a werf-dev image-hez működtek, a folyamat egyszerűsítése érdekében hagyjuk, hogy csak a gyökérverziós műtermékkel épüljön meg (az amúgy is meg van építve).

Kész az összeállítás! Térjünk át a CI/CD-re és a fontos árnyalatokra.

Pipeline a GitLab CI-ben és a dinamikus felépítés jellemzői

A build futtatásakor be kell állítanunk a használt környezeti változókat werf.yaml. Ez nem vonatkozik a REVIEW_SHA változóra, amelyet akkor fogunk beállítani, amikor a GitHub-hookról hívjuk a folyamatot.

A szükséges külső adatokat Bash szkriptben generáljuk generate_artifacts, amely két GitLab-folyamat mellékterméket generál:

• fájl releases.yml kiadási adatokkal,
• fájl common_envs.sh, amely az exportálandó környezeti változókat tartalmazza.

Fájl tartalma generate_artifacts nálunk megtalálod adattárak példákkal. Maga az adatok átvétele nem a cikk tárgya, hanem a fájl common_envs.sh fontos számunkra, mert a werf munkája attól függ. Példa a tartalmára:

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'

Használhatja egy ilyen szkript kimenetét például a Bash függvény használatával source.

Most jön a szórakoztató rész. Annak érdekében, hogy az alkalmazás felépítése és telepítése is megfelelően működjön, ezt biztosítani kell werf.yaml ez volt ugyanaz legkevésbé egy csővezetéken belül. Ha ez a feltétel nem teljesül, akkor a werf által az összeszerelés és például a telepítés során kiszámított szakaszok aláírása eltérő lesz. Ez telepítési hibához vezet, mert... a telepítéshez szükséges kép hiányozni fog.

Más szóval, ha a webhelykép összeállítása során a kiadásokra és a verziókra vonatkozó információk megegyeznek, és a telepítéskor új verzió kerül kiadásra, és a környezeti változók értéke eltérő, akkor a telepítés hibával meghiúsul: elvégre az új verzió műtárgya még nem készült el.

Ha generáció werf.yaml külső adatoktól függ (például az aktuális verziók listája, mint esetünkben), akkor az ilyen adatok összetételét és értékeit rögzíteni kell a folyamatban. Ez különösen fontos, ha a külső paraméterek gyakran változnak.

Mi fogunk külső adatok fogadása és rögzítése a folyamat első szakaszában a GitLabban (Előre építeni), és továbbítsa őket az űrlapon GitLab CI műtermék. Ez lehetővé teszi a folyamatfolyamat-feladatok futtatását és újraindítását (felépítés, telepítés, tisztítás) ugyanazzal a konfigurációval werf.yaml.

A színpad tartalma Előre építeni fájlt .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

Miután rögzítette a melléktermékben lévő külső adatokat, a szabványos GitLab CI folyamatszakaszok segítségével felépítheti és üzembe helyezheti: Build and Deploy. Magát a folyamatot indítjuk el a werf GitHub-tárházból származó hook-ok segítségével (azaz amikor változások vannak a GitHub-tárházban). Az adatok a GitLab projekt tulajdonságai között találhatók a részben CI/CD beállítások -> Pipeline triggers, majd hozza létre a megfelelő Webhookot a GitHubban (Beállítások -> Webhooks).

Az építési szakasz így fog kinézni:

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

A GitLab két műterméket ad a színpadról az építési szakaszhoz Előre építeni, tehát a konstrukció segítségével előre elkészített bemeneti adatokkal exportálunk változókat source common_envs.sh. A kivitelezési szakaszt minden esetben elindítjuk, kivéve a csővezeték ütemezett elindítását. Ütemezés szerint a tisztításhoz csővezetéket vezetünk - ebben az esetben nincs szükség összeszerelésre.

A telepítési szakaszban két feladatot fogunk leírni – külön az éles és fejlesztői áramkörökbe történő üzembe helyezéshez, YAML sablon használatával:

.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

A feladatok lényegében csak abban különböznek egymástól, hogy megjelölik azt a fürtkörnyezetet, amelyben a werf-nek végre kell hajtania a telepítést (WERF_KUBE_CONTEXT), és állítsa be a ciklus környezeti változóit (environment.name и environment.url), amelyeket aztán Helm diagram sablonokban használnak. A sablonok tartalmát nem adjuk meg, mert... nincs ott semmi érdekes a kérdéses témához, de megtalálod őket a cikk tárháza.

Végső érintés

Mivel a werf verziók gyakran megjelennek, gyakran fognak új lemezképek készülni, és a Docker Registry folyamatosan bővül. Ezért feltétlenül be kell állítani az automatikus képtisztítást a házirendek alapján. Nagyon könnyű megtenni.

A megvalósításhoz szüksége lesz:

• Adjon hozzá egy tisztítási lépést .gitlab-ci.yml;
• Tisztítási feladat időszakos végrehajtásának hozzáadása;
• Állítson be egy környezeti változót írási hozzáférési tokennel.

Tisztítási szakasz hozzáadása a .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

Szinte mindezt már láttuk egy kicsit magasabban – csak a tisztításhoz először be kell jelentkezni a Docker Registry-be egy olyan tokennel, amely jogosult képeket törölni a Docker Registry-ben (az automatikusan kiadott GitLab CI feladat token nem rendelkeznek ilyen jogokkal). A tokent előre kell létrehozni a GitLab-ban, és meg kell adni az értékét a környezeti változóban WERF_IMAGES_CLEANUP_PASSWORD program (CI/CD beállítások -> Változók).

Egy takarítási feladat hozzáadása a szükséges ütemezéssel megtörténik CI/CD ->
menetrendek.

Ennyi: a Docker Registry-ben lévő projektek többé nem fognak folyamatosan a nem használt képekből növekedni.

A gyakorlati rész végén hadd emlékeztesselek arra, hogy a cikk teljes listája itt érhető el megy:

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

Eredmény

1. Logikus összeállítási struktúrát kaptunk: verziónként egy műterméket.
2. Az összeállítás univerzális, és nem igényel manuális változtatásokat a werf új verzióinak megjelenésekor: a webhelyen található dokumentáció automatikusan frissül.
3. Két kép van összeállítva a különböző kontúrokhoz.
4. Gyorsan működik, mert A gyorsítótárazást a lehető legnagyobb mértékben használják – ha a werf új verzióját adják ki, vagy egy GitHub-hookot kérnek felülvizsgálati véglegesítésre, csak a megfelelő mellékterméket építik újra a módosított verzióval.
5. Nem kell a nem használt képek törlésére gondolni: a werf házirendek szerinti tisztítással a Docker Registry rendben lesz.

Álláspontja

• A werf használata lehetővé teszi az összeállítás gyors működését, mivel mind az összeállítás gyorsítótárazása, mind a külső tárolókkal végzett munka gyorsítótárazása.
• A külső Git-tárolókkal való munka szükségtelenné teszi a teljes adattárat minden alkalommal klónozni, vagy trükkös optimalizálási logikával újra feltalálni a kereket. A werf gyorsítótárat használ, és csak egyszer végzi el a klónozást, majd használja fetch és csak szükség esetén.
• Go-sablonok használatának lehetősége a build konfigurációs fájljában werf.yaml lehetővé teszi egy olyan összeállítás leírását, amelynek eredménye külső adatoktól függ.
• A mount használata a werf-ben jelentősen felgyorsítja a műtermékek gyűjtését - a gyorsítótár miatt, amely minden csővezetékre jellemző.
• A werf egyszerűvé teszi a tisztítás konfigurálását, ami különösen fontos dinamikus építésnél.

PS

Olvassa el blogunkon is:

• «Parancsok futtatása, miközben új alkalmazáskiadást szállít a Kubernetes számára";
• «Építsen és telepítsen azonos típusú mikroszolgáltatásokat a werf és a GitLab CI segítségével";
• «A werf használata összetett Helm-diagramok gördítéséhez";
• «A werf 1.0 stabil bemutatása: mi köze a GitOps-hoz, állapota és tervei".

Forrás: will.com