🥇Sisu põhine märgistamine werf-i ehitajas: miks ja kuidas see toimib?

werf — meie avatud lähtekoodiga GitOps CLI tööriist rakenduste ehitamiseks ja tarnimiseks Kubernetesesse. V väljaandes v1.1 kasutusele võetud uus võimalus piltide kogujas: piltide märgistamine sisu põhjal või sisu põhine märgistamine. Seni on werf'is tüüpiline märgistamisstrateegia hõlmanud Docker-piltide märgistamist Git-tägi, Git-haru või Git-commit'i järgi. Kuid kõigil neil skeemidel on puudused, mida uus märgistamisstrateegia täielikult lahendab. Üksikasjad selle kohta ja miks see nii hea on — allpool.

Mikroteenuste komplekti väljalaskmine ühest Git-repositaariumist

Sageli esineb olukordi, kus rakendus on jagatud paljude enam-vähem iseseisvate teenuste vahel. Nende teenuste versioonid võivad toimuda iseseisvalt: korraga võib välja tulla üks või mitu teenust, samas kui teised peavad jätkama tööd ilma muudatusteta. Kuid koodi hoidmise ja projekti haldamise seisukohalt on mugavam hoida selliseid rakenduse teenuseid ühes repos.

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

Kuid reaalsuses jagavad arendajad sageli ühte rakendust mitmeks mikroteenuseks, kuid igaühe jaoks eraldi reposse ja projekti rakendamine ... oleks kindlasti üle jõu käiv. Just sellest olukorrast juttu ongi: mitmed sellised mikroteenused asuvad ühes projektirepos ja väljalaskmine toimub ühtse CI/CD protsessi kaudu.

Märgistamine Git-haru ja Git-tägi järgi

Oletame, et kasutatakse kõige levinumat märgistamisstrateegiat — tag-or-branch. Git-harude puhul märgistatakse pildid haru nime järgi, ühel ajal on ühe haru nime järgi avaldatud ainult üks pilt. Git-tägi puhul märgistatakse pildid vastavalt tägi nimele.

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

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 uued nimed jõuavad Helm-mallide kaudu Kubernetes'i konfiguratsiooni. Deployment'i käivitamisel käsuga werf deploy toimub välja muude väljade värskendamine image Kubernetes'i ressursimaaniifestides ja vastavate ressursside taaskäivitamine seoses pildi nime muutumisega.

Probleem: juhul, kui eelmisest väljaandest (Git-tägi) ei ole pildi sisu tegelikult muutunud, vaid ainult selle Docker-tägi, toimub liigne taaskäivitamine, ning seega on võimalik mõningane häirivus. Kuigi selleks ei olnud tegelikke põhjusi.

Tulemusena, praeguse sildistamisstrateegiaga tuleb luua mitu eraldi Git-repositooriumit ning kerkib üles mitu repositooriumi väljaandmise korraldamise probleem. Üldiselt on selline süsteem ülekoormatud ja keeruline. Paremini oleks ühendada mitu teenust ühte repositooriumisse ja luua selliseid Docker-tägesid, et vältida liigseid taaskäivitamisi.

Sildistamine Git-commit’i järgi

Werfis on samuti olemas sildistamistrateegia, mis on seotud Git-commit'idega.

Git-commit on Git-repositooriumi sisu identifikaator ja sõltub failide redigeerimise ajaloost Git-repositooriumis, seega tundub loogiline seda kasutada piltide sildistamiseks Docker Registry's.

Siiski, sildistamine Git-commit’i järgi omab samu puudusi, mis Git-haru või Git-tähe puhul:

Võib olla loodud tühi commit, mis ei muuda faile, ja Docker-tägi muutub.
Võib olla loodud merge-commit, mis ei muuda faile, ja Docker-tägi muutub.
Võib olla loodud commit, mis muudab Git'is faile, mida pildiga ei impordita, ja Docker-tägi muutub taas.

Sildistamine Git-haru nime järgi ei peegelda pildi versiooni

On veel üks probleem, mis on seotud Git-harude sildistamisstrateegiaga.

Haru nime järgi sildistamine töötab seni, kuni selle haru commit'id kogutakse järjestikku ajaliselt.

Kui kasutaja käivitab praeguses skeemis vana commit'i, mis on seotud teatud harudega, värskendab werf vastava Docker-sildi koos uue ehitatud versiooniga vana commit'i jaoks. Selles etapis seonduvad Deployment'id riskivad, et pod'ide taaskäivitamisel tõmmatakse erinev versioon ja meie rakendus kaotab ühenduse CI-süsteemiga ning desünkroniseeritakse.

Lisaks, kui järjestikused push'id teevad ühte haru, mille vahel on väike ajavahemik, võib vana commit ehitada hiljem kui uuem: vana versioon katab uue Git-haru sildi alla. Sellised probleemid võivad lahendada CI/CD-süsteem (nt GitLab CI, kus järjestikuste commit'ide jaoks käivitatakse torujuhe viimase jaoks). Kuid mitte kõik süsteemid ei toetada seda ja peaks olema usaldusväärsem viis selliste fundamentaalsete probleemide vältimiseks.

Mis on sisu põhine sildistamine?

Nii et, mis on sisu põhine sildistamine — sildistamine sisu põhjal.

Docker-siltide loomiseks kasutatakse mitte Git'i primitiive (Git-haru, Git-silt...), vaid kontrollsumma, mis on seotud:

pildi sisuga. Pildi sildi identifikaator peegeldab selle sisu. Uue versiooni ehitamisel ei muutu see identifikaator, kui pildis ei muutu failid;
selle pildi loomise ajalooga Git'is. Erinevatesse Git-harudesse ja erineva ehitusajaloo kaudu werf seotud pildid omavad erinevaid sildi identifikaatoreid.

Sellise identifikaatori sildina esindab nii öeldud etapi allkiri.

Iga pilt koosneb etappide kogumist: from, before-install, git-archive, install, imports-after-install, before-setup,… git-latest-patch jne. Igal etapil on identifikaator, mis peegeldab selle sisu — etapi allkiri (etapi allkiri).

Lõplik pilt, mis koosneb nendest etappidest, on sildistatud nii öeldud etappide kogumi allkirja — etappide allkiri, — mis on üldine kõigi pildi etappide jaoks.

Igal pildil konfigureerimise järgi werf.yaml on tavaliselt oma selline allkiri ja vastavalt Docker-silt.

Etapi allkiri lahendab kõik eeltoodud probleemid:

On resistentne tühi Git-commit'ide suhtes.
On resistentne Git-commit'ide suhtes, mis muudavad faile, mis ei ole pildile asjakohased.
Ei too kaasa probleemi kehtiva pildi versiooni katmisest, kui taaskäivitada ehitusi vanade Git-commit'ide jaoks harust.

Nüüd on see soovitatav märgistamisstrateegia ja seda kasutatakse vaikimisi werf'is kõigis CI-süsteemides.

Kuidas lubada ja kasutada werf'is

Tegelikult sai see valik meeskonna poolt werf publish: --tag-by-stages-signature=true|false

CI-süsteemis määratakse märgistamisstrateegia käsuga werf ci-env. Varem määrati selle jaoks parameeter werf ci-env --tagging-strategy=tag-or-branch. Nüüd, kui näidatakse werf ci-env --tagging-strategy=stages-signature või ei näidata seda valikut, siis werf kasutab vaikimisi märgistamisstrateegiat 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 täiendavaid valikuid vaja näidata.

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 kujutised:

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

Siin 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d — see on pildistamise etapi signatuur backend, vaid f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — etapi signatuur pildi jaoks frontend.

Kasutades spetsiaalseid funktsioone werf_container_image ja werf_container_env Helmi mallides ei pea midagi muutma: need funktsioonid genereerivad automaatselt õiged pildinimed.

Näide CI-süsteemi konfiguratsioonist:

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

Rohkema teabe jaoks seadistamise kohta on saadaval dokumentatsioon:

Kokkuvõttes

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 näidata, siis kasutatakse vaikimisi stages-signature).
Kui varem kasutati Git-kinnitustega märgistamisvalikuid (WERF_TAG_GIT_COMMIT või valikut werf publish --tag-git-commit COMMIT), peab kindlasti üle minema märgistamisstrateegiale stages-signature.
Uued projektid on parem kohe uuele märgistamisstruktuurile üle viia.
Vanad projektid oleks soovitatav viia over werf 1.1, kuid vana tag-or-branch jätkub endiselt.

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

Docker-tagi nime vastupidavus tühjade Git-kinnituste suhtes.
Docker-tagi nime vastupidavus Git-kinnituste suhtes, mis muudavad mitteolulisi faile pildile.
Ei tekita probleeme, kui vana Git-commitide jaoks käivitate ehitusi ja versiooni pildistamine ei toimi.

Kasutage! Ja ärge unustage meid külastada GitHub, et luua issue või leida juba olemasolev, anda pluss, luua PR või lihtsalt jälgida projekti arengut.