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

Rydym eisoes wedi siarad am ein hofferyn GitOps fwy nag unwaith. werff, a'r tro hwn hoffem rannu ein profiad o gydosod y safle gyda dogfennaeth y prosiect ei hun - werf.io (ei fersiwn Rwsieg yw en.werf.io). Mae hwn yn safle sefydlog cyffredin, ond mae ei gynulliad yn ddiddorol gan ei fod wedi'i adeiladu gan ddefnyddio nifer deinamig o arteffactau.

Ewch i mewn i naws strwythur y wefan: creu dewislen gyffredin ar gyfer pob fersiwn, tudalennau gyda gwybodaeth am ddatganiadau, ac ati. - ni fyddwn. Yn lle hynny, gadewch i ni ganolbwyntio ar faterion a nodweddion cydosod deinamig ac ychydig ar y prosesau CI/CD sy'n cyd-fynd â nhw.

Cyflwyniad: sut mae'r safle'n gweithio

I ddechrau, mae dogfennaeth werff yn cael ei storio ynghyd â'i god. Mae hyn yn gosod rhai gofynion datblygu sydd yn gyffredinol y tu hwnt i gwmpas yr erthygl hon, ond o leiaf gellir dweud:

• Ni ddylid rhyddhau swyddogaethau werff newydd heb ddiweddaru'r ddogfennaeth ac, i'r gwrthwyneb, mae unrhyw newidiadau yn y ddogfennaeth yn awgrymu rhyddhau fersiwn newydd o werff;
• Mae gan y prosiect ddatblygiad eithaf dwys: gellir rhyddhau fersiynau newydd sawl gwaith y dydd;
• Mae unrhyw weithrediadau llaw i leoli safle gyda fersiwn newydd o ddogfennaeth o leiaf yn ddiflas;
• Mae'r prosiect yn mabwysiadu ymagwedd semantig fersiwn, gyda 5 sianel sefydlogrwydd. Mae'r broses ryddhau yn golygu taith ddilyniannol fersiynau trwy sianeli er mwyn cynyddu sefydlogrwydd: o alffa i graig-solid;
• Mae gan y wefan fersiwn Rwsieg, sy'n “byw ac yn datblygu” (h.y., y mae ei chynnwys yn cael ei diweddaru) ochr yn ochr â'r prif fersiwn (hy, Saesneg).

I guddio’r holl “gegin fewnol” hon rhag y defnyddiwr, gan gynnig rhywbeth “jyst yn gweithio” iddo, fe wnaethom ni offeryn gosod a diweddaru werf ar wahân - A yw amlwerf. Does ond angen i chi nodi'r 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.

Yn y ddewislen dewis fersiwn ar y wefan, mae'r fersiynau diweddaraf o werff ar gael ym mhob sianel. Yn ddiofyn, yn ôl cyfeiriad werf.io/dogfennaeth mae'r fersiwn o'r sianel fwyaf sefydlog ar gyfer y datganiad diweddaraf yn agor - mae hefyd yn cael ei fynegeio gan beiriannau chwilio. Mae dogfennau ar gyfer y sianel ar gael mewn cyfeiriadau ar wahân (er enghraifft, werf.io/v1.0-beta/documentation ar gyfer rhyddhau beta 1.0).

Yn gyfan gwbl, mae gan y wefan y fersiynau canlynol ar gael:

1. gwraidd (yn agor yn ddiofyn),
2. ar gyfer pob sianel diweddaru gweithredol o bob datganiad (er enghraifft, werf.io/v1.0-beta).

I gynhyrchu fersiwn benodol o wefan, yn gyffredinol, mae'n ddigon i'w lunio gan ddefnyddio Jekylltrwy redeg yn y cyfeiriadur /docs gorchymyn cyfatebol ystorfa werf (jekyll build), ar ôl newid i'r tag Git o'r fersiwn ofynnol.

Nid oes ond angen ychwanegu bod:

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

tasgau

Nawr, gadewch i ni lunio tasgau sy'n ystyried yr holl fanylion a ddisgrifir:

1. Ar ôl newid y fersiwn werf ar unrhyw sianel diweddaru dylai dogfennaeth ar y wefan gael ei diweddaru'n awtomatig.
2. Ar gyfer datblygiad 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 y broses o adeiladu'r ddelwedd byddwn yn cael y nodweddion canlynol:

• Gan fod y rhestr o fersiynau ar sianeli yn newid, nid oes ond angen ailadeiladu'r ddogfennaeth ar gyfer sianeli lle mae'r fersiwn wedi newid. Wedi'r cyfan, nid yw ailadeiladu popeth eto yn braf iawn.
• Gall y set o sianeli ar gyfer datganiadau newid. Ar ryw adeg, er enghraifft, efallai na fydd fersiwn ar y sianeli yn fwy sefydlog na'r datganiad mynediad cynnar 1.1, ond dros amser byddant yn ymddangos - yn yr achos hwn, oni ddylech chi newid y cynulliad â llaw?

Mae'n ymddangos bod cydosod yn dibynnu ar newid data allanol.

Gweithredu

Dewis Dull

Fel arall, gallwch redeg pob fersiwn ofynnol fel pod ar wahân yn Kubernetes. Mae'r opsiwn hwn yn awgrymu nifer fwy o wrthrychau yn y clwstwr, a fydd yn tyfu gyda'r cynnydd yn nifer y rhyddhau werff sefydlog. Ac mae hyn, yn ei dro, yn awgrymu cynnal a chadw mwy cymhleth: mae gan bob fersiwn ei gweinydd HTTP ei hun, a gyda llwyth bach. Wrth gwrs, mae hyn hefyd yn golygu mwy o gostau adnoddau.

Cymerasom yr un llwybr cydosod yr holl fersiynau angenrheidiol mewn un ddelwedd. Mae statigau cryno pob fersiwn o'r wefan wedi'u lleoli mewn cynhwysydd gyda NGINX, ac mae traffig i'r Defnydd cyfatebol yn dod trwy NGINX Ingress. Mae strwythur syml - cymhwysiad heb wladwriaeth - yn caniatáu ichi raddio Defnydd yn hawdd (yn dibynnu ar y llwyth) gan ddefnyddio Kubernetes ei hun.

I fod yn fwy manwl gywir, rydym yn casglu dwy ddelwedd: un ar gyfer y gylched gynhyrchu, mae'r ail yn un ychwanegol ar gyfer y gylched dev. Defnyddir y ddelwedd ychwanegol (wedi'i lansio) yn unig ar y gylched dev ynghyd â'r prif un ac mae'n cynnwys y fersiwn o'r wefan o'r ymrwymiad adolygu, ac mae llwybro rhyngddynt yn cael ei berfformio gan ddefnyddio adnoddau Ingress.

werf vs clôn git ac arteffactau

Fel y soniwyd eisoes, er mwyn cynhyrchu statig safle ar gyfer fersiwn benodol o'r ddogfennaeth, mae angen i chi adeiladu trwy newid i'r tag storfa priodol. Gallech chi hefyd wneud hyn trwy glonio'r ystorfa bob tro y byddwch chi'n adeiladu, gan ddewis y tagiau priodol o restr. Fodd bynnag, mae hwn yn weithrediad braidd yn ddwys o ran adnoddau ac, ar ben hynny, mae angen ysgrifennu cyfarwyddiadau nad ydynt yn ddibwys... Anfantais ddifrifol arall yw nad oes unrhyw ffordd i storio rhywbeth yn ystod y gwasanaeth gyda'r dull hwn.

Yma daw y werf ddefnyddioldeb ei hun i'n cynnorthwy, gan weithredu caching smart a chaniatáu i chi ddefnyddio cadwrfeydd allanol. Bydd defnyddio werff i ychwanegu cod o'r ystorfa yn cyflymu'r gwaith adeiladu yn sylweddol, oherwydd yn ei hanfod mae werff yn clonio'r gadwrfa unwaith ac yna'n gweithredu yn unig fetch Os yw'n anghenrheidiol. Yn ogystal, wrth ychwanegu data o'r gadwrfa, gallwn ddewis y cyfeiriaduron angenrheidiol yn unig (yn ein hachos ni dyma'r cyfeiriadur docs), a fydd yn lleihau'n sylweddol faint o ddata ychwanegol.

Gan fod Jekyll yn offeryn sydd wedi'i gynllunio ar gyfer casglu data statig ac nad oes ei angen yn y ddelwedd derfynol, byddai'n rhesymegol i lunio artifact werf, ac i'r ddelwedd derfynol mewnforio canlyniad y casgliad yn unig.

Ysgrifennwn werf.yaml

Felly, penderfynom y byddem yn llunio pob fersiwn mewn arteffact werff ar wahân. Fodd bynnag rydym nid ydym yn gwybod faint o'r arteffactau hyn fydd yn ystod y gwasanaeth, felly ni allwn ysgrifennu cyfluniad adeiladu sefydlog (a siarad yn fanwl gywir, gallwn ni o hyd, ond ni fydd yn gwbl effeithiol).

werf yn eich galluogi i ddefnyddio Ewch templedi yn eich ffeil ffurfweddu (werf.yaml), ac mae hyn yn ei gwneud yn bosibl cynhyrchu config ar y hedfan yn dibynnu ar ddata allanol (yr hyn sydd ei angen arnoch chi!). Mae data allanol yn ein hachos ni yn wybodaeth am fersiynau a datganiadau, ar sail yr hyn rydym yn casglu'r nifer gofynnol o arteffactau ac o ganlyniad rydym yn cael dwy ddelwedd: werf-doc и werf-dev i redeg ar wahanol gylchedau.

Mae data allanol yn cael ei drosglwyddo trwy newidynnau amgylchedd. Dyma eu cyfansoddiad:

• RELEASES — llinell gyda rhestr o ddatganiadau a'r fersiwn gyfredol gyfatebol o werff, ar ffurf rhestr o werthoedd wedi'u gwahanu gan ofod yn y fformat <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Enghraifft: 1.0%v1.0.4-beta.20
• CHANNELS — llinell gyda rhestr o sianeli a'r fersiwn gyfredol gyfatebol o werff, ar ffurf rhestr o werthoedd wedi'u gwahanu gan ofod yn y fformat <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Enghraifft: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — fersiwn rhyddhau werf i'w harddangos yn ddiofyn ar y wefan (nid oes angen arddangos dogfennaeth yn ôl y rhif rhyddhau uchaf bob amser). Enghraifft: v1.0.4-beta.20
• REVIEW_SHA — hash o'r ymrwymiad adolygu lle mae angen i chi adeiladu'r fersiwn ar gyfer y ddolen brawf.

Bydd y newidynnau hyn yn cael eu llenwi ar y gweill GitLab CI, a sut yn union sydd wedi'i ysgrifennu isod.

Yn gyntaf oll, er hwylustod, rydym yn diffinio yn werf.yaml Ewch i newidynnau templed, gan aseinio gwerthoedd iddynt o newidynnau amgylchedd:

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

Mae'r disgrifiad o'r arteffact ar gyfer llunio fersiwn statig y wefan yn gyffredinol yr un fath ar gyfer pob achos sydd ei angen arnom (gan gynnwys cynhyrchu'r fersiwn gwraidd, yn ogystal â'r fersiwn ar gyfer y cylched dev). Felly, byddwn yn ei symud i mewn i floc ar wahân gan ddefnyddio'r swyddogaeth define - ar gyfer ailddefnyddio dilynol include. Byddwn yn trosglwyddo'r dadleuon canlynol i'r templed:

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

Disgrifiad Templed Artifact

{{- 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, trwy ychwanegu enw'r sianel (gwerth y newidyn .Channel) fel ôl-ddodiad i enw'r arteffact: artifact: doc-{{ .Channel }}. Ond mae angen i chi ddeall, wrth fewnforio o arteffactau, y bydd angen i chi gyfeirio at yr un enwau.

Wrth ddisgrifio arteffact, defnyddir y nodwedd werf ganlynol: mowntio. Mowntio sy'n nodi'r cyfeiriadur gwasanaeth build_dir yn eich galluogi i achub y storfa Jekyll rhwng rhediadau piblinellau, sy'n yn cyflymu'r ailgynnull yn sylweddol.

Efallai eich bod hefyd wedi sylwi ar y defnydd o'r ffeil releases.yml yn ffeil YAML gyda data rhyddhau y gofynnwyd amdani github.com (arteffact a gafwyd wrth weithredu piblinell). Mae ei angen wrth lunio'r safle, ond yng nghyd-destun yr erthygl mae'n ddiddorol i ni oherwydd ei fod yn dibynnu ar ei gyflwr ailgynnull un arteffact yn unig - arteffact o fersiwn gwraidd y wefan (nid oes ei angen mewn arteffactau eraill).

Gweithredir hyn gan ddefnyddio'r datganiad amodol if Ewch templedi a dyluniadau {{ $Root.Files.Get "releases.yml" | sha256sum }} yn y llwyfan camau. Mae'n gweithio fel a ganlyn: wrth adeiladu arteffact ar gyfer y fersiwn gwraidd (amrywiol .Channel yn hafal i root) hash ffeil releases.yml yn effeithio ar lofnod y cam cyfan, gan ei fod yn rhan o enw'r dasg Ansible (paramedr name). Felly, wrth newid cynnwys ffeil releases.yml bydd yr arteffact cyfatebol yn cael ei ailosod.

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

I ddefnyddio'r templed arteffact i gynhyrchu disgrifiad o arteffact y fersiynau a drosglwyddwyd o sianeli a datganiadau, rydym yn trefnu dolen ar y newidyn .WerfVersions в werf.yaml:

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

Achos bydd y ddolen yn cynhyrchu sawl arteffact (gobeithiwn hynny), mae angen cymryd i ystyriaeth y gwahanydd rhyngddynt - y dilyniant --- (Am ragor o wybodaeth am gystrawen ffeil ffurfweddu, gweler dogfennaeth). Fel y diffinnir yn gynharach, wrth alw templed mewn dolen, rydym yn pasio'r fersiwn paramedrau, URL a chyd-destun gwraidd.

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

{{ 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 na chaiff yr arteffact ar gyfer yr ymrwymiad adolygu ei adeiladu oni bai bod y newidyn wedi'i osod .WerfReviewCommit.

Mae'r arteffactau'n barod - mae'n bryd dechrau mewnforio!

Mae'r ddelwedd derfynol, a gynlluniwyd i redeg ar Kubernetes, yn NGINX rheolaidd gyda ffeil ffurfweddu gweinydd wedi'i hychwanegu nginx.conf a statig o arteffactau. Yn ogystal ag arteffact fersiwn gwraidd y wefan, mae angen inni ailadrodd y ddolen ar y newidyn .WerfVersions i fewnforio arteffactau sianel a fersiynau rhyddhau + dilynwch y rheol enwi arteffactau a fabwysiadwyd gennym yn gynharach. Gan fod pob arteffact yn storio fersiynau o'r wefan ar gyfer dwy iaith, rydym yn eu mewnforio i'r lleoedd a ddarperir gan y ffurfweddiad.

Disgrifiad o'r ddelwedd olaf 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 -}}

Mae'r ddelwedd ychwanegol, sydd, ynghyd â'r prif un, yn cael ei lansio ar y gylched dev, yn cynnwys dwy fersiwn yn unig o'r wefan: y fersiwn o'r ymrwymiad adolygu a fersiwn gwraidd y wefan (mae yna asedau cyffredinol ac, os cofiwch , rhyddhau data). Felly, bydd y ddelwedd ychwanegol yn wahanol i'r prif un yn unig yn yr adran fewnforio (ac, wrth gwrs, yn yr enw):

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 pan fydd y newidyn amgylchedd gosodedig yn cael ei redeg y bydd yr arteffact ar gyfer ymrwymiad yr adolygiad yn cael ei gynhyrchu REVIEW_SHA. Byddai'n bosibl peidio â chynhyrchu'r ddelwedd werf-dev o gwbl os nad oes newidyn amgylchedd REVIEW_SHA, ond er mwyn glanhau gan bolisïau Roedd delweddau docwr yn werf yn gweithio ar gyfer delwedd werf-dev, byddwn yn ei adael i gael ei adeiladu yn unig gyda'r arteffact fersiwn gwraidd (mae eisoes wedi'i adeiladu beth bynnag), i symleiddio strwythur y biblinell.

Mae'r cynulliad yn barod! Gadewch i ni symud ymlaen i CI/CD a naws bwysig.

Piblinell yn GitLab CI a nodweddion adeiladu deinamig

Wrth redeg yr adeilad mae angen i ni osod y newidynnau amgylchedd a ddefnyddir ynddo werf.yaml. Nid yw hyn yn berthnasol i'r newidyn REVIEW_SHA, y byddwn yn ei osod wrth alw piblinell o'r bachyn GitHub.

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

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

Cynnwys y ffeil generate_artifacts fe welwch yn ein storfeydd gydag enghreifftiau. Nid derbyn y data ei hun yw testun yr erthygl, ond y ffeil common_envs.sh yn bwysig i ni, oherwydd mae gwaith werff 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'

Gallwch ddefnyddio allbwn sgript o'r fath, er enghraifft, gan ddefnyddio'r swyddogaeth Bash source.

Nawr daw'r rhan hwyliog. Er mwyn i'r gwaith o adeiladu a defnyddio'r cais weithio'n gywir, mae angen sicrhau hynny werf.yaml oedd yr un o leiaf o fewn un biblinell. Os na chaiff yr amod hwn ei fodloni, yna bydd llofnodion y camau y mae wef yn eu cyfrifo yn ystod y cynulliad ac, er enghraifft, y defnydd, yn wahanol. Bydd hyn yn arwain at gamgymeriad lleoli, oherwydd ... bydd y ddelwedd sydd ei hangen ar gyfer ei defnyddio ar goll.

Mewn geiriau eraill, os yw'r wybodaeth am ddatganiadau a fersiynau yr un peth yn ystod cydosod delwedd y wefan, ac ar adeg defnyddio fersiwn newydd yn cael ei rhyddhau a bod gan y newidynnau amgylchedd werthoedd gwahanol, yna bydd y gosodiad yn methu â gwall: wedi'r cyfan, nid yw arteffact y fersiwn newydd wedi'i adeiladu eto.

Os cenhedlaeth werf.yaml yn dibynnu ar ddata allanol (er enghraifft, rhestr o fersiynau cyfredol, fel yn ein hachos ni), yna 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 eithaf aml.

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

Cynnwys y llwyfan Rhag-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

Ar ôl dal y data allanol yn yr arteffact, gallwch adeiladu a defnyddio gan ddefnyddio'r camau piblinell safonol GitLab CI: Adeiladu a Defnyddio. Rydym yn lansio'r biblinell ei hun gan ddefnyddio bachau o ystorfa werf GitHub (h.y., pan fydd newidiadau yn yr ystorfa ar GitHub). Gellir dod o hyd i ddata ar eu cyfer yn y priodweddau prosiect GitLab yn yr adran Gosodiadau CI/CD -> Sbardunau piblinellau, ac yna creu'r Webhook cyfatebol yn GitHub (Gosodiadau -> Webhooks).

Bydd y cam adeiladu yn edrych 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 cam adeiladu Rhag-adeiladu, felly rydym yn allforio newidynnau gyda data mewnbwn parod gan ddefnyddio'r lluniad source common_envs.sh. Rydym yn dechrau'r cam adeiladu ym mhob achos, ac eithrio lansio'r biblinell yn unol ag amserlen. Yn ôl yr amserlen, byddwn yn rhedeg piblinell ar gyfer glanhau - yn yr achos hwn nid oes angen perfformio cynulliad.

Yn y cam defnyddio, byddwn yn disgrifio dwy dasg - ar wahân i'w defnyddio i gylchedau cynhyrchu a datblygu, 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

Yn y bôn, mae'r tasgau'n gwahaniaethu dim ond wrth nodi'r cyd-destun clwstwr y dylai werff berfformio'r defnydd ynddo (WERF_KUBE_CONTEXT), a gosod y newidynnau amgylchedd dolen (environment.name и environment.url), a ddefnyddir wedyn mewn templedi siart Helm. Ni fyddwn yn darparu cynnwys y templedi, oherwydd... nid oes dim byd diddorol yno ar gyfer y pwnc dan sylw, ond gallwch ddod o hyd iddynt yn storfeydd ar gyfer yr erthygl.

cyffwrdd terfynol

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

Er mwyn gweithredu bydd angen:

• Ychwanegu cam glanhau i .gitlab-ci.yml;
• Ychwanegu tasg glanhau o bryd i'w gilydd;
• Gosodwch newidyn amgylchedd gyda thocyn mynediad ysgrifennu.

Ychwanegu cam glanhau i .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 hyn i gyd ychydig yn uwch - dim ond i'w lanhau mae angen i chi fewngofnodi i Gofrestrfa'r Docwyr yn gyntaf gyda thocyn sydd â'r hawl i ddileu delweddau yng Nghofrestrfa'r Docwyr (nid yw tocyn tasg GitLab CI a gyhoeddir yn awtomatig yn â hawliau o'r fath). Rhaid creu'r tocyn yn GitLab ymlaen llaw a rhaid nodi ei werth yn y newidyn amgylchedd 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 prosiect yng Nghofrestrfa'r Docwyr bellach yn tyfu'n gyson o ddelweddau nas defnyddiwyd.

Ar ddiwedd y rhan ymarferol, gadewch imi eich atgoffa bod rhestrau llawn o'r erthygl ar gael yn mynd:

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

Canlyniad

1. Cawsom strwythur cydosod rhesymegol: un arteffact fesul fersiwn.
2. Mae'r cynulliad yn gyffredinol ac nid oes angen ei newid â llaw pan fydd fersiynau newydd o werff yn cael eu rhyddhau: mae'r ddogfennaeth ar y wefan yn cael ei diweddaru'n awtomatig.
3. Mae dwy ddelwedd yn cael eu cydosod ar gyfer gwahanol gyfuchliniau.
4. Mae'n gweithio'n gyflym, oherwydd Defnyddir caching gymaint ag y bo modd - pan fydd fersiwn newydd o werf yn cael ei rhyddhau neu fod bachyn GitHub yn cael ei alw ar gyfer ymrwymiad adolygu, dim ond yr arteffact cyfatebol gyda'r fersiwn newydd sy'n cael ei ailadeiladu.
5. Nid oes angen meddwl am ddileu delweddau nas defnyddiwyd: bydd glanhau yn unol â pholisïau werff yn cadw trefn ar Gofrestrfa'r Docwyr.

Canfyddiadau

• Mae defnyddio werff yn caniatáu i'r cynulliad weithio'n gyflym oherwydd bod y cynulliad ei hun yn cael ei storio a'i gadw wrth weithio gyda storfeydd allanol.
• Mae gweithio gyda storfeydd Git allanol yn dileu'r angen i glonio'r ystorfa gyfan bob tro neu ailddyfeisio'r olwyn gyda rhesymeg optimeiddio anodd. Mae werf yn defnyddio storfa ac yn clonio unwaith yn unig, ac yna'n ei ddefnyddio fetch a dim ond pan fo angen.
• Y gallu i ddefnyddio templedi Go yn y ffeil ffurfweddu adeiladu werf.yaml yn eich galluogi i ddisgrifio gwasanaeth y mae ei ganlyniad yn dibynnu ar ddata allanol.
• Mae defnyddio mownt yn werff yn cyflymu'r casgliad o arteffactau yn sylweddol - oherwydd y storfa, sy'n gyffredin i bob piblinellau.
• Mae werf yn ei gwneud hi'n hawdd ffurfweddu glanhau, sy'n arbennig o bwysig wrth adeiladu'n ddeinamig.

PS

Darllenwch hefyd ar ein blog:

• «Rhedeg gorchmynion wrth gyflwyno datganiad cais 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