CLI delle immagini

È giunto il momento di analizzare la Command-Line-Interface dedicata alle immagini.

Premetto che non si tratterà di una guida esaustiva. Si tratta piuttosto di apprendere il processo che porta a essere autonomi nella ricerca e utilizzo delle istruzioni necessarie a seconda delle circostanze e necessità.

Elencare le immagini

Analizziamo l’help del comando di listing relativo alle immagini con:

docker image ls --help

Ottenendo questo output:

Usage: docker image ls [OPTIONS] [REPOSITORY[:TAG]]
List images
Aliases:
  ls, images, list

Options:
  -a, --all             Show all images (default hides intermediate images)
      --digests         Show digests
  -f, --filter filter   Filter output based on conditions provided
      --format string   Pretty-print images using a Go template
      --no-trunc        Don't truncate output
  -q, --quiet           Only show numeric IDs

La prima cosa che salta all’occhio è che di default, tutte le immagini “intermedie” sono nascoste.

Mostrare le immagini Nascoste

Per accedere a tutte le immagini, comprese quelle intermedie, è necessario utilizzare un flag –all (o -a nella versione compatta).
Per il momento non è necessario approfondire la questione, sarà tutto più chiaro quando verrà affrontata la creazione delle immagini, tuttavia è possibile trovare ulteriori informazioni a questo link.

Filtri sulla lista delle immagini

Il flag –filter ( o -f nella versione compatta) permette di specificare quali immagini mostrare a seconda di alcune caratteristiche. In questo momento sono disponibili sono tre opzioni:

1. dangling=<booleano>
2. before=<hash_immagine>
3. since=<hash_immagine>

Nel primo caso, eseguendo:

docker image ls --filter dangling=true

si ottiene un elenco delle immagini create e poi sostituite. Queste immagini non saranno mai parte di un container.
La creazione di questo tipo di immagini è frequente nel processo di sviluppo, dove si creano molte immagini in sequenza e alcune rimangono inutilizzate nelle versioni successive. È possibile riconoscere queste immagini con un docker image ls perché avranno la colonna “NAME” valorizzata a “none”.

È altresì presente il comando simmetrico che permette di visualizzare solo le immagini che non sono rimaste “pendenti”.

I filtri before e since sono molto più semplici, eseguendo:

docker image ls --filter before=14b3ad

Si ottiene una lista di tutte le immagini presenti nel repository locale che sono state create prima dell’immagine con l’hash che inizia con 14b3ad.

Il filtro since funziona in modo simmetrico.

Scaricare un’immagine

Analizziamo l’help del comando preposto allo scaricamento immagini, ovvero docker image pull, con:

docker image pull --help

Ottenendo questo output:

Usage: docker image pull [OPTIONS] NAME[:TAG|@DIGEST]

Pull an image or a repository from a registr

Options:
  -a, --all-tags                Download all tagged images in the repository
      --disable-content-trust   Skip image verification (default true)
      --platform string         Set platform if server is multi-platform
                                capable
  -q, --quiet                   Suppress verbose output

Con il flag –all ( o -a nella versione compatta) vengono scaricate tutte le immagini del repository specificato per parametro per le quali sia stato definito un tag.
Questo comando torna comodo quando si vuole testare il comportamento di un servizio o di un aggiornamento su diverse versioni di una particolare immagine.

Rimozione delle immagini

Abbiamo capito che le immagini dangling non ci servono, per poterle rimuovere docker ha previsto un comando ad-hoc ovvero:

docker image prune

È tuttavia possibile rimuovere le immagini anche specificando l’elenco degli hash dopo il comando dedicato alla rimozione ovvero docker image rm.

Il comando seguente, è un esempio del comando di rimozione delle due immagini con hash che iniziano rispettivamente con ad17bc e cd55e6.

docker image rm ad17bc cd55e6

È importante ricordare che il prefisso dell’hash dell’immagine utilizzabile per identificarla deve identificare una sola immagine nel repository locale. La regola che preferisco è quella del “più piccolo prefisso univoco”, in genere basta utilizzare un prefisso univoco.

È possibile che un immagine sia in utilizzo da un container, anche se esso è in stato di stop o pause, in quel caso vi sono due opzioni:

1. rimuovere i container che usano l’immagine e poi rimuovere l’immagine
2. forzare la rimozione dell’immagine con il flag –force ( o -f nella forma compatta)

Ricerca delle immagini

Con il comando docker search vengono ricercate le immagini che, nel docker hub, contengono la stringa specificata. Di default il numero di immagini restituite è 25, tuttavia questo valore è modificabile fino a un massimo di 100 risultati.

L’esempio seguente mostra una ricerca con chiave “rails” fissando un limite di 100 risultati.

docker search --limit 100 rails

il risultato ha le seguenti colonne:

• NAME
• DESCRIPTION
• STARS
• OFFICIAL
• AUTOMATED

Le prime quattro colonne hanno nomi parlanti, l’ultima invece sta a specificare che la build è avvenuta in modo automatizzato, probabilmente un sistema di Continuous Integration.

è possibile specificare dei trigger che permettono di affinare la ricerca, ad esempio:

docker search --filter "is-official=true" <repository>

docker search --filter "is-automated=true" <repository>

Immagini multi architettura

Docker è nato su linux, ma si è poi esteso ad altri sistemi operativi, come Windows.
Inoltre ora docker supporta diverse architetture quali ad esempio ARM e RaspberryPy.

Sebbene questo sia assolutamente positivo, ci costringe a porci una domanda:

L’immagine che sto costruendo può venire utilizzata per istanziare un container sulla macchina sulla quale sta girando docker?

Image “Manifest” e “Manifest List”

Per ogni immagine, possono essere definiti due costrutti nel registry: Manifest e Manifest List.

Lascio il link alla documentazione: https://docs.docker.com/registry/spec/manifest-v2-2/

La Manifest List è una lista di architetture supportate da una immagine con riferimento ad un particolare tag.

Ogni record di tale lista è associato a un file manifest che specifica com’è fatta un’immagine definendo configurazioni e i relativi layer.

Quindi cosa succede al pull di un’immagine?

Ora possiamo fare un passo avanti e capire cosa accade in profondità al pull di un’immagine.

Al pull di un immagine, viene ricercata la versione compatibile con l’architettura dove è in esecuzione il demone di docker. Se questa viene trovata, allora viene scaricata l’immagine corrispondente altrimenti verrà utilizzato il manifest di default previsto per ogni immagine.

La creazione di una Manifest List è opzionale. A volte per evitare un overhead ingiustificato, altre volte perché alcuni software non sono cross platform e la definizione di una Manifest List perderebbe di senso.

—
Prosegui su: Dockerizing/Containerizing

Immagine:  Bella vista sul parco nazionale di Banff – it.freepik.com