In questo articolo affronteremo i seguenti temi:
Abbiamo visto come scrivere un Dockerfile per la creazione di un’immagine custom. Ovviamente una volta creato il Dockerfile non abbiamo una vera e propria immagine da utilizzare per deployare un container.
In questo articolo vedremo come effettivamente fare il build dell’immagine usando il Dockerfile e salvarlo localmente in modo da poterlo usare per creare container.
Fare il build dell’immagine usando un Dockerfile
L’ambiente
Una volta creato il nostro Dockerfile è conveniente spostarlo in una nuova directory assieme a tutti i file che vogliamo passare all’istruzione COPY. Fatto ciò, apriamo il terminale e spostiamoci all’interno della directory creata.
1. cd /home/desotech/DOCKER
2. ls -l
L’output che otterremo ovviamente dipende da ciò che ci abbiamo messo dentro. Il nostro Dockerfile si basava su ubuntu:22.04, installava NGINX e copiava i file locali all’interno di alcune directory di configurazione di NGINX e caricava la pagina web
Una volta fatto ciò possiamo passare ovviamente alla fase di build. Per procedere a questa fase dobbiamo essere sicuri di avere Docker correttamente installato e per verificarlo possiamo semplicemente lanciare il comando.
Se avremo dell’output non otterremo errori, quindi potremo procedere allo step successivo.
1. docker info
Il comando docker build
Per il build delle immagini il comando da usare, come è facile intuire, è proprio docker build. Questo comando crea le immagini a partire da un Dockerfile e da un “context”. Il build context è l’insieme di file che stiamo usando per buildare l’immagine. Ovviamente nel nostro caso è l’intero contenuto della cartella in cui abbiamo messo Dockerfile e i file usati in fase di copia.
Il comando usa una sintassi ben definita:
1. docker build [OPTIONS] PATH | URL | -
Come è possibile vedere abbiamo la possibilità di utilizzare delle opzioni ed in più dobbiamo necessariamente specificare uno di questi tre conesti
- PATH come è possibile intuire questo è il percorso vero al Dockerfile sulla nostra macchina locale, ovviamente può essere assoluto o relativo.
- URL è effettivamente l’URL di una sorgente ben specifica, come ad esempio una repo su Git.
- Il trattino – invece dice a docker di usare come sorgente il nostro STDIN
I contesti più usati sono comunque PATH ed URL.
Attualmente la nostra situazione è la seguente:
La cartella DOCKER è il nostro build context e al suo interno abbiamo tutto l’occorrente per eseguire il build. Entriamo nella cartella ed eseguiamo il build:
1. cd DOCKER
2. docker build .
In questo caso il nostro build context è la cartella corrente e quindi ci basterà usare semplicemente il punto ( . ). Analogamente, avremmo potuto usare il percorso assoluto “/home/desotech/DOCKER.
Una volta lanciato il comando, l’output che otterremo ci indicherà l’avanzamento del processo di build dell’immagine. Osserviamo alcune righe in particolare:
- transfering dockerfile è la fase in cui docker passa il Dockerfile al daemon che si occupa di buildare concretamente le immagini
- [x/5] INSTRUCTION sono gli step che indica concretamente che istruzione del Dockerfile sta venendo eseguita
- writing image è l’ultima riga e indica che l’immagine è stata buildata correttamente
Ora ovviamente saremo curiosi di vedere l’immagine che abbiamo creato, listiamo le immagini che abbiamo.
Come possiamo vedere l’immagine più recente è senza nome. Il motivo sta nel non aver specificato alcun -t nome:tag come nelle options. Fortunatamente rilanciando il comando appropriato non saremo costretti ad aspettare di nuovo l’intero tempo di build. Il motivo è l’utilizzo da parte di docker build della cache.
1. docker build -t nginx:ubuntu .
Le istruzioni e i file utilizzati nella creazione dell’immagine vengono memorizzati in modo tale che, se si dovesse avere la necessità di buildare da capo l’immagine come nel nostro caso, Docker non debba ricrearli nuovamente ma possa utilizzare quelli già memorizzati in precedenza.
Come possiamo vedere abbiamo creato correttamente l’immagine chiamandola nginx con tag ubuntu. L’immagine è pronta ad essere utilizzata per runnare un container.
Il comando docker save
Ora che abbiamo creato l’immagine potremmo essere, ad esempio interessati a distribuirla a qualche collega, o semplicemente utilizzarla su una macchina diversa. Docker ci consente di esportare l’immagine in un archivio .tar con un semplice comando.
Il comando usato è docker save, che ha la seguente sintassi:
1. docker save [OPTIONS] IMAGE
L’unica opzione accettata è il flag -o questo flag fa si che si scriva un file, ad esempio un archivio tar, questo generalmente è l’approccio considerato più corretto. Se volessi, tuttavia, creare un archivio .tar.gz o salvare l’archivio su un dispositivo esterno posso omettere il flag e utilizzare gli operatori bash per reindirizzare l’output.
Salviamo l’immagine in un archivio .tar usando il seguente comando:
1. docker save -o nginx-ubuntu.tar nginx:ubuntu
Alla fine dell’operazione avremo un file in più nella nostra working directory.
La contro prova
Abbiamo buildato l’immagine, l’abbiamo salvata ed ora la domanda fatidica è: “siamo sicuri funzioni?”
Possiamo semplicemente testare l’archivio appena creato e l’immagine che esso contiene. Per farlo eliminiamo prima l’immagine appena costruita, per farlo basta semplicemente usare seguente comando:
1. docker image rm -f nginx:ubuntu
In seguito, basterà importare l’immagine usando il comando docker load con il flag -i per specificare il file da passare come input:
1. docker load -i nginx-ubuntu.tar
Come è possibile vedere abbiamo eliminato l’immagine appena buildata ed abbiamo usato l’archivio appena creato per importarla come immagine e deployare un container funzionante di nginx.
Nel prossimo e conclusivo articolo dedicato al build di un’immagine NGINX con Dockerfile, vedremo come effettivamente fare il push dell’immagine all’interno di un registry privato.
Condividi l’articolo!!
Scopri i nostri corsi!
Antonello Ciaccia
DevOps Instructor & Engineer
Amo la complessita e l’atto di semplificarla attraverso l’informatica. Conosco ed amo gli strumenti di automazione e di orchestrazione come Ansible e Kubernetes. Provo un crescente interesse nei confronti di argomenti quali AI, ML e Cloud!
