a nyílt forráskódú GitOps CLI segédprogramunk, amely alkalmazások készítésére és Kubernetes számára történő szállítására szolgál. BAN BEN új funkciót vezettek be a képgyűjtőben: a képek tartalom szerinti címkézése ill tartalom alapú címkézés. Eddig a werf tipikus címkézési sémája a Docker-képek Git tag, Git branch vagy Git commit segítségével történő címkézését jelentette. De mindezen sémáknak vannak hátrányai, amelyeket az új címkézési stratégia teljesen felold. Részletek róla és arról, hogy miért olyan jó, a cikk alatt találhatók.
Mikroszolgáltatások készletének bevezetése egy Git-tárhelyből
Gyakran előfordul olyan helyzet, amikor egy alkalmazást sok többé-kevésbé független szolgáltatásra osztanak fel. Ezeknek a szolgáltatásoknak a kiadása egymástól függetlenül is megtörténhet: egy vagy több szolgáltatás egyszerre kiadható, míg a többinek változtatás nélkül tovább kell működnie. De a kódtárolás és a projektmenedzsment szempontjából kényelmesebb az ilyen alkalmazásszolgáltatásokat egyetlen tárolóban tartani.
Vannak helyzetek, amikor a szolgáltatások valóban függetlenek, és nem kapcsolódnak egyetlen alkalmazáshoz. Ebben az esetben külön projektekben helyezkednek el, és kiadásuk külön CI/CD folyamatokon keresztül történik minden egyes projektben.
A valóságban azonban a fejlesztők gyakran egyetlen alkalmazást több mikroszolgáltatásra osztanak fel, de mindegyikhez külön tárolót és projektet hoznak létre... egyértelmű túlzás. Erről a helyzetről lesz még szó: több ilyen mikroszolgáltatás található egyetlen projekttárban, és a kiadások egyetlen folyamaton keresztül történnek a CI/CD-ben.
Címkézés Git-ág és Git-címke szerint
Tegyük fel, hogy a leggyakoribb címkézési stratégiát használják - tag-or-branch. Git-ágak esetén a képek az ág nevével vannak megcímkézve, egy ághoz egyszerre csak egy közzétett kép szerepel az ág nevével. A Git-címkék esetében a képek a címke nevének megfelelően vannak címkézve.
Új Git címke létrehozásakor – például egy új verzió kiadásakor – egy új Docker címke jön létre a Docker Registry összes projektképéhez:
-
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
Ezek az új képnevek Helm-sablonokon keresztül kerülnek át a Kubernetes-konfigurációba. A telepítés elindításakor a paranccsal werf deploy mező frissítés alatt áll image a Kubernetes erőforrás-jegyzékbe, és a megfelelő erőforrások újraindítása a megváltozott képnév miatt.
probléma: abban az esetben, ha valójában a kép tartalma nem változott az előző közzététel óta (Git címke), hanem csak a Docker címkéje, ez történik felesleg az alkalmazás újraindítása, és ennek megfelelően némi leállás lehetséges. Bár nem volt igazi oka ennek az újraindításnak.
Ennek eredményeként a jelenlegi címkézési sémával több különálló Git-tárolót kell elkeríteni, és felmerül a probléma e több tároló telepítésének megszervezése. Általában egy ilyen rendszer túlterheltnek és összetettnek bizonyul. Jobb, ha sok szolgáltatást egyetlen tárolóba egyesít, és Docker-címkéket hoz létre, hogy ne legyen szükségtelen újraindítás.
Címkézés a Git commit által
A werf rendelkezik egy címkézési stratégiával is, amely a Git commitokhoz kapcsolódik.
A Git-commit a Git-tárak tartalmának azonosítója, és a Git-tárházban lévő fájlok szerkesztési előzményeitől függ, ezért logikusnak tűnik a használata a Docker Registry-ben lévő képek címkézésére.
A Git commit címkézésnek azonban ugyanazok a hátrányai vannak, mint a Git ágak vagy Git címkék általi címkézésnek:
- Létrehozhat egy üres véglegesítést, amely nem módosít egyetlen fájlt sem, de a kép Docker címkéje módosul.
- Létrehozható egy összevonási véglegesítés, amely nem módosítja a fájlokat, de a kép Docker-címkéje módosul.
- Elvégezhető egy véglegesítés, amely megváltoztatja azokat a Git-fájlokat, amelyek nincsenek importálva a képbe, és a kép Docker-címkéje ismét megváltozik.
A Git ág nevének címkézése nem tükrözi a kép verzióját
Van egy másik probléma is a Git-ágak címkézési stratégiájával kapcsolatban.
Az ágnév szerinti címkézés mindaddig működik, amíg az adott ágra vonatkozó kötelezettségvállalásokat kronológiai sorrendben egymás után gyűjtik össze.
Ha a jelenlegi sémában a felhasználó egy bizonyos ághoz társított régi véglegesítés újjáépítésébe kezd, akkor a werf átírja a képet a megfelelő Docker címkével a kép újonnan épített verziójával a régi véglegesítéshez. Az ezt a címkét használó telepítések ezentúl azzal a kockázattal járnak, hogy a pod-ok újraindításakor a kép egy másik verzióját húzzák ki, aminek következtében alkalmazásunk elveszíti kapcsolatát a CI rendszerrel, és deszinkronizálódik.
Ezen túlmenően, ha egy ágba egymás után tolja be rövid idővel, előfordulhat, hogy a régi véglegesítés később fordítható le, mint az újabb: a kép régi verziója felülírja az újat a Git ág címkével. Az ilyen problémákat meg lehet oldani egy CI/CD rendszerrel (például a GitLab CI-ben ez utóbbi folyamatát elindítják egy sor véglegesítésre). Azonban nem minden rendszer támogatja ezt, és megbízhatóbb módszert kell találni egy ilyen alapvető probléma megelőzésére.
Mi az a tartalom alapú címkézés?
Tehát mi az a tartalom alapú címkézés – képek tartalom szerinti címkézése.
A Docker címkék létrehozásához nem Git primitíveket (Git ág, Git tag...) használunk, hanem egy ellenőrző összeget, amely a következőkhöz van társítva:
- a kép tartalma. A képazonosító címke a tartalmát tükrözi. Új verzió készítésekor ez az azonosító nem változik, ha a képen lévő fájlok nem változtak;
- a kép létrehozásának története a Gitben. A különböző Git-ágakhoz és a werf-en keresztül különböző összeállítási előzményekhez társított képek eltérő azonosító címkékkel rendelkeznek.
Ilyen azonosító címke az ún kép színpadi aláírás.
Minden kép egy sor szakaszból áll: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch stb. Minden szakasznak van egy azonosítója, amely tükrözi a tartalmát − színpadi aláírás (színpadi aláírás).
A végső kép, amely ezekből a szakaszokból áll, a szakaszok halmazának úgynevezett aláírásával van ellátva - szakaszok aláírása, - ami a kép minden szakaszára általánosító.
Minden egyes képhez a konfigurációból werf.yaml általános esetben lesz saját aláírása és ennek megfelelően egy Docker címke.
A színpadi aláírás mindezen problémákat megoldja:
- Ellenáll az üres Git commitoknak.
- Resistant to Git commit, amely megváltoztatja a kép szempontjából nem releváns fájlokat.
- Nem vezet a kép jelenlegi verziójának felülvizsgálatához, amikor újraindítja a buildeket egy ág régi Git commitjaihoz.
Most ez az ajánlott címkézési stratégia, és ez az alapértelmezett werf minden CI rendszerben.
Hogyan lehet engedélyezni és használni a werf-ben
A parancsnak most van egy megfelelő opciója werf publish: --tag-by-stages-signature=true|false
CI-rendszerben a címkézési stratégiát a parancs határozza meg werf ci-env. Korábban a paraméter definiálva volt hozzá werf ci-env --tagging-strategy=tag-or-branch. Most, ha megadod werf ci-env --tagging-strategy=stages-signature vagy ne adja meg ezt a beállítást, a werf alapértelmezés szerint a címkézési stratégiát fogja használni stages-signature. Csapat werf ci-env automatikusan beállítja a parancshoz szükséges jelzőket werf build-and-publish (vagy werf publish), így ezekhez a parancsokhoz nem kell további beállításokat megadni.
Például a parancs:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature...a következő képeket hozhatja létre:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
Itt 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d a kép szakaszainak aláírása backendÉs f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - képi szakaszok aláírása frontend.
Speciális funkciók használatakor werf_container_image и werf_container_env A Helm sablonokon semmit nem kell módosítani: ezek a funkciók automatikusan generálják a megfelelő képneveket.
Példa konfigurációs CI rendszerben:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployA konfigurációról további információ a dokumentációban található:
- ;
- ;
- .
Összességében
- Új lehetőség
werf publish --tag-by-stages-signature=true|false. - Új opció értéke
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(ha nincs megadva, az alapértelmezett leszstages-signature). - Ha korábban használta a címkézési beállításokat a Git commits (
WERF_TAG_GIT_COMMITvagy opciówerf publish --tag-git-commit COMMIT), akkor mindenképpen váltson a címkézési stratégiára szakaszok-aláírás. - Jobb, ha azonnal átállítja az új projekteket az új címkézési sémára.
- A werf 1.1-re való átvitelkor célszerű a régi projekteket átállítani az új címkézési sémára, de a régit tag-or-branch továbbra is támogatott.
A tartalom alapú címkézés megoldja a cikkben tárgyalt összes problémát:
- A Docker-címkenév ellenállása az üres Git-commit-okkal szemben.
- A Docker-címke nevének rugalmassága a Git-hez, amely megváltoztatja a kép szempontjából irreleváns fájlokat.
- Nem vezet a kép jelenlegi verziójának felülvizsgálatához, amikor újraindítja a régi Git-commits Git-ágakra vonatkozó buildeket.
Használd! És ne felejtsen el ellátogatni hozzánk egy probléma létrehozásához vagy egy meglévő megtalálásához, hozzáadhat egy pluszt, létrehozhat PR-t, vagy egyszerűen csak figyelheti a projekt fejlődését.
PS
Olvassa el blogunkon is:
- «»
- «»
- «";
- Egy sor megjegyzés a werf újításairól:
- «";
- «";
- «";
- «".
Forrás: will.com