Creare immagini Docker

Se l’istanza rispetta i requisiti sopra elencanti, e funziona correttamente in locale (ad esempio eseguendo gnr web serve <nomeinstanza>), allora siamo pronti per la creazione di una immagine, lanciando il comando:

gnr app dockerize <nomeistanza>

Questo procederà ad avviare l’analisi dell’istanza, alla raccolta di tutti i suoi componenti e infine a generare l’immagine Docker localmente.

Suggerimento

È possibile indicare tramite il parametro --loglevel= un livello più o meno dettagliato di output, utile per verificare il comportamento e le azioni eseguite durante la procedura di build, ad esempio il comando gnr app dockerize <nomeistanza> --loglevel=debug mostrerà il massimo livello di dettaglio.

Eseguendo docker image ls vedremo l’immagine nell’elenco di quelle disponibili, che ha come nome il nome dell’istanza che è stato richiesto di «impacchettare».

Questo un esempio di creazione dell’immagine per l’istanza sandbox:

_images/dockerize.gif

Enviroment

L’immagine, per poter funzionare correttamente, ha necessità di avere, tramite un environment, le informazioni basilari per la sua configurazione. Questo può essere fornito in modi diversi a seconda dello strumento che viene utilizzato per avviare il nuovo container Docker tramite questa immagine. Si rimanda alla documentazione dello strumento in uso per maggiori informazioni a riguardo.

Le variabili di ambiente che dovranno essere fornite sono le seguenti:

  • GNR_DB_IMPLEMENTATION - Indica l’adapter database da utilizzare (es. «postgres3», «postgres», «sqlite» etc).

  • GNR_DB_HOST - Indica, se necessario, l’host su cui gira la macchina database.

  • GNR_DB_PORT - La porta TCP su cui risponde il server database.

  • GNR_DB_USER - Il nome utente di accesso al server database.

  • GNR_DB_PASSWORD - La password di accesso al server database.

  • GNR_ROOTPWD - La password iniziale di amministratore (admin) della istanza in esecuzione.

  • GNR_LOCALE - Il locale da utilizzare.

  • GNR_LOGLEVEL - Il livello di logging che l’applicativo deve configurare al suo avvio.

Esempio di avvio di immagine

Se l’immagine è stata creata, è possibile avviarla. Ecco una semplice guida passo passo su come avviarla localmente, per verifica/test/collaudo etc.

  • Creare un file di enviroment con le variabili indicate nella sezione «Environment». Ecco un esempio di contenuto:

    GNR_DB_IMPLEMENTATION=postgres3

    GNR_DB_HOST=172.42.84.132

    GNR_DB_PORT=5432

    GNR_DB_USER=postgres

    GNR_DB_PASSWORD=pulcinella

    GNR_ROOTPWD=lasolita

    GNR_LOCALE=IT_it

    GNR_LOGLEVEL=info

  • Salvare il file dove più comodo (NON SUL REPOSITORY GIT!!)

  • Avviare il container con l’immagine:

    $ docker run --env-file <il vostro file env> -p 8888:8888 nome_immagine

Se tutto ha funzionato a dovere, collegandosi all’indirizzo http://localhost:8888/ troveremo l’applicativo disponibile e pronto all’uso, accessibile con nome utente admin e password lasolita. Il database utilizzato si trova sul server che risponde all’indirizzo IP 172.42.84.132, a cui l’applicazione si collega utilizzando l’utente postgres con password pulcinella.

L’ultimo comando avvia l’immagine chiamata nome_immagine, imposta il suo enviroment tramite il file che è stato preparato, e associa la porta tcp 8888 del computer alla porta 8888 del container appena avviato.

Pubblicazione dell’immagine

In molti casi è utile pubblicare l’immagine in un archivio remoto («Docker registry»), pubblico o privato che sia, per consentire agli strumenti di dislocamentodi poter reperire in autonomia l’immagine da utilizzare.

Utilizzando l’opzione della linea di comando -p / --push è possibile, al termine della generazione della immagine, inviarla automaticamente ad un registro remoto. Tuttavia, è bene specificare che questa operazione può essere comunque eseguita manualmente al termine della generazione. Le opzioni --user e --registry sono a corredo, permettendo di personalizzare l’utente e il registro a cui inviare l’immagine. Per gli aspetti di autenticazione, si rimanda alla documentazione di Docker.

Personalizzazione della procedura di generazione

Per creare una immagine, come avvenuto nell’esempio precedente, lo strumento utilizza un file di configurazione che descrive il contenuto dell’immagine. Questo file descrive l’elenco dei repository Git da copiare all’interno dell’immagine, indicandone, oltre che l’indirizzo, anche il branch e/o il commit da utilizzare.

Il file si trova nella cartella config della istanza, chiamato build.xml. Se il file non è presente, lo strumento, analizzando la struttura della istanza, recupera in autonomia le informazioni osservando lo stato attuale del codice sulla macchina corrente, e genera per noi questo file. Il file può essere aggiunto al repository git, e modificato all’occorrenza per generare immagini diverse da quelle che rispecchiano lo stato corrente della macchina di sviluppo, ad esempio indicando dei branch diversi.

La procedura di ricerca funziona a partire dai package elencati nella istanza, andando a prelevare i rispettivi repository per aggiungerli al file di configurazione.

L’opzione a linea di comando --build-gen genererà un nuovo file build.xml rieseguendo la procedura di analisi automatica, anche se il file è già presente, andando a scriverci dentro la nuova versione di quanto rilevato dall’analisi stess.

Analisi delle immagini

Tutti i dati relativi al build (repository coinvolti, branch, commit etc) vengono salvati nei metadati dell’immagine stessa, quindi è possibile, a partire da questi, ricostruire una immagine identica.

Ad esempio, sempre per l’immagine sandbox di cui sopra:

(env) cgabriel@marvin:~$ docker inspect --format='{{json .Config.Labels}}' sandboxpg | json_pp
{
   "git:sandbox" : "@5bfd7d468ecc94a7504b296a57a145ce97a14682",
   "git:sandbox:url" : "https://github.com/genropy/sandbox/commit/5bfd7d468ecc94a7504b296a57a145ce97a14682",
   "gnr_app_dockerize_on" : "2025-04-10 12:16:19.169750+00:00",
   "org.opencontainers.image.description" : "Genropy web framework"
}

Si può quindi ricavare che l’immagine sia stata costruita dal tool gnr app dockerize, e che contiene, oltre al framework, anche il codice (istanza + package) di Sandbox, alla versione (commmit) 5bfd7d468ecc94a7504b296a57a145ce97a14682, oltre all’indirizzo del repository git che lo contiene.

Risoluzione dei problemi

Oltre al già citato parametro --loglevel per aumentare il dettagli sulle attività di generazione delle immagini, è possibile specificare anche --keep-temp, opzione che lascierà sul disco locale copia di quanto raccolto per essere inserito all’interno della immagine, per verificare eventuale contenuto.

Autore della sezione: Christopher Gabriel