“An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime.”

Moby Image readme.md v1.2

Tradotto: “Un’immagine è una raccolta ordinata di modifiche al filesystem di root e dei corrispondenti parametri di esecuzione da utilizzare all’interno di un container runtime.”

Mi rendo conto che da questa definizione si possa capire ben poco, cerco di rendere questa definizione più comprensibile.

Un immagine è fondamentalmente un pacchetto che contiene: Codice binario di un’App, dipendenze necessarie, Metadati e Istruzioni su come eseguire l’App.
Fondamentalmente è tutto qui.

L’applicazione verrà eseguita in un container, come processo dell’host. Questo significa che il kernel su cui gira il container creato a partire da questa immagine, è quello dell’host.

Le immagini e l’host condividono il kernel.

Un immagine può tuttavia utilizzare un Sistema Operativo diverso dall’host purché condividano il kernel, ad esempio potrei avere un host RedHat ed un container Ubuntu che condividono il kernel linux.

Spesso le immagini contengono svariate utility dei sistemi operativi di cui fanno parte, fornendo un ambiente il più completo o specializzato possibile. Questo determina inesorabilmente un aumento della loro dimensione. Un esempio è l’immagine di Ubuntu.
Di contro, possono essere anche molto scarne, privilegiando la leggerezza e lasciando agli utilizzatori l’onere di aggiungere i pacchetti necessari. Un esempio di questa categoria è Alpine.

—
Prosegui su: Com’è fatta un’immagine

Immagine: eberhard9 – it.freepik.com

L'articolo Cos’è un’immagine? proviene da Docker Tutorial.

L’insieme ordinato dei layer, costituisce il singolo oggetto immagine. 

Questa struttura ha numerosi vantaggi; Il principale è che i layer sono riusabili. 

Ad esempio, se più immagini sono costruite a partire da un’immagine della stessa versione di Ubuntu, Docker non scaricherà ogni volta una nuova copia di tale immagine ma userà la stessa per costruire tutte le immagini coinvolte.

Come funziona la condivisione dei layer?

Alla prima richiesta l’immagine di partenza verrà scaricata, alle successive sarà recuperata dal repository locale dell’host. Per “repository locale dell’host” intendo il sistema che colleziona e organizza le immagini presenti sul device che sta scaricando le immagini.

A seconda delle dipendenze la dimensione di un’immagine può variare di molto. Si può variare da pochi KiloByte a svariati GigaByte.

E’ anche possibile creare un’immagine a partire da un container, facendone una sorta di fotografia. Per fare ciò si usa il comando docker container commit.
Va detto però che è un caso che trova applicazione solo in contesti particolari.

Per chi come me si occupa di sviluppare software, penso possa essere utile fare un parallelo (per cercare di dare un’idea, non una definizione). Pensate alle immagini come a delle classi e i container come degli oggetti, ovvero delle immagini istanziate.

In realtà anche le immagini vengono costruite, producendo un binario, ma questo avviene build-time. I container invece vengono costruiti run-time.

—
Prosegui su: Cosa succede quando scarichiamo un’immagine

Immagine: Legno foto creata da wirestock – it.freepik.com

L'articolo Com’è fatta un’immagine? proviene da Docker Tutorial.

Quando scarichiamo un’immagine, ne specifichiamo solo il nome ed in alcuni casi il tag identificativo. Questo può far pensare di aver a che fare con un oggetto unico.

Nella sezione “Com’è fatta un’immagine” abbiamo visto che non è così, siamo a conoscenza del fatto che esiste un meccanismo che compone le immagini per layer successivi.

Tuttavia vale la pene vederlo con i nostri occhi scaricando due release consecutive della stessa immagine. Facciamo un esempio con redis basato su Alpine:

docker image pull redis:5-alpine

ottenendo questo output:

5-alpine: Pulling from library/redis
cbdbe7a5bc2a: Already exists 
dc0373118a0d: Pull complete 
cfd369fe6256: Pull complete 
3e45770272d9: Pull complete 
558de8ea3153: Pull complete 
a2c652551612: Pull complete 
Digest: sha256:83a3af36d5e57f2901b4783c313720e5fa3ecf0424ba86ad9775e06a9a5e35d0
Status: Downloaded newer image for redis:5-alpine
docker.io/library/redis:5-alpine

Già da qui notiamo che vengono scaricati più frammenti e non un blocco unico. Qualcosa dovrebbe già farci sospettare che l’ipotesi dell’immagine a blocco unico comincia a scricchiolare.
Possiamo inoltre vedere già il primo esempio di riuso (dalla riga “cbdbe7a5bc2a: Already exists”). Dato che stiamo utilizzando le versioni Alpine, probabilmente stiamo riutilizzando il layer del kernel Alpine da un’immagine scaricata in precedenza (qui).
Scarichiamo ora la versione 6-alpine con:

docker image pull redis:6-alpine

ottenendo questo output:

6-alpine: Pulling from library/redis
cbdbe7a5bc2a: Already exists 
dc0373118a0d: Already exists 
cfd369fe6256: Already exists 
e5396613619b: Pull complete 
6809b5ad2cd4: Pull complete 
386ecfe54d06: Pull complete 
Digest: sha256:2586f31f74ac1d7dc6f6c7eabca42f09bba5ec9911fc519d55fbd7508a9c4f01
Status: Downloaded newer image for redis:6-alpine
docker.io/library/redis:6-alpine

Qui il riuso diventa evidente. Alcuni “frammenti” della seconda immagine sono stati recuperati dalla cache del repository locale.

C’è da dire che un utilizzatore di Docker alle prime armi, avrebbe potuto lanciare diversi container senza essere consapevole di tale aspetto. Docker rende tale aspetto assolutamente trasparente, ma è indispensabile conoscerlo per evitare situazioni spiacevoli.

Come vengono aggregati i layer?

L’aggregazione dei livelli (layer) avviene mediante il concetto di Union File System.

Mi piacerebbe andare più a fondo sulla questione (parlando di aufs, overlay2, ecc), ma non vorrei andare troppo fuori tema.

Quello che dobbiamo portarci a casa è che ogni layer può aggiungere file, cartelle o metadati al prodotto dei layer precedenti. 

I layer vengono applicati uno alla volta, in ordine. Al termine dell’applicazione di un layer X, la struttura file risultante sarà la fusione di tutte le modifiche apportate da tutti i layer precedenti e dal layer X. 

Per il container, la struttura file su cui si poggia può essere intesa come un’entità singola.

—
Prosegui su: Analizzare la struttura di un’immagine

Immagine: Viaggio foto creata da freepik – it.freepik.com

L'articolo Cosa succede quando scarichiamo un’immagine proviene da Docker Tutorial.

docker image history

Attraverso questo comando è possibile visualizzare tutte le modifiche che un’immagine ha subito. Per essere precisi, va detto che non è una lista precisa di tutti i layer, alcune istruzioni (ad esempio ENV) non saranno tracciate, ma in linea di massima pensare questa lista come l’elenco dei layer è una buona approssimazione.

Credo che il miglior modo di vedere questo aspetto sia con un esempio. Prendiamo l’immagine di ubuntu.

Per scaricarla eseguiamo il comando docker image pull specificando il nome dell’immagine, in questo caso ubuntu.

docker image pull ubuntu

Nel mio caso, l’output è:

Using default tag: latest
latest: Pulling from library/ubuntu
d51af753c3d3: Pull complete 
fc878cd0a91c: Pull complete 
6154df8ff988: Pull complete 
fee5db0ff82f: Pull complete 
Digest: sha256:747d2dbbaaee995098c9792d99bd333c6783ce56150d1b11e333bbceed5c54d7
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

Non abbiamo specificato il tag, quindi è stata scaricata la versione taggata come latest. Eseguiamo quindi il comando

docker image history ubuntu:latest

Ottenendo questo output:

IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
1d622ef86b13        4 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B                  
<missing>           4 weeks ago         /bin/sh -c mkdir -p /run/systemd && echo 'do…   7B                  
<missing>           4 weeks ago         /bin/sh -c set -xe   && echo '#!/bin/sh' > /…   811B                
<missing>           4 weeks ago         /bin/sh -c [ -z "$(apt-get indextargets)" ]     1.01MB              
<missing>           4 weeks ago         /bin/sh -c #(nop) ADD file:a58c8b447951f9e30…   72.8MB  

Osservando l’output, è possibile notare che alcuni layer lasciano la dimensione dell’immagine pressoché invariata. Il motivo è che questi ultimi aggiungono solo metadati, senza apportare modifiche ai File.

I layer di questo tipo sono facilmente identificabili poché nell’output del comando docker image history, compaiono con la colonna “SIZE” valorizzata con la stringa “0B”, che sta per zero Byte. 

Nella colonna “CREATED” si può osservare la data di creazione. In questo caso sono tutte uguali, ma potrebbe non essere sempre così.

I layer sono parte di un’immagine e vengono caricati su una sorta di repository detto registry. Quello di default per docker si chiama Docker Hub ed è raggiungibile all’indirizzo hub.docker.com. Non mi dilungo oltre sui registry, avremo modo di parlarne più in dettaglio nella lezione dedicata.

Se i layer hanno valorizzazioni diverse nella colonna CREATED, significa che hanno subito variazioni in momenti diversi.

Perché risulti più chiaro, immaginate un repository git. Ogni volta che aggiornate un file esso aggiornerà anche la propria data di ultima modifica. Tuttavia i file che non hanno subito variazioni in quel commit manterranno la data di ultima modifica originaria.

Ora dovrebbe sorgere spontanea una domanda: se parliamo di “ultima modifica”, perché la colonna si chiama “CREATED” e non “UPDATED”?

Teniamo a mente che stiamo guardando la struttura che compone l’immagine e non l’immagine come pacchetto unico.
Fatta questa premessa, la risposta è che un layer costruisce un nuovo ‘strato’ a partire dalla fusione degli ‘strati’ creati negli step precedenti. Ricordate lo Union File System?

Il codice binario deve essere ricostruito, non solo aggiornato. Da qui l’indicazione di creazione e non solo di aggiornamento. 

L’hash che vediamo in testa alla colonna IMAGE è l’hash dell’immagine di ubuntu, tant’è che se eseguiamo docker image ls, vedremo che l’IMAGE ID di ubuntu è lo stesso, ovvero 1d622ef86b13.

docker image ls | grep ubuntu

Ottenendo questo output:

ubuntu                                  latest              1d622ef86b13        4 weeks ago         73.9MB

In questo caso ho usato un grep per filtrare solo le righe dell’output che contengono la stringa ubuntu, per evitare rumore nell’output.

Per ora non mi spingerei oltre. Credo che in questa fase sia opportuno tralasciare la colonna ‘CREATED BY’, diventerà tutto più chiaro quando affronteremo il Dockerfile.

Ogni layer modifica i precedenti, ma il primo cosa modifica?

Abbiamo visto che un’immagine viene costruita a pezzi, mediante dei layer che provocano variazioni successive e gestite mediante Union File System.
Ma qual è il layer da cui tutto inizia?
Il layer in questione si chiama “scratch”. In inglese ‘from scratch’ significa da zero.
Infatti, se proviamo ad eseguire:

docker image pull scratch

vedremo che il demone restituisce un errore indicandoci che il nome ‘scratch’ è riservato.

Error response from daemon: 'scratch' is a reserved name

A dire il vero un immagine può partire anche da un’altra immagine, che può partire da un’altra immagine e così via. Ma la prima di esse partirà sempre “from-scratch”.

Ogni modifica all’immagine a partire da scratch genera un nuovo layer.
Quando parleremo di Dockerfile, costruiremo i layer di un’immagine e capiremo nel dettaglio come lavorare al meglio con essi.

Ogni layer è identificato da un hash (SHA256) univoco. Questo hash è la chiave utilizzata dalle immagini per verificare la presenza o meno dei layer di cui necessitano nella cache locale dell’host.

Questo meccanismo di cache dei layer, snellisce notevolmente le operazioni di upload e download dai registry perché coinvolgono solo i layer nuovi e non ripetono tali operazioni sui layer già presenti.
Questo meccanismo resta valido sia quando carichiamo una nuova versione di un’immagine nell’hub, sia quando la scarichiamo.

—
Prosegui su: Copy-on-Write (CoW)

Immagine: Viaggio foto creata da freepik – it.freepik.com

L'articolo Analizzare la struttura di un’immagine proviene da Docker Tutorial.

Se più container condividono pezzi della stessa immagine, o addirittura tutta la stessa immagine, le modifiche operate da un container interferiscono con gli altri?

La risposta è no. Almeno non per i file relativi l’immagine.

Quando viene eseguito un container, viene creato per esso un nuovo layer accessibile in lettura e scrittura. Il container potrà accedere solo in lettura ai file dell’immagine evitando ogni tipo di conflitto.

Spesso però i container avranno bisogno di modificare alcuni file dell’immagine. Come possono farlo se ci accedono in sola lettura?

In realtà un container può sempre modificare i file dell’immagine da cui viene istanziato, ma non lo fa direttamente. Le modifiche riguardanti la sua istanza vengono persistite nel layer in lettura e scrittura creato nel momento in cui viene istanziato. 

Il modo il cui lo fa è Detto Copy-on-Write (CoW) ovvero copia quando devi scrivere.

Fino alla prima modifica di un file dell’immagine da parte del container, gli accessi avvenivano in sola lettura.

Per risparmiare risorse, in presenza di queste situazioni, Docker non copia i file nel layer in lettura e scrittura ma il container leggerà tali file direttamente dall’immagine.

Alla prima modifica di un file operata dal container, la nuova versione di tale file diverge rispetto a quella dell’immagine.

Solo a questo punto il file viene copiato dall’immagine al layer abilitato al read/write.

—
Prosegui su: Docker CLI – prima e dopo

Immagine: Viaggio foto creata da cookie_studio – it.freepik.com

L'articolo Copy-on-Write (CoW) proviene da Docker Tutorial.

Avrei potuto prendere un comando già visto ma dato che ci siamo, impariamo qualcosa di nuovo. Prendiamo quindi:

docker image inspect

Questo comando restituisce un oggetto in formato json con i metadati dell’immagine specificata per parametro.

Eseguendo:

docker image inspect alpine

Ottenendo il seguente risultato:

[
    {
        "Id": "sha256:f70734b6a266dcb5f44c383274821207885b549b75c8e119404917a61335981a",
        "RepoTags": [
            "alpine:latest"
        ],
        "RepoDigests": [
            "alpine@sha256:9a839e63dad54c3a6d1834e29692c8492d93f90c59c978c1ed79109ea4fb9a54"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2020-04-24T01:05:03.92860976Z",
        "Container": "d3de5454dd4538da6ccb451b8fe1574b2efc482f958b04e6d109f123198d3d30",
        "ContainerConfig": {
            "Hostname": "d3de5454dd45",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"/bin/sh\"]"
            ],
            "ArgsEscaped": true,
            "Image": "sha256:fce4411719cb54972247bbe799cf1dd74ecffda05bad4909df5224000dfd070e",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
        "DockerVersion": "18.09.7",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh"
            ],
            "ArgsEscaped": true,
            "Image": "sha256:fce4411719cb54972247bbe799cf1dd74ecffda05bad4909df5224000dfd070e",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 5612304,
        "VirtualSize": 5612304,
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/bb0a38faf8a51dd52fed8883ddefe73effab9736c4f67eea46a78a3ad4de4bc2/merged",
                "UpperDir": "/var/lib/docker/overlay2/bb0a38faf8a51dd52fed8883ddefe73effab9736c4f67eea46a78a3ad4de4bc2/diff",
                "WorkDir": "/var/lib/docker/overlay2/bb0a38faf8a51dd52fed8883ddefe73effab9736c4f67eea46a78a3ad4de4bc2/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

vedremo diversi hash, tag architettura di riferimento, versione di Docker e molte altre informazioni su che a mio avviso ha senso approfondire, soprattutto in questa fase. 

La cosa strana è che eseguendo:

docker inspect alpine

otteniamo esattamente lo stesso risultato.

Perché ci sono due modi diversi di eseguire lo stesso comando?

Questo avviene perché la CLI di Docker ha cambiato la sua notazione ed ora utilizza dei sotto-comandi per evitare di avere dei conflitti sui nomi e per rendere il tutto più chiaro.

Docker Inc. vorrebbe abbandonare il supporto alla notazione precedente, per capirci, quella senza i sotto-comandi. Ad oggi sono ancora operativi e siccome questo potrebbe rompere molti script su cui Docker non ha controllo è possibile che possa non avvenire nell’immediato (o forse non avvenire mai). Consiglio personale, abituiamoci ad usare la nuova notazione così ci proteggiamo da eventuali rimozioni di comandi legacy e evitiamo di incorrere in spiacevoli inconvenienti.

Ma quali sono questi sottocomandi?

Eseguiamo il comando “docker”, senza alcun parametro.

Usage:	docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/Users/fabioros/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default
                           context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/Users/fabioros/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/Users/fabioros/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/Users/fabioros/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Management Commands:
  builder     Manage builds
  checkpoint  Manage checkpoints
  config      Manage Docker configs
  container   Manage containers
  context     Manage contexts
  image       Manage images
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  build       Build an image from a Dockerfile
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  deploy      Deploy a new stack or update an existing stack
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  exec        Run a command in a running container
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  images      List images
  import      Import the contents from a tarball to create a filesystem image
  info        Display system-wide information
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  login       Log in to a Docker registry
  logout      Log out from a Docker registry
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image or a repository from a registry
  push        Push an image or a repository to a registry
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  run         Run a command in a new container
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  search      Search the Docker Hub for images
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  version     Show the Docker version information
  wait        Block until one or more containers stop, then print their exit codes

Run 'docker COMMAND --help' for more information on a command.

Quello che ci verrà restituito è un semplice cheatsheet. Non è completo, per quello è sempre possibile utilizzare l’help come indicato nell’ultima riga (Run ‘docker COMMAND –help’ for more information on a command.).
Tuttavia, questo comando ci fornisce tutto ciò di cui abbiamo bisogno in questo momento.

Tra i comandi (Commands) è possibile osservare la voce ‘inspect’.

  inspect     Return low-level information on Docker objects

La descrizione di questo comando fa riferimento ad oggetti Docker generici e non alle immagini. Probabilmente è sovraccaricato. Sappiamo già che è presente all’interno del sotto-comando image, verifichiamo se è definito anche all’interno del sotto-comando container.
Eseguiamo quindi:

docker container

È possibile notare che il comando inspect è definito anche qui e si riferisce ai container.

Utilizzare i sotto-comandi aiuta molto a mettere ordine sia agli script, sia alle idee.

—
Prosegui su: Nomi delle immagini

Immagine: Barca rossa nel lago vicino alla montagna – it.freepik.com

L'articolo Docker CLI – prima e dopo proviene da Docker Tutorial.

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.

1. ufficiali: ovvero Docker Hub
2. on-premise: dove viene installato sulle proprie macchine
3. 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

Immagine: Annata foto creata da photoangel – it.freepik.com

L'articolo Nomi delle immagini proviene da Docker Tutorial.

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

L'articolo CLI delle immagini proviene da Docker Tutorial.

Uno dei casi d’uso più comuni quando si parla di Docker è adattare un software già esistente all’architettura a container. Questo procedimento si dice “containerizing” o “dockerizing” an application e per farlo vanno costruite delle immagini ad-hoc.

Creare immagini

Per iniziare a creare un immagine abbiamo bisogno di creare un file particolare. Questo file si chiama “Dockerfile” e va salvato così, senza estensione.

Pensiamo al Dockerfile come un manuale di assemblaggio per le immagini.

Il suo scopo però non si esaurisce qui. Oltre a specificare come deve essere costruita un’immagine, descrive anche la modalità (di default) con la quale verrà avviato un container a partire da essa.

Le istruzioni dichiarate nel Dockerfile verranno eseguite in ordine e, in buona approssimazione, per ognuna di esse verrà generato un layer.

Durante il processo di build, verrà eseguita una ricerca del Dockerfile a partire dalla root del progetto (che solitamente è la cartella da cui si lancia il comando di build). È comunque possibile specificare un percorso diverso utilizzando il flag -f nel comando di build.

Non abbiamo ancora affrontato una build, ma ne parleremo tra poco. Per ora poniamo l’attenzione sul Dockerfile.

Nel prossimo post affronteremo le istruzioni che compongono il Dockerfile.

Mi sono posto come obiettivo quello di affrontare tutte le istruzioni più rilevanti, tuttavia lascio un link alla documentazione(https://docs.docker.com/engine/reference/builder/) per qualunque approfondimento o necessità diversa da quanto trattato.

Piccola nota a margine per chi conosce i design pattern. Osserviamo il link. Non leggiamo reference/Dockerfile ma reference/builder.
Vi ricorda niente?

—
Prosegui su: Dockerfile

Immagine: Acqua foto creata da freepik – it.freepik.com

L'articolo Dockerizing / Containerizing proviene da Docker Tutorial.

Per la comprensione di alcuni concetti ricorrenti, utilizzeremo l’immagine ufficiale di mysql presente nel docker hub a questo indirizzo: https://hub.docker.com/_/mysql.
Ho scelto questo esempio perché è abbastanza completo e mi da modo di mostrare un implicazione reale di quasi tutti i costrutti principali.

Aprendo la pagina noteremo ad un certo punto una sezione con la dicitura “Supported tags and respective Dockerfile links”.

Ogni riga contiene immagini che condividono lo stesso Dockerfile.

Facendo click su uno qualunque dei tag, si aprirà un link ad un Dockerfile che è esattamente quello utilizzato per creare l’immagine con tutti i tag presenti in quella riga.

Personalmente, ogni volta che ho a che fare con un’immagine che non conosco, vado a leggere il Dockerfile – se disponibile – per avere più informazioni possibili su come è stata costruita e su come è preferibile utilizzarla. Mi sento di consigliare questo approccio perché a mio avviso è molto utile.

Sintassi

È giunto il momento di una carrellata nozionistica, ma ahimè indispensabile.

FROM

Ogni Dockerfile “deve iniziare” con l’istruzione FROM.

Questa istruzione specifica l’immagine base da cui partire per costruirne una di nuova.

FROM alpine:latest

Questa istruzione sta dicendo a Docker di costruire l’immagine a partire dall’immagine del repository alpine contrassegnato dal tag latest

Piccola nota, ma di fondamentale importanza. Le immagini vengono tenute il più leggere possibile, di conseguenza è possibile che alcuni pacchetti che siamo soliti utilizzare nei sistemi corrispondenti all’immagine di base potrebbero non essere presenti di default e necessitare di installazione.

Ad esempio, l’immagine di base di Ubuntu non ha il comando ping abilitato di default. Per averne prova basta eseguire:

docker container run --rm ubuntu ping dockertutorial.it

l’output che otteniamo è:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"ping\": executable file not found in $PATH": unknown.

Il demone ci dice che non sa come eseguire “ping” e fallisce.

Eseguendo invece lo stesso container, ma con il comando ls

docker container run --rm ubuntu ls

otteniamo l’elenco dei file e cartelle.

bin
boot
dev
etc
home
lib
lib32
lib64
libx32
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

Questo accade perché il listing è abilitato di default.
Finché parliamo di ping, può ance sembrare una cosa di scarso interesse, ma potrebbe capitare per servizi molto più di largo uso quali i package manager. In questo caso l’idea è di partire da immagini che già li supportano nativamente ad esempio Ubuntu per apt, Debian per yum o Alpine per pkg.

ARG

In casi particolari, può aver senso specificare uno o più parametri da passare come argomento al FROM.

In ambiente Docker questi si chiamano argomenti e vengono definiti con la keyword ARG.

Solo la definizione di questi parametri può precedere la definizione dell’immagine di partenza, comparendo quindi prima della keyword FROM.

Modifichiamo l’esempio visto in precedenza e incapsuliamo il tag latest in un argomento.

ARG VERSIONE_IMG=latest
FROM alpine:${VERSIONE_IMG}

Andiamo per ordine.
In questo caso viene creato un parametro visibile solo al di fuori della build che riporta il tag dell’immagine di alpine da utilizzare come immagine di partenza.

La valutazione e restituzione dell’argomento viene eseguita mediante la sintassi bash ${} e verrà utilizzata nel comando che verrà invocato.

Come abbiamo detto in precedenza, l’istruzione FROM è quella che determina l’inizio della build. Quindi tutti gli argomenti definiti con ARG non sono visibili dopo il tag FROM. Almeno non di default.

Si possono rendere visibili gli argomenti anche all’interno del processo di costruzione dell’immagine dichiarandoli anche dopo il tag FROM, senza assegnarne alcun valore.

ARG VERSIONE_IMG=latest
FROM alpine:${VERSIONE_IMG}
ARG VERSIONE_IMG
RUN echo $VERSION > file.txt

Subito dopo la dichiarazione dell’argomento, vediamo il comando RUN.

In questo caso verrà eseguito un echo che produrrà in output la stringa “latest”. L’output verrà poi dirottato in un nuovo file che ho chiamato “file.txt”.

RUN

Il comando RUN ha lo scopo di eseguire una o più istruzioni definite in formato bash in un nuovo layer. Di fatto aggiungendo un blocco immutabile all’immagine.

Durante la build, l’istruzione di build successiva a quella del RUN appena definito, sarà costruita a partire dall’immagine ottenuta dall’applicazione di tutti i layer precedenti. Quello appena definito sarà l’ultimo in ordine di comparizione.

Un po’ come una pila di piatti, noi prendiamo tutta la pila ma ogni piatto viene posto sopra la tutti quelli impilati precedentemente.

Questo è un concetto chiave del Dockerfile e di Docker in generale. La build avviene per composizione di layer successivi definiti con buona approssimazione da ogni riga del dockerfile a partire da FROM.

Due modalità distinte per invocare il RUN

Quando definiamo i comandi RUN, possiamo scegliere tra due tipologie di sintassi:

1. Modalità bash
2. Modalità exec ( detta anche json )

La modalità bash esegue il comando in una shell.
Diretta conseguenza di ciò è che viene prefissa implicitamente la dichiarazione della shell. Nello specifico, in ambiente unix il modulo builder del docker engine ci anteporrà “/bin/sh -c”.

RUN echo 'testo di prova'

Ricordiamoci di questa semplificazione perché non viene proprio a gratis, ma porta con se delle conseguenze.

L’altra sintassi è quella exec. Questa modalità non invoca la shell direttamente ma fa il parse di un array json e compone la stringa dell’istruzione da eseguire fondendo i valori recuperati da tale array. 

 Tutte le stringhe che compongono l’istruzione devono essere racchiuse da doppi apici e non da apici singoli.

RUN ["sh", "-c", "echo hello"]
RUN ["/bin/bash", "-c", "echo hello"]
RUN ["file_eseguibile.sh"]
RUN ["sh", "-c", "echo $ARG_ESEMPIO"]

Inoltre, non essendo direttamente un comando su shell, la sostituzione delle stringhe con gli argomenti (quelli preceduti dal dollaro che abbiamo visto in precedenza) non funziona.

Se dovessimo trovarci nella situazione in cui necessitiamo che vengano interpretate alcune variabili,  dovremmo predisporre l’array impostando le prime stringhe con la definizione di una shell, ad esempio RUN [“sh”, “-c”, “echo $ARG_ESEMPIO”]. Questo è un mezzo trucchetto perché la $ARG_ESEMPIO non verrebbe comunque interpretata in modalità exec, però, essendo preceduta da una shell la valutazione e sostituzione delle stringhe avviene in un secondo momento, al di fuori della valutazione dell’array json.

Essendo json, può essere necessario fare l’escape dei caratteri speciali, il carattere preposto per questo scopo è, come di consueto, il backslash (\). Lo scopo è quello di comunicare all’interprete di trattare il carattere successivo al backslash come carattere di contenuto e non come un carattere che potrebbe avere una valenza diversa(ad esempio i doppi apici che chiuderebbero la stringa”).

Errori noti

Ricordate quando parlavamo di layer delle immagini? Avevamo visto che un layer che non viene modificato dalla build precedente, non viene ricostruito nuovamente durante la build di un’immagine perché già in cache.

Ma cosa succede se il layer è generato, ad esempio, da un comando che fa il pull da un dato branch di un repository? Oppure se verifica l’ora corrente e se maggiore di un certo valore cambia il comportamento?

Attenzione che questo aspetto provoca spesso errori. Le informazioni cambiano al di fuori del Dockerfile, quindi verrebbe eseguito solo la prima volta, perché l’istruzione che lo genera non ha subito modifiche e di conseguenza verrebbe semplicemente recuperato dalla cache.

Quando vi sono di questi problemi, è il caso di eseguire la build utilizzando il flag –no-cache che ha lo scopo di invalidare la cache relativa alle sole istruzioni RUN.

Dato che siamo in tema di errori noti, ne approfitto per darvi una dritta sull’invocazione dei comandi bash. Può capitare a volte di vedere delle invocazioni di più comandi separati dai caratteri “&&” oppure dal carattere “;“. La differenza sta nel fatto che nel primo caso, ogni comando viene eseguito solo se tutti i precedenti sono andati a buon fine, mentre nel secondo caso, verranno eseguite sempre tutte le istruzioni. Quando scriviamo dei Dockerfile oppure anche dei file bash generici, dobbiamo sempre pensare bene al flusso delle istruzioni multiple in modo da evitare risultati diversi da quelli che ci aspettiamo.

Fatte queste considerazioni, torniamo per un attimo al Dockerfile di mysql.

RUN set -eux; \
savedAptMark="$(apt-mark showmanual)"; \
apt-get update; \
apt-get install -y --no-install-recommends ca-certificates wget; \
rm -rf /var/lib/apt/lists/*; \
dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')"; \
wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch"; \
wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch.asc"; \
export GNUPGHOME="$(mktemp -d)"; \
gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4; \
gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu; \
gpgconf --kill all; \
rm -rf "$GNUPGHOME" /usr/local/bin/gosu.asc; \
apt-mark auto '.*' > /dev/null; \
[ -z "$savedAptMark" ] || apt-mark manual $savedAptMark > /dev/null; \
apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false; \
chmod +x /usr/local/bin/gosu; \
gosu --version; \
gosu nobody true

Il comando RUN si estende per più righe utilizzando l’apposito carattere per mandare accapo: ‘\’; Colgo la palla al balzo per evidenziare che se l’istruzione seguente è un comando, deve essere preceduta dall’indicazione di concatenazione affinché venga concatenata correttamente (in questo caso viene usato il carattere ‘;’).

Quest’ultimo punto può sembrare solo un aspetto stilistico, ma in realtà non lo è per niente. Ricordate che poco fa vi avevo detto che ogni riga del Dockerfile origina un nuovo layer? Utilizzare questa sintassi permette di raggruppare più istruzioni in un solo layer ottimizzando il processo.

CMD

Passiamo ora all’ultima istruzione necessaria per permetterci di fare la nostra prima build, ovvero CMD.

CMD è l’istruzione di default per l’esecuzione di un container. Fondamentalmente significa che al run di un container a partire dall’immagine che stiamo definendo, verrà invocata questa istruzione.

Il comando CMD, viene eseguito ogni volta che viene avviato un nuovo container oppure quando viene avviato con il comando docker container start dopo aver fermato il relativo container con docker container stop.

E’ possibile sovrascrivere questa istruzione esplicitandone una di diversa in coda al comando docker container run come abbiamo visto poche righe sopra quando abbiamo testato ping e ls sull’immagine di Ubuntu.

Ogni Dockerfile ben formato dovrebbe avere al massimo una sola occorrenza di CMD. Ad ogni modo, in presenza di invocazioni multiple, verrà utilizzata solo l’ultima di esse.

Anche in questo caso è possibile utilizzare sia la modalità bash sia quella exec.

Può sembrare che CMD e RUN siano equivalenti, ma in realtà non è così.

Sebbene siano simili nella forma non lo sono nella sostanza.

RUN  agisce in fase di build apportando modifiche all’immagine, mentre il comando CMD specifica cosa fare quando viene avviato un container a partire da un’immagine che a tutti gli effetti è già sigillata.

—
Prosegui su: Creare un’immagine

Immagine:  Acqua foto creata da freepik – it.freepik.com

L'articolo Dockerfile: FROM, RUN, ARG e CMD proviene da Docker Tutorial.