Cydosod a defnyddio delweddau Docker gyda werff gan ddefnyddio enghraifft o safle dogfennu fersiwn

Rydyn ni eisoes wedi siarad am ein teclyn GitOps sawl gwaith. werff, a'r tro hwn hoffem rannu ein profiad o adeiladu gwefan gyda dogfennaeth y prosiect ei hun - werf.io (ei fersiwn Rwsieg yw ru.werf.io). Mae hon yn safle statig nodweddiadol, ond mae ei chydosodiad yn ddiddorol gan ei fod wedi'i adeiladu gan ddefnyddio nifer deinamig o arteffactau.

Ni fyddwn yn ymchwilio i fanylion strwythur y wefan—cynhyrchu dewislen gyffredin ar gyfer pob fersiwn, tudalen gwybodaeth am y datganiad, ac ati—ond yn lle hynny, byddwn yn canolbwyntio ar y problemau a manylion penodol sy'n gysylltiedig ag adeiladweithiau deinamig ac ychydig ar y prosesau CI/CD cysylltiedig.

Cyflwyniad: Sut mae'r wefan yn gweithio

Gadewch i ni ddechrau gyda'r ffaith bod dogfennaeth werf wedi'i storio ochr yn ochr â'i god. Mae hyn yn gosod rhai gofynion datblygu sydd y tu hwnt i gwmpas yr erthygl hon, ond o leiaf, gellir dweud bod:

• Ni ddylid rhyddhau nodweddion werf newydd heb ddiweddaru'r ddogfennaeth, ac, i'r gwrthwyneb, mae unrhyw newidiadau yn y ddogfennaeth yn awgrymu rhyddhau fersiwn newydd o werf;
• Mae'r prosiect yn cael ei ddatblygu'n eithaf dwys: gellir rhyddhau fersiynau newydd sawl gwaith y dydd;
• Mae unrhyw weithrediadau â llaw i ddefnyddio safle gyda fersiwn newydd o ddogfennaeth o leiaf yn ddiflas;
• Mabwysiadodd y prosiect ddull semantig fersiwn, gyda 5 sianel sefydlogrwydd. Mae'r broses ryddhau yn cynnwys dilyniant olynol o fersiynau trwy sianeli yn nhrefn sefydlogrwydd cynyddol: o alffa i gadarn fel craig;
• Mae gan y wefan fersiwn Rwsieg, sy'n "byw ac yn datblygu" (h.y., y mae ei chynnwys yn cael ei ddiweddaru) ochr yn ochr â'r prif fersiwn (h.y., Saesneg).

Er mwyn cuddio'r holl "weithredoedd mewnol" hyn rhag y defnyddiwr, gan gynnig rhywbeth iddo sy'n "gweithio'n llwyr", fe wnaethon ni offeryn ar wahân ar gyfer gosod a diweddaru werf - A yw amlwerfNodwch y rhif rhyddhau a'r sianel sefydlogrwydd rydych chi'n barod i'w defnyddio, a bydd multiwerf yn gwirio a oes fersiwn newydd ar y sianel ac yn ei lawrlwytho os oes angen.

Mae'r fersiynau diweddaraf o'r werf ar gael ym mhob sianel yn y ddewislen dewis fersiwn ar y wefan. Yn ddiofyn, yn werf.io/dogfennaeth Mae'r fersiwn sianel fwyaf sefydlog ar gyfer y datganiad diweddaraf wedi'i hagor—mae hefyd wedi'i mynegeio gan beiriannau chwilio. Mae dogfennaeth ar gyfer y sianel ar gael mewn cyfeiriadau ar wahân (er enghraifft, werf.io/v1.0-beta/dogfennaeth ar gyfer fersiwn beta 1.0).

At ei gilydd, mae'r fersiynau canlynol ar gael ar y wefan:

1. gwraidd (yn agor yn ddiofyn),
2. ar gyfer pob sianel diweddaru weithredol o bob rhyddhad (e.e. werf.io/v1.0-beta).

I gynhyrchu fersiwn benodol o wefan, yn gyffredinol, mae'n ddigonol ei llunio gan ddefnyddio Jekyll, yn rhedeg yn y cyfeiriadur /docs gorchymyn cyfatebol ystorfa werf (jekyll build), ar ôl newid i'r tag Git o'r fersiwn ofynnol o'r blaen.

Dim ond ychwanegu hynny sydd ar ôl:

• defnyddir y cyfleustodau ei hun (werf) ar gyfer cydosod;
• Mae prosesau CI/CD wedi'u hadeiladu ar sail GitLab CI;
• ac mae hyn i gyd, wrth gwrs, yn rhedeg yn Kubernetes.

tasgau

Nawr gadewch inni lunio'r tasgau sy'n ystyried yr holl fanylion a ddisgrifir:

1. Ar ôl newid y fersiwn werf ar unrhyw sianel ddiweddaru Dylai'r ddogfennaeth ar y wefan gael ei diweddaru'n awtomatig.
2. I ddatblygu mae angen i chi allu weithiau gweld fersiynau rhagolwg o'r wefan.

Rhaid ail-grynhoi'r wefan ar ôl newid y fersiwn ar unrhyw sianel o'r tagiau Git cyfatebol, ond yn ystod y broses o gydosod delweddau byddwn yn profi'r nodweddion canlynol:

• Gan fod y rhestr fersiynau ar sianeli yn newid, dim ond y ddogfennaeth ar gyfer y sianeli lle mae'r fersiwn wedi newid sydd angen ei hailadeiladu. Wedi'r cyfan, nid yw ailadeiladu popeth o'r dechrau yn beth braf iawn.
• Gall y sianeli rhyddhau eu hunain newid. Ar ryw adeg, er enghraifft, efallai na fydd fersiwn fwy sefydlog na'r datganiad mynediad cynnar 1.1 ar gael ar y sianeli, ond byddant yn ymddangos yn y pen draw—siawns na fyddai'n rhaid i chi newid yr adeiladwaith â llaw yn yr achos hwnnw?

Mae'n ymddangos bod mae'r cynulliad yn dibynnu ar newid data allanol.

Gweithredu

Dewis dull

Fel arall, gellir lansio pob fersiwn ofynnol fel pod ar wahân yn Kubernetes. Mae'r opsiwn hwn yn gofyn am nifer fwy o wrthrychau yn y clwstwr, a fydd yn tyfu gyda nifer y datganiadau werf sefydlog. Mae hyn, yn ei dro, yn gofyn am waith cynnal a chadw mwy cymhleth: mae angen ei gweinydd HTTP ei hun ar bob fersiwn, gyda llwyth ysgafnach. Wrth gwrs, mae hyn hefyd yn golygu costau adnoddau uwch.

Aethon ni'r un ffordd adeiladau o'r holl fersiynau gofynnol mewn un ddelweddMae'r ffeiliau statig a luniwyd ar gyfer pob fersiwn o'r wefan yn cael eu storio mewn cynhwysydd NGINX, a derbynnir traffig i'r Deployment cyfatebol trwy NGINX Ingress. Mae'r strwythur syml—cymhwysiad di-wladwriaeth—yn caniatáu graddio'r Deployment yn hawdd (yn dibynnu ar y llwyth) gan ddefnyddio Kubernetes ei hun.

I fod yn fwy manwl gywir, rydym yn adeiladu dau ddelwedd: un ar gyfer yr amgylchedd cynhyrchu, ac ail ddelwedd ychwanegol ar gyfer yr amgylchedd datblygu. Defnyddir (rhedeg) y ddelwedd ychwanegol ar yr amgylchedd datblygu yn unig, ynghyd â'r brif ddelwedd, ac mae'n cynnwys fersiwn y wefan o'r ymrwymiad adolygu. Cyflawnir llwybro rhyngddynt gan ddefnyddio adnoddau Ingress.

clôn werf vs. git ac arteffactau

Fel y soniwyd, i gynhyrchu cynnwys safle statig ar gyfer fersiwn benodol o ddogfennaeth, mae angen i chi redeg adeiladwaith trwy newid i'r tag storfa gyfatebol. Gellid gwneud hyn hefyd trwy glonio'r storfa bob tro y byddwch chi'n adeiladu, gan ddewis y tagiau priodol o restr. Fodd bynnag, mae hwn yn weithrediad sy'n eithaf dwys o ran adnoddau ac mae angen ysgrifennu cyfarwyddiadau nad ydynt yn ddibwys. Anfantais fawr arall yw nad yw'r dull hwn yn caniatáu storio yn ystod yr adeiladwaith.

Yma mae'r cyfleustodau werf ei hun yn dod i'n cynorthwyo, gan weithredu storio clyfar a chaniatáu defnyddio ystorfeydd allanolBydd defnyddio werf i ychwanegu cod o storfa yn cyflymu'r broses adeiladu yn sylweddol, gan fod werf yn clonio'r storfa unwaith ac yna'n rhedeg. yn unig fetch os oes angen. Yn ogystal, wrth ychwanegu data o'r storfa, dim ond y cyfeiriaduron angenrheidiol y gallwn eu dewis (yn ein hachos ni, dyma'r cyfeiriadur docs), a fydd yn lleihau faint o ddata ychwanegol yn sylweddol.

Gan fod Jekyll yn offeryn a gynlluniwyd ar gyfer llunio ffeiliau statig ac nad oes ei angen yn y ddelwedd derfynol, byddai'n rhesymegol ei lunio yn arteffact werf, ac yn y ddelwedd derfynol mewnforio'r canlyniad crynhoi yn unig.

Ysgrifennu werf.yaml

Felly, penderfynon ni y byddem yn llunio pob fersiwn mewn arteffact werf ar wahân. Fodd bynnag, fe wnaethon ni Dydyn ni ddim yn gwybod faint o'r arteffactau hyn fydd yna yn ystod y cydosod., felly ni allwn ysgrifennu cyfluniad adeiladu sefydlog (a bod yn fanwl gywir, gallwn, ond ni fydd yn effeithiol iawn).

Mae werf yn caniatáu ichi ddefnyddio Mynd i dempledi yn eich ffeil ffurfweddu (werf.yaml), ac mae hyn yn ei gwneud hi'n bosibl cynhyrchu ffurfweddiad ar unwaith Yn dibynnu ar ddata allanol (yr hyn sydd ei angen arnom!). Yn ein hachos ni, y data allanol yw gwybodaeth am fersiynau a datganiadau, ac yn seiliedig ar hynny rydym yn casglu'r nifer gofynnol o arteffactau ac yn cael dau ddelwedd o ganlyniad: werf-doc и werf-dev i redeg ar gylchedau gwahanol.

Mae data allanol yn cael ei basio drwy newidynnau amgylcheddol. Dyma beth maen nhw'n ei gynnwys:

• RELEASES — llinyn gyda rhestr o ryddhadau a'r fersiwn gyfredol gyfatebol o werf, ar ffurf rhestr o werthoedd wedi'u gwahanu gan fylchau yn y fformat <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Enghraifft: 1.0%v1.0.4-beta.20
• CHANNELS — llinyn gyda rhestr o sianeli a'r fersiwn gyfredol gyfatebol o werf, ar ffurf rhestr o werthoedd wedi'u gwahanu gan fylchau yn y fformat <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Enghraifft: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — y fersiwn rhyddhau werf i'w harddangos yn ddiofyn ar y wefan (nid yw bob amser yn angenrheidiol arddangos dogfennaeth yn seiliedig ar y rhif rhyddhau uchaf). Enghraifft: v1.0.4-beta.20
• REVIEW_SHA — hash y ymrwymiad adolygu y dylid adeiladu'r fersiwn ar gyfer y gylched brawf ohono.

Bydd y newidynnau hyn yn cael eu llenwi ym mhiblinell CI GitLab, a disgrifir sut yn union isod.

Yn gyntaf oll, er hwylustod, gadewch i ni ddiffinio yn werf.yaml Ewch i newidynnau templed trwy aseinio gwerthoedd iddynt o newidynnau amgylcheddol:

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

Mae disgrifiad yr arteffact ar gyfer llunio'r fersiwn statig o'r wefan yr un fath yn gyffredinol ar gyfer pob achos sydd ei angen arnom (gan gynnwys cynhyrchu'r fersiwn gwraidd, yn ogystal â'r fersiwn ar gyfer yr amgylchedd datblygu). Felly, byddwn yn ei symud i floc ar wahân gan ddefnyddio'r ffwythiant define - i'w ailddefnyddio wedyn gyda chymorth includeByddwn yn trosglwyddo'r dadleuon canlynol i'r templed:

• Version — y fersiwn a gynhyrchwyd (enw'r tag);
• Channel — enw'r sianel ddiweddaru y cynhyrchir yr arteffact ar ei chyfer;
• Commit — cyflawni hash, os cynhyrchir yr arteffact ar gyfer cyflawniad adolygu;
• cyd-destun.

Disgrifiad o'r templed arteffact

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

Rhaid i enw'r arteffact fod yn unigryw. Gallwn gyflawni hyn, er enghraifft, drwy ychwanegu enw'r sianel (gwerth amrywiol .Channel) fel ôl-ddodiad i enw'r arteffact: artifact: doc-{{ .Channel }}Ond mae'n bwysig deall, wrth fewnforio o arteffactau, y bydd angen i chi gyfeirio at yr un enwau.

Wrth ddisgrifio arteffact, defnyddir y nodwedd werf ganlynol: mowntioMowntio gyda chyfeiriadur gwasanaeth penodedig build_dir yn caniatáu ichi gadw storfa Jekyll rhwng rhediadau piblinell, sydd yn cyflymu ail-ymgynnull yn sylweddol.

Efallai eich bod hefyd wedi sylwi ar y defnydd o'r ffeil releases.yml — yn ffeil YAML gyda data rhyddhau, wedi'i gofyn gan github.com (arteffact a gafwyd yn ystod gweithredu piblinell). Mae ei angen ar gyfer llunio gwefannau, ond yng nghyd-destun yr erthygl hon, mae o ddiddordeb i ni oherwydd bod ei gyflwr yn pennu ail-ymgynnull un arteffact yn unig — arteffact safle o'r fersiwn gwreiddyn (nid oes ei angen mewn arteffactau eraill).

Mae hyn yn cael ei weithredu gan ddefnyddio'r gweithredwr amodol. if Templedi a chystrawennau Mynd {{ $Root.Files.Get "releases.yml" | sha256sum }} yn y llwyfan camauMae'n gweithio fel hyn: wrth adeiladu arteffact ar gyfer y fersiwn gwraidd (newidyn .Channel yn hafal i root) hash ffeil releases.yml yn effeithio ar lofnod y llwyfan cyfan, gan ei fod yn gydran o enw'r dasg Ansible (paramedr name). Felly, wrth newid cynnwys ffeil releases.yml bydd yr arteffact cyfatebol yn cael ei ail-ymgynnull.

Rhowch sylw hefyd i weithio gydag ystorfa allanol. Yn y ddelwedd arteffact o storfa werf, dim ond y cyfeiriadur sy'n cael ei ychwanegu /docs, ac yn dibynnu ar y paramedrau a basiwyd, ychwanegir data'r tag neu'r ymrwymiad adolygu gofynnol ar unwaith.

I ddefnyddio'r templed arteffact i gynhyrchu disgrifiad arteffact y fersiynau a'r rhyddhadau sianel a drosglwyddwyd, rydym yn trefnu dolen yn ôl newidyn .WerfVersions в werf.yaml:

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

Gan y bydd y cylchred yn cynhyrchu sawl arteffact (gobeithio hynny), mae angen ystyried y gwahanydd rhyngddynt - y dilyniant --- (am ragor o wybodaeth am gystrawen y ffeil ffurfweddu, gweler dogfennaethFel y gwnaethom ddiffinio yn gynharach, wrth alw templed mewn dolen, rydym yn pasio'r paramedrau fersiwn, URL, a chyd-destun gwraidd.

Yn yr un modd, ond heb y ddolen, rydym yn galw'r templed arteffact ar gyfer “achosion arbennig”: ar gyfer y fersiwn gwraidd, yn ogystal â'r fersiwn o'r ymrwymiad adolygu:

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

Sylwch mai dim ond os yw'r newidyn wedi'i osod y bydd yr arteffact ar gyfer yr ymrwymiad adolygu yn cael ei adeiladu. .WerfReviewCommit.

Mae'r arteffactau'n barod - amser dechrau mewnforio!

Y ddelwedd derfynol a gynlluniwyd i redeg ar Kubernetes yw NGINX rheolaidd gyda ffeil ffurfweddu gweinydd wedi'i hychwanegu. nginx.conf a stateg o arteffactau. Yn ogystal ag arteffact fersiwn y safle gwraidd, mae angen i ni ailadrodd dros y newidyn .WerfVersions I fewnforio arteffactau sianel a fersiwn rhyddhau, byddwn yn dilyn y confensiwn enwi arteffactau a fabwysiadwyd gennym yn gynharach. Gan fod pob arteffact yn storio fersiynau safle ar gyfer dwy iaith, byddwn yn eu mewnforio i'r lleoliadau a bennir gan y ffurfweddiad.

Disgrifiad o'r ddelwedd werf-doc derfynol

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

Mae'r ddelwedd ychwanegol, sy'n rhedeg ochr yn ochr â'r brif ddelwedd ar yr amgylchedd datblygu, yn cynnwys dim ond dwy fersiwn o'r wefan: y fersiwn o'r ymrwymiad adolygu a'r fersiwn wreiddyn o'r wefan (sy'n cynnwys asedau a rennir ac, os cofiwch chi, data rhyddhau). Felly, dim ond yn yr adran fewnforio (ac, wrth gwrs, yr enw) y bydd y ddelwedd ychwanegol yn wahanol i'r brif ddelwedd:

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

Fel y nodwyd uchod, dim ond wrth redeg y newidyn amgylcheddol gosodedig y bydd yr arteffact ar gyfer y ymrwymiad adolygu yn cael ei gynhyrchu. REVIEW_SHAByddai'n bosibl peidio â chynhyrchu'r ddelwedd werf-dev o gwbl os nad oes newidyn amgylcheddol. REVIEW_SHA, ond er mwyn glanhau yn ôl polisïau Gweithiodd delweddau Docker yn werf ar gyfer y ddelwedd werf-dev, byddwn yn ei gadael wedi'i hadeiladu gyda'r arteffact fersiwn gwraidd yn unig (mae eisoes wedi'i adeiladu beth bynnag), er mwyn symleiddio strwythur y biblinell.

Mae'r adeiladwaith yn barod! Gadewch i ni symud ymlaen at CI/CD a rhai manylion pwysig.

Piblinell CI GitLab a Nodweddion Adeiladu Dynamig

Wrth redeg yr adeiladwaith, mae angen i ni osod y newidynnau amgylcheddol a ddefnyddir yn werf.yamlNid yw hyn yn berthnasol i'r newidyn REVIEW_SHA, y byddwn yn ei osod wrth alw'r biblinell o'r bachyn GitHub.

Byddwn yn symud cynhyrchu'r data allanol angenrheidiol i sgript Bash generate_artifacts, a fydd yn cynhyrchu dau arteffact piblinell GitLab:

• файл releases.yml gyda data rhyddhau,
• файл common_envs.sh, sy'n cynnwys newidynnau amgylcheddol i'w hallforio.

Cynnwys y ffeil generate_artifacts fe welwch chi yn ein storfeydd gydag enghreifftiauNid cael y data ei hun yw pwnc yr erthygl, ond y ffeil common_envs.sh Mae hyn yn bwysig i ni oherwydd bod gweithrediad y werf yn dibynnu arno. Enghraifft o'i gynnwys:

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'

Gellir defnyddio allbwn sgript o'r fath, er enghraifft, gan ddefnyddio'r ffwythiant Bash. source.

Nawr daw'r rhan hwyl. Er mwyn i'r gwaith o adeiladu a defnyddio'r rhaglen weithio'n gywir, mae'n angenrheidiol sicrhau bod werf.yaml oedd yr un peth o leiaf o fewn un biblinellOs na chyflawnir y cyflwr hwn, bydd llofnodion y llwyfan a gyfrifir gan werf yn ystod yr adeiladu ac, er enghraifft, y defnydd yn wahanol. Bydd hyn yn arwain at wall defnydd, gan y bydd y ddelwedd sydd ei hangen ar gyfer y defnydd ar goll.

Hynny yw, os yw adeiladwaith delwedd y safle yn cynnwys yr un wybodaeth rhyddhau a fersiwn, ond bod fersiwn newydd yn cael ei rhyddhau yn ystod y defnydd a bod gan y newidynnau amgylcheddol werthoedd gwahanol, bydd y defnydd yn methu, gan nad yw arteffact y fersiwn newydd wedi'i adeiladu eto.

Os yw cenhedlaeth werf.yaml Os yw piblinell yn dibynnu ar ddata allanol (er enghraifft, rhestr o fersiynau cyfredol, fel yn ein hachos ni), dylid cofnodi cyfansoddiad a gwerthoedd data o'r fath o fewn y biblinell. Mae hyn yn arbennig o bwysig os yw paramedrau allanol yn newid yn aml.

Byddwn yn derbyn a chofnodi data allanol yng ngham cyntaf y biblinell yn GitLab (Cyn-adeiladu) a'u trosglwyddo ymhellach ar ffurf Arteffact CI GitLabBydd hyn yn caniatáu ichi redeg ac ailgychwyn swyddi piblinell (adeiladu, defnyddio, glanhau) gyda'r un ffurfweddiad yn werf.yaml.

Cynnwys y llwyfan Cyn-adeiladu ffeil .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

Unwaith y bydd y data allanol wedi'i gipio yn yr arteffact, gallwch ei adeiladu a'i ddefnyddio gan ddefnyddio camau piblinell safonol GitLab CI: Adeiladu a Defnyddio. Rydym yn sbarduno'r biblinell ei hun gan ddefnyddio bachynnau o storfa werf GitHub (h.y., pan wneir newidiadau i storfa GitHub). Gellir dod o hyd i'r data ar gyfer y bachynnau hyn yn adran priodweddau prosiect GitLab. Gosodiadau CI/CD -> Sbardunau piblinell, ac yna creu'r Webhook cyfatebol yn GitHub (Gosodiadau -> Webbooks).

Bydd y cam adeiladu fel hyn:

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

Bydd GitLab yn ychwanegu dau arteffact o'r llwyfan i'r llwyfan adeiladu Cyn-adeiladu, felly rydym yn allforio newidynnau gyda data mewnbwn parod gan ddefnyddio'r adeiladwaith source common_envs.shRydym yn rhedeg y cam adeiladu ym mhob achos ac eithrio wrth redeg y biblinell ar amserlen. Bydd y rhediad wedi'i drefnu at ddibenion glanhau; yn yr achos hwn, nid oes angen rhedeg adeiladu.

Yn ystod y cam defnyddio, byddwn yn disgrifio dau dasg—un ar gyfer defnyddio i gynhyrchu ac un ar gyfer datblygu amgylcheddau—gan ddefnyddio templed 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

Mae'r tasgau'n wahanol yn y bôn dim ond o ran nodi cyd-destun y clwstwr y dylai werf gyflawni'r defnydd ynddo (WERF_KUBE_CONTEXT), a gosod y newidynnau amgylchedd cyfuchlin (environment.name и environment.url), sydd wedyn yn cael eu defnyddio mewn templedi siart Helm. Ni fyddwn yn rhestru cynnwys y templedi, gan nad ydynt yn cynnwys unrhyw beth o ddiddordeb i'r pwnc dan sylw, ond gallwch ddod o hyd iddynt yn storfeydd ar gyfer yr erthygl.

cyffwrdd terfynol

Gan fod fersiynau o'r werf yn cael eu rhyddhau'n eithaf aml, bydd delweddau newydd yn cael eu hadeiladu'n aml, a bydd y Gofrestrfa Docker yn tyfu'n gyson. Felly, mae'n hanfodol sefydlu glanhau delweddau awtomatig yn seiliedig ar bolisïau. Mae'n hawdd iawn i'w wneud.

Ar gyfer gweithredu bydd angen:

• Ychwanegu cam glanhau at .gitlab-ci.yml;
• Ychwanegu gweithredu tasg glanhau yn gyfnodol;
• Gosodwch newidyn amgylcheddol gyda thocyn mynediad ysgrifennu.

Ychwanegu cam glanhau at .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

Rydym eisoes wedi gweld bron pob un o hyn uchod—yr unig wahaniaeth yw, er mwyn glanhau, mae angen i chi fewngofnodi i Gofrestrfa Docker yn gyntaf gyda thocyn sydd â chaniatâd i ddileu delweddau yng Nghofrestrfa Docker (nid oes gan y tocyn swydd GitLab CI a gyhoeddir yn awtomatig y caniatâd hyn). Mae angen i chi greu tocyn yn GitLab ymlaen llaw a nodi ei werth mewn newidyn amgylcheddol. WERF_IMAGES_CLEANUP_PASSWORD y prosiect (Gosodiadau CI/CD -> Newidynnau).

Mae ychwanegu tasg glanhau gyda'r amserlen ofynnol yn cael ei wneud yn CI/CD ->
Atodlenni.

Dyna ni: ni fydd eich prosiect Cofrestrfa Docker yn tyfu'n gyson o ddelweddau nas defnyddir mwyach.

I gloi’r rhan ymarferol, hoffwn eich atgoffa bod y rhestrau llawn o’r erthygl ar gael yn mynd:

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

Canlyniad

1. Rydym wedi cael strwythur cydosod rhesymegol: un arteffact fesul fersiwn.
2. Mae'r adeiladwaith yn gyffredinol ac nid oes angen newidiadau â llaw pan fydd fersiynau newydd o werf yn cael eu rhyddhau: mae'r ddogfennaeth ar y wefan yn cael ei diweddaru'n awtomatig.
3. Cesglir dwy ddelwedd ar gyfer gwahanol gyfuchliniau.
4. Mae'n gweithio'n gyflym oherwydd ei fod yn gwneud y defnydd mwyaf o storio celc: pan ryddheir fersiwn newydd o werf neu pan alwir bachyn GitHub am ymrwymiad adolygu, dim ond yr arteffact cyfatebol gyda'r fersiwn wedi'i newid sy'n cael ei ailadeiladu.
5. Nid oes angen poeni am ddileu delweddau nas defnyddiwyd: bydd glanhau yn seiliedig ar bolisi werf yn cadw'ch Cofrestrfa Docker yn daclus.

Canfyddiadau

• Mae defnyddio werf yn caniatáu i'r adeilad redeg yn gyflym oherwydd storio'r adeilad ei hun yn y storfa dros dro a storio wrth weithio gydag ystorfeydd allanol.
• Mae gweithio gyda storfeydd Git allanol yn dileu'r angen i glonio'r storfa gyfan bob tro neu ailddyfeisio'r olwyn gyda rhesymeg optimeiddio glyfar. Mae werf yn defnyddio storfa ac yn clonio unwaith yn unig, ac yna'n defnyddio fetch a dim ond pan fo angen.
• Y gallu i ddefnyddio templedi Go yn y ffeil ffurfweddu adeiladu werf.yaml yn caniatáu ichi ddisgrifio cynulliad y mae ei ganlyniad yn dibynnu ar ddata allanol.
• Mae defnyddio mowntiau yn werf yn cyflymu casglu arteffactau yn sylweddol oherwydd y storfa, sy'n cael ei rhannu ar draws yr holl biblinellau.
• Mae werf yn ei gwneud hi'n hawdd ffurfweddu glanhau, sy'n arbennig o bwysig ar gyfer adeiladweithiau deinamig.

PS

Darllenwch hefyd ar ein blog:

• «Rhedeg gorchmynion wrth gyflwyno rhyddhad cymhwysiad newydd i Kubernetes";
• «Adeiladu a defnyddio microwasanaethau o'r un math gyda werff a GitLab CI";
• «Defnyddio werff i gyflwyno siartiau Helm cymhleth";
• «Cyflwyno werf 1.0 sefydlog: beth sydd gan GitOps i'w wneud ag ef, statws a chynlluniau'.

Ffynhonnell: hab.com