Come funzionano i tag Docker?

Logo del portone.

Le immagini Docker usano i registri per il controllo della versione, come l’hub Docker che ospita immagini pubbliche che chiunque può scaricare ed eseguire. Tuttavia, prima di caricare un’immagine nell’Hub o in qualsiasi registro, è necessario assegnarle i tag appropriati.

Contenitore contro immagine

È importante comprendere la differenza tra contenitori e immagini prima di parlare di tag, poiché sono spesso usati in modo abbastanza intercambiabile e ciò può creare confusione.

Un’immagine Docker è ciò che ottieni dalla corsa docker build con il tuo Dockerfile. È composto da più livelli per ottimizzare l’utilizzo del disco e della memoria. Un’immagine è di sola lettura.

Un contenitore Docker è un’istanza di un’immagine in cui vengono effettivamente eseguiti i processi. È un file system di lettura/scrittura, quindi essenzialmente un’immagine è un modello da cui si utilizza per creare più contenitori. Contiene il codice di base e tutto ciò di cui l’app ha bisogno per iniziare. I contenitori vengono inizializzati con l’immagine quando vengono creati, quindi possono modificare il file system a loro piacimento.

Le immagini sono ciò che si invia al registro contenitori. Quindi, sui tuoi server, puoi fare riferimento all’immagine nel registro per scaricare il contenitore.

Tag Traccia le versioni delle immagini costruite

Ogni volta che corri un docker build, crei una nuova immagine con un ID univoco, ad esempio “38054d5e8a27”.

I tag sono semplicemente etichette che forniscono un modo migliore per gestire il controllo della versione e le versioni. Sono come etichette che puoi assegnare a qualsiasi build completata. Piuttosto che fare riferimento all’ID build, puoi taggare un’immagine con un’etichetta nel formato major.minor.patch ed essere facilmente in grado di dire quale immagine è quale, o qualunque formato preferisca la tua organizzazione.

L’etichettatura è abbastanza facile. Puoi usare docker tag farlo dopo il fatto, ma è molto più facile farlo quando costruisci usando il -t bandiera:

 docker build -t repository/image:tag .

Questo crea l’immagine dal Dockerfile e la tagga con il tag che hai specificato. Il tag è il [:TAG] parte, dopo il punto e virgola, anche se Docker dirà “Successfully tagged repository/image:tag.” Il repository/image part è solo il nome dell’immagine, e se stai pianificando di eseguire il push in un repository, devi taggarlo nel repository/image:tag formato.

Per Docker Hub, il nome del repository è solo il tuo nome utente, quindi il comando sarà simile a:

 docker build -t anthonyheddings/nginx:tag .

Se non specifichi un tag specifico, Docker lo contrassegna automaticamente come “più recente”.

Un’altra pratica comune è quella di taggare l’immagine con l’ID commit git, collegando così il controllo della versione con le immagini create. Puoi automatizzarlo abbastanza facilmente con git rev-parse:

docker build -t vicerust/core:$(git rev-parse --verify HEAD) .

Una volta che un’immagine è stata taggata, puoi inviarla al registro con docker push, passando in repository/image nome:

docker push repository/image

Da lì, puoi accedervi in docker run come normale. Se non specifichi un tag, docker run usa automaticamente latest.

L’ultimo non significa sempre “ultimo”

Il "Latest" il tag è un po’ confuso. Nonostante come suoni il nome, non sempre punta all’ultima versione. È semplicemente un tag speciale che viene assegnato automaticamente ogni volta che non specifichi un tag. Questo ha l’effetto di evitare del tutto i tag e di spingere semplicemente una versione “più recente”.

Puoi utilizzare l’ultimo tag semplicemente non specificando un tag specifico:

 docker build -t repository/image .

Oppure taggando manualmente un’immagine come latest:

 docker build -t repository/image:latest .

che funziona bene se stai usando solo il tag più recente. Ma se vuoi usare anche i tag ID versione, dovrai taggare due volte le tue immagini ogni volta, il che può portare a “latest” che non sempre significa l’ultima immagine creata. È buona norma evitare l’uso latest insieme ad altri tag per evitare questa confusione. Basta versione i tuoi tag, ogni volta, con numeri di patch manuali o con ID commit git.