🥇Dynamísk samsetning og dreifing á Docker myndum með werf með því að nota dæmi um útfærða skjalasíðuna

Við höfum þegar talað um GitOps tólið okkar oftar en einu sinni. werf, og að þessu sinni viljum við deila reynslu okkar af því að setja saman síðuna með skjölum um verkefnið sjálft - werf.io (Rússneska útgáfan er en.werf.io). Þetta er venjuleg kyrrstæð síða, en samsetning hennar er áhugaverð að því leyti að hún er byggð með kraftmiklum fjölda gripa.

Farðu í blæbrigði vefsvæðisins: búa til sameiginlega valmynd fyrir allar útgáfur, síður með upplýsingum um útgáfur osfrv. - við munum ekki. Í staðinn skulum við einbeita okkur að vandamálum og eiginleikum kraftmikilla samsetningar og aðeins að meðfylgjandi CI/CD ferlum.

Inngangur: hvernig vefsíðan virkar

Til að byrja með eru werf skjöl geymd ásamt kóðanum. Þetta gerir ákveðnar kröfur um þróun sem eru almennt utan gildissviðs þessarar greinar, en að minnsta kosti má segja að:

Nýjar werf aðgerðir ætti ekki að gefa út án þess að uppfæra skjölin og öfugt, allar breytingar á skjölunum fela í sér útgáfu nýrrar útgáfu af werf;
Verkefnið hefur nokkuð mikla þróun: nýjar útgáfur geta verið gefnar út nokkrum sinnum á dag;
Allar handvirkar aðgerðir til að dreifa vefsvæði með nýrri útgáfu af skjölum eru að minnsta kosti leiðinlegar;
Verkefnið tekur upp merkingarfræðilega nálgun útgáfugerð, með 5 stöðugleikarásum. Útgáfuferlið felur í sér að útgáfur fara í röð í gegnum rásir í röð til að auka stöðugleika: frá alfa til steinsteypts;
Þessi síða er með rússnesku útgáfu sem „lifir og þróast“ (þ.e. innihald hennar er uppfært) samhliða aðalútgáfunni (þ.e. á ensku).

Til að fela allt þetta „innra eldhús“ fyrir notandanum, bjóða honum eitthvað sem „bara virkar“, gerðum við aðskilið werf uppsetningar- og uppfærslutól - Er multiwerf. Þú þarft bara að tilgreina útgáfunúmerið og stöðugleikarásina sem þú ert tilbúinn til að nota, og multiwerf mun athuga hvort það sé ný útgáfa á rásinni og hlaða henni niður ef þörf krefur.

Í útgáfu valmyndinni á vefsíðunni eru nýjustu útgáfur af werf fáanlegar á hverri rás. Sjálfgefið, eftir heimilisfangi werf.io/documentation útgáfan af stöðugustu rásinni fyrir nýjustu útgáfuna opnast - hún er einnig skráð af leitarvélum. Skjöl fyrir rásina eru fáanleg á sérstökum heimilisföngum (td. werf.io/v1.0-beta/documentation fyrir beta útgáfu 1.0).

Alls er síðan eftirfarandi útgáfur í boði:

root (opnast sjálfgefið),
fyrir hverja virka uppfærslurás hverrar útgáfu (til dæmis, werf.io/v1.0-beta).

Til að búa til ákveðna útgáfu af síðu er almennt nóg að setja hana saman með því að nota Jekyllmeð því að keyra í möppunni /docs werf repository samsvarandi skipun (jekyll build), eftir að hafa skipt yfir í Git merkið á nauðsynlegri útgáfu.

Það er aðeins eftir að bæta því við:

tólið sjálft (werf) er notað til samsetningar;
CI/CD ferlar eru byggðir á grundvelli GitLab CI;
og allt þetta keyrir auðvitað í Kubernetes.

verkefni

Nú skulum við móta verkefni sem taka tillit til allra lýstra sérstakra:

Eftir að hafa breytt werf útgáfunni á hvaða uppfærslurás sem er skjöl á síðunni ættu að vera sjálfkrafa uppfærð.
Til að þroskast þarftu að geta það stundum skoða forskoðunarútgáfur af síðunni.

Síðan verður að setja saman síðuna aftur eftir að búið er að breyta útgáfunni á hvaða rás sem er úr samsvarandi Git merkjum, en í því ferli að byggja myndina munum við fá eftirfarandi eiginleika:

Þar sem listi yfir útgáfur á rásum breytist er aðeins nauðsynlegt að endurbyggja skjölin fyrir rásir þar sem útgáfan hefur breyst. Enda er ekki mjög sniðugt að endurbyggja allt aftur.
Rásir fyrir útgáfur geta breyst. Á einhverjum tímapunkti, til dæmis, getur verið að það sé ekki útgáfa á rásunum sem er stöðugri en 1.1 útgáfan með snemma aðgangi, en með tímanum munu þær birtast - í þessu tilfelli, ættirðu ekki að breyta samsetningunni handvirkt?

Það kemur í ljós að samsetning er háð því að breyta ytri gögnum.

Framkvæmd

Að velja nálgun

Að öðrum kosti geturðu keyrt hverja nauðsynlega útgáfu sem sérstakan hólf í Kubernetes. Þessi valkostur felur í sér meiri fjölda hluta í þyrpingunni, sem mun stækka með aukningu á fjölda stöðugra werf losunar. Og þetta, aftur á móti, felur í sér flóknara viðhald: hver útgáfa hefur sinn HTTP netþjón og með lítið álag. Þetta hefur auðvitað líka í för með sér meiri auðlindakostnað.

Við fórum sömu leið að setja saman allar nauðsynlegar útgáfur í einni mynd. Samanlögð tölfræði allra útgáfa af síðunni er staðsett í gámi með NGINX og umferð til samsvarandi dreifingar kemur í gegnum NGINX Ingress. Einföld uppbygging - ríkisfangslaust forrit - gerir þér kleift að skala dreifingu auðveldlega (fer eftir álagi) með því að nota Kubernetes sjálft.

Til að vera nákvæmari, þá erum við að safna tveimur myndum: önnur fyrir framleiðslurásina, önnur er viðbótarmynd fyrir þróunarrásina. Viðbótarmyndin er aðeins notuð (ræst) á þróunarrásinni ásamt þeirri aðal og inniheldur útgáfu síðunnar frá endurskoðunarboðinu og leið á milli þeirra er framkvæmd með Ingress auðlindum.

werf vs git klón og artifacts

Eins og áður hefur verið nefnt, til þess að búa til truflanir á vefsvæðinu fyrir tiltekna útgáfu af skjölunum, þarftu að byggja með því að skipta yfir í viðeigandi geymslumerki. Þú gætir líka gert þetta með því að klóna geymsluna í hvert skipti sem þú byggir, velja viðeigandi merki af lista. Hins vegar er þetta frekar fjármagnsfrek aðgerð og krefst þess að auki að skrifa ekki léttvægar leiðbeiningar... Annar alvarlegur ókostur er að með þessari nálgun er engin leið að skyndima eitthvað við samsetningu.

Hér kemur werfveitan sjálf okkur til hjálpar, framkvæmd snjall skyndiminni og leyfa þér að nota ytri geymslur. Að nota werf til að bæta við kóða úr geymslunni mun flýta verulega fyrir byggingu, vegna þess að werf klónar í rauninni geymsluna einu sinni og keyrir síðan aðeins fetch ef nauðsynlegt er. Að auki, þegar við bætum við gögnum úr geymslunni, getum við aðeins valið nauðsynlegar möppur (í okkar tilfelli er þetta skráin docs), sem mun draga verulega úr magni bættra gagna.

Þar sem Jekyll er tól hannað til að safna saman kyrrstæðum gögnum og er ekki þörf á lokamyndinni, væri rökrétt að safna saman í werf gripur, og inn í lokamyndina flyttu aðeins inn niðurstöðuna úr samantektinni.

Við skrifum werf.yaml

Svo ákváðum við að setja saman hverja útgáfu í sérstökum werf gripi. Hins vegar við við vitum ekki hversu margir af þessum gripum verða við samsetningu, þannig að við getum ekki skrifað fasta smíðastillingu (strangt til tekið, við getum það enn, en það mun ekki vera alveg skilvirkt).

werf gerir þér kleift að nota Farðu sniðmát í stillingarskránni þinni (werf.yaml), og þetta gerir það mögulegt búa til stillingar á flugu eftir ytri gögnum (það sem þú þarft!). Ytri gögn í okkar tilviki eru upplýsingar um útgáfur og útgáfur, á grundvelli þeirra söfnum við nauðsynlegum fjölda gripa og þar af leiðandi fáum við tvær myndir: werf-doc и werf-dev að keyra á mismunandi hringrásum.

Ytri gögn eru send í gegnum umhverfisbreytur. Hér er samsetning þeirra:

RELEASES — lína með lista yfir útgáfur og samsvarandi núverandi útgáfu af werf, í formi gildislista með bili á sniðinu <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Dæmi: 1.0%v1.0.4-beta.20
CHANNELS — lína með lista yfir rásir og samsvarandi núverandi útgáfu af werf, í formi gildislista með bili á sniði <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Dæmi: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — werf útgáfuútgáfa sem birtist sjálfgefið á síðunni (það er ekki alltaf nauðsynlegt að sýna skjöl með hæsta útgáfunúmerinu). Dæmi: v1.0.4-beta.20
REVIEW_SHA — kjötkássa af endurskoðunarframkvæmdinni sem þú þarft að búa til útgáfuna fyrir prófunarlykkjuna.

Þessar breytur verða fylltar út í GitLab CI leiðsluna og hvernig nákvæmlega er skrifað hér að neðan.

Fyrst af öllu, til hægðarauka, skilgreinum við inn werf.yaml Farðu í sniðmátsbreytur, gefðu þeim gildi úr umhverfisbreytum:

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

Lýsingin á gripnum til að setja saman kyrrstæðu útgáfu vefsvæðisins er almennt sú sama fyrir öll tilvik sem við þurfum (þar á meðal að búa til rótarútgáfuna, sem og útgáfuna fyrir þróunarrásina). Þess vegna munum við færa það í sérstakan blokk með því að nota aðgerðina define - til síðari endurnotkunar include. Við munum senda eftirfarandi rök til sniðmátsins:

Version — mynduð útgáfa (heiti merkis);
Channel — heiti uppfærslurásarinnar sem gripurinn er búinn til fyrir;
Commit — commit hash, ef gripurinn er myndaður fyrir endurskoðunarframkvæmd;
samhengi.

Artifact Sniðmát Lýsing

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

Heiti griparins verður að vera einstakt. Við getum náð þessu, til dæmis með því að bæta við heiti rásarinnar (gildi breytunnar .Channel) sem viðskeyti við nafn gripsins: artifact: doc-{{ .Channel }}. En þú þarft að skilja að þegar þú flytur inn úr gripum þarftu að vísa í sömu nöfn.

Þegar gripi er lýst er eftirfarandi werf eiginleiki notaður: uppsetningu. Uppsetning sem gefur til kynna þjónustuskrána build_dir gerir þér kleift að vista Jekyll skyndiminni á milli leiðslukeyrslu, sem flýtir verulega fyrir endursamsetningu.

Þú gætir líka hafa tekið eftir notkun skráarinnar releases.yml er YAML skrá með útgáfugögnum sem óskað er eftir Github.com (gripur sem fæst þegar leiðsla er framkvæmd). Það er nauðsynlegt þegar þú setur síðuna saman, en í samhengi við greinina er það áhugavert fyrir okkur vegna þess að það fer eftir ástandi hennar endursamsetning á aðeins einum gripi — gripur af rótarútgáfu síðunnar (hann er ekki nauðsynlegur í öðrum gripum).

Þetta er útfært með því að nota skilyrtu yfirlýsinguna if Farðu í sniðmát og hönnun {{ $Root.Files.Get "releases.yml" | sha256sum }} á sviðinu stigum. Það virkar sem hér segir: þegar búið er að byggja grip fyrir rótarútgáfuna (breytu .Channel er jafn root) skráarhash releases.yml hefur áhrif á undirskrift alls stigsins, þar sem það er hluti af nafni Ansible verkefnisins (breytu name). Svona þegar verið er að breyta efni skrá releases.yml samsvarandi gripur verður settur saman aftur.

Vinsamlegast athugaðu líka að vinna með ytri geymslu. Í mynd af gripi frá werf geymsla, aðeins skránni er bætt við /docs, og allt eftir samþykktum færibreytum er gögnum um nauðsynlega merkimiða eða endurskoðunarskuld bætt við strax.

Til að nota artifact sniðmátið til að búa til lýsingu á artifact af fluttum útgáfum af rásum og útgáfum, skipuleggjum við lykkju um breytuna .WerfVersions в werf.yaml:

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

Vegna þess að lykkjan mun búa til nokkra gripi (við vonum það), það er nauðsynlegt að taka tillit til skilju á milli þeirra - röð --- (Nánari upplýsingar um setningafræði stillingarskráa er að finna í skjöl). Eins og áður var skilgreint, þegar hringt er í sniðmát í lykkju, sendum við færibreyturnar útgáfu, vefslóð og rótarsamhengi.

Á sama hátt, en án lykkju, köllum við artifact sniðmátið fyrir „sértilvik“: fyrir rótarútgáfuna, sem og útgáfuna frá endurskoðunarskuldbindingunni:

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

Vinsamlegast athugaðu að gripurinn fyrir endurskoðunarskuldbindinguna verður aðeins byggður ef breytan er stillt .WerfReviewCommit.

Munirnir eru tilbúnir - það er kominn tími til að hefja innflutning!

Lokamyndin, hönnuð til að keyra á Kubernetes, er venjulegur NGINX með stillingarskrá miðlara bætt við nginx.conf og truflanir frá gripum. Til viðbótar við gripinn af rótarútgáfu síðunnar þurfum við að endurtaka lykkjuna á breytunni .WerfVersions til að flytja inn gripi af rás- og útgáfuútgáfum + fylgdu nafngiftareglunni sem við tókum upp áðan. Þar sem hver gripur geymir útgáfur af síðunni fyrir tvö tungumál flytjum við þær inn á staðina sem uppsetningin gefur upp.

Lýsing á endanlegri mynd 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 -}}

Viðbótarmyndin, sem, ásamt þeirri aðal, er hleypt af stokkunum á þróunarrásinni, inniheldur aðeins tvær útgáfur af síðunni: útgáfuna frá endurskoðunarboðinu og rótarútgáfan af síðunni (það eru almennar eignir og, ef þú manst , gefa út gögn). Þannig mun viðbótarmyndin aðeins vera frábrugðin þeirri aðal í innflutningshlutanum (og auðvitað í nafninu):

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

Eins og fram kemur hér að ofan, mun gripurinn fyrir endurskoðunarskuldbindinguna aðeins myndast þegar stillta umhverfisbreytan er keyrð REVIEW_SHA. Það væri alls ekki hægt að búa til werf-dev myndina ef það er engin umhverfisbreyta REVIEW_SHA, en til þess hreinsun eftir stefnu Docker myndir í werf virkuðu fyrir werf-dev myndina, við munum láta hana byggja aðeins með rótarútgáfu artifact (hann er nú þegar byggður samt), til að einfalda leiðslu uppbyggingu.

Samkoman er tilbúin! Höldum áfram að CI/CD og mikilvægum blæbrigðum.

Leiðsla í GitLab CI og eiginleikar kraftmikillar byggingu

Þegar þú keyrir bygginguna þurfum við að stilla umhverfisbreyturnar sem notaðar eru í werf.yaml. Þetta á ekki við um REVIEW_SHA breytuna, sem við munum stilla þegar hringt er í leiðslu frá GitHub króknum.

Við munum búa til nauðsynleg ytri gögn í Bash handriti generate_artifacts, sem mun búa til tvo GitLab leiðslugripi:

файл releases.yml með útgáfugögnum,
файл common_envs.sh, sem inniheldur umhverfisbreyturnar sem á að flytja út.

Innihald skráar generate_artifacts þú finnur í okkar geymslur með dæmum. Að fá gögnin sjálf er ekki efni greinarinnar, heldur skráin common_envs.sh er mikilvægt fyrir okkur, vegna þess starf werf fer eftir því. Dæmi um innihald þess:

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'

Þú getur notað úttak slíkrar forskriftar, til dæmis með því að nota Bash aðgerðina source.

Nú kemur skemmtilegi þátturinn. Til þess að bæði smíði og uppsetning forritsins virki rétt er nauðsynlegt að tryggja það werf.yaml var það sama síst innan einni leiðslu. Ef þetta skilyrði er ekki uppfyllt, þá verða undirskriftir þrepanna sem werf reiknar við samsetningu og td dreifingu öðruvísi. Þetta mun leiða til dreifingarvillu vegna þess að... myndina sem þarf til dreifingar vantar.

Með öðrum orðum, ef upplýsingarnar um útgáfur og útgáfur eru þær sömu meðan á samsetningu síðumyndarinnar stendur, og þegar ný útgáfa er dreifing er gefin út og umhverfisbreyturnar hafa mismunandi gildi, þá mun uppsetningin mistakast með villu: enda hefur gripur nýju útgáfunnar ekki enn verið byggður.

Ef kynslóð werf.yaml fer eftir ytri gögnum (til dæmis lista yfir núverandi útgáfur, eins og í okkar tilviki), þá ætti að skrá samsetningu og gildi slíkra gagna innan leiðslunnar. Þetta er sérstaklega mikilvægt ef ytri breytur breytast nokkuð oft.

Við munum taka á móti og skrá ytri gögn á fyrsta stigi leiðslunnar í GitLab (Forsmíði) og sendu þær áfram í formi GitLab CI artifact. Þetta gerir þér kleift að keyra og endurræsa leiðsluverk (smíða, dreifa, hreinsa) með sömu uppsetningu í werf.yaml.

Innihald sviðsins Forsmíði skrá .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

Eftir að hafa tekið ytri gögnin í gripnum geturðu smíðað og sett í notkun með því að nota staðlaða GitLab CI leiðsluþrepin: Byggja og dreifa. Við ræsum leiðsluna sjálfa með því að nota króka frá werf GitHub geymslunni (þ.e. þegar breytingar eru á GitHub geymslunni). Gögn fyrir þá er að finna í GitLab verkefniseiginleikum í kaflanum CI/CD Stillingar -> Pipeline triggers, og búðu síðan til samsvarandi Webhook í GitHub (Stillingar -> Webhooks).

Byggingarstigið mun líta svona út:

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 mun bæta tveimur gripum frá sviðinu við byggingarstigið Forsmíði, þannig að við flytjum út breytur með tilbúnum inntaksgögnum með því að nota smíðina source common_envs.sh. Við hefjum byggingarstigið í öllum tilfellum, nema að ræsa lögnina samkvæmt áætlun. Samkvæmt áætlun munum við keyra leiðslu fyrir hreinsun - í þessu tilfelli er engin þörf á að framkvæma samsetningu.

Á dreifingarstigi munum við lýsa tveimur verkefnum - sérstaklega fyrir dreifingu í framleiðslu- og þróunarrásir, með því að nota YAML sniðmát:

.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

Verkefnin eru í meginatriðum aðeins ólík þegar kemur að því að gefa til kynna klasasamhengið sem werf ætti að framkvæma dreifinguna í (WERF_KUBE_CONTEXT), og stillir lykkjuumhverfisbreyturnar (environment.name и environment.url), sem síðan eru notuð í Helm grafsniðmátum. Við munum ekki veita innihald sniðmátanna, vegna þess að... það er ekkert áhugavert þarna um viðkomandi efni, en þú getur fundið þau í geymslum fyrir greinina.

Final snerta

Þar sem werf útgáfur eru gefnar út nokkuð oft verða nýjar myndir byggðar oft og Docker Registry mun stöðugt stækka. Þess vegna er mikilvægt að stilla sjálfvirka myndhreinsun út frá stefnum. Það er mjög auðvelt að gera það.

Til að hrinda í framkvæmd þarftu:

Bættu hreinsunarskref við .gitlab-ci.yml;
Bættu við reglubundinni framkvæmd hreinsunarverkefnis;
Settu upp umhverfisbreytu með skrifaðgangslykil.

Bætir hreinsunarstigi við .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

Við höfum nú þegar séð næstum allt þetta aðeins hærra - aðeins til að þrífa það þarftu fyrst að skrá þig inn á Docker Registry með tákni sem hefur réttindi til að eyða myndum í Docker Registry (sjálfkrafa útgefinn GitLab CI verkefnalykill gerir það ekki hafa slík réttindi). Táknið verður að búa til í GitLab fyrirfram og gildi þess verður að vera tilgreint í umhverfisbreytunni WERF_IMAGES_CLEANUP_PASSWORD verkefnið (CI/CD Stillingar -> Breytur).

Að bæta við hreinsunarverkefni með nauðsynlegri áætlun er gert í CI/CD ->
Áætlanir.

Það er það: verkefni í Docker Registry mun ekki lengur vaxa stöðugt úr ónotuðum myndum.

Í lok verklega hlutans, vil ég minna þig á að allar skráningar úr greininni eru fáanlegar í fara:

Niðurstaðan

Við fengum rökrétta samsetningarbyggingu: einn grip í hverri útgáfu.
Samsetningin er alhliða og þarfnast ekki handvirkra breytinga þegar nýjar útgáfur af werf eru gefnar út: skjölin á vefsíðunni eru sjálfkrafa uppfærð.
Tvær myndir eru settar saman fyrir mismunandi útlínur.
Það virkar fljótt, því Skyndiminni er notað eins mikið og mögulegt er - þegar ný útgáfa af werf er gefin út eða GitHub krókur er kallaður fyrir endurskoðunarframkvæmd, er aðeins samsvarandi gripur með breyttri útgáfu endurbyggður.
Engin þörf á að hugsa um að eyða ónotuðum myndum: hreinsun samkvæmt reglum werf mun halda Docker Registry í lagi.

Niðurstöður

Notkun werf gerir samsetningunni kleift að vinna hratt vegna skyndiminni bæði samstæðunnar sjálfrar og skyndiminni þegar unnið er með ytri geymslum.
Að vinna með ytri Git geymslum útilokar þörfina á að klóna alla geymsluna í hvert sinn eða finna upp hjólið aftur með erfiðri hagræðingarrökfræði. werf notar skyndiminni og gerir klónunina aðeins einu sinni og notar síðan fetch og aðeins þegar þörf krefur.
Geta til að nota Go sniðmát í uppsetningarskránni werf.yaml gerir þér kleift að lýsa samsetningu þar sem niðurstaðan er háð ytri gögnum.
Notkun mount í werf flýtir verulega fyrir söfnun gripa - vegna skyndiminni, sem er sameiginlegt fyrir allar leiðslur.
werf gerir það auðvelt að stilla hreinsun, sem er sérstaklega mikilvægt þegar smíðað er kraftmikið.