El tema del monorepository se ha discutido más de una vez y, como regla, provoca un debate muy activo. Al crear
werf como una herramienta de código abierto diseñada para mejorar el proceso de
compilación de código de aplicación de imágenes de Git a Docker (y su posterior envío a Kubernetes), no pensamos mucho en qué opción es mejor. Para nosotros, es fundamental proporcionar todo lo necesario para los partidarios de diferentes opiniones (si esto no contradice el sentido común, por supuesto).
El reciente soporte para mono-repo en werf es un buen ejemplo. Pero primero, veamos cómo este soporte está generalmente asociado con el uso de werf y qué tiene que ver el Registro de Docker con él ...
Problema
Imagina esta situación. La compañía tiene muchos equipos de desarrollo involucrados en proyectos independientes. La mayoría de las aplicaciones se ejecutan en Kubernetes y, en consecuencia, están en contenedores. Para almacenar contenedores, imágenes, se requiere un registro. La compañía utiliza Docker Hub con una sola cuenta de
COMPANY como tal registro. Similar a la mayoría de los sistemas de almacenamiento de código fuente,
Docker Hub no le permite crear una jerarquía anidada de repositorios como
COMPANY/PROJECT/IMAGE . En este caso ... ¿cómo se pueden mantener aplicaciones no monolíticas en el registro con esta restricción sin crear una cuenta separada para cada proyecto?
Quizás la situación descrita es familiar para alguien de primera mano, pero consideremos el problema de organizar el almacenamiento de aplicaciones en general, es decir sin referencia al ejemplo anterior y al Docker Hub.
Soluciones
Si la aplicación es
monolítica , viene en una imagen, entonces no hay preguntas y solo guardamos las imágenes en el repositorio del proyecto.
Cuando una aplicación se presenta en forma de varios componentes,
microservicios , se requiere elegir un enfoque específico. Usando un ejemplo de una aplicación web típica que consta de dos imágenes:
frontend y
backend -
backend , las opciones posibles son las siguientes:
- Almacene imágenes en repositorios anidados separados:
- Almacene todo en un repositorio y tome el nombre de la imagen en la etiqueta, por ejemplo, de la siguiente manera:
NB : En realidad, todavía existe la opción de almacenar PROJECT-frontend y PROJECT-backend en varios repositorios, pero no lo consideraremos debido a la complejidad del soporte, la organización y la distribución de los derechos entre los usuarios.Soporte Werf
Inicialmente, werf se limitó a repositorios anidados; afortunadamente, la mayoría de los registros admiten esta característica. A partir de la versión
v1.0.4-alpha.3 , se ha agregado trabajo con registros en los que
no se admite la anidación , y Docker Hub entre ellos. A partir de este momento, el usuario tenía la opción de almacenar las imágenes de la aplicación.
La implementación está disponible como parte de la opción
--images-repo-mode=multirepo|monorepo (por defecto,
multirepo , es decir, almacenamiento en repositorios anidados). Define los patrones por los cuales las imágenes se almacenan en el registro. Es suficiente elegir el modo deseado al usar los comandos básicos, y todo lo demás permanecerá sin cambios.
Como la mayoría de las opciones de werf se pueden configurar
con variables de entorno , en los sistemas CI / CD, el modo de almacenamiento suele ser fácil de configurar globalmente para todo el proyecto. Por ejemplo,
en el caso de GitLab, simplemente agregue la variable de entorno en la configuración del proyecto:
Configuración -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo .
Si hablamos de publicar imágenes y desplegar aplicaciones (puede leer sobre estos procesos en detalle en los artículos de documentación relevantes:
proceso de publicación y
proceso de implementación ), entonces el modo determina exclusivamente la plantilla con la que puede trabajar con la imagen.
Diablo en detalle
La diferencia y la principal dificultad al agregar un nuevo método de almacenamiento es durante el proceso de limpieza del registro
(para ver las opciones de limpieza compatibles con werf, consulte el proceso de limpieza ) .
Al limpiar, werf tiene en cuenta las imágenes utilizadas en los clústeres de Kubernetes, así como las políticas configuradas por el usuario. Las políticas se basan en dividir las etiquetas en estrategias. Estrategias actualmente soportadas:
- 3 estrategias relacionadas con las primitivas de Git, como tag, branch y commit;
- 1 estrategia para etiquetas personalizadas.
Guardamos información sobre la estrategia de etiqueta al publicar la imagen en las etiquetas de la imagen final. El significado en sí mismo, la llamada
metaetiqueta , es necesaria para la aplicación de algunas políticas. Por ejemplo, al eliminar una rama o etiqueta del repositorio de Git, es lógico eliminar las imágenes
no utilizadas asociadas del registro, que está cubierto por parte de nuestras políticas.
Al guardar en un repositorio (
monorepo ), además de la metaetiqueta, el nombre de la imagen también se puede almacenar en la etiqueta de la imagen:
PROJECT: frontend -META-TAG . Para separarlos, no introdujimos ningún separador específico, simplemente agregamos el valor necesario a la etiqueta de la imagen final al publicar.
NB : si está interesado en ver todo lo descrito en el código fuente werf, entonces PR 1684 puede servir como punto de partida.En este artículo, no prestaremos más atención a los problemas y la justificación de nuestro enfoque: sobre estrategias de etiquetado, almacenamiento de datos en etiquetas y el proceso de publicación en su conjunto; todo esto se describe en detalle en un informe reciente de Dmitry Stolyarov: "
werf es nuestra herramienta para CI / CD en Kubernetes ".
Resumiendo
La falta de soporte de registro sin anidar no fue un factor de bloqueo para nosotros o para los usuarios de werf que conocemos: siempre puede generar un registro de imágenes por separado (o cambiar al Registro de Contenedores condicional en Google Cloud) ... Sin embargo, eliminar esta restricción parecía lógico para que la herramienta fuera más conveniente amplia comunidad de DevOps. Al implementarlo, enfrentamos la principal dificultad para procesar el mecanismo para limpiar el registro del contenedor. Ahora que todo está listo, es bueno saber que se ha vuelto más fácil para alguien, y nosotros (como los principales desarrolladores del proyecto) no tenemos dificultades significativas para respaldar aún más esta función.
¡Quédese con nosotros y muy pronto le informaremos sobre otras innovaciones en
werf !
PS
Lea también en nuestro blog: