El tema del monorepositorio ya se ha discutido en varias ocasiones y, por lo general, provoca debates bastante activos. Al crear una herramienta de código abierto destinada a mejorar los procesos de compilación de aplicaciones desde Git a imágenes Docker (y su posterior entrega en Kubernetes), rara vez reflexionamos sobre cuál es la mejor opción. Para nosotros, lo primordial es garantizar todo lo necesario para los partidarios de diferentes opiniones (siempre que no contravenga el sentido común, por supuesto).
El reciente soporte para mono-repo en werf es un buen ejemplo de esto. Pero primero, aclaremos cómo este soporte se relaciona con el uso de werf y qué tiene que ver con el Docker Registry...
Problemática
Imaginemos una situación. En la empresa hay numerosos equipos de desarrolladores que trabajan en proyectos independientes. La mayoría de las aplicaciones funcionan en Kubernetes, y, por lo tanto, están contenerizadas. Para almacenar los contenedores y las imágenes, se necesita un registro. Como registro, la empresa utiliza Docker Hub con una única cuenta COMPANY. Siguiendo la analogía de la mayoría de los sistemas de almacenamiento de código fuente, Docker Hub no permite crear una jerarquía de repositorios anidada, como COMPANY/PROJECT/IMAGE. En este caso... ¿cómo almacenar en el registro aplicaciones no monolíticas sin crear una cuenta separada para cada proyecto?
Es posible que esta situación sea familiar para algunos, pero consideremos la cuestión de la organización del almacenamiento de aplicaciones en general, es decir, sin atenernos al ejemplo descrito anteriormente y a Docker Hub.
Opciones de solución
Si la aplicación es monolítica, no hay preguntas y simplemente almacenamos las imágenes en el registro de contenedores del proyecto.
Cuando la aplicación se presenta en forma de varios componentes, microservicios, se requiere elegir un enfoque específico. Tomando como ejemplo una aplicación web típica, que consta de dos imágenes: frontend y backend — las posibles opciones son las siguientes:
- Almacenar imágenes en repositorios anidados separados:
- Almacenar todo en un solo repositorio y considerar el nombre de la imagen en la etiqueta, por ejemplo, de la siguiente manera:
NB: En realidad, hay otra opción que consiste en guardar en diferentes repositorios, PROJECT-frontend y PROJECT-backend, pero no la consideraremos debido a la complejidad de soporte, organización y distribución de derechos entre los usuarios.
Soporte en werf
Inicialmente, werf se limitó a repositorios anidados, ya que la mayoría de los registros soportan esta funcionalidad. A partir de la versión , se añadió compatibilidad con registros que no soportan anidamiento, siendo Docker Hub uno de ellos. A partir de este momento, los usuarios tienen la opción de cómo almacenar las imágenes de la aplicación.
La implementación está disponible en el marco de la opción --images-repo-mode=multirepo|monorepo (por defecto, multirepo, es decir, almacenamiento en repositorios anidados). Esta opción define las plantillas según las cuales se almacenan las imágenes en el registro. Basta con seleccionar el modo deseado al utilizar los comandos básicos, y el resto permanecerá sin cambios.
Dado que la mayoría de las opciones de werf se pueden establecer mediante variables de entorno, en sistemas CI/CD, el modo de almacenamiento suele establecerse globalmente para todo el proyecto. Por ejemplo, en el caso de GitLab , es suficiente con agregar una variable de entorno en la configuración del proyecto: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
En términos de publicación de imágenes y despliegue de aplicaciones (se puede leer más sobre estos procesos en los artículos correspondientes de la documentación: y ), el modo únicamente determina la plantilla según la cual se puede trabajar con la imagen.
El diablo está en los detalles
La diferencia y la principal dificultad al agregar un nuevo método de almacenamiento radica en el proceso de limpieza del registro (las capacidades de limpieza soportadas en werf se pueden ver en ).
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. La base de las políticas reside en la división de etiquetas en estrategias. Las estrategias actualmente soportadas son:
- 3 estrategias relacionadas con primitivas de Git, como etiquetas, ramas y confirmaciones;
- 1 estrategia para etiquetas de usuario arbitrarias.
La información sobre la estrategia de etiquetas se guarda al publicar la imagen en las etiquetas de la imagen final. El propio valor, el llamado metatag , es necesario para aplicar parte de las políticas. Por ejemplo, al eliminar una rama o etiqueta del repositorio de Git, es lógico eliminar también las imágenes no utilizadas del registro, lo cual está cubierto por parte de nuestras políticas.
Al guardar en un solo repositorio (monorepo), en la etiqueta de la imagen, además del metatag, también puede almacenarse el nombre de la imagen: PROYECTO:frontend-META-TAG. Para separarlos, no introdujimos un separador específico, sino que simplemente añadimos el valor necesario en la etiqueta de la imagen final al publicarla.
NB: Si te interesa ver todo lo descrito en el código fuente de werf, el punto de partida puede ser .
En este artículo no abordaremos más el problema y la justificación de nuestro enfoque: sobre las estrategias de etiquetado, el almacenamiento de datos en etiquetas y el proceso de publicación en general — todo esto se detalla en un reciente informe de Dmitry Stolyarov: «».
Resumiendo
La falta de soporte para registros sin anidación no fue un factor bloqueante para nosotros o para los usuarios conocidos de werf — siempre se puede levantar un registro separado de imágenes (o pasar a un Container Registry en Google Cloud)… Sin embargo, eliminar tal restricción parecía lógico para que la herramienta fuera más conveniente para una comunidad DevOps más amplia. Al implementarlo, nos encontramos con la principal dificultad en la reestructuración del mecanismo de limpieza del registro de contenedores. Ahora que todo está preparado, es gratificante saber que a alguien le resulta más fácil, y para nosotros (como principales desarrolladores del proyecto) no se prevén dificultades significativas en el soporte futuro de esta función.
Mantente con nosotros y muy pronto te contaremos sobre otras novedades en !
P.D.
También puedes leer en nuestro blog:
- «»;
- «».
Fuente: habr.com
