Get best of the week

Etiquetado basado en contenido en werf collector: ¿por qué y cómo funciona?



werf es nuestra utilidad CLI GitOps de código abierto para crear y entregar aplicaciones a Kubernetes. En la versión v1.1 tiene una nueva característica para el colector de imágenes: etiquetado de imágenes por contenido o etiquetado basado en contenido . Hasta ahora, el esquema de etiquetado típico en werf implicaba etiquetar imágenes de Docker usando una etiqueta Git, una rama Git o una confirmación Git. Pero todos estos esquemas tienen fallas que están completamente resueltas por la nueva estrategia de etiquetado. Detalles sobre ella y por qué es tan buena, debajo del corte.

Deshacer un conjunto de microservicios de un repositorio Git


A menudo hay una situación en la que la aplicación se divide en muchos servicios más o menos independientes. Las versiones de estos servicios pueden ocurrir de manera independiente: uno o varios servicios pueden ser lanzados a la vez, mientras que el resto debe continuar funcionando sin ningún cambio. Pero desde el punto de vista del almacenamiento de código y la gestión de proyectos, es más conveniente mantener dichos servicios de aplicaciones en un único repositorio.

Hay situaciones en las que los servicios son verdaderamente independientes y no están conectados con una sola aplicación. En este caso, se ubicarán en proyectos separados y su lanzamiento se realizará a través de procesos CI / CD separados en cada uno de los proyectos.

Sin embargo, en realidad, los desarrolladores a menudo dividen una sola aplicación en varios microservicios, pero tener un repositorio y un proyecto separados para cada ... es una exageración obvia. Es sobre esta situación que se discutirá más a fondo: varios de estos microservicios se encuentran en un único repositorio de proyectos y las versiones se producen a través de un solo proceso en CI / CD.

Etiqueta Git y etiquetado Git


Digamos que se usa la estrategia de etiquetado más común: etiqueta o rama . Para las ramas de Git, las imágenes se etiquetan con el nombre de la rama, para una rama a la vez solo hay una imagen publicada nombrada para esta rama. Para las etiquetas Git, las imágenes se etiquetan de acuerdo con el nombre de la etiqueta.

Al crear una nueva etiqueta Git, por ejemplo, cuando se lanza una nueva versión, se creará una nueva etiqueta Docker para todas las imágenes del proyecto en el Registro 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

Estos nuevos nombres de imágenes atraviesan los patrones de Helm en la configuración de Kubernetes. Cuando comienza la implementación, el equipo werf deployactualiza el campo imageen los manifiestos de recursos de Kubernetes y reinicia los recursos correspondientes debido al nombre de la imagen modificada.

Problema : en un caso donde el vykata anterior (etiqueta Git) no ha cambiado el contenido de la imagen, sino solo su etiqueta Docker que ocurre una vez que reinicia esta aplicación y, en consecuencia, algunas posibles. Aunque no había una razón real para hacer este reinicio.

Como resultado, con el esquema de etiquetado actual, debe cerrar varios repositorios Git separados y surge el problema de organizar el despliegue de estos repositorios. En general, dicho esquema está sobrecargado y es complejo. Es mejor combinar muchos servicios en un único repositorio y crear tales etiquetas Docker para que no haya reinicios innecesarios.

Etiquetado Git commit


Werf también tiene una estrategia de etiquetado relacionada con los compromisos de Git.

Git-commit es el identificador del contenido del repositorio de Git y depende del historial de ediciones de archivos en el repositorio de Git, por lo que parece lógico usarlo para etiquetar imágenes en el Registro de Docker.

Sin embargo, el etiquetado por Git commit tiene los mismos inconvenientes que las ramas de Git o las etiquetas de Git:

  • , , Docker- .
  • merge-, , Docker- .
  • , Git, , Docker- .

Git-


Hay otro problema relacionado con la estrategia de etiquetado para las ramas de Git.

El etiquetado por el nombre de una rama funciona siempre que los commits de esta rama se recopilen secuencialmente en orden cronológico.

Si en el esquema actual el usuario comienza a reconstruir la confirmación anterior asociada con alguna rama, werf borrará la imagen utilizando la etiqueta Docker correspondiente con la versión recién ensamblada de la imagen para la confirmación anterior. Las implementaciones que usan esta etiqueta a partir de ahora en riesgo durante el reinicio del pod para extraer otra versión de la imagen, como resultado de lo cual nuestra aplicación perderá la conexión con el sistema CI y no estará sincronizada.

Además, con push'ahs consecutivos en una rama con un pequeño intervalo de tiempo entre ellos, la confirmación anterior se puede recopilar más tarde que la nueva: la versión anterior de la imagen borrará la nueva usando la etiqueta de la rama Git. Tales problemas pueden ser resueltos por el sistema CI / CD (por ejemplo, en GitLab CI, la tubería de este último se lanza para una serie de confirmaciones). Sin embargo, esto no es compatible con todos los sistemas y debería haber una forma más confiable de prevenir un problema tan fundamental.

¿Qué es el etiquetado basado en contenido?


Entonces, qué es exactamente el etiquetado basado en contenido: etiquetar imágenes por contenido.

Para crear etiquetas Docker, no se usan primitivas Git (rama Git, etiqueta Git ...), sino una suma de verificación asociada con:

  • . - . , ;
  • Git. , Git- werf, -.

La llamada firma de las etapas de la imagen actúa como una etiqueta de identificación .

Cada imagen consiste en una serie de pasos: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patchetc. Cada etapa tiene un identificador, que refleja su contenido: la etapa de firma (firma de etapa) .

La imagen final, que consta de estas etapas, está etiquetada con la llamada firma del conjunto de estas etapas, la firma de etapas , que se generaliza para todas las etapas de la imagen.

Cada imagen de la configuración werf.yamlgeneralmente tendrá su propia firma y, en consecuencia, la etiqueta Docker.

La firma del escenario resuelve todos estos problemas:

  • Resistente al vacio git commits.
  • Resistente a las confirmaciones de git que cambian archivos que no son relevantes para la imagen.
  • No conduce a un problema con el rectificado de la versión actual de la imagen al reiniciar ensamblajes para las confirmaciones de Git antiguas de la rama.

Esta es ahora la estrategia de etiquetado recomendada y se usa por defecto en werf para todos los sistemas de CI.

Cómo habilitar y usar en werf


La opción correspondiente apareció para el equipo werf publish: --tag-by-stages-signature=true|false

en el sistema CI, el comando establece la estrategia de etiquetado werf ci-env. Anteriormente, se definía un parámetro para ello werf ci-env --tagging-strategy=tag-or-branch. Ahora, si especifica werf ci-env --tagging-strategy=stages-signatureesta opción o no, werf utilizará una estrategia de etiquetado de forma predeterminada stages-signature. El comando werf ci-envestablecerá automáticamente los indicadores necesarios para el comando werf build-and-publish(o werf publish), por lo tanto, no es necesario especificar opciones adicionales para estos comandos.

Por ejemplo, el comando:

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

... puede crear las siguientes imágenes:

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

Aquí 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386destá la firma de las etapas de la imagen backend, y f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6es la firma de las etapas de la imagen frontend.

Cuando se utilizan funciones especiales werf_container_imagey werf_container_enven plantillas de Helm, no es necesario cambiar nada: estas funciones generarán automáticamente los nombres de imagen correctos.

Ejemplo de configuración en un sistema CI:

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

Más información de configuración está disponible en la documentación:


Total


  • Nueva opción werf publish --tag-by-stages-signature=true|false.
  • El nuevo valor de la opción werf ci-env --tagging-strategy=stages-signature|tag-or-branch(si no se especifica, será por defecto stages-signature).
  • Si las opciones de etiquetado para las confirmaciones de Git se usaron antes ( WERF_TAG_GIT_COMMITo la opción werf publish --tag-git-commit COMMIT), asegúrese de cambiar a la estrategia de etiquetado de firma por etapas .
  • Los nuevos proyectos son mejores para cambiar inmediatamente a un nuevo esquema de etiquetado.
  • Al traducir a werf 1.1, es aconsejable cambiar los proyectos antiguos al nuevo esquema de etiquetado, sin embargo, la antigua etiqueta o rama todavía es compatible.

El etiquetado basado en contenido resuelve todos los problemas destacados en el artículo:

  • Estabilidad de nombre de etiqueta Docker para vaciar git commits.
  • La estabilidad del nombre de la etiqueta Docker para Git confirma que cambian los archivos que no son relevantes para la imagen.
  • No conduce a un problema con el rectificado de la versión actual de la imagen al reiniciar ensamblajes para compromisos Git antiguos para ramas Git.

Úsalo! Y no olvide pasar por nuestro GitHub para crear un problema o encontrar uno existente, poner un plus, crear un PR o simplemente ver el desarrollo del proyecto.

PD


Lea también en nuestro blog:

More articles:


All Articles