Suggerimenti per l'assegnazione di tag e il controllo delle versioni delle immagini del contenitore

Quando si esegue il push delle immagini dei contenitori in un registro contenitori e le si distribuisce, è necessaria una strategia per l'assegnazione di tag e il controllo delle versioni delle immagini. In questo articolo vengono illustrati due approcci e la loro collocazione nel ciclo di vita del contenitore:

• Tag stabili: tag riutilizzati, ad esempio per indicare una versione principale o secondaria, ad esempio mycontainerimage:1.0.
• Tag univoci: un tag diverso per ogni immagine di cui si esegue il push in un registro, ad esempio mycontainerimage:abc123.

Tag stabili

Raccomandazione: usare tag stabili per mantenere immagini di base per le compilazioni dei contenitori. Evitare distribuzioni con tag stabili, perché questi tag continuano a ricevere aggiornamenti e possono introdurre incoerenze negli ambienti di produzione.

Tag stabili significa che uno sviluppatore, o un sistema di compilazione, può continuare a eseguire il pull di un tag specifico, che continua a ottenere gli aggiornamenti. Stabile non significa che il contenuto sia bloccato. Piuttosto, stabile implica che l'immagine deve essere stabile per la finalità di tale versione. Per far sì che rimangano "stabili", potrebbe essere necessario applicare patch di sicurezza o aggiornamenti del framework.

Esempio

Un team framework include la versione 1.0. Si sa che saranno spediti gli aggiornamenti, inclusi quelli secondari. Per supportare tag stabili per una determinata versione principale e secondaria, ci sono due set di tag stabili.

• :1: un tag stabile per la versione principale. 1 rappresenta la versione 1 "ultima" o "più recente"*.
• :1.0: un tag stabile per la versione 1.0, che consente a uno sviluppatore di legarsi agli aggiornamenti della 1.0 e di non essere trasferito alla 1.1 quando questa viene rilasciata.

Quando sono disponibili gli aggiornamenti dell'immagine di base o qualsiasi tipo di manutenzione del framework, le immagini con i tag stabili vengono aggiornate al digest più recente, che rappresenta la versione stabile più recente di quella versione.

In questo caso, i tag principali e secondari vengono gestiti con continuità. Da uno scenario di immagine di base, questo consente al proprietario dell'immagine di fornire immagini gestite.

Cancellare manifesti privi di tag

Se un'immagine con un tag stabile viene aggiornata, l'immagine in precedenza contrassegnata è priva di tag, generando un'immagine orfana. Il manifesto dell'immagine precedente i dati dei relativi unici dei livelli rimangono nel registro. Per mantenere le dimensioni del Registro di sistema, è possibile eliminare periodicamente manifesti privi di tag risultanti da aggiornamenti stabili delle immagini. Ad esempio, la rimozione automatica di manifesti senza tag precedenti a una durata specificata o l'impostazione di un criterio di conservazione per i manifesti senza tag.

Tag univoci

Raccomandazione: usare tag univoci per le distribuzioni, in particolare in un ambiente che potrebbe essere ridimensionato su più nodi. È probabile che si vogliano distribuzioni intenzionali di una versione coerente dei componenti. Se il contenitore viene riavviato o un agente di orchestrazione aumenta il numero di istanze, gli host non eseguiranno accidentalmente il pull di una versione più recente, che risulta incoerente con gli altri nodi.

L'assegnazione di tag univoci significa semplicemente che ogni immagine inserita in un registro possiede un tag univoco. I tag non vengono riutilizzati. Esistono diversi modelli che è possibile seguire per generare tag univoci, tra cui:

• Indicatore data e ora: questo approccio è piuttosto comune, perché è possibile indicare chiaramente quando è stata compilata l'immagine. Ma come correlarla al sistema di compilazione? È necessario trovare la compilazione che è stata completata nello stesso periodo? In quale fuso orario ti trovi? Tutti i sistemi di compilazione sono calibrati in formato UTC?

• Commit Git: questo approccio funziona fino a quando non si inizia a supportare gli aggiornamenti delle immagini di base. Se si verifica un aggiornamento dell'immagine di base, il sistema di compilazione viene avviata con lo stesso commit Git della build precedente. Tuttavia, l'immagine di base ha nuovo contenuto. In generale, un commit Git fornisce un tag semistabile.

• Digest manifesto: ogni immagine del contenitore di cui è stato eseguito il push in un registro contenitori è associata a un manifesto, identificato da un hash SHA-256 univoco o da un digest. Anche se univoco, il digest è lungo, difficile da leggere e non correlato all'ambiente di compilazione.

• L'ID di compilazione: questa opzione può essere migliore perché è probabile che sia incrementale e consente di correlare alla compilazione specifica per trovare tutti gli artefatti e i log. Tuttavia, al pari di un digest manifesto, potrebbe essere difficile da leggere per un essere umano.

  Se l'organizzazione possiede diversi sistemi di compilazione, il prefisso del tag con il nome del sistema di compilazione è una variante di tale opzione: <build-system>-<build-id>. Ad esempio, si possono differenziare le build dal sistema di build Jenkins del team API e dal sistema di build Azure Pipelines del team Web.

Bloccare i tag di immagine distribuiti

Come procedura consigliata, è consigliabile bloccare qualsiasi tag di immagine distribuito impostando il relativo attributo write-enabled su false. Questa procedura impedisce di rimuovere inavvertitamente un'immagine dal Registro di sistema ed eventualmente interrompere le distribuzioni. È possibile includere il passaggio del blocco nella pipeline di versione.

Il blocco di un'immagine distribuita consente comunque di rimuovere altre immagini non distribuite dal registro usando le funzionalità di Registro Azure Container per gestire il registro. Ad esempio, la rimozione automatica di manifesti senza tag o di immagini bloccate precedenti a una durata specificata o l'impostazione di un criterio di conservazione per i manifesti senza tag.

Passaggi successivi

Per una descrizione più dettagliata dei concetti riportati in questo articolo, vedere il post di blog Docker Tagging: Procedure consigliate per l'assegnazione di tag e il controllo delle versioni delle immagini Docker.

Per ottimizzare le prestazioni e un uso efficace del registro Azure Container, vedere Procedure consigliate per Registro Azure Container.