🥇Dynamic nga asembliya ug pag-deploy sa mga imahe sa Docker nga adunay werf gamit ang panig-ingnan sa usa ka bersyon nga site sa dokumentasyon

Nahisgotan na namo ang bahin sa among tool sa GitOps labaw sa kausa. werf, ug niining higayona gusto namong ipaambit ang among kasinatian sa pag-assemble sa site gamit ang dokumentasyon sa proyekto mismo - werf.io (ang Russian nga bersyon niini en.werf.io). Kini usa ka ordinaryo nga static nga site, apan ang asembliya niini makapaikag tungod kay kini gitukod gamit ang usa ka dinamikong gidaghanon sa mga artifact.

Lakaw ngadto sa mga nuances sa gambalay sa site: paghimo sa usa ka komon nga menu alang sa tanan nga mga bersyon, mga panid uban sa impormasyon mahitungod sa pagpagawas, etc. - dili kita. Hinunoa, atong ipunting ang mga isyu ug mga bahin sa dinamikong asembliya ug gamay sa nag-uban nga mga proseso sa CI/CD.

Pasiuna: kung giunsa ang site molihok

Sa pagsugod, ang dokumentasyon sa werf gitipigan kauban ang code niini. Nagpahamtang kini og piho nga mga kinahanglanon sa pag-uswag nga sa kasagaran lapas sa kasangkaran niini nga artikulo, apan sa labing gamay maingon nga:

Ang mga bag-ong function sa werf kinahanglan dili ipagawas nga wala’y pag-update sa dokumentasyon ug, sukwahi, ang bisan unsang mga pagbag-o sa dokumentasyon nagpasabut sa pagpagawas sa usa ka bag-ong bersyon sa werf;
Ang proyekto adunay usa ka medyo intensive development: bag-ong mga bersyon mahimong buhian sa pipila ka mga higayon sa usa ka adlaw;
Ang bisan unsang manual nga mga operasyon sa pag-deploy sa usa ka site nga adunay bag-ong bersyon sa dokumentasyon labing menos makakapoy;
Ang proyekto nagsagop sa usa ka semantiko nga pamaagi pag-bersiyon, nga adunay 5 ka stability channels. Ang proseso sa pagpagawas naglakip sa sequential passage sa mga bersyon pinaagi sa mga channel aron sa pagdugang sa kalig-on: gikan sa alpha ngadto sa rock-solid;
Ang site adunay bersyon sa Russian nga pinulongan, nga "nagkinabuhi ug nag-uswag" (i.e., ang sulod niini gi-update) nga susama sa main (ie, English-language) nga bersyon.

Aron itago kining tanan nga "sulod nga kusina" gikan sa tiggamit, nga nagtanyag kaniya og usa ka butang nga "nagtrabaho lang", among gibuhat bulag nga pag-install ug pag-update nga himan sa werf Mao ba multiwerf. Kinahanglan ra nimo nga ipiho ang numero sa pagpagawas ug ang channel sa kalig-on nga andam nimong gamiton, ug susihon sa multiwerf kung adunay bag-ong bersyon sa channel ug i-download kini kung kinahanglan.

Sa menu sa pagpili sa bersyon sa website, ang pinakabag-o nga bersyon sa werf anaa sa matag channel. Pinaagi sa default, pinaagi sa adres werf.io/documentation ang bersyon sa labing lig-on nga channel alang sa pinakabag-o nga pagpagawas gibuksan - kini usab gi-index sa mga search engine. Ang dokumentasyon para sa channel anaa sa bulag nga mga adres (pananglitan, werf.io/v1.0-beta/documentation alang sa beta release 1.0).

Sa kinatibuk-an, ang site adunay mga mosunod nga bersyon nga magamit:

gamut (nag-abli pinaagi sa default),
alang sa matag aktibo nga channel sa pag-update sa matag pagpagawas (pananglitan, werf.io/v1.0-beta).

Aron makamugna og usa ka piho nga bersyon sa usa ka site, sa kinatibuk-an, igo na ang pag-compile niini gamit Jekyllpinaagi sa pagdagan sa direktoryo /docs werf repository nga katugbang nga sugo (jekyll build), human sa pagbalhin ngadto sa Git tag sa gikinahanglan nga bersyon.

Nagpabilin lamang nga idugang kana:

ang utility mismo (werf) gigamit alang sa asembliya;
Ang mga proseso sa CI/CD gitukod base sa GitLab CI;
ug kining tanan, siyempre, nagdagan sa Kubernetes.

buluhaton

Karon maghimo kita og mga buluhaton nga gikonsiderar ang tanan nga gihulagway nga mga detalye:

Human sa pag-usab sa werf nga bersyon sa bisan unsa nga update channel Ang dokumentasyon sa site kinahanglan nga awtomatiko nga ma-update.
Alang sa kalamboan kinahanglan nimo nga makahimo usahay tan-awa ang preview nga mga bersyon sa site.

Ang site kinahanglan nga i-recompile human mabag-o ang bersyon sa bisan unsang channel gikan sa katugbang nga mga tag sa Git, apan sa proseso sa pagtukod sa imahe makuha namon ang mga musunud nga bahin:

Tungod kay ang lista sa mga bersyon sa mga channel nagbag-o, gikinahanglan lamang ang pagtukod pag-usab sa dokumentasyon alang sa mga channel diin ang bersyon nausab. Human sa tanan, ang pagtukod pag-usab sa tanan dili kaayo nindot.
Ang hugpong sa mga channel alang sa mga pagpagawas mahimong mausab. Sa pila ka punto sa panahon, pananglitan, mahimo’g wala’y bersyon sa mga kanal nga mas lig-on kaysa sa sayo nga pag-access sa 1.1 nga pagpagawas, apan sa paglabay sa panahon kini makita - sa kini nga kaso, dili ba nimo usbon ang asembliya nga mano-mano?

Nahitabo kana Ang asembliya nagdepende sa pagbag-o sa eksternal nga datos.

Pagpatuman

Pagpili ug Pamaagi

Sa laing bahin, mahimo nimong ipadagan ang matag gikinahanglan nga bersyon isip bulag nga pod sa Kubernetes. Kini nga kapilian nagpasabot sa usa ka mas dako nga gidaghanon sa mga butang sa cluster, nga motubo uban sa pagdugang sa gidaghanon sa mga stable werf releases. Ug kini, sa baylo, nagpasabut nga labi ka komplikado nga pagpadayon: ang matag bersyon adunay kaugalingon nga HTTP server, ug adunay gamay nga karga. Siyempre, nagkinahanglan usab kini og mas dako nga gasto sa kahinguhaan.

Parehas mig dalan pag-assemble sa tanang gikinahanglan nga mga bersyon sa usa ka hulagway. Ang natipon nga estadistika sa tanang bersiyon sa site nahimutang sa usa ka sudlanan nga adunay NGINX, ug ang trapiko sa katugbang nga Deployment moabut pinaagi sa NGINX Ingress. Usa ka yano nga istruktura - usa ka stateless nga aplikasyon - nagtugot kanimo nga dali nga ma-scale ang Deployment (depende sa load) gamit ang Kubernetes mismo.

Aron mahimong mas tukma, nagkolekta kami og duha ka mga imahe: ang usa alang sa production circuit, ang ikaduha usa ka dugang alang sa dev circuit. Ang dugang nga imahe gigamit (gilunsad) lamang sa dev circuit kauban ang nag-unang usa ug naglangkob sa bersyon sa site gikan sa review commit, ug ang routing tali kanila gihimo gamit ang Ingress resources.

werf vs git clone ug artifacts

Sama sa nahisgotan na, aron makamugna og mga estadistika sa site alang sa usa ka piho nga bersyon sa dokumentasyon, kinahanglan nimo nga magtukod pinaagi sa pagbalhin sa angay nga tag sa repository. Mahimo usab nimo kini pinaagi sa pag-clone sa repository matag higayon nga magtukod ka, pagpili sa angay nga mga tag gikan sa usa ka lista. Apan, kini mao ang usa ka hinoon resource-intensive nga operasyon ug, dugang pa, nagkinahanglan sa pagsulat non-trivial nga mga instruksyon... Laing seryoso nga disbentaha mao nga uban niini nga paagi walay paagi sa cache sa usa ka butang sa panahon sa asembliya.

Dinhi ang werf utility mismo moabut sa among pagtabang, pagpatuman smart caching ug nagtugot kanimo sa paggamit gawas nga mga repositoryo. Ang paggamit sa werf aron idugang ang code gikan sa repository makapadali sa pagtukod, tungod kay Ang werf sa tinuud nag-clone sa repository kausa ug dayon gipatuman lamang fetch kung kinahanglan. Dugang pa, kung magdugang mga datos gikan sa repository, mahimo ra naton mapili ang kinahanglan nga mga direktoryo (sa among kaso kini ang direktoryo docs), nga makapakunhod pag-ayo sa gidaghanon sa gidugang nga datos.

Tungod kay ang Jekyll usa ka himan nga gidisenyo alang sa pag-compile sa static nga datos ug wala kinahanglana sa katapusan nga imahe, makatarunganon nga i-compile sa werf artifact, ug ngadto sa kataposang hulagway import lang ang resulta sa compilation.

Gisulat namon ang werf.yaml

Mao nga, nakahukom kami nga among i-compile ang matag bersyon sa usa ka lahi nga artifact sa werf. Hinuon kami wala kita mahibalo kon pila niini nga mga artifact ang anaa sa panahon sa asembliya, mao nga dili kami makasulat sa usa ka fixed build configuration (estrikto nga pagsulti, mahimo gihapon namo, apan dili kini hingpit nga epektibo).

werf nagtugot kanimo sa paggamit Lakaw sa mga templates sa imong configuration file (werf.yaml), ug kini nagpaposible niini makamugna og config sa langaw depende sa external data (unsay imong gikinahanglan!). Ang gawas nga datos sa among kaso mao ang kasayuran bahin sa mga bersyon ug pagpagawas, nga gibase sa among pagkolekta sa gikinahanglan nga gidaghanon sa mga artifact ug ingon usa ka sangputanan nakakuha kami duha nga mga imahe: werf-doc и werf-dev sa pagdagan sa lain-laing mga sirkito.

Ang eksternal nga datos gipasa pinaagi sa mga variable sa palibot. Ania ang ilang komposisyon:

RELEASES — usa ka linya nga adunay usa ka lista sa mga pagpagawas ug ang katugbang nga karon nga bersyon sa werf, sa porma sa usa ka lista sa mga kantidad nga gibulag sa wanang sa format <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Usa ka pananglitan: 1.0%v1.0.4-beta.20
CHANNELS - usa ka linya nga adunay usa ka lista sa mga kanal ug ang katugbang nga karon nga bersyon sa werf, sa porma sa usa ka lista sa mga kantidad nga gibulag sa wanang sa format <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Usa ka pananglitan: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — Werf release nga bersyon nga ipakita sa default sa site (dili kanunay kinahanglan nga ipakita ang dokumentasyon sa pinakataas nga release number). Pananglitan: v1.0.4-beta.20
REVIEW_SHA - hash sa review commit diin kinahanglan nimo nga tukuron ang bersyon para sa test loop.

Kini nga mga baryable mapuno sa GitLab CI pipeline, ug sa unsang paagi tukma ang pagkasulat sa ubos.

Una sa tanan, alang sa kasayon, atong gihubit sa werf.yaml Lakaw ang mga variable sa template, paghatag kanila og mga kantidad gikan sa mga variable sa palibot:

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

Ang paghulagway sa artifact alang sa pag-compile sa static nga bersyon sa site sa kasagaran parehas alang sa tanan nga mga kaso nga kinahanglan namon (lakip ang paghimo sa gamut nga bersyon, ingon man ang bersyon alang sa dev circuit). Busa, atong ibalhin kini sa usa ka bulag nga bloke gamit ang function define - para sa sunod nga paggamit pag-usab include. Atong ipasa ang mosunod nga mga argumento ngadto sa template:

Version - namugna nga bersyon (tag name);
Channel - ang ngalan sa update channel diin ang artifact gihimo;
Commit — commit hash, kung ang artifact gihimo para sa usa ka review commit;
konteksto.

Deskripsyon sa Template sa 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 }}

Ang ngalan sa artifact kinahanglan nga talagsaon. Mahimo naton kini, pananglitan, pinaagi sa pagdugang sa ngalan sa channel (ang kantidad sa variable .Channel) isip suffix sa ngalan sa artifact: artifact: doc-{{ .Channel }}. Apan kinahanglan nimong masabtan nga kung mag-import gikan sa mga artifact, kinahanglan nimo nga i-refer ang parehas nga mga ngalan.

Kung naghulagway sa usa ka artifact, ang mosunod nga werf feature gigamit: pagpataas. Pag-mount nga nagpakita sa direktoryo sa serbisyo build_dir nagtugot kanimo sa pagluwas sa Jekyll cache tali sa pipeline run, nga kamahinungdanon pagpadali sa reassembly.

Tingali nakamatikod ka usab sa paggamit sa file releases.yml usa ka YAML file nga adunay gihangyo nga datos sa pagpagawas Github.com (usa ka artifact nga nakuha sa dihang nagpatuman sa usa ka pipeline). Gikinahanglan kini sa pag-compile sa site, apan sa konteksto sa artikulo kini makapainteres kanato tungod kay kini nagdepende sa estado niini reassembly sa usa lang ka artifact — usa ka artifact sa gamut nga bersyon sa site (wala kini kinahanglan sa ubang mga artifact).

Gipatuman kini gamit ang conditional statement if Lakaw sa mga templates ug mga disenyo {{ $Root.Files.Get "releases.yml" | sha256sum }} sa entablado mga yugto. Naglihok kini sama sa mosunod: kung nagtukod usa ka artifact alang sa bersyon sa gamut (variable .Channel parehas sa root) file hash releases.yml makaapekto sa pirma sa tibuok nga yugto, tungod kay kini kabahin sa ngalan sa Ansible nga buluhaton (parameter name). Busa, sa dihang nagbag-o sulod file releases.yml ang katugbang nga artifact pagatigumon pag-usab.

Palihug hatagi usab ug pagtagad ang pagtrabaho sa usa ka eksternal nga tipiganan. Sa hulagway sa usa ka artifact gikan sa werf repository, ang direktoryo ra ang gidugang /docs, ug depende sa gipasa nga mga parameter, ang datos sa gikinahanglan nga tag o review commit idugang dayon.

Aron magamit ang template sa artifact aron makamugna usa ka paghulagway sa artifact sa gibalhin nga mga bersyon sa mga channel ug pagpagawas, nag-organisar kami usa ka loop sa variable .WerfVersions в werf.yaml:

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

Kay ang loop makamugna og daghang mga artifact (naglaum kami nga), kinahanglan nga tagdon ang separator tali kanila - ang pagkasunod-sunod --- (Alang sa dugang nga impormasyon sa configuration file syntax, tan-awa dokumentasyon). Sama sa gipasabut sa sayo pa, kung nagtawag sa usa ka template sa usa ka loop, gipasa namon ang mga parameter sa bersyon, URL ug konteksto sa gamut.

Sa susama, apan walay loop, among gitawag ang artifact template para sa "espesyal nga mga kaso": alang sa gamut nga bersyon, ingon man ang bersyon gikan sa review commit:

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

Palihug timan-i nga ang artifact para sa review commit pagatukoron lang kung ang variable gitakda .WerfReviewCommit.

Andam na ang mga artifact - panahon na nga magsugod sa pag-import!

Ang katapusan nga imahe, nga gidisenyo nga modagan sa Kubernetes, usa ka regular nga NGINX nga adunay gidugang nga file sa configuration sa server nginx.conf ug static gikan sa mga artifact. Dugang pa sa artifact sa gamut nga bersyon sa site, kinahanglan namon nga balikon ang loop sa variable .WerfVersions sa pag-import sa mga artifact sa channel ug pagpagawas sa mga bersyon + sunda ang lagda sa pagngalan sa artifact nga among gisagop sa sayo pa. Tungod kay ang matag artifact nagtipig sa mga bersyon sa site alang sa duha ka mga pinulongan, among gi-import kini sa mga lugar nga gihatag sa configuration.

Deskripsyon sa katapusang imahen 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 -}}

Ang dugang nga imahe, nga, kauban ang panguna, gilansad sa dev circuit, adunay duha ra nga bersyon sa site: ang bersyon gikan sa commit sa pagsusi ug ang gamut nga bersyon sa site (adunay mga kinatibuk-ang kabtangan ug, kung nahinumduman nimo , pagpagawas sa datos). Sa ingon, ang dugang nga imahe magkalainlain gikan sa panguna sa seksyon sa import (ug, siyempre, sa ngalan):

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

Sama sa nahisgotan na sa ibabaw, ang artifact para sa review commit mabuhat lamang kung ang set environment variable gipadagan REVIEW_SHA. Posible nga dili makamugna ang imahe sa werf-dev kung wala’y variable sa palibot REVIEW_SHA, apan aron paglimpyo pinaagi sa mga palisiya Ang mga imahe sa Docker sa werf nagtrabaho alang sa werf-dev nga imahe, ibilin namon kini nga matukod lamang gamit ang artifact nga bersyon sa ugat (gihimo na kini), aron mapasimple ang istruktura sa pipeline.

Andam na ang asembliya! Mopadayon kita sa CI/CD ug importanteng mga nuances.

Pipeline sa GitLab CI ug mga bahin sa dinamikong pagtukod

Kung gipadagan ang pagtukod kinahanglan namon nga itakda ang mga variable sa palibot nga gigamit sa werf.yaml. Dili kini magamit sa REVIEW_SHA variable, nga among itakda sa pagtawag sa pipeline gikan sa GitHub hook.

Maghimo kami sa gikinahanglan nga external data sa usa ka Bash script generate_artifacts, nga makamugna og duha ka GitLab pipeline artifacts:

file releases.yml uban ang datos sa pagpagawas,
file common_envs.sh, nga adunay sulod nga mga variable sa palibot nga i-eksport.

Mga sulod sa file generate_artifacts imong makit-an sa among mga repositoryo nga adunay mga pananglitan. Ang pagdawat sa datos mismo dili ang hilisgutan sa artikulo, apan ang file common_envs.sh importante kanato, tungod kay ang buhat sa werf nagdepende niini. Usa ka pananglitan sa sulod niini:

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'

Mahimo nimong gamiton ang output sa ingon nga script, pananglitan, gamit ang Bash function source.

Karon moabut ang makalingaw nga bahin. Aron ang pagtukod ug pag-deploy sa aplikasyon molihok sa husto, kinahanglan nga masiguro kana werf.yaml maoy parehas labing gamay sulod sa usa ka pipeline. Kung kini nga kondisyon dili matuman, nan ang mga pirma sa mga yugto nga gikalkula sa werf sa panahon sa asembliya ug, pananglitan, ang pag-deploy, magkalainlain. Motultol kini sa usa ka sayup sa pag-deploy, tungod kay ... ang imahe nga gikinahanglan alang sa pag-deploy mawala.

Sa laing pagkasulti, kung sa panahon sa asembliya sa imahe sa site parehas ang kasayuran bahin sa mga pagpagawas ug mga bersyon, ug sa panahon sa pag-deploy usa ka bag-ong bersyon ang gipagawas ug ang mga variable sa palibot adunay lainlaing mga kantidad, nan ang pag-deploy mapakyas sa usa ka sayup: human sa tanan, ang artifact sa bag-ong bersyon wala pa matukod.

Kon henerasyon werf.yaml nagdepende sa eksternal nga datos (pananglitan, usa ka lista sa karon nga mga bersyon, sama sa among kaso), nan ang komposisyon ug mga kantidad sa ingon nga datos kinahanglan nga irekord sa sulod sa pipeline. Kini labi ka hinungdanon kung ang mga parameter sa gawas kanunay magbag-o.

Atong buhaton makadawat ug pagrekord sa eksternal nga datos sa unang yugto sa pipeline sa GitLab (Prebuild) ug ipadala pa kini sa porma GitLab CI artifact. Makatugot kini kanimo sa pagpadagan ug pagsugod pag-usab sa mga trabaho sa pipeline (pagtukod, pag-deploy, paglimpyo) nga adunay parehas nga pagsumpo sa werf.yaml.

Mga sulod sa entablado Prebuild file .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

Nakuha na ang eksternal nga datos sa artifact, mahimo kang magtukod ug mag-deploy gamit ang standard GitLab CI pipeline stages: Build and Deploy. Gilunsad namon ang pipeline mismo gamit ang mga kaw-it gikan sa werf GitHub repository (ie, kung adunay mga pagbag-o sa GitHub repository). Ang datos alang kanila makita sa mga kabtangan sa proyekto sa GitLab sa seksyon CI/CD Settings -> Pipeline triggers, ug dayon paghimo sa katugbang nga Webhook sa GitHub (Mga Setting -> Mga Webhook).

Ang yugto sa pagtukod mahimong ingon niini:

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

Ang GitLab magdugang og duha ka artifact gikan sa entablado ngadto sa entablado sa pagtukod Prebuild, mao nga gi-eksport namo ang mga variable nga adunay giandam nga data sa input gamit ang construct source common_envs.sh. Gisugdan namon ang yugto sa pagtukod sa tanan nga mga kaso, gawas sa paglansad sa pipeline sumala sa usa ka iskedyul. Sumala sa iskedyul, magpadagan kami usa ka pipeline alang sa paglimpyo - sa kini nga kaso dili kinahanglan nga himuon ang asembliya.

Sa yugto sa pag-deploy, among ihulagway ang duha ka buluhaton - gilain alang sa pag-deploy sa produksiyon ug mga dev circuit, gamit ang usa ka template sa 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

Ang mga buluhaton sa esensya lainlain lamang sa pagpaila sa konteksto sa cluster diin ang werf kinahanglan nga maghimo sa pag-deploy (WERF_KUBE_CONTEXT), ug pag-set sa loop environment variables (environment.name и environment.url), nga gigamit dayon sa mga template sa tsart sa Helm. Dili namo ihatag ang sulod sa mga templates, tungod kay... walay bisan unsa nga makapaikag didto alang sa hilisgutan sa pangutana, apan kamo makakaplag kanila sa repository alang sa artikulo.

katapusan nga paghikap

Tungod kay ang mga bersyon sa werf kanunay nga gipagawas, ang mga bag-ong imahe kanunay nga matukod, ug ang Docker Registry kanunay nga motubo. Busa, kinahanglan nga i-configure ang awtomatikong paglimpyo sa imahe base sa mga palisiya. Sayon ra kaayo buhaton.

Aron ipatuman kinahanglan nimo:

Pagdugang ug lakang sa pagpanglimpyo sa .gitlab-ci.yml;
Idugang ang regular nga pagpatuman sa buluhaton sa pagpanglimpyo;
Pagbutang ug environment variable nga naay write access token.

Pagdugang og yugto sa pagpanglimpyo sa .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

Nakita na namo ang halos tanan niini nga mas taas og gamay - aron lamang limpyohan kini kinahanglan nimo nga una nga mag-log in sa Docker Registry nga adunay usa ka token nga adunay katungod sa pagtangtang sa mga hulagway sa Docker Registry (ang awtomatik nga gi-isyu nga GitLab CI task token dili. adunay ingon nga mga katungod). Ang token kinahanglang himoon daan sa GitLab ug ang bili niini kinahanglang itakda sa environment variable WERF_IMAGES_CLEANUP_PASSWORD proyekto (Mga Setting sa CI/CD -> Mga Variable).

Ang pagdugang sa usa ka buluhaton sa pagpanglimpyo uban ang gikinahanglan nga eskedyul gihimo sa CI/CD ->
Mga Iskedyul.

Mao kana: ang usa ka proyekto sa Docker Registry dili na kanunay nga motubo gikan sa wala magamit nga mga imahe.

Sa pagtapos sa praktikal nga bahin, pahinumdoman ko ikaw nga ang tibuuk nga mga lista gikan sa artikulo magamit sa Git:

resulta

Nakadawat kami usa ka lohikal nga istruktura sa asembliya: usa ka artifact matag bersyon.
Ang asembliya kay unibersal ug wala magkinahanglan ug manwal nga mga pagbag-o kung ang mga bag-ong bersyon sa werf gipagawas: ang dokumentasyon sa website awtomatikong gi-update.
Duha ka mga imahe ang gitigum alang sa lainlaing mga contour.
Kini molihok dayon, tungod kay Ang pag-cache gigamit kutob sa mahimo - kung ang usa ka bag-ong bersyon sa werf gibuhian o ang usa ka GitHub hook gitawag alang sa usa ka review commit, ang katugbang nga artifact nga adunay giusab nga bersyon ang gitukod pag-usab.
Dili kinahanglan nga maghunahuna bahin sa pagtangtang sa wala magamit nga mga imahe: ang paglimpyo sumala sa mga palisiya sa werf magpadayon sa pagkahan-ay sa Docker Registry.

kaplag

Ang paggamit sa werf nagtugot sa asembliya nga molihok dayon tungod sa pag-cache sa asembliya mismo ug pag-cache kung nagtrabaho sa mga eksternal nga repositoryo.
Ang pagtrabaho sa mga eksternal nga Git repository nagwagtang sa panginahanglan sa pag-clone sa tibuok repository sa matag higayon o pag-imbento pag-usab sa ligid nga adunay tricky optimization logic. Ang werf naggamit sa usa ka cache ug gihimo ang pag-clone kausa ra, ug dayon gigamit fetch ug kon gikinahanglan lamang.
Abilidad sa paggamit sa Go templates sa build configuration file werf.yaml nagtugot kanimo sa paghulagway sa usa ka asembliya kansang resulta nagdepende sa eksternal nga datos.
Ang paggamit sa mount sa werf hinungdanon nga nagpadali sa pagkolekta sa mga artifact - tungod sa cache, nga kasagaran sa tanan nga mga pipeline.
Gipadali sa werf ang pag-configure sa paglimpyo, nga labi ka hinungdanon kung magtukod nga dinamiko.

PS

Basaha usab sa among blog:

Source: www.habr.com

Dinamikong asembliya ug pag-deploy sa mga imahe sa Docker nga adunay werf gamit ang panig-ingnan sa usa ka bersyon nga site sa dokumentasyon