🥇Perakitan dinamis lan panyebaran gambar Docker nganggo werf nggunakake conto situs dokumentasi versi

Kita wis ngomong babagan alat GitOps luwih saka sepisan werf, lan wektu iki kita pengin nuduhake pengalaman ngumpulake situs web kanthi dokumentasi proyek kasebut dhewe - werf.io (versi Rusia yaiku ru.werf.io). Iki minangka situs statis biasa, nanging perakitan kasebut menarik amarga dibangun kanthi nggunakake artefak sing dinamis.

Kita ora bakal pindhah menyang nuansa saka struktur situs: ngasilaken menu umum kanggo kabeh versi, kaca karo informasi bab Rilis, etc. Nanging, kita bakal fokus ing masalah lan fitur saka Déwan dinamis lan sethitik ing gawan CI / pangolahan CD.

Pambuka: Cara kerja situs

Ayo diwiwiti kanthi kasunyatan manawa dokumentasi werf disimpen bebarengan karo kode kasebut. Iki ngetrapake syarat tartamtu babagan pangembangan, sing umume ngluwihi ruang lingkup artikel iki, nanging paling ora kita bisa ujar manawa:

fungsi werf anyar ngirim ora dirilis tanpa nganyari dokumentasi lan, Kosok baline, owah-owahan ing dokumentasi ora pati jelas release saka versi anyar saka werf;
Proyèk iki nduweni pangembangan sing cukup intensif: versi anyar bisa dirilis kaping pirang-pirang dina;
Sembarang operasi manual kanggo nyebarake situs kanthi dokumentasi versi anyar paling ora nyenengake;
Proyek kasebut nggunakake pendekatan semantik versi, kanthi 5 saluran stabilitas. Proses rilis kalebu wacana urutan versi liwat saluran supaya nambah stabilitas: saka alpha kanggo rock-padhet;
Situs iki nduweni versi basa Rusia, sing "urip lan berkembang" (yaiku isi sing dianyari) sejajar karo versi utama (yaiku basa Inggris).

Kanggo ndhelikake kabeh "kerja batin" iki saka pangguna, nawakake barang sing "mung dianggo", kita digawe alat kapisah kanggo nginstal lan nganyari werf Punika multiwerf. Sampeyan mung kudu nemtokake nomer release lan saluran stabilitas sampeyan siyap kanggo nggunakake, lan multiwerf bakal mriksa yen ana versi anyar ing saluran lan download yen perlu.

Versi paling anyar saka werf kasedhiya ing saben saluran ing menu pilihan versi ing situs. Kanthi gawan, ing werf.io/documentation versi saluran sing paling stabil kanggo rilis paling anyar dibukak - uga diindeks dening mesin telusur. Dokumentasi saluran kasedhiya ing alamat sing kapisah (contone, werf.io/v1.0-beta/documentation kanggo beta release 1.0).

Secara total, situs kasebut nduweni versi ing ngisor iki sing kasedhiya:

root (mbukak kanthi standar),
kanggo saben saluran nganyari aktif saben rilis (contone. werf.io/v1.0-beta).

Kanggo ngasilake versi tartamtu saka situs, ing umum, iku cukup kanggo ngumpulake nggunakake Jekyll, mlaku ing direktori /docs werf repositori perintah sing cocog (jekyll build), sadurunge ngalih menyang tag Git saka versi sing dibutuhake.

Iku mung tetep kanggo nambah:

sarana dhewe (werf) digunakake kanggo perakitan;
Proses CI / CD dibangun kanthi basis GitLab CI;
lan kabeh iki, mesthi, mlaku ing Kubernetes.

tugas

Saiki ayo ngrumusake tugas sing nganggep kabeh spesifik sing diterangake:

Sawise ngganti versi werf ing sembarang saluran nganyari dokumentasi ing situs kudu dianyari kanthi otomatis.
Kanggo ngembangake sampeyan kudu bisa kadhangkala ndeleng pratinjau situs.

Kompilasi ulang situs kasebut kudu ditindakake sawise ngganti versi ing saluran apa wae saka tag Git sing cocog, nanging sajrone proses ngumpulake gambar, kita bakal entuk fitur ing ngisor iki:

Wiwit dhaptar versi ing saluran diganti, mung perlu kanggo mbangun maneh dokumentasi kanggo saluran ngendi versi wis diganti. Sawise kabeh, mbangun maneh kabeh saka awal ora apik banget.
Setel saluran kanggo rilis bisa diganti. Ing sawetara wektu, contone, bisa uga ora ana versi saluran sing luwih stabil tinimbang release 1.1 akses awal, nanging bakal katon liwat wektu - sampeyan ora bisa ngganti mbangun kanthi manual ing kasus iki, ta?

Ternyata sing Déwan gumantung ing ngganti data external.

Реализация

Milih pendekatan

Utawa, sampeyan bisa mbukak saben versi sing dibutuhake minangka pod kapisah ing Kubernetes. Opsi iki nyebabake luwih akeh obyek ing kluster, sing bakal tuwuh kanthi nambah jumlah rilis werf sing stabil. Lan iki, kanthi mangkono, nuduhake pangopènan sing luwih rumit: saben versi duwe server HTTP dhewe, kanthi muatan cilik. Mesthi, iki uga mbutuhake biaya sumber daya sing luwih gedhe.

Kita tindak kanthi cara sing padha mbangun kabeh versi sing dibutuhake ing siji gambar. Statika kompilasi kabeh versi situs kasebut ana ing wadhah karo NGINX, lan lalu lintas menyang Deployment sing cocog liwat NGINX Ingress. Struktur sing prasaja - aplikasi tanpa negara - ngidini sampeyan kanthi gampang ngukur Deployment (gumantung saka beban) nggunakake Kubernetes dhewe.

Kanggo luwih tepat, kita mbangun rong gambar: siji kanggo sirkuit produksi, sing liyane tambahan, kanggo sirkuit dev. Gambar tambahan digunakake (mbukak) mung ing sirkuit dev bebarengan karo sing utama lan ngemot versi situs saka review commit, lan nuntun antarane wong-wong mau dileksanakake nggunakake sumber Ingress.

werf vs git klon lan artefak

Kaya sing kasebut, kanggo ngasilake statis situs kanggo versi dokumentasi tartamtu, sampeyan kudu mbangun kanthi ngalih menyang tag repositori sing cocog. Sampeyan uga bisa nindakake iki kanthi kloning repositori saben-saben sampeyan mbangun, milih tag sing cocog saka dhaptar. Nanging, iki minangka operasi sing cukup intensif sumber daya lan, saliyane, mbutuhake nulis instruksi sing ora pati penting ... Kerugian serius liyane yaiku kanthi pendekatan iki, ora ana cara kanggo cache apa wae sajrone mbangun.

Kene utilitas werf dhewe teka kanggo bantuan kita, ngleksanakake caching pinter lan ngidini sampeyan nggunakake repositori njaba. Nggunakake werf kanggo nambah kode saka repositori bakal nyepetake pambangunan kanthi signifikan, amarga werf ateges klone repositori sapisan lan banjur mlaku. mung fetch yen perlu. Kajaba iku, nalika nambahake data saka repositori, kita mung bisa milih direktori sing dibutuhake (ing kasus kita, iki minangka direktori docs), sing bakal nyuda jumlah data sing ditambahake.

Amarga Jekyll minangka alat sing dirancang kanggo ngumpulake file statis lan ora dibutuhake ing gambar pungkasan, mula logis kanggo kompilasi ing artefak werf, lan ing gambar pungkasan ngimpor mung asil kompilasi.

Kita nulis werf.yaml

Dadi, kita mutusake yen bakal ngumpulake saben versi ing artefak werf sing kapisah. Nanging, kita kita ora ngerti carane akeh artefak iki bakal ana sak perakitan, supaya kita ora bisa nulis konfigurasi mbangun tetep (strictly ngandika, kita bisa, nanging ora bakal banget efisien).

werf ngidini sampeyan nggunakake Go templates ing file konfigurasi sampeyan (werf.yaml), lan iki ndadekake iku bisa generate config "on the fly" gumantung ing data eksternal (apa sing kita butuhake!). Ing kasus kita, data eksternal minangka informasi babagan versi lan rilis, adhedhasar sing kita ngumpulake jumlah artefak sing dibutuhake lan entuk rong gambar minangka asil: werf-doc и werf-dev kanggo miwiti ing sirkuit beda.

Data eksternal dilewati liwat variabel lingkungan. Punika komposisinipun:

RELEASES — baris kanthi dhaptar rilis lan versi werf saiki sing cocog, minangka dhaptar nilai sing dipisahake spasi ing format kasebut <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Tuladha: 1.0%v1.0.4-beta.20
CHANNELS - baris karo dhaptar saluran lan versi werf saiki sing cocog, ing wangun dhaptar nilai sing dipisahake spasi ing format <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Tuladha: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION - versi release werf kanggo ditampilake minangka standar ing situs (ora perlu kanggo nampilake dokumentasi kanthi nomer release paling dhuwur). Tuladha: v1.0.4-beta.20
REVIEW_SHA - hash review commit saka versi kanggo sirkuit test kudu dibangun.

Variabel kasebut bakal diisi ing pipa GitLab CI, lan kepiye carane diterangake ing ngisor iki.

Kaping pisanan, kanggo penak, ayo nemtokake werf.yaml Go variabel template kanthi menehi nilai saka variabel lingkungan:

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

Katrangan artefak kanggo nyusun versi statis situs kasebut umume padha kanggo kabeh kasus sing kita butuhake (kalebu ngasilake versi root, uga versi kanggo kontur dev). Mulane, kita bakal njupuk menyang blok kapisah nggunakake fungsi kasebut define - kanggo nggunakake maneh sakteruse karo bantuan saka include. Kita bakal ngirim argumen ing ngisor iki menyang cithakan:

Version - versi sing digawe (jeneng tag);
Channel - jeneng saluran nganyari sing artefak digawe;
Commit - commit hash, yen artefak digawe kanggo review commit;
konteks.

Katrangan saka cithakan artefak

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

Jeneng artefak kudu unik. Kita bisa entuk iki, contone, kanthi nambahake jeneng saluran (nilai variabel .Channel) minangka seselan kanggo jeneng artefak: artifact: doc-{{ .Channel }}. Nanging sampeyan kudu ngerti yen nalika ngimpor saka artefak, sampeyan kudu ngrujuk jeneng sing padha.

Nalika nerangake artefak, fitur werf ing ngisor iki digunakake: dipasang. Pemasangan kanthi direktori layanan sing ditemtokake build_dir ngijini sampeyan kanggo ngreksa cache Jekyll antarane pipo mlaku, kang Ngartekno nyepetake reassembly.

Sampeyan bisa uga wis ngelingi panggunaan file kasebut releases.yml - minangka file YAML kanthi data rilis sing dijaluk saka github.com (artefak sing dipikolehi nalika nglakokake pipa). Perlu nalika nyusun situs, nanging ing konteks artikel kasebut menarik kanggo kita amarga negarane gumantung reassembly mung siji artefak - artefak saka versi ROOT saka situs (ora perlu ing artefak liyane).

Iki dileksanakake nggunakake operator kondisional. if Bukak template lan konstruksi {{ $Root.Files.Get "releases.yml" | sha256sum }} ing tataran tahapan. Kerjane kaya iki: nalika mbangun artefak kanggo versi root (variabel .Channel padha karo root) file hash releases.yml mengaruhi teken kabeh tataran, amarga iku komponen saka jeneng tugas Ansible (parameter name). Mangkono, nalika ngganti isi ngajukake releases.yml artefak cocog bakal reassembled.

Mangga uga menehi perhatian kanggo nggarap repositori eksternal. Ing gambar artefak saka repositori werf, mung direktori sing ditambahake /docs, lan gumantung saka paramèter sing dilewati, data saka tag sing dibutuhake utawa komitmen review langsung ditambahake.

Kanggo nggunakake cithakan artefak kanggo ngasilake deskripsi artefak babagan versi saluran sing ditransfer lan rilis, kita ngatur loop kanthi variabel .WerfVersions в werf.yaml:

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

Wiwit siklus bakal ngasilake pirang-pirang artefak (mugo-mugo), sampeyan kudu nganggep pemisah ing antarane - urutan --- (kanggo informasi luwih lengkap babagan sintaks file konfigurasi, deleng dokumentasi). Kaya sing wis ditemtokake sadurunge, nalika nelpon cithakan ing daur ulang, kita ngliwati parameter versi, URL lan konteks root.

Kajaba iku, nanging tanpa siklus, kita nyebut template artefak kanggo "kasus khusus": kanggo versi root, uga versi saka 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 }}

Elinga yen artefak kanggo review commit mung bakal dibangun yen variabel disetel. .WerfReviewCommit.

Artefak wis siyap - wektu kanggo miwiti ngimpor!

Gambar pungkasan sing dimaksudake kanggo mbukak ing Kubernetes yaiku NGINX biasa kanthi file konfigurasi server sing ditambahake. nginx.conf lan statis saka artefak. Saliyane artefak versi root situs, kita kudu mbaleni siklus kanthi variabel .WerfVersions kanggo ngimpor saluran lan ngeculake artefak versi + tindakake aturan jeneng artefak sing diadopsi sadurunge. Wiwit saben artefak nyimpen versi situs kanggo rong basa, kita ngimpor menyang lokasi sing diwenehake dening konfigurasi.

Katrangan saka gambar pungkasan 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 -}}

Gambar tambahan, sing diluncurake ing sirkuit dev bebarengan karo sing utama, mung ngemot rong versi situs: versi saka review commit lan versi root situs kasebut (isi aset umum lan, yen sampeyan ngelingi, ngeculake data). Mangkono, gambar tambahan bakal beda-beda saka sing utama mung ing bagean impor (lan, mesthi, jeneng):

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

Kaya sing kasebut ing ndhuwur, artefak kanggo komit review mung bakal digawe nalika nglakokake variabel lingkungan sing disetel REVIEW_SHA. Bisa uga ora ngasilake gambar werf-dev yen ora ana variabel lingkungan REVIEW_SHA, nanging supaya reresik dening kawicaksanan Gambar Docker ing werf makarya kanggo gambar werf-dev, kita bakal ninggalake kanggo dibangun mung karo artefak versi ROOT (wis dibangun tho), kanggo menakake struktur pipo.

Mbangun wis siyap! Ayo pindhah menyang CI / CD lan nuansa penting.

Pipeline ing GitLab CI lan fitur mbangun dinamis

Nalika mbukak mbangun, kita kudu nyetel variabel lingkungan sing digunakake ing werf.yaml. Iki ora ditrapake kanggo variabel REVIEW_SHA, sing bakal disetel nalika nelpon pipa saka pancing GitHub.

Kita bakal mindhah tatanan saka data external perlu kanggo script Bash generate_artifacts, sing bakal ngasilake rong artefak pipa GitLab:

ngajukake releases.yml karo data rilis,
ngajukake common_envs.sh, ngemot variabel lingkungan kanggo ekspor.

Isi file generate_artifacts sampeyan bakal nemokake ing kita repositori karo conto. Akuisisi data dhewe ora dadi subyek artikel, nanging file common_envs.sh penting kanggo kita, amarga operasi werf gumantung ing. Conto isine:

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'

Output saka skrip kasebut bisa digunakake, contone, nggunakake fungsi Bash source.

Saiki teka bagean paling menarik. Supaya loro perakitan lan panyebaran aplikasi bisa mlaku kanthi bener, perlu kanggo mesthekake yen werf.yaml ana padha paling ora ing siji pipa. Yen kondisi iki ora ketemu, banjur teken panggung sing werf ngetung sak perakitan lan, contone, penyebaran prajurit, bakal beda. Iki bakal nyebabake kesalahan panyebaran, amarga gambar sing dibutuhake kanggo panyebaran bakal ilang.

Ing tembung liya, yen nalika ngrakit gambar situs informasi babagan rilis lan versi padha, lan ing wektu penyebaran versi anyar dirilis lan variabel lingkungan duwe nilai sing beda-beda, banjur penyebaran bakal rampung kanthi kesalahan: sawise kabeh, artefak versi anyar durung dirakit.

Yen generasi werf.yaml gumantung saka data eksternal (contone, dhaptar versi saiki, kaya ing kasus kita), banjur komposisi lan nilai data kasebut kudu direkam ing pipa. Iki penting banget yen paramèter eksternal asring diganti.

Kita bakal nampa lan ngrekam data eksternal ing tahap pisanan saka pipa ing GitLab (Prebuild) lan ngirimake luwih akeh ing wangun artefak GitLab CI. Iki bakal ngidini sampeyan mbukak lan miwiti maneh tugas pipa (mbangun, nyebarake, ngresiki) kanthi konfigurasi sing padha werf.yaml.

Isine panggung Prebuild ngajukake .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

Duwe data eksternal tetep ing artefak, sampeyan bisa mbangun lan nyebarake nggunakake tahapan standar pipa GitLab CI: Mbangun lan Nyebar. Kita miwiti pipeline dhewe nggunakake pancingan saka werf repositori GitHub (yaiku nalika ana owah-owahan ing repositori ing GitHub). Data kanggo wong-wong mau bisa dijupuk saka properti proyek GitLab ing bagean kasebut Setelan CI/CD -> Pemicu Pipeline, banjur gawe Webhook sing cocog ing GitHub (Setelan -> Webhooks).

Tahap mbangun bakal katon kaya iki:

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 bakal nambah rong artefak saka panggung menyang panggung mbangun Prebuild, supaya kita ngekspor variabel karo data input disiapake nggunakake mbangun source common_envs.sh. Kita miwiti tahap mbangun ing kabeh kasus kajaba ngluncurake pipa kanthi jadwal. Ing jadwal, kita bakal miwiti pipa kanggo reresik - ora perlu kanggo nindakake mbangun ing kasus iki.

Ing tataran penyebaran, kita bakal njlèntrèhaké rong tugas - kanthi kapisah kanggo panyebaran menyang produksi lan sirkuit dev, nggunakake cithakan 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

Tugas kasebut mung beda-beda ing indikasi konteks kluster ing ngendi werf kudu nindakake panyebaran (WERF_KUBE_CONTEXT), lan nyetel variabel lingkungan kontur (environment.name и environment.url), sing banjur digunakake ing template grafik Helm. Kita ora bakal nyedhiyani isi cithakan, amarga ora ana sing menarik kanggo topik sing dipikirake, nanging sampeyan bisa nemokake ing repositori kanggo artikel.

tutul pungkasan

Wiwit versi werf dirilis cukup asring, gambar anyar bakal asring dibangun, lan Docker Registry bakal terus berkembang. Mulane, iku perlu kanggo nyiyapake reresik gambar otomatis dening kawicaksanan. Iku gampang banget kanggo nindakake.

Kanggo implementasine sampeyan kudu:

Tambah langkah reresik kanggo .gitlab-ci.yml;
Tambah eksekusi periodik saka tugas reresik;
Nggawe variabel lingkungan kanthi token akses tulis.

Tambah tataran reresik kanggo .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

Kita wis ndeleng meh kabeh ing ndhuwur - mung kanggo ngresiki, sampeyan kudu mlebu menyang Docker Registry kanthi token sing duwe hak kanggo mbusak gambar ing Docker Registry (token tugas GitLab CI sing diterbitake kanthi otomatis ora duwe hak kasebut). Token kudu digawe ing GitLab sadurunge lan nilai kasebut kudu ditemtokake ing variabel lingkungan WERF_IMAGES_CLEANUP_PASSWORD saka project (Setelan CI/CD -> Variabel).

Nambahake tugas reresik kanthi jadwal sing dibutuhake wis rampung CI/CD ->
Jadwal.

Yaiku: proyek Docker Registry sampeyan ora bakal terus berkembang saka gambar sing ora digunakake.

Ing kesimpulan saka bagean praktis, aku pengin ngelingake sampeyan manawa dhaptar lengkap saka artikel kasedhiya ing Git:

asil

Kita entuk struktur perakitan logis: siji artefak saben versi.
Déwan kasebut universal lan ora mbutuhake owah-owahan manual nalika versi werf anyar dirilis: dokumentasi ing situs kasebut kanthi otomatis dianyari.
Loro gambar diklumpukake kanggo kontur sing beda.
Kerjane cepet amarga caching digunakake kanggo ombone maksimum - nalika versi anyar saka werf dirilis utawa pancing GitHub disebut kanggo review commit, mung artefak cocog karo versi diganti dibangun maneh.
Ora perlu kuwatir babagan mbusak gambar sing ora digunakake: reresik adhedhasar kabijakan werf bakal njaga Registry Docker sampeyan.

temonan

Nggunakake werf ngidini mbangun bisa cepet amarga caching saka mbangun dhewe lan caching nalika nggarap repositori eksternal.
Nggarap repositori Git eksternal ngilangake kebutuhan kanggo kloning repositori saben-saben rampung utawa reinvent roda kanthi logika optimasi sing angel. werf nggunakake cache lan kloning mung sapisan, lan banjur nggunakake fetch lan mung yen perlu.
Kemampuan kanggo nggunakake template Go ing file konfigurasi mbangun werf.yaml ngijini sampeyan kanggo njlèntrèhaké Déwan kang asil gumantung ing data external.
Nggunakake soyo tambah ing werf Ngartekno nyepetake koleksi artefak - amarga cache, kang umum kanggo kabeh pipelines.
werf nggampangake konfigurasi ngresiki, sing penting banget kanggo mbangun dinamis.