{"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\/fr\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Le probl\u00e8me de l'\u00ab intelligent \u00bb nettoyage des images de conteneurs et sa solution dans werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Le
\n
\nCet article aborde la probl\u00e9matique du nettoyage des images qui s'accumulent dans les registres de conteneurs (Docker Registry et ses alternatives) dans le contexte des pipelines CI\/CD modernes pour les applications cloud native d\u00e9ploy\u00e9es sur Kubernetes. Les principaux crit\u00e8res de pertinence des images sont pr\u00e9sent\u00e9s, ainsi que les difficult\u00e9s qui en d\u00e9coulent pour automatiser le nettoyage, \u00e9conomiser de l'espace et r\u00e9pondre aux besoins des \u00e9quipes. Enfin, \u00e0 travers un exemple d'un projet Open Source concret, nous expliquerons comment surmonter ces difficult\u00e9s.<\/p>\n

Introduction<\/h2>\n

\nLe nombre d'images dans le registre des conteneurs peut cro\u00eetre rapidement, occupant plus d'espace de stockage et, par cons\u00e9quent, augmentant consid\u00e9rablement son co\u00fbt. Pour contr\u00f4ler, limiter ou maintenir une croissance acceptable de l'espace occup\u00e9 dans le registre, il est courant de :<\/p>\n

    \n
  1. utiliser un nombre fixe de tags pour les images ;<\/li>\n
  2. nettoyer les images d'une mani\u00e8re ou d'une autre.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nLa premi\u00e8re restriction est parfois acceptable pour de petites \u00e9quipes. Si les d\u00e9veloppeurs se contentent de tags fixes (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> etc.), le registre ne gonflera pas en taille et pendant longtemps, il n'est pas n\u00e9cessaire de penser \u00e0 un nettoyage. En effet, toutes les images obsol\u00e8tes sont remplac\u00e9es, et il n'y a tout simplement pas de travail de nettoyage (tout est g\u00e9r\u00e9 par le ramasse-miettes standard).<\/p>\n

    Cependant, cette approche limite fortement le d\u00e9veloppement et est rarement applicable aux projets CI\/CD modernes. L'automatisation est devenue une partie int\u00e9grante du d\u00e9veloppement, qui permet de tester, d\u00e9ployer et livrer de nouvelles fonctionnalit\u00e9s aux utilisateurs beaucoup plus rapidement. Par exemple, dans tous nos projets, un pipeline CI est automatiquement cr\u00e9\u00e9 \u00e0 chaque commit. Celui-ci construit l'image, la teste, la d\u00e9ploie dans divers environnements Kubernetes pour le d\u00e9bogage et les v\u00e9rifications restantes, et si tout va bien, les modifications atteignent l'utilisateur final. Ce n'est plus une science-fus\u00e9e, mais une banalit\u00e9 pour beaucoup \u2014 probablement pour vous \u00e9galement, puisque vous lisez cet article.<\/strong>\u00c9tant donn\u00e9 que la correction des bogues et le d\u00e9veloppement de nouvelles fonctionnalit\u00e9s se d\u00e9roulent en parall\u00e8le, et que des versions peuvent \u00eatre effectu\u00e9es plusieurs fois par jour, il est \u00e9vident que le processus de d\u00e9veloppement est accompagn\u00e9 d'un nombre consid\u00e9rable de commits, ce qui signifie \u2014<\/p>\n

    un grand nombre d'images dans le registre. En cons\u00e9quence, la question de l'organisation d'un nettoyage efficace du registre se pose avec acuit\u00e9, c'est-\u00e0-dire la suppression d'images obsol\u00e8tes.<\/strong>.<\/p>\n

    Mais comment d\u00e9terminer si l'image est pertinente ?<\/p>\n

    Crit\u00e8res de pertinence de l'image<\/h2>\n

    \nDans la grande majorit\u00e9 des cas, les crit\u00e8res principaux seront les suivants :<\/p>\n

    1. Le premier (le plus \u00e9vident et le plus critique de tous) \u2014 ce sont les images qui sont actuellement utilis\u00e9es dans Kubernetes<\/strong>. La suppression de ces images peut entra\u00eener des co\u00fbts importants li\u00e9s \u00e0 l'arr\u00eat de la production (par exemple, les images peuvent \u00eatre n\u00e9cessaires lors de la r\u00e9plication) ou compromettre les efforts de l'\u00e9quipe qui se consacre au d\u00e9bogage sur l'un des environnements. (C'est pourquoi nous avons m\u00eame cr\u00e9\u00e9 un <\/i>exportateur Prometheus<\/i><\/a><\/noindex>, qui surveille l'absence de telles images dans tout cluster Kubernetes.)<\/i><\/p>\n

    2. Le deuxi\u00e8me (moins \u00e9vident, mais toujours tr\u00e8s important et \u00e0 nouveau li\u00e9 \u00e0 l'exploitation) \u2014 les images qui sont n\u00e9cessaires pour revenir en arri\u00e8re en cas de probl\u00e8mes majeurs<\/strong> dans la version actuelle. Par exemple, dans le cas de Helm, ce sont les images utilis\u00e9es dans les versions enregistr\u00e9es du d\u00e9ploiement. (\u00c0 propos, par d\u00e9faut, Helm a une limite de 256 r\u00e9visions, mais est-ce que quelqu'un a vraiment besoin de conserver autant<\/i> de versions ?..) En effet, nous stockons des versions dans le but de pouvoir les utiliser ult\u00e9rieurement, c'est-\u00e0-dire 'revenir en arri\u00e8re' si n\u00e9cessaire.<\/p>\n

    3. Le troisi\u00e8me \u2014 les besoins des d\u00e9veloppeurs<\/strong>: toutes les images li\u00e9es \u00e0 leurs travaux en cours. Par exemple, si nous examinons un PR, il est logique de conserver l'image correspondant au dernier commit et, disons, au commit pr\u00e9c\u00e9dent : ainsi, le d\u00e9veloppeur pourra revenir rapidement \u00e0 n'importe quelle t\u00e2che et travailler avec les derni\u00e8res modifications. <\/p>\n

    4. Le quatri\u00e8me \u2014 les images qui correspondent aux versions de notre application<\/strong>, c'est-\u00e0-dire qui sont le produit final : v1.0.0, 20.04.01, sierra, etc.<\/p>\n

    NB : Les crit\u00e8res \u00e9tablis ici ont \u00e9t\u00e9 formul\u00e9s sur la base de l'exp\u00e9rience avec des dizaines d'\u00e9quipes de d\u00e9veloppement de diverses entreprises. Cependant, bien s\u00fbr, selon les particularit\u00e9s des processus de d\u00e9veloppement et de l'infrastructure utilis\u00e9e (par exemple, Kubernetes n'est pas utilis\u00e9), ces crit\u00e8res peuvent diff\u00e9rer. <\/p>\n

    Conformit\u00e9 aux crit\u00e8res et solutions existantes<\/h2>\n

    \nLes services populaires de registre de conteneurs proposent g\u00e9n\u00e9ralement leurs politiques de nettoyage des images : vous pouvez d\u00e9finir les conditions dans lesquelles un tag est supprim\u00e9 du registre. Cependant, les options de ces conditions sont limit\u00e9es par des param\u00e8tres tels que les noms, les dates de cr\u00e9ation et le nombre de tags*.<\/p>\n

    * D\u00e9pend des impl\u00e9mentations sp\u00e9cifiques de container registry. Nous avons examin\u00e9 les possibilit\u00e9s des solutions suivantes : Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 \u00e0 partir de septembre 2020.<\/i><\/p>\n

    Cet ensemble de param\u00e8tres est tout \u00e0 fait suffisant pour r\u00e9pondre au quatri\u00e8me crit\u00e8re \u2014 c'est-\u00e0-dire s\u00e9lectionner des images correspondant aux versions. Cependant, pour tous les autres crit\u00e8res, il faut opter pour une solution de compromis (une politique plus stricte ou, au contraire, plus indulgente) \u2014 selon les attentes et les possibilit\u00e9s financi\u00e8res.<\/p>\n

    Par exemple, le troisi\u00e8me crit\u00e8re \u2014 concernant les besoins des d\u00e9veloppeurs \u2014 peut \u00eatre r\u00e9solu en organisant des processus au sein des \u00e9quipes : nomination sp\u00e9cifique des images, tenue de listes d'autorisation sp\u00e9ciales et accords internes. Mais en fin de compte, il faut cependant automatiser cela. Et si les options des solutions pr\u00eates \u00e0 l'emploi ne suffisent pas, il faut cr\u00e9er sa propre solution.<\/p>\n

    La situation est similaire pour les deux premiers crit\u00e8res : ils ne peuvent pas \u00eatre satisfaits sans obtenir des donn\u00e9es d'un syst\u00e8me externe \u2014 celui o\u00f9 le d\u00e9ploiement des applications a lieu (dans notre cas, il s'agit de Kubernetes).<\/p>\n

    Illustration du workflow dans Git<\/h3>\n

    \nSupposons que vous travaillez selon un sch\u00e9ma similaire dans Git :<\/p>\n

    \"Le
    \n
    \nLes images des conteneurs, marqu\u00e9es par une ic\u00f4ne avec une t\u00eate dans le sch\u00e9ma, sont actuellement d\u00e9ploy\u00e9es dans Kubernetes pour certains utilisateurs (utilisateurs finaux, testeurs, gestionnaires, etc.) ou sont utilis\u00e9es par les d\u00e9veloppeurs pour le d\u00e9bogage et des objectifs similaires.<\/i><\/p>\n

    Que se passera-t-il si les politiques de nettoyage permettent de conserver (ne pas supprimer) les images uniquement selon des noms de tags d\u00e9finis<\/b>?<\/p>\n

    \"Le
    \n
    \nIl est \u00e9vident qu'un tel sc\u00e9nario ne ravira personne.<\/p>\n

    Que changera si les politiques permettent de ne pas supprimer les images selon un intervalle de temps donn\u00e9 \/ le nombre de derniers commits<\/b>?<\/p>\n

    \"Le
    \n
    \nLe r\u00e9sultat est devenu significativement meilleur, mais reste encore \u00e9loign\u00e9 de l'id\u00e9al. En effet, nous avons toujours des d\u00e9veloppeurs qui ont besoin d'images dans le registre (ou m\u00eame d\u00e9ploy\u00e9es dans K8s) pour d\u00e9boguer des bugs\u2026<\/p>\n

    En r\u00e9sumant la situation actuelle sur le march\u00e9 : les fonctionnalit\u00e9s disponibles dans les registres de conteneurs n'offrent pas la flexibilit\u00e9 n\u00e9cessaire pour le nettoyage, et la principale raison en est l'absence d'interaction avec le monde ext\u00e9rieur<\/strong>. Par cons\u00e9quent, les \u00e9quipes qui n\u00e9cessitent une telle flexibilit\u00e9 doivent impl\u00e9menter elles-m\u00eames la suppression des images \u00ab de l'ext\u00e9rieur \u00bb en utilisant l'API de Docker Registry (ou l'API native de l'impl\u00e9mentation correspondante).<\/p>\n

    Cependant, nous recherchions une solution universelle qui automatiserait le nettoyage des images pour diff\u00e9rentes \u00e9quipes utilisant diff\u00e9rents registres...<\/p>\n

    Notre chemin vers un nettoyage universel des images<\/h2>\n

    \nD'o\u00f9 vient ce besoin ? Il se trouve que nous ne sommes pas un groupe de d\u00e9veloppeurs isol\u00e9, mais une \u00e9quipe qui soutient plusieurs d'entre eux, en les aidant \u00e0 r\u00e9soudre de mani\u00e8re globale les questions de CI\/CD. Et l'outil technique principal pour cela est l'utilitaire Open Source werf<\/a><\/noindex>. Sa particularit\u00e9 est qu'il n'ex\u00e9cute pas une seule fonction, mais accompagne les processus de livraison continue \u00e0 toutes les \u00e9tapes : de la construction au d\u00e9ploiement.<\/p>\n

    La publication dans le registre* des images (imm\u00e9diatement apr\u00e8s leur construction) est une fonctionnalit\u00e9 \u00e9vidente d'un tel utilitaire. Et puisque les images y sont stock\u00e9es, si votre stockage n'est pas illimit\u00e9, il faut \u00e9galement s'assurer de leur nettoyage ult\u00e9rieur. Nous expliquerons comment nous avons r\u00e9ussi cela, en satisfaisant tous les crit\u00e8res pos\u00e9s.<\/p>\n

    * Bien que les registres eux-m\u00eames puissent \u00eatre diff\u00e9rents (Docker Registry, GitLab Container Registry, Harbor, etc.), leurs utilisateurs rencontrent les m\u00eames probl\u00e8mes. La solution universelle dans notre cas ne d\u00e9pend pas de l'impl\u00e9mentation du registre, car elle s'ex\u00e9cute en dehors des registres eux-m\u00eames et propose un comportement identique pour tous.<\/i><\/p>\n

    Bien que nous utilisions werf comme exemple d'impl\u00e9mentation, nous esp\u00e9rons que les approches utilis\u00e9es seront utiles \u00e0 d'autres \u00e9quipes confront\u00e9es \u00e0 des difficult\u00e9s similaires.<\/p>\n

    Ainsi, nous nous sommes attaqu\u00e9s \u00e0 l'impl\u00e9mentation<\/i> d'un m\u00e9canisme de nettoyage des images \u2014 plut\u00f4t que d'utiliser les possibilit\u00e9s d\u00e9j\u00e0 int\u00e9gr\u00e9es dans les registres de conteneurs. La premi\u00e8re \u00e9tape a \u00e9t\u00e9 l'utilisation de l'API de Docker Registry pour cr\u00e9er ces politiques primitives sur le nombre de balises et leur date de cr\u00e9ation (mentionn\u00e9es ci-dessus). \u00c0 celles-ci a \u00e9t\u00e9 ajout\u00e9e une liste d'autorisation bas\u00e9e sur les images utilis\u00e9es dans l'infrastructure d\u00e9ploy\u00e9e<\/strong>, c'est-\u00e0-dire Kubernetes. Pour cela, il suffisait de passer par l'API Kubernetes pour parcourir toutes les ressources d\u00e9ploy\u00e9es et obtenir une liste de valeurs. image<\/code>.<\/p>\n

    Cette solution triviale a r\u00e9solu le probl\u00e8me le plus critique (crit\u00e8re n\u00b01), mais n'\u00e9tait que le d\u00e9but de notre parcours pour am\u00e9liorer le m\u00e9canisme de nettoyage. Le prochain \u2014 et beaucoup plus int\u00e9ressant \u2014 pas a \u00e9t\u00e9 de r\u00e9soudre le lien entre les images publi\u00e9es et l'historique Git.<\/strong>.<\/p>\n

    Sch\u00e9mas de balisage<\/h3>\n

    \nPour commencer, nous avons choisi une approche o\u00f9 l'image finale devait conserver les informations n\u00e9cessaires pour le nettoyage, et nous avons construit le processus sur des sch\u00e9mas de balisage. Lors de la publication de l'image, l'utilisateur choisissait une option de balisage (branche-git<\/code>, commit-git<\/code> ou tag-git<\/code>) et utilisait la valeur correspondante. Dans les syst\u00e8mes CI, ces valeurs \u00e9taient d\u00e9finies automatiquement sur la base des variables d'environnement. En essence, l'image finale \u00e9tait li\u00e9e \u00e0 un certain \u00e9l\u00e9ment Git<\/strong>, conservant les donn\u00e9es n\u00e9cessaires pour le nettoyage dans les labels.<\/p>\n

    Dans le cadre de cette approche, un ensemble de politiques a \u00e9t\u00e9 mis en place, permettant d'utiliser Git comme la seule source de v\u00e9rit\u00e9 :<\/p>\n