és la nostra utilitat GitOps CLI de codi obert per crear i lliurar aplicacions a Kubernetes. EN es va introduir una nova característica al col·lector d'imatges: etiquetar imatges per contingut o etiquetatge basat en contingut. Fins ara, l'esquema d'etiquetatge típic de werf consistia a etiquetar imatges de Docker per etiqueta Git, branca Git o Git commit. Però tots aquests esquemes tenen desavantatges que es resolen completament amb la nova estratègia d'etiquetatge. Els detalls sobre això i per què és tan bo estan sota el tall.
Desplegant un conjunt de microserveis des d'un dipòsit de Git
Sovint es produeix una situació quan una aplicació es divideix en molts serveis més o menys independents. Els llançaments d'aquests serveis es poden produir de manera independent: es poden alliberar un o més serveis alhora, mentre que la resta han de continuar funcionant sense cap canvi. Però des del punt de vista de l'emmagatzematge de codi i la gestió de projectes, és més convenient mantenir aquests serveis d'aplicacions en un únic repositori.
Hi ha situacions en què els serveis són realment independents i no estan associats a una sola aplicació. En aquest cas, s'ubicaran en projectes separats i el seu llançament es realitzarà mitjançant processos CI/CD separats en cadascun dels projectes.
Tanmateix, en realitat, els desenvolupadors sovint divideixen una sola aplicació en diversos microserveis, però crear un repositori i un projecte separats per a cadascun... és una exageració clara. És aquesta situació la que es tractarà més endavant: diversos d'aquests microserveis es troben en un únic repositori del projecte i els llançaments es produeixen mitjançant un únic procés en CI/CD.
Etiquetatge per branca de Git i etiqueta de Git
Suposem que s'utilitza l'estratègia d'etiquetatge més habitual: etiqueta o branca. Per a les branques de Git, les imatges s'etiqueten amb el nom de la branca, per a una branca a la vegada només hi ha una imatge publicada amb el nom d'aquesta branca. Per a les etiquetes Git, les imatges s'etiqueten segons el nom de l'etiqueta.
Quan es crea una nova etiqueta Git, per exemple, quan es publica una nova versió, es crearà una nova etiqueta Docker per a totes les imatges del projecte al registre Docker:
-
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
Aquests nous noms d'imatges es passen a través de plantilles Helm a la configuració de Kubernetes. Quan s'inicia el desplegament amb l'ordre werf deploy camp s'està actualitzant image als manifests de recursos de Kubernetes i reiniciant els recursos corresponents a causa del canvi de nom de la imatge.
problema: en el cas que, de fet, el contingut de la imatge no hagi canviat des del llançament anterior (etiqueta Git), sinó només la seva etiqueta Docker, això passa excés reiniciant aquesta aplicació i, en conseqüència, és possible un temps d'inactivitat. Tot i que no hi havia cap motiu real per dur a terme aquest reinici.
Com a resultat, amb l'esquema d'etiquetatge actual és necessari tancar diversos dipòsits Git separats i sorgeix el problema d'organitzar el desplegament d'aquests diversos dipòsits. En general, aquest esquema resulta ser sobrecarregat i complex. És millor combinar molts serveis en un sol dipòsit i crear etiquetes Docker perquè no hi hagi reinicis innecessaris.
Etiquetat per Git commit
werf també té una estratègia d'etiquetatge associada amb les confirmacions de Git.
Git-commit és un identificador per al contingut d'un repositori Git i depèn de l'historial d'edició dels fitxers del repositori Git, per la qual cosa sembla lògic utilitzar-lo per etiquetar imatges al Registre Docker.
Tanmateix, l'etiquetatge per Git commit té els mateixos desavantatges que l'etiquetatge per branques de Git o etiquetes de Git:
- Es podria crear una confirmació buida que no canviï cap fitxer, però es canviarà l'etiqueta Docker de la imatge.
- Es podria crear una confirmació de combinació que no canviï els fitxers, però es canviarà l'etiqueta Docker de la imatge.
- Es podria fer una confirmació que canviï els fitxers de Git que no s'importen a la imatge i es tornarà a canviar l'etiqueta Docker de la imatge.
L'etiquetatge del nom de la branca de Git no reflecteix la versió de la imatge
Hi ha un altre problema associat a l'estratègia d'etiquetatge per a les branques de Git.
L'etiquetatge pel nom de la branca funciona sempre que les confirmacions d'aquesta branca es recullin seqüencialment en ordre cronològic.
Si en l'esquema actual l'usuari comença a reconstruir una confirmació antiga associada a una branca determinada, aleshores werf reescriurà la imatge utilitzant l'etiqueta Docker corresponent amb una versió recentment construïda de la imatge per a la confirmació antiga. Els desplegaments que utilitzen aquesta etiqueta a partir d'ara corren el risc de treure una versió diferent de la imatge quan es reinicien els pods, de manera que la nostra aplicació perdrà la connexió amb el sistema CI i es dessincronitzarà.
A més, amb impulsos successius a una branca amb un curt període de temps entre elles, la confirmació antiga es pot compilar més tard que la nova: la versió antiga de la imatge sobreescriurà la nova utilitzant l'etiqueta de branca de Git. Aquests problemes es poden resoldre mitjançant un sistema CI/CD (per exemple, a GitLab CI, el pipeline d'aquest últim es llança per a una sèrie de commits). Tanmateix, no tots els sistemes admeten això i hi ha d'haver una manera més fiable de prevenir un problema tan fonamental.
Què és l'etiquetatge basat en contingut?
Aleshores, què és l'etiquetatge basat en contingut: etiquetar imatges per contingut.
Per crear etiquetes Docker, no s'utilitzen primitives Git (branca Git, etiqueta Git...), sinó una suma de control associada a:
- continguts de la imatge. L'etiqueta d'identificació de la imatge reflecteix el seu contingut. Quan es construeix una nova versió, aquest identificador no canviarà si els fitxers de la imatge no han canviat;
- historial de creació d'aquesta imatge a Git. Les imatges associades amb diferents branques de Git i diferents historials de compilació mitjançant werf tindran diferents etiquetes d'identificació.
Aquesta etiqueta identificadora és l'anomenada signatura de l'escenari de la imatge.
Cada imatge consta d'un conjunt d'etapes: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch etc. Cada etapa té un identificador que reflecteix el seu contingut − signatura escènica (signatura escènica).
La imatge final, que consta d'aquestes etapes, està etiquetada amb l'anomenada signatura del conjunt d'aquestes etapes - signatura d'etapes, - que s'està generalitzant per a totes les etapes de la imatge.
Per a cada imatge de la configuració werf.yaml en el cas general, hi haurà la seva pròpia signatura i, en conseqüència, una etiqueta Docker.
La signatura d'escenari resol tots aquests problemes:
- Resistent a les confirmacions de Git buides.
- Resistent a les confirmacions de Git que canvien fitxers que no són rellevants per a la imatge.
- No comporta el problema de revisar la versió actual de la imatge quan es reinicien les compilacions per a les commits antigues de Git d'una branca.
Aquesta és ara l'estratègia d'etiquetatge recomanada i és la predeterminada a werf per a tots els sistemes CI.
Com activar i utilitzar a werf
L'ordre ara té una opció corresponent werf publish: --tag-by-stages-signature=true|false
En un sistema CI, l'estratègia d'etiquetatge s'especifica mitjançant l'ordre werf ci-env. Anteriorment, s'havia definit el paràmetre per a això werf ci-env --tagging-strategy=tag-or-branch. Ara, si ho especifiqueu werf ci-env --tagging-strategy=stages-signature o no especifiqueu aquesta opció, werf utilitzarà l'estratègia d'etiquetatge per defecte stages-signature. Equip werf ci-env establirà automàticament els senyaladors necessaris per a l'ordre werf build-and-publish (O werf publish), de manera que no cal especificar cap opció addicional per a aquestes ordres.
Per exemple, l'ordre:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature...pot crear les imatges següents:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
Aquí 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d és una signatura de les etapes de la imatge backendI f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - Signatura d'etapes d'imatge frontend.
Quan utilitzeu funcions especials werf_container_image и werf_container_env No cal canviar res a les plantilles Helm: aquestes funcions generaran automàticament els noms d'imatges correctes.
Exemple de configuració en un sistema CI:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployMés informació sobre la configuració està disponible a la documentació:
- ;
- ;
- .
En total
- Nova opció
werf publish --tag-by-stages-signature=true|false. - Nou valor d'opció
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(si no s'especifica, el valor predeterminat seràstages-signature). - Si abans heu utilitzat les opcions d'etiquetatge per a les confirmacions de Git (
WERF_TAG_GIT_COMMITo opciówerf publish --tag-git-commit COMMIT), després assegureu-vos de canviar a l'estratègia d'etiquetatge etapes-signatura. - És millor canviar immediatament els nous projectes al nou esquema d'etiquetatge.
- Quan es transfereix a werf 1.1, és recomanable canviar els projectes antics al nou esquema d'etiquetatge, però l'antic etiqueta o branca encara es dóna suport.
L'etiquetatge basat en contingut resol tots els problemes tractats a l'article:
- Resistència del nom de l'etiqueta Docker a les confirmacions de Git buides.
- La resiliència del nom de l'etiqueta Docker a les confirmacions de Git que canvien els fitxers irrellevants per a la imatge.
- No comporta el problema de revisar la versió actual de la imatge quan es reinicien les compilacions per a les commits antigues de Git per a les branques de Git.
Utilitza-ho! I no us oblideu de visitar-nos a per crear un problema o trobar-ne un existent, afegir un plus, crear un PR o simplement veure el desenvolupament del projecte.
PS
Llegeix també al nostre blog:
- «»
- «»
- «»;
- Una sèrie de notes sobre les innovacions en werf:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com