{"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\/it\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Il problema della 'pulizia intelligente' delle immagini dei container e la sua soluzione in werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Il
\n
\nL'articolo affronta il problema della pulizia delle immagini accumulate nei registri dei container (Docker Registry e suoi analoghi) nel contesto degli attuali pipeline CI\/CD per applicazioni cloud native distribuite su Kubernetes. Vengono presentati i principali criteri di rilevanza delle immagini e le conseguenti difficolt\u00e0 nell'automatizzazione della pulizia, del risparmio di spazio e della soddisfazione delle esigenze dei team. Infine, attraverso un esempio di un progetto Open Source specifico, spiegheremo come superare queste difficolt\u00e0.<\/p>\n

Introduzione<\/h2>\n

\nIl numero di immagini nel registro dei container pu\u00f2 crescere rapidamente, occupando pi\u00f9 spazio di archiviazione e, di conseguenza, aumentando significativamente i costi. Per controllare, limitare o mantenere una crescita accettabile dello spazio occupato nel registry, \u00e8 consuetudine:<\/p>\n

    \n
  1. utilizzare un numero fisso di tag per le immagini;<\/li>\n
  2. pulire le immagini in qualche modo.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nLa prima limitazione \u00e8 talvolta accettabile per piccoli team. Se agli sviluppatori bastano tag fissi (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> e cos\u00ec via), il registro non si gonfier\u00e0 e per lungo tempo non sar\u00e0 necessario pensare alla pulizia. Infatti, tutte le immagini non pi\u00f9 attuali vengono sovrascritte e non resta lavoro da fare per la pulizia (tutto viene gestito dal garbage collector standard).<\/p>\n

    Tuttavia, questo approccio limita fortemente lo sviluppo ed \u00e8 raramente applicabile ai progetti CI\/CD moderni. Una parte essenziale dello sviluppo \u00e8 diventata automazione<\/strong>, che consente di testare, distribuire e fornire nuove funzionalit\u00e0 agli utenti in modo molto pi\u00f9 veloce. Ad esempio, in tutti i nostri progetti viene automaticamente creato un pipeline CI ad ogni commit. In essa viene creato un'immagine, testata, distribuita in vari ambienti Kubernetes per debugging e controlli rimanenti, e se va tutto bene \u2014 le modifiche raggiungono l'utente finale. E non \u00e8 pi\u00f9 una rocket science, ma una consuetudine per molti \u2014 probabilmente anche per voi, dato che state leggendo questo articolo.<\/p>\n

    Poich\u00e9 la correzione dei bug e lo sviluppo di nuove funzionalit\u00e0 avviene in parallelo, e i rilasci possono essere effettuati pi\u00f9 volte al giorno, \u00e8 evidente che il processo di sviluppo \u00e8 accompagnato da un numero significativo di commit, il che significa \u2014 con un gran numero di immagini nel registry<\/strong>. Di conseguenza, emerge la questione di come organizzare una pulizia efficace del registry, cio\u00e8 la rimozione delle immagini obsolete.<\/p>\n

    Ma come possiamo davvero determinare se un'immagine \u00e8 ancora attuale?<\/p>\n

    Criteri di attualit\u00e0 dell'immagine<\/h2>\n

    \nNella stragrande maggioranza dei casi, i principali criteri saranno i seguenti:<\/p>\n

    1. Il primo (il pi\u00f9 ovvio e critico di tutti) sono le immagini che sono attualmente utilizzate in Kubernetes<\/strong>. La rimozione di queste immagini potrebbe portare a costi significativi a causa dei tempi di inattivit\u00e0 della produzione (ad esempio, le immagini potrebbero essere necessarie durante la replica) o vanificare gli sforzi del team che si occupa del debug su uno dei contorni. (Per questa ragione abbiamo persino creato un <\/i>Prometheus exporter<\/i><\/a><\/noindex>, che monitora l'assenza di tali immagini in qualsiasi cluster Kubernetes.)<\/i><\/p>\n

    2. Il secondo (meno ovvio, ma ancora molto importante e nuovamente relativo all'operativit\u00e0) sono le immagini che sono necessarie per il rollback in caso di gravi problemi.<\/strong> nella versione attuale. Ad esempio, nel caso di Helm, si tratta delle immagini utilizzate nelle versioni salvate del rilascio. (A proposito, di default in Helm c'\u00e8 un limite di 256 revisioni, ma difficilmente qualcuno ha davvero bisogno di salvarle molteplici versioni? ..) questo<\/i> Dopotutto, noi, in particolare, memorizziamo le versioni affinch\u00e9 possano essere utilizzate in seguito, cio\u00e8 per \u00abtornare\u00bb a esse in caso di necessit\u00e0.<\/p>\n

    3. Il terzo \u2014 le esigenze degli sviluppatori<\/strong>: tutte le immagini che sono correlate ai loro lavori attuali. Ad esempio, se consideriamo una PR, ha senso mantenere l'immagine corrispondente all'ultimo commit e, diciamo, al commit precedente: in questo modo lo sviluppatore potr\u00e0 tornare rapidamente a qualsiasi attivit\u00e0 e lavorare con le ultime modifiche. <\/p>\n

    4. Il quarto \u2014 le immagini che corrispondono alle versioni della nostra applicazione<\/strong>, cio\u00e8 sono il prodotto finale: v1.0.0, 20.04.01, sierra, ecc.<\/p>\n

    NB: I criteri qui definiti sono stati elaborati sulla base dell'esperienza acquisita interagendo con decine di team di sviluppo provenienti da diverse aziende. Tuttavia, a seconda delle peculiarit\u00e0 nei processi di sviluppo e delle infrastrutture utilizzate (ad esempio, se Kubernetes non \u00e8 in uso), questi criteri possono differire. <\/p>\n

    Criteri di conformit\u00e0 e soluzioni esistenti<\/h2>\n

    \nI servizi popolari con container registry di solito offrono le proprie politiche di pulizia delle immagini: in esse puoi definire le condizioni in base alle quali un tag viene rimosso dal registry. Tuttavia, le possibilit\u00e0 di queste condizioni sono limitate a parametri come nomi, data di creazione e numero di tag*.<\/p>\n

    * Dipende dalle specifiche implementazioni del container registry. Abbiamo esaminato le possibilit\u00e0 delle seguenti soluzioni: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 aggiornato a settembre 2020.<\/i><\/p>\n

    Un insieme di parametri del genere \u00e8 pi\u00f9 che sufficiente per soddisfare il quarto criterio, cio\u00e8 quello di selezionare le immagini corrispondenti alle versioni. Tuttavia, per tutti gli altri criteri \u00e8 necessario optare per una soluzione compromissoria (una politica pi\u00f9 rigorosa o, al contrario, pi\u00f9 indulgente), a seconda delle aspettative e delle risorse finanziarie.<\/p>\n

    Ad esempio, il terzo criterio, relativo alle esigenze degli sviluppatori, pu\u00f2 essere affrontato attraverso l'organizzazione dei processi all'interno dei team: una denominazione specifica delle immagini, la gestione di liste di autorizzazione speciali e accordi interni. Ma alla fine \u00e8 comunque necessario automatizzarlo. E se le soluzioni pronte non sono sufficienti, bisogna crearne di proprie.<\/p>\n

    La situazione \u00e8 simile per i primi due criteri: non possono essere soddisfatti senza ricevere dati da un sistema esterno, quello in cui avviene il deployment delle applicazioni (nel nostro caso, Kubernetes).<\/p>\n

    Illustrazione del workflow in Git<\/h3>\n

    \nSupponiamo che lavoriate pi\u00f9 o meno secondo questo schema in Git:<\/p>\n

    \"Il
    \n
    \nL'icona con la testa nello schema indica le immagini dei container che attualmente sono distribuite in Kubernetes per alcuni utenti (utenti finali, tester, manager, ecc.) o utilizzate dagli sviluppatori per il debug e scopi simili.<\/i><\/p>\n

    Cosa succeder\u00e0 se le politiche di pulizia consentono di mantenere (non eliminare) le immagini solo in base ai nomi dei tag specificati<\/b>?<\/p>\n

    \"Il
    \n
    \nOvviamente, uno scenario del genere non far\u00e0 felice nessuno.<\/p>\n

    Cosa cambier\u00e0 se le politiche consentono di non eliminare le immagini in base a un intervallo di tempo specifico \/ al numero degli ultimi commit<\/b>?<\/p>\n

    \"Il
    \n
    \nIl risultato \u00e8 migliorato notevolmente, ma \u00e8 comunque lontano dall'ideale. Infatti, abbiamo ancora sviluppatori che necessitano di immagini nel registro (o addirittura distribuite in K8s) per il debug dei bug...<\/p>\n

    Riassumendo la situazione attuale del mercato: le funzioni disponibili nei registri dei container non offrono la flessibilit\u00e0 necessaria nella pulizia, e la ragione principale \u00e8 che non c'\u00e8 possibilit\u00e0 di interagire con il mondo esterno<\/strong>. Dunque, i team che necessitano di tale flessibilit\u00e0 sono costretti a implementare autonomamente la rimozione delle immagini \"dall'esterno\", utilizzando l'API Docker Registry (o l'API nativa della relativa implementazione).<\/p>\n

    Tuttavia, stavamo cercando una soluzione universale che automatizzasse la pulizia delle immagini per diversi team che utilizzano registri diversi\u2026<\/p>\n

    Il nostro percorso verso una pulizia universale delle immagini<\/h2>\n

    \nDa dove proviene questa esigenza? Il fatto \u00e8 che non siamo solo un gruppo di sviluppatori, ma un team che supporta molti di questi, aiutando a risolvere integralmente le questioni del CI\/CD. E il principale strumento tecnico per fare ci\u00f2 \u00e8 un'utilit\u00e0 Open Source werf<\/a><\/noindex>. La sua caratteristica principale \u00e8 che non svolge una sola funzione, ma accompagna i processi di consegna continua in tutte le fasi: dalla costruzione al deployment.<\/p>\n

    La pubblicazione nel registro* delle immagini (subito dopo la loro costruzione) \u00e8 una funzione ovvia di tale utilit\u00e0. E poich\u00e9 le immagini vengono archiviate, se il vostro deposito non \u00e8 illimitato, \u00e8 necessario occuparsi anche della loro successiva pulizia. Di come abbiamo avuto successo in questo, soddisfacendo tutti i criteri stabiliti, sar\u00e0 parlato successivamente.<\/p>\n

    * Anche se i registry possono variare (Docker Registry, GitLab Container Registry, Harbor, ecc.), gli utenti affrontano gli stessi problemi. La soluzione universale nel nostro caso non dipende dall'implementazione del registry, poich\u00e9 viene eseguita al di fuori dei registry stessi e offre un comportamento uniforme per tutti.<\/i><\/p>\n

    Sebbene utilizziamo werf come esempio di implementazione, speriamo che gli approcci usati possano essere utili anche ad altre squadre che si trovano ad affrontare difficolt\u00e0 simili.<\/p>\n

    Quindi, ci siamo occupati di un'implementazione<\/i> esterna del meccanismo per la pulizia delle immagini \u2014 invece delle funzionalit\u00e0 gi\u00e0 integrate nei registry per i container. Il primo passo \u00e8 stato utilizzare l'API di Docker Registry per creare le stesse politiche primitive riguardo al numero di tag e al loro tempo di creazione (menzionate sopra). A queste \u00e8 stata aggiunta una lista di autorizzazione basata sulle immagini utilizzate nell'infrastruttura distribuita<\/strong>, cio\u00e8 Kubernetes. Per quest'ultimo, \u00e8 stato sufficiente scorrere tutte le risorse distribuite tramite l'API di Kubernetes e ottenere un elenco di valori. image<\/code>.<\/p>\n

    Questa soluzione banale ha risolto il problema pi\u00f9 critico (criterio n. 1), ma \u00e8 stata solo l'inizio del nostro percorso di miglioramento del meccanismo di pulizia. Il passo successivo \u2014 e molto pi\u00f9 interessante \u2014 \u00e8 stato la soluzione per collegare le immagini pubblicate alla storia di Git<\/strong>.<\/p>\n

    Schemi di tagging<\/h3>\n

    \nPer iniziare, abbiamo scelto un approccio in cui l'immagine finale deve conservare le informazioni necessarie per la pulizia e abbiamo strutturato il processo sugli schemi di tagging. Durante la pubblicazione dell'immagine, l'utente sceglieva un'opzione di tagging specifica (git-branch<\/code>, git-commit<\/code> o git-tag<\/code>) e utilizzava il valore corrispondente. Nelle CI systems, l'impostazione di questi valori veniva eseguita automaticamente sulla base delle variabili d'ambiente. In sostanza l'immagine finale veniva collegata a un determinato primitivo Git<\/strong>, conservando i dati necessari per la pulizia nelle etichette.<\/p>\n

    Con questo approccio \u00e8 stato creato un insieme di politiche che permetteva di utilizzare Git come unica fonte di verit\u00e0:<\/p>\n