{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Soporte para monorepos y multirepos en werf y qu\u00e9 tiene que ver Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Soporte
\n
\nEl tema del monorepositorio ya se ha discutido en varias ocasiones y, por lo general, provoca debates bastante activos. Al crear werf<\/a><\/noindex> una herramienta de c\u00f3digo abierto destinada a mejorar los procesos de compilaci\u00f3n de aplicaciones desde Git a im\u00e1genes Docker (y su posterior entrega en Kubernetes), rara vez reflexionamos sobre cu\u00e1l es la mejor opci\u00f3n. Para nosotros, lo primordial es garantizar todo lo necesario para los partidarios de diferentes opiniones (siempre que no contravenga el sentido com\u00fan, por supuesto).<\/p>\n

El reciente soporte para mono-repo en werf es un buen ejemplo de esto. Pero primero, aclaremos c\u00f3mo este soporte se relaciona con el uso de werf y qu\u00e9 tiene que ver con el Docker Registry...<\/a><\/noindex><\/p>\n

Problem\u00e1tica<\/h2>\n

\nImaginemos una situaci\u00f3n. En la empresa hay numerosos equipos de desarrolladores que trabajan en proyectos independientes. La mayor\u00eda de las aplicaciones funcionan en Kubernetes, y, por lo tanto, est\u00e1n contenerizadas. Para almacenar los contenedores y las im\u00e1genes, se necesita un registro. Como registro, la empresa utiliza Docker Hub con una \u00fanica cuenta COMPANY<\/code>. Siguiendo la analog\u00eda de la mayor\u00eda de los sistemas de almacenamiento de c\u00f3digo fuente, Docker Hub no permite crear una jerarqu\u00eda de repositorios anidada<\/b>, como COMPANY\/PROJECT\/IMAGE<\/code>. En este caso... \u00bfc\u00f3mo almacenar en el registro aplicaciones no monol\u00edticas sin crear una cuenta separada para cada proyecto? <\/p>\n

\"Soporte
\n
\nEs posible que esta situaci\u00f3n sea familiar para algunos, pero consideremos la cuesti\u00f3n de la organizaci\u00f3n del almacenamiento de aplicaciones en general, es decir, sin atenernos al ejemplo descrito anteriormente y a Docker Hub.<\/p>\n

Opciones de soluci\u00f3n<\/h3>\n

\nSi la aplicaci\u00f3n es monol\u00edtica<\/b>, no hay preguntas y simplemente almacenamos las im\u00e1genes en el registro de contenedores del proyecto.<\/p>\n

Cuando la aplicaci\u00f3n se presenta en forma de varios componentes, microservicios<\/b>, se requiere elegir un enfoque espec\u00edfico. Tomando como ejemplo una aplicaci\u00f3n web t\u00edpica, que consta de dos im\u00e1genes: frontend<\/code> y backend<\/code> \u2014 las posibles opciones son las siguientes:<\/p>\n

    \n
  1. Almacenar im\u00e1genes en repositorios anidados separados:\n

    \"Soporte<\/li>\n

  2. Almacenar todo en un solo repositorio y considerar el nombre de la imagen en la etiqueta, por ejemplo, de la siguiente manera:\n

    \"Soporte<\/li>\n<\/ol>\n

    \nNB<\/b>: En realidad, hay otra opci\u00f3n que consiste en guardar en diferentes repositorios, PROJECT-frontend<\/code> y PROJECT-backend<\/code>, pero no la consideraremos debido a la complejidad de soporte, organizaci\u00f3n y distribuci\u00f3n de derechos entre los usuarios.<\/i><\/p>\n

    Soporte en werf<\/h2>\n

    \nInicialmente, werf se limit\u00f3 a repositorios anidados, ya que la mayor\u00eda de los registros soportan esta funcionalidad. A partir de la versi\u00f3n v1.0.4-alpha.3<\/a><\/noindex>, se a\u00f1adi\u00f3 compatibilidad con registros que no soportan anidamiento<\/b>, siendo Docker Hub uno de ellos. A partir de este momento, los usuarios tienen la opci\u00f3n de c\u00f3mo almacenar las im\u00e1genes de la aplicaci\u00f3n.<\/p>\n

    La implementaci\u00f3n est\u00e1 disponible en el marco de la opci\u00f3n --images-repo-mode=multirepo|monorepo<\/code> (por defecto, multirepo<\/code>, es decir, almacenamiento en repositorios anidados). Esta opci\u00f3n define las plantillas seg\u00fan las cuales se almacenan las im\u00e1genes en el registro. Basta con seleccionar el modo deseado al utilizar los comandos b\u00e1sicos, y el resto permanecer\u00e1 sin cambios.<\/p>\n

    Dado que la mayor\u00eda de las opciones de werf se pueden establecer mediante variables de entorno<\/b>, en sistemas CI\/CD, el modo de almacenamiento suele establecerse globalmente para todo el proyecto. Por ejemplo, en el caso de GitLab<\/b> , es suficiente con agregar una variable de entorno en la configuraci\u00f3n del proyecto: Settings -> CI \/ CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    En t\u00e9rminos de publicaci\u00f3n de im\u00e1genes y despliegue de aplicaciones (se puede leer m\u00e1s sobre estos procesos en los art\u00edculos correspondientes de la documentaci\u00f3n: Proceso de publicaci\u00f3n<\/a><\/noindex> y Proceso de despliegue<\/a><\/noindex>), el modo \u00fanicamente determina la plantilla seg\u00fan la cual se puede trabajar con la imagen.<\/p>\n

    El diablo est\u00e1 en los detalles<\/h3>\n

    \nLa diferencia y la principal dificultad al agregar un nuevo m\u00e9todo de almacenamiento radica en el proceso de limpieza del registro (las capacidades de limpieza soportadas en werf se pueden ver en Proceso de limpieza<\/a><\/noindex>)<\/i>.<\/p>\n

    Al limpiar, werf tiene en cuenta las im\u00e1genes utilizadas en los cl\u00fasteres de Kubernetes, as\u00ed como las pol\u00edticas configuradas por el usuario. La base de las pol\u00edticas reside en la divisi\u00f3n de etiquetas en estrategias. Las estrategias actualmente soportadas son:<\/p>\n

      \n
    1. 3 estrategias relacionadas con primitivas de Git, como etiquetas, ramas y confirmaciones;<\/li>\n
    2. 1 estrategia para etiquetas de usuario arbitrarias.<\/li>\n<\/ol>\n

      \nLa informaci\u00f3n sobre la estrategia de etiquetas se guarda al publicar la imagen en las etiquetas de la imagen final. El propio valor, el llamado metatag<\/b> , es necesario para aplicar parte de las pol\u00edticas. Por ejemplo, al eliminar una rama o etiqueta del repositorio de Git, es l\u00f3gico eliminar tambi\u00e9n las im\u00e1genes no utilizadas<\/i> del registro, lo cual est\u00e1 cubierto por parte de nuestras pol\u00edticas.<\/p>\n

      Al guardar en un solo repositorio (monorepo<\/code>), en la etiqueta de la imagen, adem\u00e1s del metatag, tambi\u00e9n puede almacenarse el nombre de la imagen: PROYECTO:frontend<\/b>-META-TAG<\/code>. Para separarlos, no introdujimos un separador espec\u00edfico, sino que simplemente a\u00f1adimos el valor necesario en la etiqueta de la imagen final al publicarla.<\/p>\n

      NB<\/b>: Si te interesa ver todo lo descrito en el c\u00f3digo fuente de werf, el punto de partida puede ser PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      En este art\u00edculo no abordaremos m\u00e1s el problema y la justificaci\u00f3n de nuestro enfoque: sobre las estrategias de etiquetado, el almacenamiento de datos en etiquetas y el proceso de publicaci\u00f3n en general \u2014 todo esto se detalla en un reciente informe de Dmitry Stolyarov: \u00abwerf \u2014 nuestra herramienta para CI\/CD en Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Resumiendo<\/h2>\n

      \nLa falta de soporte para registros sin anidaci\u00f3n no fue un factor bloqueante para nosotros o para los usuarios conocidos de werf \u2014 siempre se puede levantar un registro separado de im\u00e1genes (o pasar a un Container Registry en Google Cloud)\u2026 Sin embargo, eliminar tal restricci\u00f3n parec\u00eda l\u00f3gico para que la herramienta fuera m\u00e1s conveniente para una comunidad DevOps m\u00e1s amplia. Al implementarlo, nos encontramos con la principal dificultad en la reestructuraci\u00f3n del mecanismo de limpieza del registro de contenedores. Ahora que todo est\u00e1 preparado, es gratificante saber que a alguien le resulta m\u00e1s f\u00e1cil, y para nosotros (como principales desarrolladores del proyecto) no se prev\u00e9n dificultades significativas en el soporte futuro de esta funci\u00f3n.<\/p>\n

      Mantente con nosotros y muy pronto te contaremos sobre otras novedades en werf<\/a><\/noindex>!<\/p>\n

      P.D.<\/h2>\n

      \nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n