{"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 \u2018pulizia intelligente\u2019 delle immagini dei container e la sua soluzione in werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Il
\n
\nL'articolo esamina la problematica della pulizia delle immagini che si accumulano nei registri dei contenitori (Docker Registry e suoi analoghi) nel contesto degli attuali pipeline CI\/CD per le applicazioni cloud native distribuite su Kubernetes. Vengono forniti i principali criteri di attualit\u00e0 delle immagini e le difficolt\u00e0 derivanti nell'automazione della pulizia, nel risparmio di spazio e nella soddisfazione delle esigenze dei team. Infine, attraverso un esempio concreto di un progetto Open Source, spiegheremo come queste difficolt\u00e0 possano essere superate.<\/p>\n

Introduzione<\/h2>\n

\nIl numero di immagini nel registro dei contenitori pu\u00f2 crescere rapidamente, occupando pi\u00f9 spazio di archiviazione e, di conseguenza, aumentando significativamente il suo costo. 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. in qualche modo pulire le immagini.<\/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 simili), il registro non si ingrandir\u00e0 e per un lungo periodo non sar\u00e0 necessario nemmeno pensare alla pulizia. Infatti, tutte le immagini obsolete vengono sovrascritte e non rimane lavoro da fare per la pulizia (tutto viene gestito dal garbage collector standard).<\/p>\n

    Tuttavia, questo approccio limita notevolmente lo sviluppo e raramente si adatta ai progetti CI\/CD moderni. Un elemento imprescindibile dello sviluppo \u00e8 diventato automazione<\/strong>, che consente di testare, distribuire e fornire nuove funzionalit\u00e0 agli utenti in modo molto pi\u00f9 rapido. Ad esempio, in tutti i nostri progetti, ad ogni commit viene automaticamente creato un pipeline CI. In esso viene assemblata un'immagine, testata, distribuita in diversi ambienti Kubernetes per debugging e ulteriori verifiche, e se tutto va bene, le modifiche arrivano all'utente finale. E non \u00e8 pi\u00f9 una questione di rocket science, ma una routine per molti \u2014 probabilmente anche per te, dato che leggi questo articolo.<\/p>\n

    Poich\u00e9 la risoluzione dei bug e lo sviluppo di nuove funzionalit\u00e0 avvengono in parallelo, e i rilasci possono avvenire pi\u00f9 volte al giorno, \u00e8 ovvio che il processo di sviluppo \u00e8 accompagnato da un considerevole numero di commit, e quindi \u2014 un gran numero di immagini nel registry<\/strong>. Di conseguenza, sorge l'importante questione di come organizzare una pulizia efficace del registry, ossia la rimozione delle immagini obsolete.<\/p>\n

    Ma come si pu\u00f2 definire se un'immagine \u00e8 attuale?<\/p>\n

    Criteri di rilevanza dell'immagine<\/h2>\n

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

    1. Il primo (il pi\u00f9 ovvio e critico di tutti) \u00e8 rappresentato dalle immagini che attualmente vengono utilizzate in Kubernetes<\/strong>. La rimozione di queste immagini potrebbe comportare costi significativi dovuti ai 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 questo motivo abbiamo persino creato un <\/i>exporter Prometheus<\/i><\/a><\/noindex>, per monitorare l'assenza di tali immagini in qualsiasi cluster Kubernetes.)<\/i><\/p>\n

    2. Il secondo (meno ovvio, ma comunque molto importante e ancora relativo all'operativit\u00e0) sono le immagini che sono necessarie per il downgrade 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 \u00e8 improbabile che qualcuno abbia realmente bisogno di mantenere tanto<\/i> grande numero di versioni?..) Infatti, noi, per esempio, conserviamo versioni in modo da poterle utilizzare successivamente, cio\u00e8 \"tornare\" su di esse in caso di necessit\u00e0.<\/p>\n

    3. Il terzo \u00e8 il bisogno degli sviluppatori<\/strong>: tutte le immagini correlate ai loro lavori attuali. Ad esempio, se stiamo considerando un PR, ha senso mantenere l'immagine corrispondente all'ultimo commit e, diciamo, al commit precedente: in questo modo lo sviluppatore pu\u00f2 tornare rapidamente a qualsiasi attivit\u00e0 e lavorare con le ultime modifiche. <\/p>\n

    4. Il quarto sono 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 indicati qui sono stati formulati sulla base dell'esperienza di interazione con decine di team di sviluppo di diverse aziende. Tuttavia, naturalmente, a seconda delle peculiarit\u00e0 nei processi di sviluppo e dell'infrastruttura utilizzata (ad esempio, se non viene utilizzato Kubernetes), questi criteri possono variare. <\/p>\n

    Corrispondenza dei criteri e soluzioni esistenti<\/h2>\n

    \nI servizi popolari con container registry offrono generalmente le proprie politiche di pulizia delle immagini: in esse \u00e8 possibile 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 implementazioni specifiche 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 alla data di settembre 2020.<\/i><\/p>\n

    Un tale insieme di parametri \u00e8 pi\u00f9 che sufficiente per soddisfare il quarto criterio \u2014 cio\u00e8 selezionare le immagini corrispondenti alle versioni. Tuttavia, per tutti gli altri criteri \u00e8 necessario scegliere una qualche soluzione di compromesso (una politica pi\u00f9 rigida o, al contrario, pi\u00f9 permissiva) \u2014 a seconda delle aspettative e delle possibilit\u00e0 finanziarie.<\/p>\n

    Ad esempio, il terzo criterio \u2014 legato alle esigenze degli sviluppatori \u2014 pu\u00f2 essere affrontato organizzando i processi all'interno dei team: denominazione specifica delle immagini, gestione di speciali allow lists e accordi interni. Ma alla fine deve comunque essere automatizzato. E se le funzionalit\u00e0 delle soluzioni pronte non sono sufficienti, \u00e8 necessario fare qualcosa di proprio.<\/p>\n

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

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

    \nSupponiamo che tu stia lavorando pi\u00f9 o meno con questo schema in Git:<\/p>\n

    \"Il
    \n
    \nNella diagramma, le icone con la testa indicano le immagini dei contenitori attualmente 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
    \n\u00c8 ovvio che tale scenario non far\u00e0 piacere a nessuno.<\/p>\n

    Cosa cambier\u00e0 se le politiche permettono di non eliminare le immagini in base a un intervallo temporale specificato \/ numero di ultimi commit<\/b>?<\/p>\n

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

    Ricapitolando la situazione attuale sul mercato: le funzionalit\u00e0 disponibili nei registri dei contenitori non offrono la flessibilit\u00e0 necessaria durante la pulizia, e la principale ragione \u00e8 che non c'\u00e8 possibilit\u00e0 di interagire con il mondo esterno<\/strong>. Si tratta quindi di team che richiedono tale flessibilit\u00e0, costretti a gestire autonomamente la rimozione delle immagini \"esternamente\", utilizzando l'API di 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

    \nPerch\u00e9 c'\u00e8 questa necessit\u00e0? Il fatto \u00e8 che non siamo un gruppo di sviluppatori isolato, ma un team che supporta molteplici gruppi di questo tipo, aiutando a risolvere complessivamente le questioni CI\/CD. E il principale strumento tecnico per questo \u00e8 un'utilit\u00e0 Open Source werf<\/a><\/noindex>. La sua particolarit\u00e0 \u00e8 che non esegue una sola funzione, ma accompagna i processi di consegna continua in tutte le fasi: dalla compilazione 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 memorizzate l\u00ec, se il tuo archivio non \u00e8 illimitato, \u00e8 necessario occuparsi anche della loro successiva pulizia. Di come abbiamo raggiunto il successo in questo, soddisfacendo tutti i criteri richiesti, si parler\u00e0 pi\u00f9 avanti.<\/p>\n

    * Anche se i registri stessi possono essere diversi (Docker Registry, GitLab Container Registry, Harbor, ecc.), i loro utenti si trovano di fronte agli stessi problemi. La soluzione universale nel nostro caso non dipende dall'implementazione del registro, poich\u00e9 viene eseguita al di fuori dei registri stessi e offre un comportamento uniforme per tutti.<\/i><\/p>\n

    Anche se utilizziamo werf come esempio di implementazione, speriamo che gli approcci utilizzati possano essere utili anche ad altri team che si trovano ad affrontare difficolt\u00e0 simili.<\/p>\n

    Quindi, ci siamo occupati esternamente<\/i> dell'implementazione di un meccanismo per la pulizia delle immagini \u2014 invece delle funzionalit\u00e0 gi\u00e0 integrate nei registri per i contenitori. Il primo passo \u00e8 stato l'uso dell'API di Docker Registry per creare le stesse politiche primitive riguardo al numero di tag e al loro tempo di creazione (menzionati sopra). A esse \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

    Una soluzione cos\u00ec triviale ha risolto il problema pi\u00f9 critico (criterio n. 1), ma \u00e8 stata solo l'inizio del nostro viaggio per migliorare il meccanismo di pulizia. Il passo successivo \u2014 decisamente pi\u00f9 interessante \u2014 \u00e8 stato trovare una soluzione per collegare le immagini pubblicate con la 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 costruito il processo sugli schemi di tagging. Quando si pubblica un'immagine, l'utente seleziona una specifica opzione di tagging (git-branch<\/code>, git-commit<\/code> o git-tag<\/code>) e utilizza il valore corrispondente. Nei sistemi CI, l'impostazione di questi valori avveniva automaticamente sulla base delle variabili d'ambiente. In sostanza l'immagine finale era collegata a un particolare primitivo Git<\/strong>, conservando i dati necessari per la pulizia nelle etichette.<\/p>\n

    Con questo approccio, \u00e8 stata realizzata una serie di politiche che consentivano di utilizzare Git come unica fonte di verit\u00e0:<\/p>\n