Building delle immagini

Una volta visto il Dockerfile e imparate le istruzioni più importanti, cerchiamo di capire come creare da qui la nostra immagine. Il nostro fine ultimo, infatti, sarà quello di avere immagini su misura per le nostre esigenze, da cui tirar su i relativi container già pronti per l'uso.

Il comando fondamentale che vedremo lungo il corso di questa lezione è il comando docker build. Questo, partendo dal Dockerfile, genererà l'immagine che poi utilizzeremo. La sintassi di questo comando è abbastanza semplice:

docker build [OPT ...] <build context>

Il parametro <build context> è obbligatorio e fornisce all'engine di build il relativo contesto. Ad esempio, l'istruzione COPY, utilizzabile all'interno del Dockerfile, ha come sorgente un path obbligatoriamente relativo, e per risolvere tale path l'engine ha bisogno di conoscerne il contesto: è proprio qui che entra in gioco il <build context>. Tale informazione è esprimibile come un normale percorso di filesystem Unix, ove, il più delle volte viene usato il carattere punto (.), in modo da specificare la directory corrente come contesto di build.

Il comando, inoltre, accetta una serie di parametri opzionali; quello che useremo più spesso sarà generalmente il parametro -t, anche espresso come --tag, utile quando si vuole assegnare alla nostra immagine un tag.

Un altro parametro interessante è -f (o --file), per specificare all'engine dove recuperare il Dockerfile, nel caso in cui questo non sia presente nel <build context>. Per non aumentare la lunghezza del comando, in genere, si tende ad avere il Dockerfile all'interno del build context, anche se in alcuni scenari si preferisce utilizzare un Dockerfile esterno per poi specificarne il path con -f.

Il <build context> è un concetto abbastanza ostico. Il miglior modo per padroneggiarlo a pieno è sperimentare e capire le varie combinazioni che ne possono derivare. Di seguito troviamo un esempio pratico da cui partire per le prime prove pratiche.

Esempio - Hosting di pagine statiche

Nella lezione 5 abbiamo avviato un container con il demone httpd di Apache, aperto le porte necessarie e verificato tramite una chiamata nel browser se questo rispondeva o meno.
Il tutto è stato realizzato da linea di comando ed ha funzionato senza molti problemi, salvo uno: serviva a poco o nulla!
Più utile sarebbe stato se avessimo avuto una nostra immagine del demone httpd, con all'interno le pagine statiche già pronte da serivere.

Supponendo, quindi di avere tali pagine sul nostro computer, precisamente al path C:\Users\htmlit\www\src, ci basterà raggiungere il path C:\Users\htmlit\www e creare all'interno un nuovo Dockerfile come questo:

FROM httpd:2.4
LABEL Author="Mariano Calandra"
EXPOSE 80
COPY ./src/ /usr/local/apache2/htdocs/

Così facendo stiamo definendo un'immagine a partire dall'immagine di Apache httpd:2.4. Il container risultante esporrà la porta 80 in modo da poter mostrare all'esterno i file che abbiamo copiato nella directory Apache grazie all'istruzione COPY.
Per effettuare ora il build dell'immagine, ci sposteremo dove è posizionato il Dockerfile, ovvero in C:\Users\htmlit\www, e digiteremo il comando:

docker build -t esempio_1 .

In alternativa, se volessimo assegnare anche una versione all'immagine:

docker build -t esempio_1:v1 .

Attenzione al punto! Spesso non lo si nota, ma una parte fondamentale del comando di build è proprio quel . che rappresenta il contesto di build. Questo è un concetto fondamentale in quanto, come già anticipato, darà un senso ai path relativi in cui ci imbatteremo lungo il processo di building.

Riguardando il Dockerfile, infatti, si nota come l'istruzione COPY abbia un path relativo ./src/.
Il . che abbiamo fornito nel comando build esprime la directory corrente, e siccome siamo in C:\Users\htmlit\www, il path relativo ./src/ corrisponderà proprio al path assoluto C:\Users\htmlit\www\src. Più semplice di quanto sembrasse!

Una volta che l'istruzione docker build ha avuto luogo, la nuova immagine si troverà nel computer locale insieme a tutte le altre ufficiali, e non e sarà possibile vederla eseguendo docker image ls come di consueto.

A questo punto non ci resta altro che eseguirla. Come al solito, abbiamo più di un modo per arrivare allo stesso risultato. Siccome il Dockerfile espone la porta utilizzata da Apache (ovvero la classica 80), basterà utilizzare il parametro -P nel comando docker run:

docker run -d --name esempio_1 -P esempio_1

Se invece volessimo definire noi una certa porta, useremmo il parametro -p:

docker run -d --name esempio_1 -p 8088:80 esempio_1

Non ci resta altro che aprire il nostro browser e verificare che effettivamente le pagine statiche siano visibili.
Se stiamo utilizzando Docker Toolbox, allora il nostro container è ospitato all'interno della macchina virtuale, per cui servirà conoscerne l'IP. Nella maggior parte dei casi l'indirizzo è 192.168.99.100, per cui http://192.168.99.100:8088/miofilestatico.html dovrebbe funzionare, ma se non siete fortunati potrete usare il comando docker-machine ip per venirne a capo.