🥇Sisupõhine sildistamine werf'i ehitajas: miks ja kuidas see töötab?

werf — meie GitOps CLI tööriist, millel on avatud kood, et ehitada ja tarnida rakendusi Kubernetesesse. V väljalaskes v1.1 tutvustati uut funktsiooni piltide koostamisel: piltide märgistamine sisu või sisu põhine märgistamine. Varasemalt eeldas tüüpiline märgistamisplaan werf'is, et Docker-pilte märgistatakse Git'i sildi, Git'i haru või Git'i commit'e järgi. Kuid kõigil neil skeemidel on puudused, mille lahendab täielikult uus märgistamisstrateegia. Üksikasjad sellest ja miks see on nii hea — allpool.

Mikroteenuste komplekti väljatöötamine ühest Git-repositoriumist

Sageli esineb olukord, kus rakendus on jagatud mitmeks enam-vähem iseseiliseks teenuseks. Nende teenuste väljalaskmine võib toimuda iseseisvalt: korraga võib välja lasta ühe või mitu teenust, samal ajal kui teised peavad jätkama tööd ilma muudatusteta. Kuid koodi salvestamise ja projekti juhtimise seisukohalt on mugavam hoida selliseid rakenduse teenuseid ühes repos.

On olukordi, kus teenused on tõeliselt iseseisvad ja ei ole seotud ühe rakendusega. Sel juhul asuvad need eraldi projektides ning nende väljaandmine toimub iga projekti kaudu eraldi CI/CD protsesside kaudu.

Kuid tegelikkuses jagavad arendajad sageli ühte rakendust mitmeks mikroteenuseks, kuid igaühe jaoks eraldi hoidla ja projekti loomine… on ilmselge üleliialdus. Just sellest olukorrast juttu tuleb: mitu sellist mikroteenust asub ühes projektis ja väljaanded toimuvad läbi ühtse CI/CD protsessi.

Tegimine Git haru ja Git sildiga

Oletame, et kasutatakse kõige levinumat sildistamisstrateegiat — tag-or-branch. Git harude puhul sildistatakse pildid haru nimega, ühe haru kohta eksisteerib hetkel ainult üks avaldatud pilt selle haru nimega. Git siltide puhul sildistatakse pildid vastavalt sildi nimega.

Uue Git-sildi loomisel — näiteks uue versiooni väljalaskmisel — luuakse kõigi projekti piltide jaoks Docker Registry's uus Docker-silt:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Need uurde uued pildid sekod Helem malli kaudu Kubernetes'i konfiguratsiooni. Käivitamisel deployment'i käsuga werf deploy uuendatakse pilt Kubernetes'i ressursimainetes ja vastavate ressursside taaskäivitamine seoses pildi nime muutumisega.

Probleem: juhul, kui eelmisest väljalaskmisest (Git-silt) ei muutu pildi sisu, vaid ainult selle Docker-silt, toimub liigne taaskäivitamine ning vastavalt on võimalik mõningane lihtne. Kuigi pole olnud reaalseid põhjuseid selle taaskäivitamise tegemiseks.

Seetõttu, praeguse silti-määramise skeemi korral tuleb kasutada mitut eraldi Git-repositooriumi ja tekib mitme repositooriumi väljalaskmise korraldamise probleem. Üldiselt on selline skeem ülekoormatud ja keeruline. Parim on ühendada mitmed teenused ühte repositooriumisse ja teha selliseid Docker-silte, et vältida liigseid taaskäivitamisi.

Siltimine Git-kommi kaudu

Werf'is on samuti silti-määramise strateegia, mis on seotud Git-kommidega.

Git commit on Git-repo sisu identifikaator ja sõltub Git-reposi failide muudatuste ajaloost, seega tundub loogiline kasutada seda Docker Registry piltide märgistamiseks.

Kuid Git commit'il põhinev märgistamine omab samu puudusi kui Git harude või Git tähiste puhul:

Võib olla loodud tühi commit, mis ei muuda faile, ja Docker-pildi silt muutub.
Võib olla loodud merge commit, mis ei muuda faile, ja Docker-pildi silt muutub.
Võib olla loodud commit, mis muudab Git'is faile, mis ei impordita pildile, ja Docker-pildi silt muutub jälle.

Harunime põhinev märgistamine ei kajasta pildi versiooni.

On veel üks probleem, mis on seotud harunime põhise märgistamisstrateegiaga.

Harunime põhine märgistamine töötab seni, kuni selle haru commit'id kogutakse järjestikku kronoloogilises järjekorras.

Kui kasutaja käivitab vanade commit'de ümberkomplekteerimise antud harus, siis werf asendab pildi vastava Docker'i sildiga uue versiooniga vanast commit'ist. Edasi kasutavad selle silti Deployment'id riskivad, et pod'ide taaskäivitamisel tõmmatakse teine pildi versioon, mille tõttu meie rakendus kaotab ühenduse CI-süsteemiga ja satub desünkroonsusse.

Lisaks, kui ühte haru surutakse järjestikku lühikese ajavahega, võib vana commit tulla välja hiljem kui uuem: vana pildi versioon asendab uue Git-haru sildi järgi. Selliseid probleeme võib lahendada CI/CD-süsteem (näiteks GitLab CI puhul käivitub viimasest commit'st pipeline). Kuid mitte kõik süsteemid ei toeta seda ning peab olema usaldusväärsem viis selliste põhiprobleemide vältimiseks.

Mis on sisupõhine sildistamine?

Nii et mis on sisupõhine sildistamine — piltide sildistamine sisu alusel.

Docker'i siltide loomiseks ei kasutata Git'i primitiive (Git-haru, Git-silt…), vaid kontrollsummat, mis on seotud:

pildi sisuga. Pildi identifikaatori silt kajastab selle sisu. Uue versiooni koostamisel ei muutu see identifikaator, kui pildis ei ole faile muudetud;
selle pildi loomise ajalooga Git. Erinevatest Git-haarudest ja erineva koostamise ajalooga seotud pildid werf'i kaudu saavad erinevad sildid-identifikaatorid.

Sellise identifikaatori silt on nii kutsutud staadiumi allkiri.

Iga pilt koosneb staadiumide kogumist: from, before-install, git-archive, install, imports-after-install, before-setup,… git-latest-patch jne. Igal staadiumil on identifikaator, mis kajastab selle sisu, — staadiumi allkiri (stage signature).

Lõplik pilt, mis koosneb nendest staadiumidest, sildistatakse nii nimetatud staadiumite kogumi allkirjaga — stages signature, — mis on üldistav kõigi pildi staadiumide jaoks.

Igal pildil, mis on saadud konfiguratsioonist werf.yaml , on tavaliselt oma selline allkiri ja seega ka Docker-silt.

Staadiumi allkiri lahendab kõik eespool nimetatud probleemid:

On vastupidav tühjade Git-commit'ide suhtes.
On vastupidav Git-commit'ide suhtes, mis muudavad faile, mis ei ole pildile asjakohased.
Ei põhjusta probleemi hetke pildi versiooni kattumisega vanade Git-kommiteede harude kogumite taaskäivitamisel.

See on nüüd soovitatav sildistamise strateegia ja seda kasutatakse vaikimisi werf'is kõikides CI-süsteemides.

Kuidas werf'is sisse lülitada ja kasutada

Seotud valik ilmnes käsule werf publish: --tag-by-stages-signature=true|false

CI-süsteemis määratakse sildistamise strateegia käsuga werf ci-env. Varasemalt määrati selle jaoks parameeter werf ci-env --tagging-strategy=tag-or-branch. Nüüd, kui määrata werf ci-env --tagging-strategy=stages-signature või seda valikut mitte määrata, kasutab werf vaikimisi sildistamise strateegiat stages-signature. Käsk werf ci-env seadistab automaatselt vajalikud lipud käsule werf build-and-publish (või werf publish), seega ei ole nende käskude jaoks vaja täiendavaid valikuid määrata.

Näiteks käsk:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

… võib luua järgmised pildid:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Siit 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d — on pildi etappide allkiri tagaosa, ja f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — pildi etappide allkiri eesmine.

Kasutades spetsiaalseid funktsioone werf_container_image ja werf_container_env Helmi mallides ei ole muudatusi vajalikke: need funktsioonid genereerivad automaatselt õiged pildinimed.

Konfiguratsiooni näide CI-süsteemis:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Rohkem teavet seadistamise kohta on saadaval dokumentatsioonis:

Kokku

Uus valik werf publish --tag-by-stages-signature=true|false.
Uue valiku väärtus werf ci-env --tagging-strategy=stages-signature|tag-or-branch (kui ei ole määratud, siis vaikimisi on stages-signature).
Kui enne oli kasutusel Git-commitide põhine sildistamine (WERF_TAG_GIT_COMMIT või valik werf publish --tag-git-commit COMMIT), siis tuleb kindlasti vahetada sildistamistrateegiale stages-signature.
Uued projektid on parem kohe uuele sildistamisskeemile üle viia.
Vanad projektid tasub werf 1.1 kasutusele võttes üle viia uuele sildistamisskeemile, kuid vana tag-or-branch on endiselt toetatud.

Sisu põhine sildistamine lahendab kõik artiklis käsitletud probleemid:

Docker-tagi nime vastupidavus tühi Git-commitide suhtes.
Docker-tagi nimi püsivus Git-commit'ide suhtes, mis muudavad konteineriga mitte seotud faile.
Ei põhjusta probleeme olemasoleva konteineri versiooni üle kirjutamisega vanemate Git-commit'ide või Git-harude ehituste kordamisel.

Kasutage julgelt! Ja ärge unustage meie juurde vaadata GitHub, et luua probleem või leida juba olemasolev, anda plusspoole, esitada PR või lihtsalt jälgida projekti arengut.