El tema de un mono-repositorio ha sido discutido más de una vez y, por regla general, provoca una controversia muy activa. Por crear como una herramienta de código abierto diseñada para mejorar el proceso de creación de código de aplicación desde Git a imágenes de Docker (y luego enviarlas a Kubernetes), no pensamos mucho en qué opción es la mejor. Para nosotros, es primordial proporcionar todo lo necesario para los partidarios de opiniones diferentes (si esto no contradice el sentido común, por supuesto).
El soporte mono-repo reciente de werf es un buen ejemplo de esto. Pero primero, averigüemos cómo este soporte se relaciona generalmente con el uso de werf y qué tiene que ver Docker Registry con él...
Problemas
Imaginemos una situación así. La empresa tiene muchos equipos de desarrollo que trabajan en proyectos independientes. La mayoría de las aplicaciones se ejecutan en Kubernetes y, por lo tanto, están en contenedores. Para almacenar contenedores, imágenes, necesita un registro (registro). Como tal registro, la empresa usa Docker Hub con una sola cuenta COMPANY. Similar a la mayoría de los sistemas de almacenamiento de código fuente, Docker Hub no permite la jerarquía de repositorios anidados, como COMPANY/PROJECT/IMAGE. En ese caso… ¿cómo puedes almacenar aplicaciones no monolíticas en el registro con esta limitación sin crear una cuenta separada para cada proyecto?
Tal vez, la situación descrita sea 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 Docker Hub.
Soluciones
Si la aplicación monolítico, viene en una imagen, entonces no hay preguntas y simplemente guardamos las imágenes en el registro del contenedor del proyecto.
Cuando una aplicación se presenta como varios componentes, microservicios, entonces se requiere cierto enfoque. En el ejemplo de una aplicación web típica que consta de dos imágenes: frontend и backend - las posibles opciones son:
- Almacene imágenes en repositorios anidados separados:
- Almacene todo en un repositorio y considere el nombre de la imagen en la etiqueta, por ejemplo, de la siguiente manera:
NB: En realidad, hay otra opción con guardar en diferentes repositorios, PROJECT-frontend и PROJECT-backend, pero no lo consideraremos por la complejidad de soporte, organización y distribución de derechos entre usuarios.
apoyo de werf
Inicialmente, werf se limitaba a repositorios anidados; afortunadamente, la mayoría de los registros admiten esta característica. A partir de la versión , trabajo añadido con registros en los que la anidación no es compatible, y Docker Hub es uno de ellos. A partir de ese momento, el usuario puede elegir cómo almacenar las imágenes de la aplicación.
Implementación disponible bajo opción --images-repo-mode=multirepo|monorepo (defecto multirepo, es decir. almacenamiento en repositorios anidados). Define los patrones por los cuales las imágenes se almacenan en el registro. Basta con seleccionar el modo deseado al usar los comandos básicos, y todo lo demás permanecerá sin cambios.
Porque la mayoría de las opciones de werf se pueden configurar 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 una variable de entorno en la configuración del proyecto: Ajustes -> 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: и ), entonces el modo determina únicamente la plantilla con la que puede trabajar con la imagen.
El diablo en detalle
La diferencia y la principal dificultad al agregar un nuevo método de almacenamiento está en el proceso de limpieza del registro. (para ver las funciones de purga admitidas por werf, consulte ).
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 la división de etiquetas en estrategias. Estrategias admitidas actualmente:
- 3 estrategias vinculadas por primitivas de Git como etiqueta, rama y compromiso;
- 1 estrategia para etiquetas personalizadas arbitrarias.
Guardamos información sobre la estrategia de etiquetas al publicar la imagen en las etiquetas de la imagen final. El significado mismo es el llamado etiqueta meta - Requerido para aplicar algunas de las políticas. Por ejemplo, al eliminar una rama o etiqueta de un repositorio de Git, es lógico eliminar las relacionadas sin usar imágenes del registro, que está cubierto por parte de nuestras políticas.
Cuando se guarda en un repositorio (monorepo), en la etiqueta de la imagen, además de la metaetiqueta, también se puede almacenar el nombre de la imagen: PROJECT:frontend-META-TAG. Para separarlas, no introducimos ningún separador específico, sino que simplemente añadimos 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 de werf, entonces el punto de partida puede ser .
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: “".
Resumiendo
La falta de compatibilidad con los registros no anidados no fue un factor de bloqueo para nosotros ni para los usuarios de werf que conocemos; después de todo, siempre puede crear un registro de imagen independiente (o cambiar a un Registro de contenedor condicional en Google Cloud)... Sin embargo, eliminar tal restricción parecía lógico para que la herramienta fuera más conveniente para la comunidad DevOps en general. Al implementarlo, nos enfrentamos a la principal dificultad de reelaborar el mecanismo de limpieza del registro de contenedores. Ahora que todo está listo, es bueno darse cuenta de que se ha vuelto más fácil para alguien, y nosotros (como los principales desarrolladores del proyecto) no tendremos ninguna dificultad notable para admitir aún más esta función.
Quédate con nosotros y muy pronto te hablaremos de otras novedades en !
PS
Lea también en nuestro blog:
- «";
- «".
Fuente: habr.com