Abbiamo sempre parlato di hash ottenuti tramite SHA256, ma per fare il pull di un’immagine abbiamo sempre utilizzato il suo nome e, in alcuni casi, un tag.
Come viene associato un nome ad un immagine? Per capirlo abbiamo bisogno di qualche informazione in più sul concetto di Registry.
I Registry persistono le immagini. Per darvi un’idea, un registry fa per le immagini qualcosa di simile a quello che Github fa per il codice.
I registry permettono di creare diversi repository, ognuno dei quali può contenere diverse immagini, un po’ come se venissero fatti dei branch su Github.
Ogni repository può contenere più immagini, spesso per fornirne diverse versioni.
Le immagini all’interno di un repository sono contraddistinte da un hash univoco, ma possono avere anche dei tag.
Anche i tag funzionano in modo simile a git, permettendo di gestire diverse versioni. In realtà non si tratta di un vero e proprio indicatore di versione, ma di un etichetta appiccicata ad uno specifico commit di quell’immagine nel suo repository.
Giusto per completezza, i Registry possono essere di tre tipi.
- ufficiali: ovvero Docker Hub
- on-premise: dove viene installato sulle proprie macchine
- di terze parti: figure terze forniscono un servizio simile a quello offerto da Docker Hub
Docker Hub
I repository presenti su Docker Hub si dividono in ufficiali e non ufficiali, ma come possiamo distinguerli?
Nella pagine relativa ad un’immagine ufficiale su docker hub, viene specificata la dicitura “Docker Official Images”. Inoltre, l’url di un repository non ufficiale è nella forma https://hub.docker.com/r/user_or_organization/repository mentre, nel caso di un repository ufficiale, l’utente è sostituito dal carattere underscore ‘_’ (es. https://hub.docker.com/_/alpine).
Quelle non ufficiali sono curate da figure terze, persone oppure organizzazioni. Come è possibile osservare anche dal repository “https://hub.docker.com/r/alpine/git“, l’underscore è stato sostituito dal nome utente o dell’organizzazione che possiede il repository.
Immediatamente prima dello username, vi è l’indicazione del fatto che la risorsa sia un utente o un repository rispettivamente con le lettere ‘u’ o ‘r’.
L’organizzazione relativa al repository di alpine con git dell’esempio qui sopra è “alpine”: https://hub.docker.com/u/alpine
Le immagini non hanno propriamente un nome
Ora che sappiamo cos’è un registry, cos’è un repository e cos’è un tag, siamo pronti a scoprire che le immagini in realtà non hanno propriamente un nome ma solo repository e tag.
Eseguendo docker image ls, infatti, vediamo che la prima colonna non ha come titolo ‘NAME’ ma ‘REPOSITORY’.
Quando scarichiamo un’immagine da Docker Hub, quindi, ci stiamo riferendo ad una coppia di repository e tag.
In caso di repository non ufficiali, dobbiamo specificare anche il nome o l’organizzazione dell’account che possiede il repository prima del nome del repository e separandolo con uno slash.
Tag
Quale versione dell’immagine viene scaricata all’esecuzione di docker image pull <repository> se non specifico il tag?
In caso di assenza di tag, Docker userà implicitamente il tag “latest”.
Attenzione però. Non è scontato che latest sia il tag relativo all’ultima versione dell’immagine. Molti repository utilizzano tag alpha, beta, edge per indicare le ultime versioni disponibili.
Proprio come in git, ad un immagine possono essere associati molti tag.
È facile accorgersi di ciò guardando l’output di “docker image ls | grep alpine” : osserveremo un’occorrenza per ogni tag, ma l’hash (IMAGE ID) rimarrà lo stesso per le versioni 3.9 e 3.9.6.
redis 6-alpine 360360313017 3 weeks ago 31.6MB redis 5-alpine 3661c84ee9d0 4 weeks ago 29.8MB alpine 3.9 78a2ce922f86 4 weeks ago 5.55MB alpine 3.9.6 78a2ce922f86 4 weeks ago 5.55MB alpine latest f70734b6a266 4 weeks ago 5.61MB
—
Prosegui su: CLI delle immagini