🥇Etiquetado baseado no contido no colector werf: por que e como funciona?

werf é a nosa utilidade CLI GitOps de código aberto para crear e entregar aplicacións a Kubernetes. EN versión v1.1 introduciuse unha nova función no colector de imaxes: etiquetar imaxes por contido ou etiquetaxe baseada no contido. Ata agora, o esquema de etiquetado típico en werf implicaba etiquetar as imaxes de Docker por etiqueta Git, rama Git ou Git commit. Pero todos estes esquemas teñen desvantaxes que se solucionan completamente coa nova estratexia de etiquetado. Os detalles sobre el e por que é tan bo están baixo o corte.

Lanzamento dun conxunto de microservizos desde un repositorio de Git

A miúdo ocorre unha situación cando unha aplicación está dividida en moitos servizos máis ou menos independentes. Os lanzamentos destes servizos poden producirse de forma independente: pódense lanzar un ou máis servizos á vez, mentres que o resto debe seguir funcionando sen ningún cambio. Pero desde o punto de vista do almacenamento de código e da xestión de proxectos, é máis conveniente manter estes servizos de aplicacións nun único repositorio.

Hai situacións nas que os servizos son verdadeiramente independentes e non están asociados a unha única aplicación. Neste caso, situaranse en proxectos separados e a súa liberación realizarase mediante procesos CI/CD separados en cada un dos proxectos.

Non obstante, en realidade, os desenvolvedores adoitan dividir unha única aplicación en varios microservizos, pero crear un repositorio e un proxecto separados para cada un... é un claro exceso. É esta situación a que se discutirá máis adiante: varios destes microservizos están situados nun só repositorio do proxecto e os lanzamentos prodúcense a través dun único proceso en CI/CD.

Etiquetado por rama de Git e etiqueta de Git

Digamos que se usa a estratexia de etiquetado máis común: etiqueta ou rama. Para as ramas de Git, as imaxes están etiquetadas co nome da rama, para unha rama á vez só hai unha imaxe publicada co nome desa rama. Para as etiquetas Git, as imaxes están etiquetadas segundo o nome da etiqueta.

Cando se crea unha nova etiqueta Git, por exemplo, cando se publica unha nova versión, crearase unha nova etiqueta Docker para todas as imaxes do proxecto no Rexistro de 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

Estes novos nomes de imaxe pásanse a través de modelos de Helm á configuración de Kubernetes. Ao iniciar o despregamento co comando werf deploy campo estase actualizando image nos manifestos de recursos de Kubernetes e reiniciando os recursos correspondentes debido ao nome da imaxe modificado.

problema: no caso de que, de feito, o contido da imaxe non cambiou desde o lanzamento anterior (etiqueta Git), senón só a súa etiqueta Docker, isto ocorre extra reiniciando esta aplicación e, en consecuencia, é posible un tempo de inactividade. Aínda que non había ningún motivo real para realizar este reinicio.

Como resultado, co esquema de etiquetado actual é necesario cercar varios repositorios Git separados e xorde o problema de organizar o lanzamento destes varios repositorios. En xeral, tal esquema resulta ser sobrecargado e complexo. É mellor combinar moitos servizos nun só repositorio e crear etiquetas Docker para que non haxa reinicios innecesarios.

Etiquetado por Git commit

werf tamén ten unha estratexia de etiquetado asociada aos commits de Git.

Git-commit é un identificador para o contido dun repositorio de Git e depende do historial de edición dos ficheiros do repositorio de Git, polo que parece lóxico usalo para etiquetar imaxes no Rexistro de Docker.

Non obstante, a etiquetaxe mediante Git commit ten as mesmas desvantaxes que a etiquetaxe por ramas de Git ou etiquetas Git:

Pódese crear un commit baleiro que non cambie ningún ficheiro, pero a etiqueta Docker da imaxe cambiarase.
Pódese crear unha confirmación de combinación que non cambie os ficheiros, pero a etiqueta Docker da imaxe cambiarase.
Pódese crear un commit que cambie os ficheiros en Git que non se importan na imaxe e a etiqueta Docker da imaxe cambiarase de novo.

Etiquetar o nome da rama de Git non reflicte a versión da imaxe

Hai outro problema asociado coa estratexia de etiquetado para as ramas de Git.

A etiquetaxe polo nome da rama funciona sempre que os commits desa rama se recollan secuencialmente en orde cronolóxica.

Se no esquema actual o usuario comeza a reconstruír un commit antigo asociado a unha determinada rama, entón werf reescribirá a imaxe usando a etiqueta Docker correspondente cunha versión recentemente construída da imaxe para o commit antigo. Os despregamentos que utilicen esta etiqueta a partir de agora corren o risco de sacar unha versión diferente da imaxe ao reiniciar pods, polo que a nosa aplicación perderá a conexión co sistema CI e quedará desincronizado.

Ademais, con empuxóns sucesivos nunha rama cun curto período de tempo entre elas, a commit antiga pode compilarse máis tarde que a máis nova: a versión antiga da imaxe sobrescribirá a nova usando a etiqueta de rama de Git. Estes problemas pódense resolver mediante un sistema CI/CD (por exemplo, en GitLab CI, a canalización deste último lánzase para unha serie de commits). Non obstante, non todos os sistemas admiten isto e debe haber unha forma máis fiable de previr un problema tan fundamental.

Que é a etiquetaxe baseada no contido?

Entón, que é a etiquetaxe baseada no contido: etiquetar imaxes por contido.

Para crear etiquetas Docker, non se usan primitivas de Git (rama Git, etiqueta Git...), senón unha suma de comprobación asociada a:

contidos da imaxe. A etiqueta ID da imaxe reflicte o seu contido. Ao crear unha nova versión, este identificador non cambiará se os ficheiros da imaxe non cambiaron;
historial de creación desta imaxe en Git. As imaxes asociadas con diferentes ramas de Git e diferentes historiais de compilación a través de werf terán diferentes etiquetas de identificación.

Tal etiqueta identificadora é a chamada sinatura da etapa da imaxe.

Cada imaxe consta dun conxunto de etapas: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch etc. Cada etapa ten un identificador que reflicte o seu contido − sinatura de escenario (sinatura de escenario).

A imaxe final, que consta destas etapas, está etiquetada coa chamada sinatura do conxunto destas etapas - sinatura de etapas, - que é xeneralizador para todas as fases da imaxe.

Para cada imaxe da configuración werf.yaml no caso xeral, haberá sinatura propia e, en consecuencia, etiqueta Docker.

A sinatura do escenario resolve todos estes problemas:

Resistente aos commits de Git baleiros.
Resistant to Git commits que cambian ficheiros que non son relevantes para a imaxe.
Non leva ao problema de revisar a versión actual da imaxe ao reiniciar as compilacións para as antigas confirmacións de Git dunha rama.

Esta é agora a estratexia de etiquetado recomendada e é a predeterminada en werf para todos os sistemas CI.

Como activar e usar en werf

O comando agora ten unha opción correspondente werf publish: --tag-by-stages-signature=true|false

Nun sistema CI, a estratexia de etiquetado é especificada polo comando werf ci-env. Anteriormente, definiuse o parámetro para iso werf ci-env --tagging-strategy=tag-or-branch. Agora, se o especificas werf ci-env --tagging-strategy=stages-signature ou non especifique esta opción, werf usará a estratexia de etiquetado por defecto stages-signature. Equipo werf ci-env establecerá automaticamente as marcas necesarias para o comando werf build-and-publish (Ou werf publish), polo que non é necesario especificar opcións adicionais para estes comandos.

Por exemplo, o comando:

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

...pode crear as seguintes imaxes:

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

Aquí 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d é unha sinatura das etapas da imaxe backendE f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - sinatura das etapas da imaxe frontend.

Cando se usan funcións especiais werf_container_image и werf_container_env Non hai que cambiar nada nos modelos Helm: estas funcións xerarán automaticamente os nomes de imaxe correctos.

Exemplo de configuración nun sistema CI:

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

Máis información sobre a configuración está dispoñible na documentación:

En total

Nova opción werf publish --tag-by-stages-signature=true|false.
Novo valor da opción werf ci-env --tagging-strategy=stages-signature|tag-or-branch (se non se especifica, o valor predeterminado será stages-signature).
Se usaches anteriormente as opcións de etiquetado para as confirmacións de Git (WERF_TAG_GIT_COMMIT ou opción werf publish --tag-git-commit COMMIT), a continuación, asegúrate de cambiar á estratexia de etiquetado etapas-sinatura.
É mellor cambiar inmediatamente os novos proxectos ao novo esquema de etiquetado.
Ao transferir a werf 1.1, é recomendable cambiar os proxectos antigos ao novo esquema de etiquetado, pero o antigo etiqueta ou rama aínda é compatible.

A etiquetaxe baseada no contido resolve todos os problemas tratados no artigo:

Resistencia do nome da etiqueta Docker aos commits de Git baleiros.
A resistencia do nome da etiqueta Docker aos compromisos de Git que cambian ficheiros irrelevantes para a imaxe.
Non leva ao problema de revisar a versión actual da imaxe ao reiniciar as compilacións para as antigas confirmacións de Git para as ramas de Git.

Úsao! E non esquezas visitarnos en GitHubpara crear un problema ou atopar un existente, engadir un plus, crear un PR ou simplemente ver o desenvolvemento do proxecto.

PS

Lea tamén no noso blog:

Fonte: www.habr.com

Etiquetado baseado no contido no werf builder: por que e como funciona?