ProHoster > Blogs > Administrācija > Docker attēlu dinamiska montāža un izvietoÅ”ana ar werf, izmantojot versijas dokumentācijas vietnes piemēru

Docker attēlu dinamiska montāža un izvietoÅ”ana ar werf, izmantojot versijas dokumentācijas vietnes piemēru

Mēs jau vairāk nekā vienu reizi esam runājuÅ”i par mÅ«su GitOps rÄ«ku. werf, un Å”oreiz vēlamies dalÄ«ties pieredzē par vietnes komplektÄ“Å”anu ar paÅ”a projekta dokumentāciju - werf.io (tā krievu versija ir en.werf.io). Å Ä« ir parasta statiska vietne, taču tās montāža ir interesanta ar to, ka tā ir veidota, izmantojot dinamisku artefaktu skaitu.

Docker attēlu dinamiska montāža un izvietoÅ”ana ar werf, izmantojot versijas dokumentācijas vietnes piemēru

Iedziļinieties vietnes struktÅ«ras niansēs: kopējas izvēlnes Ä£enerÄ“Å”ana visām versijām, lapas ar informāciju par izlaidumiem utt. - mēs to nedarÄ«sim. Tā vietā pievērsÄ«simies dinamiskās montāžas problēmām un iezÄ«mēm un nedaudz uz pavadoÅ”ajiem CI/CD procesiem.

Ievads: kā vietne darbojas

Sākumā werf dokumentācija tiek saglabāta kopā ar tās kodu. Tas uzliek noteiktas izstrādes prasības, kas parasti neietilpst Ŕī panta darbības jomā, taču vismaz var teikt, ka:

  • Jaunas werf funkcijas nedrÄ«kst izlaist, neatjauninot dokumentāciju, un, gluži pretēji, jebkuras izmaiņas dokumentācijā nozÄ«mē jaunas werf versijas izlaiÅ”anu;
  • Projektam ir diezgan intensÄ«va attÄ«stÄ«ba: jaunas versijas var izdot vairākas reizes dienā;
  • Visas manuālās darbÄ«bas, lai izvietotu vietni ar jaunu dokumentācijas versiju, ir vismaz nogurdinoÅ”as;
  • Projekts izmanto semantisko pieeju versiju veidoÅ”ana, ar 5 stabilitātes kanāliem. IzlaiÅ”anas process ietver secÄ«gu versiju pāreju pa kanāliem, lai palielinātu stabilitāti: no alfa uz cieto;
  • Vietnei ir versija krievu valodā, kas ā€œdzÄ«vo un attÄ«stāsā€ (t.i., kuras saturs tiek atjaunināts) paralēli galvenajai (t.i., angļu valodas) versijai.

Lai noslēptu visu Å”o ā€œiekŔējo virtuviā€ no lietotāja, piedāvājot viņam kaut ko, kas ā€œvienkārÅ”i darbojasā€, mēs to darÄ«jām atseviŔķs werf instalÄ“Å”anas un atjaunināŔanas rÄ«ks -Å o multiwerf. Jums vienkārÅ”i jānorāda izlaiduma numurs un stabilitātes kanāls, kuru esat gatavs izmantot, un multiwerf pārbaudÄ«s, vai kanālā ir jauna versija, un nepiecieÅ”amÄ«bas gadÄ«jumā to lejupielādēs.

TÄ«mekļa vietnes versiju izvēles izvēlnē ir pieejamas jaunākās werf versijas katrā kanālā. Pēc noklusējuma, pēc adreses werf.io/documentation tiek atvērta visstabilākā kanāla versija jaunākajam izlaidumam - to indeksē arÄ« meklētājprogrammas. Kanāla dokumentācija ir pieejama atseviŔķās adresēs (piemēram, werf.io/v1.0-beta/documentation beta versijai 1.0).

Kopumā vietnei ir pieejamas Ŕādas versijas:

  1. sakne (atveras pēc noklusējuma),
  2. katram katra laidiena aktÄ«vajam atjaunināŔanas kanālam (piemēram, werf.io/v1.0-beta).

Lai Ä£enerētu konkrētu vietnes versiju, parasti pietiek ar tās kompilÄ“Å”anu, izmantojot Jekyllpalaižot direktorijā /docs werf repozitorija atbilstoŔā komanda (jekyll build), pēc pārslēgÅ”anās uz vajadzÄ«gās versijas Git tagu.

Atliek tikai piebilst, ka:

  • montāžai tiek izmantota pati lietderÄ«ba (werf);
  • CI/CD procesi ir veidoti uz GitLab CI bāzes;
  • un tas viss, protams, darbojas Kubernetes.

uzdevumi

Tagad formulēsim uzdevumus, kuros ņemta vērā visa aprakstītā specifika:

  1. Pēc werf versijas maiņas jebkurā atjaunināŔanas kanālā dokumentācija vietnē ir automātiski jāatjaunina.
  2. Lai attÄ«stÄ«tu, jums dažreiz ir jāspēj skatiet vietnes priekÅ”skatÄ«juma versijas.

Vietne ir jāpārkompilē pēc versijas maiņas jebkurā kanālā no atbilstoÅ”ajiem Git tagiem, taču attēla veidoÅ”anas procesā mēs iegÅ«sim Ŕādas funkcijas:

  • Tā kā kanālu versiju saraksts mainās, ir nepiecieÅ”ams tikai atjaunot dokumentāciju tiem kanāliem, kuru versija ir mainÄ«jusies. Galu galā atkal visu pārbÅ«vēt nav Ä«paÅ”i jauki.
  • Izlaidumu kanālu kopa var mainÄ«ties. Piemēram, kādā brÄ«dÄ« kanālos var nebÅ«t stabilākas versijas par agrÄ«nās piekļuves 1.1 versiju, taču laika gaitā tās parādÄ«sies ā€” vai Å”ajā gadÄ«jumā nevajadzētu manuāli mainÄ«t komplektāciju?

Izrādās, ka montāža ir atkarīga no ārējo datu maiņas.

IevieŔana

Pieejas izvēle

Varat arÄ« palaist katru nepiecieÅ”amo versiju kā atseviŔķu aplikāciju pakalpojumā Kubernetes. Å Ä« opcija nozÄ«mē lielāku objektu skaitu klasterÄ«, kas pieaugs, palielinoties stabilo werf izlaidumu skaitam. Un tas, savukārt, nozÄ«mē sarežģītāku apkopi: katrai versijai ir savs HTTP serveris un ar nelielu slodzi. Protams, tas rada arÄ« lielākas resursu izmaksas.

Mēs gājām to paÅ”u ceļu visu nepiecieÅ”amo versiju salikÅ”ana vienā attēlā. Visu vietnes versiju apkopotā statistika atrodas konteinerā ar NGINX, un datplÅ«sma uz atbilstoÅ”o izvietoÅ”anu tiek nodroÅ”ināta, izmantojot NGINX Ingress. VienkārÅ”a struktÅ«ra - bezvalsts lietojumprogramma - ļauj viegli mērogot izvietoÅ”anu (atkarÄ«bā no slodzes), izmantojot paÅ”u Kubernetes.

PrecÄ«zāk sakot, mēs apkopojam divus attēlus: vienu ražoÅ”anas ķēdei, otrs ir papildu attēls izstrādes shēmai. Papildu attēls tiek izmantots (palaists) tikai izstrādātāju shēmā kopā ar galveno, un tajā ir vietnes versija no pārskatÄ«Å”anas saistÄ«bas, un marÅ”rutÄ“Å”ana starp tiem tiek veikta, izmantojot Ingress resursus.

werf vs git klons un artefakti

Kā jau minēts, lai Ä£enerētu vietnes statiku konkrētai dokumentācijas versijai, jums ir jāveido, pārslēdzoties uz atbilstoÅ”o repozitorija tagu. To var izdarÄ«t arÄ«, klonējot repozitoriju katru reizi, kad veidojat, sarakstā atlasot atbilstoÅ”os tagus. Taču Ŕī ir diezgan resursietilpÄ«ga darbÄ«ba un turklāt prasa rakstÄ«t netriviālas instrukcijas... Vēl viens nopietns trÅ«kums ir tas, ka ar Å”o pieeju montāžas laikā nav iespējams kaut ko saglabāt keÅ”atmiņā.

Å eit mums palÄ«gā nāk pati werf utilÄ«ta, ievieÅ”ot viedā keÅ”atmiņa un ļaujot jums izmantot ārējās krātuves. Izmantojot werf, lai pievienotu kodu no repozitorija, ievērojami paātrinās bÅ«vniecÄ«bu, jo werf bÅ«tÄ«bā vienreiz klonē repozitoriju un pēc tam izpilda tikai fetch ja nepiecieÅ”ams. Turklāt, pievienojot datus no repozitorija, mēs varam atlasÄ«t tikai nepiecieÅ”amos direktorijus (mÅ«su gadÄ«jumā tas ir direktorijs docs), kas ievērojami samazinās pievienoto datu apjomu.

Tā kā Jekyll ir rÄ«ks, kas paredzēts statisku datu apkopoÅ”anai un nav vajadzÄ«gs galÄ«gajā attēlā, bÅ«tu loÄ£iski apkopot werf artefakts, un gala attēlā importēt tikai apkopoÅ”anas rezultātu.

Mēs rakstām werf.yaml

Tāpēc mēs nolēmām, ka mēs apkoposim katru versiju atseviŔķā werf artefaktā. Tomēr mēs mēs nezinām, cik daudz Å”o artefaktu bÅ«s montāžas laikā, tāpēc mēs nevaram uzrakstÄ«t fiksētu bÅ«vējuma konfigurāciju (stingri sakot, mēs joprojām varam, taču tas nebÅ«s pilnÄ«gi efektÄ«vs).

werf ļauj izmantot Iet uz veidnēm konfigurācijas failā (werf.yaml), un tas padara to iespējamu Ä£enerēt konfigurāciju lidojumā atkarÄ«bā no ārējiem datiem (kas jums nepiecieÅ”ams!). Ārējie dati mÅ«su gadÄ«jumā ir informācija par versijām un izlaidumiem, uz kuru pamata mēs savācam nepiecieÅ”amo artefaktu skaitu un rezultātā iegÅ«stam divus attēlus: werf-doc Šø werf-dev darboties dažādās ķēdēs.

Ārējie dati tiek nodoti caur vides mainīgajiem. Šeit ir viņu sastāvs:

  • RELEASES ā€” rinda ar izlaidumu sarakstu un atbilstoÅ”o paÅ”reizējo werf versiju ar atstarpi atdalÄ«ta vērtÄ«bu saraksta formā formātā <ŠŠžŠœŠ•Š _Š Š•Š›Š˜Š—Š>%<ŠŠžŠœŠ•Š _Š’Š•Š Š”Š˜Š˜>. Piemērs: 1.0%v1.0.4-beta.20
  • CHANNELS ā€” rinda ar kanālu sarakstu un atbilstoÅ”o paÅ”reizējo werf versiju ar atstarpi atdalÄ«ta vērtÄ«bu saraksta formā formātā <ŠšŠŠŠŠ›>%<ŠŠžŠœŠ•Š _Š’Š•Š Š”Š˜Š˜>. Piemērs: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION ā€” werf izlaiduma versija, kas pēc noklusējuma tiek rādÄ«ta vietnē (ne vienmēr ir nepiecieÅ”ams parādÄ«t dokumentāciju pēc lielākā izlaiduma numura). Piemērs: v1.0.4-beta.20
  • REVIEW_SHA ā€” pārskatÄ«Å”anas saistÄ«bu jaucējkods, no kura jums ir jāizveido testa cilpas versija.

Šie mainīgie tiks aizpildīti GitLab CI konveijerā, un kā tieŔi tas ir rakstīts tālāk.

Pirmkārt, ērtÄ«bas labad mēs definējam werf.yaml Dodieties uz veidņu mainÄ«gajiem, pieŔķirot tiem vērtÄ«bas no vides mainÄ«gajiem:

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

Vietnes statiskās versijas apkopoÅ”anai paredzētā artefakta apraksts parasti ir vienāds visiem mums nepiecieÅ”amajiem gadÄ«jumiem (tostarp saknes versijas Ä£enerÄ“Å”anai, kā arÄ« izstrādes shēmas versijai). Tāpēc mēs to pārvietosim atseviŔķā blokā, izmantojot funkciju define - turpmākai atkārtotai lietoÅ”anai include. Mēs nodosim veidnei Ŕādus argumentus:

  • Version ā€” Ä£enerētā versija (taga nosaukums);
  • Channel ā€” tā atjaunināŔanas kanāla nosaukums, kuram artefakts ir Ä£enerēts;
  • Commit ā€” veikt hash, ja artefakts ir Ä£enerēts pārskatÄ«Å”anas saistÄ«bām;
  • kontekstā.

Artefakta veidnes apraksts

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

Artefakta nosaukumam ir jābÅ«t unikālam. Mēs to varam panākt, piemēram, pievienojot kanāla nosaukumu (mainÄ«gā vērtÄ«ba .Channel) kā artefakta nosaukuma sufiksu: artifact: doc-{{ .Channel }}. Bet jums ir jāsaprot, ka, importējot no artefaktiem, jums bÅ«s jāatsaucas uz tiem paÅ”iem nosaukumiem.

Aprakstot artefaktu, tiek izmantota Ŕāda werf funkcija: montāža. Montāža, kas norāda servisa direktoriju build_dir ļauj saglabāt Jekyll keÅ”atmiņu starp konveijera palaiÅ”anu, kas ievērojami paātrina montāžu.

Iespējams, arÄ« esat pamanÄ«jis faila izmantoÅ”anu releases.yml ir YAML fails ar laidiena datiem, kas pieprasÄ«ti no github.com (artefakts, kas iegÅ«ts, izpildot cauruļvadu). Tas ir nepiecieÅ”ams, veidojot vietni, bet raksta kontekstā tas mums ir interesants, jo tas ir atkarÄ«gs no tā stāvokļa tikai viena artefakta montāža ā€” vietnes saknes versijas artefakts (citos artefaktos tas nav vajadzÄ«gs).

Tas tiek Ä«stenots, izmantojot nosacÄ«jumu paziņojumu if Iet uz veidnēm un dizainu {{ $Root.Files.Get "releases.yml" | sha256sum }} stadijā posmos. Tas darbojas Ŕādi: veidojot artefaktu saknes versijai (mainÄ«gais .Channel vienāds root) failu hash releases.yml ietekmē visa posma parakstu, jo tā ir daļa no Ansible uzdevuma nosaukuma (parametrs name). Tādējādi, mainot saturu failu releases.yml attiecÄ«gais artefakts tiks salikts no jauna.

LÅ«dzu, pievērsiet uzmanÄ«bu arÄ« darbam ar ārēju repozitoriju. Artefakta attēlā no werf repozitorijs, tiek pievienots tikai direktorijs /docs, un atkarÄ«bā no nodotajiem parametriem nekavējoties tiek pievienoti vajadzÄ«gā taga vai pārskatÄ«Å”anas saistÄ«bas dati.

Lai izmantotu artefakta veidni, lai izveidotu kanālu un laidienu pārsÅ«tÄ«to versiju artefakta aprakstu, mainÄ«gajam tiek organizēta cilpa. .WerfVersions Š² werf.yaml:

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

Jo cilpa Ä£enerēs vairākus artefaktus (mēs tā ceram), ir jāņem vērā atdalÄ«tājs starp tiem - secÄ«ba --- (Papildinformāciju par konfigurācijas faila sintaksi skatiet sadaļā dokumentācija). Kā definēts iepriekÅ”, izsaucot veidni cilpā, mēs nododam versijas parametrus, URL un saknes kontekstu.

LÄ«dzÄ«gi, bet bez cilpas, mēs saucam artefakta veidni ā€œÄ«paÅ”iem gadÄ«jumiemā€: saknes versijai, kā arÄ« versijai no pārskatÄ«Å”anas saistÄ«bas:

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

LÅ«dzu, ņemiet vērā, ka artefakts pārskatÄ«Å”anas saistÄ«bām tiks izveidots tikai tad, ja ir iestatÄ«ts mainÄ«gais .WerfReviewCommit.

Artefakti ir gatavi ā€” ir pienācis laiks sākt importÄ“Å”anu!

Pēdējais attēls, kas paredzēts darbam ar Kubernetes, ir parasts NGINX ar pievienotu servera konfigurācijas failu nginx.conf un statiski no artefaktiem. Papildus vietnes saknes versijas artefaktam mums ir jāatkārto mainÄ«gā cilpa .WerfVersions lai importētu kanālu un laidiena versiju artefaktus + ievērojiet artefaktu nosaukÅ”anas noteikumu, ko mēs pieņēmām iepriekÅ”. Tā kā katrā artefaktā tiek glabātas vietnes versijas divām valodām, mēs tās importējam konfigurācijas nodroÅ”inātajās vietās.

Galīgā attēla apraksts 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 -}}

Papildu attēlā, kas kopā ar galveno tiek palaists izstrādes ķēdē, ir tikai divas vietnes versijas: versija no pārskatÄ«Å”anas saistÄ«bas un vietnes saknes versija (ir vispārÄ«gi lÄ«dzekļi un, ja atceraties , izlaiduma dati). Tādējādi papildu attēls no galvenā atŔķirsies tikai importa sadaļā (un, protams, nosaukumā):

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

Kā minēts iepriekÅ”, artefakts pārskatÄ«Å”anas saistÄ«bām tiks Ä£enerēts tikai tad, kad tiks palaists iestatÄ«tais vides mainÄ«gais REVIEW_SHA. Ja nav vides mainÄ«gā, werf-dev attēlu varētu neÄ£enerēt vispār REVIEW_SHA, bet lai tÄ«rÄ«Å”ana pēc politikām Docker attēli werf darbojās werf-dev attēlam, mēs atstāsim to veidot tikai ar saknes versijas artefaktu (tas jau ir uzbÅ«vēts tik un tā), lai vienkārÅ”otu cauruļvada struktÅ«ru.

Montāža ir gatava! Pāriesim pie CI/CD un svarīgām niansēm.

Cauruļvads GitLab CI un dinamiskās veidoŔanas funkcijas

Palaižot būvējumu, mums ir jāiestata izmantotie vides mainīgie werf.yaml. Tas neattiecas uz mainīgo REVIEW_SHA, ko iestatīsim, izsaucot konveijeru no GitHub āķa.

Mēs Ä£enerēsim nepiecieÅ”amos ārējos datus Bash skriptā generate_artifacts, kas Ä£enerēs divus GitLab cauruļvada artefaktus:

  • fails releases.yml ar izlaiduma datiem,
  • fails common_envs.sh, kas satur eksportējamos vides mainÄ«gos.

Faila saturs generate_artifacts jÅ«s atradÄ«siet mÅ«su krātuves ar piemēriem. Pati datu saņemÅ”ana nav raksta priekÅ”mets, bet gan fails common_envs.sh mums ir svarÄ«gi, jo no tā ir atkarÄ«gs werfa darbs. Tās satura piemērs:

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'

Šāda skripta izvadi var izmantot, piemēram, izmantojot funkciju Bash source.

Tagad nāk jautrākā daļa. Lai gan lietojumprogrammas izveide, gan izvietoÅ”ana darbotos pareizi, tas ir jānodroÅ”ina werf.yaml bija tas pats vismaz viena cauruļvada ietvaros. Ja Å”is nosacÄ«jums nav izpildÄ«ts, tad to posmu paraksti, kurus werf aprēķina montāžas un, piemēram, izvietoÅ”anas laikā, bÅ«s atŔķirÄ«gi. Tas radÄ«s izvietoÅ”anas kļūdu, jo... izvietoÅ”anai nepiecieÅ”amā attēla trÅ«ks.

Citiem vārdiem sakot, ja vietnes attēla montāžas laikā informācija par laidieniem un versijām ir vienāda un izvietoÅ”anas laikā tiek izlaista jauna versija un vides mainÄ«gajiem ir atŔķirÄ«gas vērtÄ«bas, izvietoÅ”ana neizdosies ar kļūdu: galu galā jaunās versijas artefakts vēl nav uzbÅ«vēts.

Ja paaudze werf.yaml ir atkarÄ«gs no ārējiem datiem (piemēram, paÅ”reizējo versiju saraksta, kā mÅ«su gadÄ«jumā), tad Ŕādu datu sastāvs un vērtÄ«bas ir jāreÄ£istrē cauruļvadā. Tas ir Ä«paÅ”i svarÄ«gi, ja ārējie parametri mainās diezgan bieži.

Mēs bÅ«sim saņemt un ierakstÄ«t ārējos datus cauruļvada pirmajā posmā GitLab (IepriekŔēja uzbÅ«ve) un pārsÅ«tiet tos tālāk formā GitLab CI artefakts. Tas ļaus palaist un restartēt konveijera darbus (veidot, izvietot, tÄ«rÄ«t) ar tādu paÅ”u konfigurāciju werf.yaml.

Skatuves saturs IepriekŔēja uzbÅ«ve failu .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

Pēc ārējo datu tverÅ”anas artefaktā varat izveidot un izvietot, izmantojot standarta GitLab CI konveijera posmus: Build un Deploy. Mēs palaižam paÅ”u cauruļvadu, izmantojot āķus no werf GitHub repozitorijas (t.i., kad GitHub repozitorijā ir izmaiņas). Datus par tiem var atrast GitLab projekta rekvizÄ«tos sadaļā CI/CD iestatÄ«jumi -> Cauruļvada aktivizētājiun pēc tam izveidojiet atbilstoÅ”o tÄ«mekļa aizÄ·eri GitHub (IestatÄ«jumi -> TÄ«mekļa aizÄ·eres).

BÅ«vÄ“Å”anas posms izskatÄ«sies Ŕādi:

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 pievienos divus artefaktus no skatuves izveides stadijai IepriekŔēja uzbÅ«ve, tāpēc mēs eksportējam mainÄ«gos ar sagatavotiem ievades datiem, izmantojot konstrukciju source common_envs.sh. Mēs sākam bÅ«vniecÄ«bas posmu visos gadÄ«jumos, izņemot cauruļvada palaiÅ”anu saskaņā ar grafiku. AtbilstoÅ”i grafikam izvadÄ«sim cauruļvadu tÄ«rÄ«Å”anai - Å”ajā gadÄ«jumā nav jāveic montāža.

IzvietoÅ”anas posmā mēs aprakstÄ«sim divus uzdevumus ā€” atseviŔķi izvietoÅ”anai ražoÅ”anas un izstrādes shēmās, izmantojot YAML veidni:

.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

Uzdevumi bÅ«tÄ«bā atŔķiras tikai ar to, ka tiek norādÄ«ts klastera konteksts, kurā werf jāveic izvietoÅ”ana (WERF_KUBE_CONTEXT) un cilpas vides mainÄ«go iestatÄ«Å”ana (environment.name Šø environment.url), kuras pēc tam tiek izmantotas Helm diagrammas veidnēs. Veidņu saturu nesniegsim, jo... tur nav nekā interesanta par attiecÄ«go tēmu, bet tos var atrast raksta krātuves.

Galīgais pieskāriens

Tā kā werf versijas tiek izlaistas diezgan bieži, jauni attēli tiks veidoti bieži, un Docker reÄ£istrs pastāvÄ«gi pieaugs. Tāpēc ir obligāti jākonfigurē automātiskā attēla tÄ«rÄ«Å”ana, pamatojoties uz politikām. Tas ir ļoti viegli izdarāms.

Lai īstenotu, jums būs nepiecieŔams:

  • Pievienojiet tÄ«rÄ«Å”anas darbÄ«bu .gitlab-ci.yml;
  • Pievienojiet periodisku tÄ«rÄ«Å”anas uzdevuma izpildi;
  • Iestatiet vides mainÄ«go ar rakstÄ«Å”anas piekļuves pilnvaru.

TīrīŔanas posma pievienoŔana .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

GandrÄ«z visu to jau esam redzējuÅ”i nedaudz augstāk ā€“ tikai lai to notÄ«rÄ«tu, vispirms jāpiesakās Docker reÄ£istrā ar marÄ·ieri, kuram ir tiesÄ«bas dzēst attēlus Docker reÄ£istrā (automātiski izsniegtais GitLab CI uzdevuma marÄ·ieris to nedara ir Ŕādas tiesÄ«bas). Tokens ir jāizveido GitLab iepriekÅ” un tā vērtÄ«ba jānorāda vides mainÄ«gajā WERF_IMAGES_CLEANUP_PASSWORD projekts (CI/CD iestatÄ«jumi -> MainÄ«gie).

TīrīŔanas uzdevuma pievienoŔana ar nepiecieŔamo grafiku tiek veikta CI/CD ->
Grafiki.

Tas arī viss: projekts Docker reģistrā vairs nepārtraukti neizaugs no neizmantotiem attēliem.

Praktiskās daļas beigās atgādināŔu, ka pilni saraksti no raksta ir pieejami Git:

Piedzīvojiet efektīvu rezultātu spēku

  1. Mēs saņēmām loģisku montāžas struktūru: viens artefakts katrā versijā.
  2. Montāža ir universāla un neprasa manuālas izmaiņas, kad tiek izlaistas jaunas werf versijas: dokumentācija vietnē tiek automātiski atjaunināta.
  3. Divi attēli ir salikti dažādām kontūrām.
  4. Tas darbojas ātri, jo KeÅ”atmiņa tiek izmantota pēc iespējas vairāk ā€” kad tiek izlaista jauna werf versija vai GitHub āķis tiek izsaukts pārskatÄ«Å”anai, tiek pārbÅ«vēts tikai atbilstoÅ”ais artefakts ar mainÄ«to versiju.
  5. Nav jādomā par neizmantoto attēlu dzÄ“Å”anu: tÄ«rÄ«Å”ana saskaņā ar werf politikām uzturēs Docker reÄ£istru kārtÄ«bā.

Atzinumi

  • Izmantojot werf, montāža var darboties ātri, jo tiek saglabāta keÅ”atmiņa gan paÅ”ai montāžai, gan keÅ”atmiņai, strādājot ar ārējām krātuvēm.
  • Strādājot ar ārējām Git krātuvēm, nav nepiecieÅ”ams katru reizi klonēt visu repozitoriju vai no jauna izgudrot riteni, izmantojot sarežģītu optimizācijas loÄ£iku. werf izmanto keÅ”atmiņu un veic klonÄ“Å”anu tikai vienu reizi un pēc tam izmanto fetch un tikai nepiecieÅ”amÄ«bas gadÄ«jumā.
  • Iespēja izmantot Go veidnes bÅ«vējuma konfigurācijas failā werf.yaml ļauj aprakstÄ«t montāžu, kuras rezultāts ir atkarÄ«gs no ārējiem datiem.
  • Montāžas izmantoÅ”ana werf ievērojami paātrina artefaktu vākÅ”anu, pateicoties keÅ”atmiņai, kas ir kopÄ«ga visiem cauruļvadiem.
  • werf ļauj viegli konfigurēt tÄ«rÄ«Å”anu, kas ir Ä«paÅ”i svarÄ«gi, veidojot dinamiski.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru