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

Quando si esegue il push delle immagini del contenitore in un registro contenitori e quindi si distribuisce tali immagini, è necessaria una strategia per l'assegnazione di tag alle immagini e il controllo delle versioni. Questo articolo illustra due approcci e dove ognuno si adatta durante il 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 : 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 le 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.

I tag stabili indicano che uno sviluppatore o un sistema di compilazione può continuare a eseguire il pull di un tag specifico, che continua a ottenere gli aggiornamenti. Stable non significa che il contenuto sia bloccato. Invece, stabile implica che l'immagine deve essere stabile per la finalità di tale versione. Per rimanere "stabile", potrebbe essere gestito per applicare patch di sicurezza o aggiornamenti del framework.

Esempio

Un team del framework viene fornito nella versione 1.0. Sanno che spediranno gli aggiornamenti, inclusi gli aggiornamenti secondari. Per supportare tag stabili per una determinata versione principale e secondaria, hanno due set di tag stabili.

• :1 : tag stabile per la versione principale. 1 rappresenta la versione "più recente" o "più recente" 1.*.
• :1.0- Un tag stabile per la versione 1.0, consentendo a uno sviluppatore di eseguire il binding agli aggiornamenti della versione 1.0 e non di essere inoltrato alla versione 1.1 quando viene rilasciato.

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

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

Eliminare manifesti senza tag

Se viene aggiornata un'immagine con un tag stabile, l'immagine contrassegnata in precedenza non viene contrassegnata con tag, generando un'immagine orfana. I dati del manifesto e del livello univoco dell'immagine precedente rimangono nel Registro di sistema. Per mantenere le dimensioni del Registro di sistema, è possibile eliminare periodicamente manifesti senza tag risultanti da aggiornamenti stabili delle immagini. Ad esempio, eliminare automaticamente i manifesti senza tag precedenti a una durata specificata o impostare un criterio di conservazione per i manifesti senza tag.

Tag univoci

Raccomandazione: usare tag univoci per le distribuzioni, in particolare in un ambiente che può 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, incoerente con gli altri nodi.

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

• Data e ora : questo approccio è abbastanza comune, perché è possibile indicare chiaramente quando è stata compilata l'immagine. Ma come correlarla al sistema di compilazione? È necessario trovare la compilazione completata contemporaneamente? In quale fuso orario ci si trova? 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 inizia con lo stesso commit Git della build precedente. Tuttavia, l'immagine di base ha un nuovo contenuto. In generale, un commit Git fornisce un tag semi-stabile.

• Digest del 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.

• ID compilazione: questa opzione può risultare ottimale perché è probabilmente incrementale e consente di correlare alla compilazione specifica per trovare tutti gli artefatti e i log. Tuttavia, come un digest manifesto, potrebbe essere difficile per un essere umano leggere.

  Se l'organizzazione ha diversi sistemi di compilazione, il prefisso del tag con il nome del sistema di compilazione è una variante di questa opzione: <build-system>-<build-id>. Ad esempio, è possibile distinguere le compilazioni dal sistema di compilazione Jenkins del team API e dal sistema di compilazione Azure Pipelines del team Web.

Bloccare i tag di immagine distribuiti

Come procedura consigliata, è consigliabile bloccare qualsiasi tag di immagine distribuito impostandone l'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 di blocco nella pipeline di versione.

Il blocco di un'immagine distribuita consente comunque di rimuovere altre immagini non distribuite dal registro usando Registro Azure Container funzionalità per mantenere il registro. Ad esempio, eliminare automaticamente manifesti senza tag o immagini sbloccate precedenti a una durata specificata o impostare un criterio di conservazione per manifesti senza tag.

Passaggi successivi

Per una descrizione più dettagliata dei concetti di 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 l'uso conveniente del registro Azure Container, vedere Procedure consigliate per Registro Azure Container.