Dinaminis „Docker“ vaizdų surinkimas ir diegimas naudojant werf naudojant versijų dokumentacijos svetainės pavyzdį

Apie mūsų „GitOps“ įrankį jau kalbėjome ne kartą. werf, o šį kartą norime pasidalinti savo patirtimi surenkant aikštelę su paties projekto dokumentacija - werf.io (jo rusiška versija yra en.werf.io). Tai įprasta statinė svetainė, tačiau jos surinkimas įdomus tuo, kad jis pastatytas naudojant dinamišką artefaktų skaičių.

Apsvarstykite svetainės struktūros niuansus: sukurkite bendrą meniu visoms versijoms, puslapius su informacija apie leidimus ir pan. - mes ne. Vietoj to, sutelkime dėmesį į dinaminio surinkimo problemas ir ypatybes bei šiek tiek į lydinčius CI / CD procesus.

Įvadas: kaip veikia svetainė

Pirmiausia werf dokumentacija saugoma kartu su jos kodu. Tai nustato tam tikrus plėtros reikalavimus, kurie paprastai nepatenka į šio straipsnio taikymo sritį, tačiau galima sakyti, kad bent jau:

• Naujos werf funkcijos neturėtų būti išleistos neatnaujinus dokumentacijos ir, atvirkščiai, bet kokie dokumentacijos pakeitimai reiškia naujos werf versijos išleidimą;
• Projektas vystomas gana intensyviai: naujos versijos gali būti išleistos kelis kartus per dieną;
• Bet kokios rankinės operacijos diegiant svetainę su nauja dokumentacijos versija yra bent jau varginančios;
• Projekte laikomasi semantinio požiūrio versijų kūrimas, su 5 stabilumo kanalais. Išleidimo procesas apima nuoseklų versijų perėjimą kanalais, siekiant padidinti stabilumą: nuo alfa iki kieto;
• Svetainėje yra versija rusų kalba, kuri „gyvena ir vystosi“ (t. y. kurios turinys atnaujinamas) lygiagrečiai su pagrindine (t. y. anglų kalba) versija.

Norėdami paslėpti visą šią „vidinę virtuvę“ nuo vartotojo, pasiūlydami jam tai, kas „tiesiog veikia“, mes padarėme atskiras werf diegimo ir atnaujinimo įrankis - yra multiwerf. Jums tereikia nurodyti išleidimo numerį ir stabilumo kanalą, kurį esate pasiruošę naudoti, o multiwerf patikrins, ar kanale nėra naujos versijos ir, jei reikia, ją atsisiųs.

Svetainės versijų pasirinkimo meniu kiekviename kanale yra naujausios werf versijos. Pagal numatytuosius nustatymus, pagal adresą werf.io/documentation atsidaro naujausio leidimo stabiliausio kanalo versija – ją taip pat indeksuoja paieškos sistemos. Kanalo dokumentaciją galima rasti atskirais adresais (pvz., werf.io/v1.0-beta/documentation 1.0 beta versijai).

Iš viso svetainėje yra šios versijos:

1. root (atidaroma pagal numatytuosius nustatymus),
2. kiekvienam aktyviam kiekvieno leidimo naujinimo kanalui (pvz., werf.io/v1.0-beta).

Norint sugeneruoti konkrečią svetainės versiją, pakanka ją sukompiliuoti naudojant Jekyllpaleisdami kataloge /docs werf saugykla atitinkama komanda (jekyll build), perjungę į reikiamos versijos Git žymą.

Belieka tik pridurti, kad:

• surinkimui naudojamas pats įrankis (werf);
• CI/CD procesai sukurti GitLab CI pagrindu;
• ir visa tai, žinoma, vyksta Kubernetes.

užduotys

Dabar suformuluokime užduotis, kuriose būtų atsižvelgta į visą aprašytą specifiką:

1. Pakeitus werf versiją bet kuriame naujinimo kanale svetainėje esantys dokumentai turėtų būti automatiškai atnaujinami.
2. Norint tobulėti, kartais reikia sugebėti peržiūrėti peržiūros svetainės versijas.

Svetainė turi būti perkompiliuota pakeitus versiją bet kuriame kanale iš atitinkamų Git žymų, tačiau kurdami vaizdą gausime šias funkcijas:

• Kadangi keičiasi kanalų versijų sąrašas, tereikia iš naujo sukurti kanalų, kurių versija pasikeitė, dokumentaciją. Juk iš naujo viską atstatyti nėra labai gražu.
• Leidimų kanalų rinkinys gali keistis. Pavyzdžiui, tam tikru momentu kanaluose gali nebūti stabilesnės versijos nei ankstyvos prieigos 1.1 leidimas, tačiau laikui bėgant jie pasirodys – ar šiuo atveju neturėtumėte keisti surinkimo rankiniu būdu?

Pasirodo, kad surinkimas priklauso nuo išorinių duomenų keitimo.

Vykdymas

Požiūrio pasirinkimas

Arba galite paleisti kiekvieną reikiamą versiją kaip atskirą paketą „Kubernetes“. Ši parinktis reiškia didesnį objektų skaičių klasteryje, kuris augs didėjant stabilių werf leidimų skaičiui. O tai, savo ruožtu, reiškia sudėtingesnę priežiūrą: kiekviena versija turi savo HTTP serverį ir su maža apkrova. Žinoma, tai reiškia ir didesnes išteklių sąnaudas.

Mes ėjome tuo pačiu keliu visų reikiamų versijų surinkimas viename paveikslėlyje. Sukompiliuota visų svetainės versijų statistika yra talpykloje su NGINX, o srautas į atitinkamą diegimą ateina per NGINX Ingress. Paprasta struktūra – programa be būsenos – leidžia lengvai keisti diegimo mastelį (atsižvelgiant į apkrovą) naudojant patį „Kubernetes“.

Tiksliau tariant, mes renkame du vaizdus: vienas skirtas gamybos grandinei, antrasis yra papildomas kūrimo grandinei. Papildomas vaizdas naudojamas (paleidžiamas) tik dev grandinėje kartu su pagrindiniu ir jame yra svetainės versija iš peržiūros įsipareigojimo, o maršrutas tarp jų atliekamas naudojant Ingress išteklius.

werf vs git klonas ir artefaktai

Kaip jau minėta, norint sukurti svetainės statiką konkrečiai dokumentacijos versijai, turite sukurti perjungdami į atitinkamą saugyklos žymą. Taip pat galite tai padaryti kiekvieną kartą, kai kuriate saugyklą, klonuodami saugyklą, pasirinkdami atitinkamas žymas iš sąrašo. Tačiau tai gana daug resursų reikalaujanti operacija, be to, reikia rašyti nebanalias instrukcijas... Kitas rimtas trūkumas yra tai, kad naudojant tokį metodą surinkimo metu nėra galimybės ko nors išsaugoti talpykloje.

Čia mums į pagalbą ateina pati „werf“ programa, kurią įgyvendina išmanusis talpyklos kaupimas ir leidžia jums naudotis išorinės saugyklos. Naudodami werf kodui iš saugyklos pridėti, žymiai paspartinsite kūrimą, nes werf iš esmės vieną kartą klonuoja saugyklą ir tada vykdo tik fetch jei būtina. Be to, pridėdami duomenis iš saugyklos, galime pasirinkti tik reikiamus katalogus (mūsų atveju tai yra katalogas docs), o tai žymiai sumažins pridedamų duomenų kiekį.

Kadangi Jekyll yra įrankis, skirtas statiniams duomenims kompiliuoti ir nėra reikalingas galutiniame vaizde, logiška būtų kompiliuoti werf artefaktas, ir į galutinį vaizdą importuoti tik kompiliavimo rezultatą.

Rašome werf.yaml

Taigi nusprendėme, kad kiekvieną versiją sudarysime atskirame werf artefakte. Tačiau mes mes nežinome, kiek šių artefaktų bus surinkimo metu, todėl negalime parašyti fiksuotos versijos konfigūracijos (griežtai kalbant, vis tiek galime, bet ji nebus visiškai efektyvi).

werf leidžia naudoti Eikite į šablonus savo konfigūracijos faile (werf.yaml), ir tai leidžia tai padaryti generuoti konfigūraciją skrydžio metu priklausomai nuo išorinių duomenų (ko jums reikia!). Išoriniai duomenys mūsų atveju yra informacija apie versijas ir leidimus, kurių pagrindu surenkame reikiamą artefaktų skaičių ir dėl to gauname du vaizdus: werf-doc и werf-dev veikti skirtingomis grandinėmis.

Išoriniai duomenys perduodami per aplinkos kintamuosius. Štai jų sudėtis:

• RELEASES — eilutė su leidimų sąrašu ir atitinkama dabartine werf versija, tarpais atskirto formato reikšmių sąrašo forma <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Pavyzdys: 1.0%v1.0.4-beta.20
• CHANNELS — eilutė su kanalų sąrašu ir atitinkama dabartine werf versija, tarpais atskirto reikšmių sąrašo formatu <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Pavyzdys: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — pagal numatytuosius nustatymus svetainėje turi būti rodoma werf leidimo versija (ne visada būtina pateikti dokumentus pagal didžiausią leidimo numerį). Pavyzdys: v1.0.4-beta.20
• REVIEW_SHA — peržiūros įsipareigojimo maiša, iš kurios reikia sukurti bandomosios ciklo versiją.

Šie kintamieji bus užpildyti „GitLab CI“ konvejeryje, o kaip tiksliai, parašyta žemiau.

Visų pirma, patogumo dėlei mes apibrėžiame werf.yaml Eikite į šablono kintamuosius, priskirdami jiems reikšmes iš aplinkos kintamųjų:

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

Artefakto, skirto statinei svetainės versijai sudaryti, aprašymas paprastai yra vienodas visais mums reikalingais atvejais (įskaitant šakninės versijos generavimą, taip pat kūrimo grandinės versiją). Todėl naudodami funkciją perkelsime jį į atskirą bloką define - vėlesniam pakartotiniam naudojimui include. Į šabloną pateiksime šiuos argumentus:

• Version — sugeneruota versija (žymos pavadinimas);
• Channel — atnaujinimo kanalo, kuriam sugeneruotas artefaktas, pavadinimas;
• Commit — atlikti maišą, jei artefaktas sukurtas peržiūros įsipareigojimui;
• kontekste.

Artefakto šablono aprašymas

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

Artefakto pavadinimas turi būti unikalus. Tai galime pasiekti, pavyzdžiui, pridėdami kanalo pavadinimą (kintamojo reikšmę .Channel) kaip artefakto pavadinimo priesaga: artifact: doc-{{ .Channel }}. Bet jūs turite suprasti, kad importuodami iš artefaktų turėsite nurodyti tuos pačius pavadinimus.

Apibūdinant artefaktą, naudojama ši werf funkcija: montavimas. Montavimas, nurodantis paslaugų katalogą build_dir leidžia išsaugoti Jekyll talpyklą tarp dujotiekio paleidimų, o tai žymiai pagreitina surinkimą.

Galbūt pastebėjote ir failo naudojimą releases.yml yra YAML failas su išleidimo duomenimis, iš kurių prašoma github.com (artefaktas, gautas vykdant dujotiekį). Jis reikalingas kuriant svetainę, bet straipsnio kontekste jis mums įdomus, nes priklauso nuo jos būsenos tik vieno artefakto surinkimas — pagrindinės svetainės versijos artefaktas (kituose artefaktuose jis nereikalingas).

Tai įgyvendinama naudojant sąlyginį sakinį if Eikite į šablonus ir dizainus {{ $Root.Files.Get "releases.yml" | sha256sum }} stadijoje etapai. Tai veikia taip: kuriant artefaktą šakninei versijai (kintamasis .Channel yra lygus root) failų maišos releases.yml paveikia viso etapo parašą, nes tai yra Ansible užduoties pavadinimo dalis (parametras name). Taigi keičiant turinys failą releases.yml atitinkamas artefaktas bus surinktas iš naujo.

Taip pat atkreipkite dėmesį į darbą su išorine saugykla. Artefakto atvaizde iš werf saugykla, pridedamas tik katalogas /docs, ir priklausomai nuo perduotų parametrų, iš karto pridedami reikiamos žymos arba peržiūros įsipareigojimo duomenys.

Norėdami naudoti artefakto šabloną perkeltų kanalų ir leidimų versijų artefakto aprašymui generuoti, kintamajame organizuojame kilpą .WerfVersions в werf.yaml:

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

Nes kilpa sugeneruos kelis artefaktus (to tikimės), būtina atsižvelgti į skirtuką tarp jų - seką --- (Daugiau informacijos apie konfigūracijos failo sintaksę žr dokumentacija). Kaip apibrėžta anksčiau, kai iškviečiame šabloną cikle, perduodame versijos parametrus, URL ir šakninį kontekstą.

Panašiai, bet be kilpos, artefakto šabloną vadiname „ypatingiems atvejams“: šakninei versijai, taip pat versijai iš peržiūros įsipareigojimo:

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

Atminkite, kad peržiūros įsipareigojimo artefaktas bus sukurtas tik tada, jei nustatytas kintamasis .WerfReviewCommit.

Artefaktai paruošti – laikas pradėti importuoti!

Galutinis vaizdas, sukurtas veikti Kubernetes, yra įprastas NGINX su pridėtu serverio konfigūracijos failu nginx.conf o statinis iš artefaktų. Be pagrindinės svetainės versijos artefakto, turime pakartoti kintamojo kilpą .WerfVersions norėdami importuoti kanalo ir leidimo versijų artefaktus + vadovaukitės artefaktų pavadinimo taisyklėmis, kurias priėmėme anksčiau. Kadangi kiekvienas artefaktas saugo svetainės versijas dviem kalbomis, jas importuojame į konfigūracijos numatytas vietas.

Galutinio vaizdo aprašymas 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 -}}

Papildomame paveikslėlyje, kuris kartu su pagrindiniu paleidžiamas kūrėjo grandinėje, yra tik dvi svetainės versijos: versija iš peržiūros įsipareigojimo ir pagrindinė svetainės versija (yra bendrieji ištekliai ir, jei prisimenate , išleidimo duomenys). Taigi papildomas vaizdas nuo pagrindinio skirsis tik importo skiltyje (ir, žinoma, pavadinime):

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

Kaip minėta aukščiau, peržiūros įsipareigojimo artefaktas bus sugeneruotas tik tada, kai bus paleistas nustatytas aplinkos kintamasis REVIEW_SHA. Jei nėra aplinkos kintamojo, werf-dev vaizdo būtų galima iš viso negeneruoti REVIEW_SHA, bet tam, kad valymas pagal politiką „Docker“ vaizdai werf veikė werf-dev atvaizdui, paliksime jį sukurti tik su šakninės versijos artefaktu (jis vis tiek jau sukurtas), kad supaprastintume konvejerio struktūrą.

Surinkimas paruoštas! Pereikime prie CI/CD ir svarbių niuansų.

„GitLab CI“ vamzdynas ir dinaminės kūrimo funkcijos

Vykdydami kūrimą turime nustatyti naudojamus aplinkos kintamuosius werf.yaml. Tai netaikoma kintamajam REVIEW_SHA, kurį nustatysime iškviesdami dujotiekį iš „GitHub“ kablio.

Mes sugeneruosime reikiamus išorinius duomenis Bash scenarijuje generate_artifacts, kuris sugeneruos du „GitLab“ dujotiekio artefaktus:

• failą releases.yml su išleidimo duomenimis,
• failą common_envs.sh, kuriame yra eksportuotini aplinkos kintamieji.

Failo turinys generate_artifacts rasite mūsų saugyklos su pavyzdžiais. Pats duomenų gavimas yra ne straipsnio tema, o failas common_envs.sh mums svarbu, nes nuo to priklauso werfo darbas. Jo turinio pavyzdys:

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'

Galite naudoti tokio scenarijaus išvestį, pavyzdžiui, naudodami funkciją Bash source.

Dabar ateina linksmoji dalis. Kad ir programos kūrimas, ir diegimas veiktų tinkamai, būtina tai užtikrinti werf.yaml buvo tas pats bent jau per vieną dujotiekį. Jei ši sąlyga neįvykdyta, etapų, kuriuos werf apskaičiuoja surinkimo ir, pavyzdžiui, diegimo, parašai bus skirtingi. Tai sukels diegimo klaidą, nes... trūks įdiegimui reikalingo vaizdo.

Kitaip tariant, jei kuriant svetainės vaizdą informacija apie leidimus ir versijas yra ta pati, o diegimo metu išleidžiama nauja versija, o aplinkos kintamieji turi skirtingas reikšmes, tada diegimas nepavyks su klaida: juk naujos versijos artefaktas dar nepastatytas.

Jei kartos werf.yaml priklauso nuo išorinių duomenų (pavyzdžiui, dabartinių versijų sąrašo, kaip mūsų atveju), tada tokių duomenų sudėtis ir reikšmės turėtų būti įrašytos į dujotiekį. Tai ypač svarbu, jei išoriniai parametrai keičiasi gana dažnai.

Mes padarysime gauti ir įrašyti išorinius duomenis pirmajame dujotiekio etape „GitLab“ (Iš anksto pastatyti) ir persiųskite juos toliau formoje GitLab CI artefaktas. Tai leis paleisti ir iš naujo paleisti dujotiekio užduotis (kurti, diegti, išvalyti) su ta pačia konfigūracija werf.yaml.

Scenos turinys Iš anksto pastatyti failą .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

Užfiksavę išorinius duomenis artefakte, galite kurti ir įdiegti naudodami standartinius GitLab CI dujotiekio etapus: Sukūrimas ir diegimas. Mes paleidžiame patį dujotiekį naudodami kabliukus iš werf GitHub saugyklos (t. y. kai yra pakeitimų GitHub saugykloje). Duomenis apie juos rasite GitLab projekto ypatybėse skiltyje CI / CD nustatymai -> Dujotiekio paleidikliai, tada sukurkite atitinkamą Webhook „GitHub“ (Nustatymai -> Webhooks).

Kūrimo etapas atrodys taip:

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“ pridės du artefaktus iš scenos į kūrimo etapą Iš anksto pastatyti, todėl kintamuosius eksportuojame su paruoštais įvesties duomenimis naudodami konstrukciją source common_envs.sh. Visais atvejais pradedame tiesimo etapą, išskyrus dujotiekio paleidimą pagal grafiką. Pagal grafiką pravešime vamzdyną valymui – tokiu atveju surinkimo atlikti nereikia.

Diegimo etape apibūdinsime dvi užduotis – atskirai, skirtos diegimui gamybos ir kūrimo grandinėse, naudojant YAML šabloną:

.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

Užduotys iš esmės skiriasi tik tuo, kad nurodo klasterio kontekstą, kuriame werf turėtų atlikti diegimą (WERF_KUBE_CONTEXT) ir nustatyti ciklo aplinkos kintamuosius (environment.name и environment.url), kurie vėliau naudojami Helm diagramos šablonuose. Šablonų turinio nepateiksime, nes... ten nėra nieko įdomaus aptariama tema, bet galite juos rasti straipsnio saugyklos.

Galutinis prisilietimas

Kadangi werf versijos išleidžiamos gana dažnai, nauji vaizdai bus kuriami dažnai, o Docker registras nuolat augs. Todėl būtina sukonfigūruoti automatinį vaizdo valymą pagal politiką. Tai labai lengva padaryti.

Norėdami įgyvendinti, jums reikės:

• Pridėkite valymo veiksmą prie .gitlab-ci.yml;
• Pridėti periodišką valymo užduoties vykdymą;
• Nustatykite aplinkos kintamąjį su rašymo prieigos raktu.

Valymo etapo pridėjimas prie .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

Beveik visa tai jau matėme šiek tiek aukščiau – tik norint jį išvalyti, pirmiausia reikia prisijungti prie Docker registro su prieigos raktu, turinčiu teisę ištrinti vaizdus Docker registre (automatiškai išduotas GitLab CI užduoties prieigos raktas ne turi tokias teises). Žetonas turi būti sukurtas GitLab iš anksto ir jo reikšmė turi būti nurodyta aplinkos kintamajame WERF_IMAGES_CLEANUP_PASSWORD projektas (CI / CD nustatymai -> kintamieji).

Pridedama valymo užduotis su reikiamu grafiku CI/CD ->
Tvarkaraščiai.

Viskas: Docker registre esantis projektas nebebus nuolat auga iš nenaudojamų vaizdų.

Praktinės dalies pabaigoje leiskite jums priminti, kad visi straipsnio sąrašai yra prieinami git:

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

Rezultatas

1. Gavome logišką surinkimo struktūrą: po vieną artefaktą kiekvienai versijai.
2. Surinkimas yra universalus ir nereikalauja rankinių pakeitimų, kai išleidžiamos naujos werf versijos: dokumentacija svetainėje automatiškai atnaujinama.
3. Surenkami du vaizdai skirtingiems kontūrams.
4. Tai veikia greitai, nes Talpykla yra naudojama kiek įmanoma – kai išleidžiama nauja werf versija arba „GitHub Hook“ iškviečiamas peržiūros įsipareigojimui, atkuriamas tik atitinkamas artefaktas su pakeista versija.
5. Nereikia galvoti apie nenaudojamų vaizdų ištrynimą: išvalius pagal werf politiką, Docker registras bus tvarkingas.

išvados

• Naudojant werf, surinkimas gali veikti greitai, nes tiek pats mazgas, tiek ir dirbant su išorinėmis saugyklomis yra talpykloje.
• Dirbant su išorinėmis „Git“ saugyklomis, nebereikia kiekvieną kartą klonuoti visos saugyklos arba išradinėti ratą iš naujo naudojant sudėtingą optimizavimo logiką. werf naudoja talpyklą ir klonuoja tik vieną kartą, o tada naudoja fetch ir tik tada, kai reikia.
• Galimybė naudoti Go šablonus kūrimo konfigūracijos faile werf.yaml leidžia apibūdinti mazgą, kurio rezultatas priklauso nuo išorinių duomenų.
• Naudojant mount in werf žymiai pagreitėja artefaktų rinkimas – dėl talpyklos, kuri yra bendra visiems vamzdynams.
• werf leidžia lengvai konfigūruoti valymą, o tai ypač svarbu kuriant dinamiškai.

PS

Taip pat skaitykite mūsų tinklaraštyje:

• «Vykdomos komandos pristatant naują programos leidimą Kubernetes»;
• «Kurkite ir įdiekite to paties tipo mikropaslaugas naudodami werf ir GitLab CI»;
• «Naudojant werf sudėtingoms Helm diagramoms išskleisti»;
• «Pristatome werf 1.0 stabilų: ką su juo turi „GitOps“, būsena ir planai".

Šaltinis: www.habr.com