{"id":96065,"date":"2020-10-07T13:42:09","date_gmt":"2020-10-07T11:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf"},"modified":"2020-10-07T13:42:09","modified_gmt":"2020-10-07T11:42:09","slug":"problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"El problema de la \"limpieza inteligente\" de im\u00e1genes de contenedores y su soluci\u00f3n en werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"El
\n
\nEl art\u00edculo aborda la problem\u00e1tica de la limpieza de im\u00e1genes que se acumulan en los registros de contenedores (Docker Registry y sus an\u00e1logos) en el contexto de las modernas tuber\u00edas CI\/CD para aplicaciones cloud native entregadas en Kubernetes. Se presentan los principales criterios de relevancia de las im\u00e1genes y las complicaciones que surgen en su limpieza automatizada, preservaci\u00f3n de espacio y satisfacci\u00f3n de las necesidades de los equipos. Finalmente, a trav\u00e9s de un ejemplo concreto de un proyecto de c\u00f3digo abierto, describiremos c\u00f3mo se pueden superar estas dificultades.<\/p>\n

Introducci\u00f3n<\/h2>\n

\nLa cantidad de im\u00e1genes en el registro de contenedores puede crecer r\u00e1pidamente, ocupando m\u00e1s espacio en el almacenamiento y, en consecuencia, aumentando significativamente su costo. Para controlar, limitar o mantener un crecimiento aceptable del espacio ocupado en el registry, se establece:<\/p>\n

    \n
  1. utilizar un n\u00famero fijo de etiquetas para las im\u00e1genes;<\/li>\n
  2. limpiar las im\u00e1genes de alguna manera.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nLa primera limitaci\u00f3n es a veces aceptable para equipos peque\u00f1os. Si a los desarrolladores les bastan etiquetas fijas (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> ), el registro no se expandir\u00e1 en tama\u00f1o y durante mucho tiempo se puede no pensar en la limpieza. Dado que todas las im\u00e1genes obsoletas se sobrescriben, no queda trabajo para limpiar (todo lo hace el recolector de basura est\u00e1ndar).<\/p>\n

    Sin embargo, este enfoque limita severamente el desarrollo y rara vez se aplica a CI\/CD de proyectos modernos. La automatizaci\u00f3n<\/strong>ha pasado a ser parte integral del desarrollo, permitiendo probar, desplegar y entregar nuevas funcionalidades a los usuarios con mayor rapidez. Por ejemplo, en todos nuestros proyectos, se crea autom\u00e1ticamente una tuber\u00eda CI con cada commit. En ella, se construye la imagen, se prueba, se despliega en varios entornos de Kubernetes para depuraci\u00f3n y comprobaciones restantes, y si todo va bien, los cambios llegan al usuario final. Y esto ya no es ciencia espacial, sino una rutina para muchos \u2014 probablemente tambi\u00e9n para usted, dado que est\u00e1 leyendo este art\u00edculo.<\/p>\n

    Dado que la correcci\u00f3n de errores y el desarrollo de nuevas funcionalidades se llevan a cabo en paralelo, y los lanzamientos pueden realizarse varias veces al d\u00eda, es evidente que el proceso de desarrollo genera una cantidad sustancial de commits, lo que significa que hay un gran n\u00famero de im\u00e1genes en el registry.<\/strong>Como resultado, surge con urgencia la cuesti\u00f3n de organizar una limpieza efectiva del registry, es decir, eliminar im\u00e1genes obsoletas.<\/p>\n

    \u00bfPero c\u00f3mo determinar si la imagen es realmente relevante?<\/p>\n

    Criterios de relevancia de la imagen<\/h2>\n

    \nEn la gran mayor\u00eda de los casos, los criterios principales ser\u00e1n los siguientes:<\/p>\n

    1. El primero (el m\u00e1s obvio y cr\u00edtico de todos) son las im\u00e1genes que actualmente se utilizan en Kubernetes<\/strong>. Eliminar estas im\u00e1genes puede resultar en costos significativos debido a la inactividad de la producci\u00f3n (por ejemplo, es posible que se necesiten im\u00e1genes durante la replicaci\u00f3n) o puede anular los esfuerzos del equipo que est\u00e1 depurando en cualquiera de los entornos. (Por esta raz\u00f3n, incluso hemos creado un <\/i>exportador de Prometheus<\/i><\/a><\/noindex>, que monitorea la ausencia de tales im\u00e1genes en cualquier cl\u00faster de Kubernetes.)<\/i><\/p>\n

    2. El segundo (menos obvio, pero tambi\u00e9n muy importante y que nuevamente se relaciona con la operaci\u00f3n) son las im\u00e1genes que se requieren para un revertir en caso de que se detecten problemas graves<\/strong> en la versi\u00f3n actual. Por ejemplo, en el caso de Helm, son las im\u00e1genes que se utilizan en las versiones guardadas del lanzamiento. (Por cierto, de forma predeterminada, Helm tiene un l\u00edmite de 256 revisiones, pero es poco probable que alguien realmente necesite conservar de eso<\/i> una gran cantidad de versiones?..) De hecho, guardamos versiones precisamente para que se puedan usar posteriormente, es decir, \"revertir\" a ellas en caso de necesidad.<\/p>\n

    3. El tercero son las necesidades de los desarrolladores<\/strong>: todas las im\u00e1genes que est\u00e1n relacionadas con su trabajo actual. Por ejemplo, si estamos considerando un PR, tiene sentido mantener la imagen correspondiente al \u00faltimo commit y, digamos, al commit anterior: as\u00ed el desarrollador podr\u00e1 regresar r\u00e1pidamente a cualquier tarea y trabajar con los cambios m\u00e1s recientes. <\/p>\n

    4. El cuarto son las im\u00e1genes que corresponden a las versiones de nuestra aplicaci\u00f3n<\/strong>, es decir, son el producto final: v1.0.0, 20.04.01, sierra, etc.<\/p>\n

    NB: Los criterios aqu\u00ed definidos se han formulado en base a la experiencia de interacci\u00f3n con decenas de equipos de desarrollo de diferentes empresas. Sin embargo, por supuesto, dependiendo de las caracter\u00edsticas en los procesos de desarrollo y de la infraestructura utilizada (por ejemplo, si no se utiliza Kubernetes), estos criterios pueden variar. <\/p>\n

    Cumplimiento de los criterios y soluciones existentes<\/h2>\n

    \nLos servicios populares de container registry suelen ofrecer sus propias pol\u00edticas de limpieza de im\u00e1genes: en ellas puedes definir las condiciones bajo las cuales una etiqueta se elimina del registry. Sin embargo, las posibilidades de estas condiciones se limitan a par\u00e1metros como nombres, tiempo de creaci\u00f3n y cantidad de etiquetas*.<\/p>\n

    * Depende de las implementaciones espec\u00edficas del registro de contenedores. Hemos considerado las capacidades de las siguientes soluciones: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 a fecha de septiembre de 2020.<\/i><\/p>\n

    Este conjunto de par\u00e1metros es m\u00e1s que suficiente para satisfacer el cuarto criterio \u2014 es decir, seleccionar im\u00e1genes que correspondan a las versiones. Sin embargo, para todos los dem\u00e1s criterios, hay que optar por alguna soluci\u00f3n de compromiso (una pol\u00edtica m\u00e1s estricta o, por el contrario, m\u00e1s indulgente) \u2014 dependiendo de las expectativas y las capacidades financieras.<\/p>\n

    Por ejemplo, el tercer criterio \u2014 relacionado con las necesidades de los desarrolladores \u2014 puede resolverse organizando procesos dentro de los equipos: nombramiento espec\u00edfico de im\u00e1genes, mantenimiento de listas de permitidos y acuerdos internos. Pero, al final, a\u00fan es necesario automatizarlo. Y si las capacidades de las soluciones listas no son suficientes, hay que hacer algo propio.<\/p>\n

    La situaci\u00f3n es similar con los dos primeros criterios: no se pueden satisfacer sin obtener datos de un sistema externo \u2014 el mismo donde se realiza la implementaci\u00f3n de aplicaciones (en nuestro caso, es Kubernetes).<\/p>\n

    Ilustraci\u00f3n del flujo de trabajo en Git<\/h3>\n

    \nSupongamos que trabajas m\u00e1s o menos con este esquema en Git:<\/p>\n

    \"El
    \n
    \nLa imagen con un icono de cabeza en el esquema marca las im\u00e1genes de contenedor que actualmente est\u00e1n desplegadas en Kubernetes para ciertos usuarios (usuarios finales, testers, gerentes, etc.) o son utilizadas por los desarrolladores para depuraci\u00f3n y objetivos similares.<\/i><\/p>\n

    \u00bfQu\u00e9 suceder\u00e1 si las pol\u00edticas de limpieza permiten dejar (no eliminar) im\u00e1genes solo por nombres de etiquetas espec\u00edficos?<\/b>?<\/p>\n

    \"El
    \n
    \nObviamente, tal escenario no le agradar\u00e1 a nadie.<\/p>\n

    \u00bfQu\u00e9 cambiar\u00e1 si las pol\u00edticas permiten no eliminar im\u00e1genes por un intervalo de tiempo espec\u00edfico \/ n\u00famero de \u00faltimos commits?<\/b>?<\/p>\n

    \"El
    \n
    \nEl resultado es significativamente mejor, aunque todav\u00eda est\u00e1 lejos de ser ideal. Despu\u00e9s de todo, todav\u00eda tenemos desarrolladores que necesitan im\u00e1genes en el registry (o incluso desplegadas en K8s) para depurar errores...<\/p>\n

    Resumiendo la situaci\u00f3n actual del mercado: las funciones disponibles en los registros de contenedores no ofrecen la flexibilidad suficiente para la limpieza, y la principal raz\u00f3n es que no hay posibilidad de interactuar con el mundo exterior.<\/strong>Esto significa que los equipos que requieren dicha flexibilidad deben implementar por su cuenta la eliminaci\u00f3n de im\u00e1genes \"externamente\", utilizando la API de Docker Registry (o la API nativa de la implementaci\u00f3n correspondiente).<\/p>\n

    Sin embargo, est\u00e1bamos buscando una soluci\u00f3n universal que automatizara la limpieza de im\u00e1genes para diferentes equipos que utilizan diferentes registros...<\/p>\n

    Nuestro camino hacia la limpieza universal de im\u00e1genes.<\/h2>\n

    \n\u00bfDe d\u00f3nde proviene esta necesidad? La cuesti\u00f3n es que no somos un grupo aislado de desarrolladores, sino un equipo que atiende a muchos de ellos, ayudando a resolver integralmente los problemas de CI\/CD. Y la principal herramienta t\u00e9cnica para esto es una utilidad de c\u00f3digo abierto werf<\/a><\/noindex>. Su caracter\u00edstica es que no realiza una \u00fanica funci\u00f3n, sino que acompa\u00f1a los procesos de entrega continua en todas las etapas: desde la construcci\u00f3n hasta el despliegue.<\/p>\n

    La publicaci\u00f3n en el registro* de im\u00e1genes (inmediatamente despu\u00e9s de su construcci\u00f3n) es una funci\u00f3n evidente de dicha utilidad. Y dado que las im\u00e1genes se almacenan all\u00ed, si su almacenamiento no es ilimitado, tambi\u00e9n se debe responder por su posterior limpieza. A continuaci\u00f3n, se explicar\u00e1 c\u00f3mo logramos esto, cumpliendo con todos los criterios establecidos.<\/p>\n

    * Aunque los registros en s\u00ed pueden ser diversos (Docker Registry, GitLab Container Registry, Harbor, etc.), sus usuarios se enfrentan a los mismos problemas. La soluci\u00f3n universal en nuestro caso no depende de la implementaci\u00f3n del registro, ya que se lleva a cabo fuera de los propios registros y ofrece un comportamiento uniforme para todos.<\/i><\/p>\n

    A pesar de que utilizamos werf como ejemplo de implementaci\u00f3n, esperamos que los enfoques utilizados sean \u00fatiles para otros equipos que enfrenten dificultades similares.<\/p>\n

    As\u00ed que nos dedicamos a la<\/i> implementaci\u00f3n externa de un mecanismo para limpiar im\u00e1genes \u2014 en lugar de las capacidades que ya est\u00e1n integradas en los registros para contenedores. El primer paso fue utilizar la API de Docker Registry para crear las mismas pol\u00edticas primitivas sobre la cantidad de etiquetas y el tiempo de su creaci\u00f3n (mencionadas anteriormente). A ellas se a\u00f1adi\u00f3 una lista permitida basada en las im\u00e1genes utilizadas en la infraestructura desplegada.<\/strong>, es decir, Kubernetes. Para esto \u00faltimo, bastaba con recorrer todos los recursos desplegados a trav\u00e9s de la API de Kubernetes y obtener una lista de valores. image<\/code>.<\/p>\n

    Esta soluci\u00f3n trivial resolvi\u00f3 el problema m\u00e1s cr\u00edtico (criterio n.\u00ba 1), pero solo fue el comienzo de nuestro camino hacia la mejora del mecanismo de limpieza. El siguiente, y mucho m\u00e1s interesante, paso fue encontrar la forma de vincular las im\u00e1genes publicadas con el historial de Git.<\/strong>.<\/p>\n

    Esquemas de etiquetado<\/h3>\n

    \nPara comenzar, elegimos un enfoque en el que la imagen final debe almacenar la informaci\u00f3n necesaria para la limpieza, y construimos el proceso sobre esquemas de etiquetado. Al publicar la imagen, el usuario seleccionaba una opci\u00f3n de etiquetado espec\u00edfica (git-branch<\/code>, git-commit<\/code> o git-tag<\/code>) y utilizaba el valor correspondiente. En los sistemas CI, la configuraci\u00f3n de estos valores se realizaba autom\u00e1ticamente seg\u00fan las variables de entorno. En esencia, la imagen final se vinculaba a un determinado primitivo de Git,<\/strong>almacenando los datos necesarios para la limpieza en las etiquetas.<\/p>\n

    Con este enfoque, se logr\u00f3 un conjunto de pol\u00edticas que permitieron usar Git como la \u00fanica fuente de verdad:<\/p>\n