ENTRYPOINT è una delle opzioni di configurazione più importanti di Docker. Si trova nel Dockerfile e permette di definire il comportamento predefinito del container. Questa capacità rende ENTRYPOINT estremamente utile per automatizzare il comportamento dei container in fase di esecuzione.

Questo articolo esplora a fondo l’uso di ENTRYPOINT in Docker: come funziona, perché è essenziale e come configurarlo correttamente.

Cos’è l’ENTRYPOINT di Docker

ENTRYPOINT è il punto di partenza del processo di runtime di un container Docker. Quando creaimo un’immagine Docker e la istanziamo come container, il comando ENTRYPOINT viene eseguito per impostazione predefinita.

ENTRYPOINT permette di impostare lo scopo principale del container, come l’esecuzione di un server web, di un database o di un’applicazione. Inoltre, permette di passare degli argomenti in fase di esecuzione per personalizzare il comportamento del container.

Sintassi e uso di ENTRYPOINT

Le due opzioni di sintassi per definire ENTRYPOINT in un Dockerfile sono la forma shell e la forma exec. Entrambi gli approcci prevedono l’inserimento di una riga nel Dockerfile. Poiché la configurazione di ENTRYPOINT non influisce direttamente sul processo di compilazione, possiamo inserirla in qualsiasi punto del file. Tuttavia, la maggior parte dei programmatori tende a inserire il comando ENTRYPOINT verso la fine.

Sintassi della forma shell

Quando ENTRYPOINT viene eseguito utilizzando la forma shell, richiama una shell di comando per l’elaborazione. Questo metodo include le sostituzioni delle variabili d’ambiente ma blocca la possibilità di aggiungere argomenti in forma exec:

ENTRYPOINT command param1 param2

In questo caso, command è il comando principale che viene eseguito all’avvio del container. param1 e param2 sono gli argomenti del comando.

Sintassi del modulo Exec

Il modulo Exec non richiama una shell di comando. Al contrario, esegue direttamente il comando e i parametri specificati. Questo metodo consente di aggiungere argomenti tramite CMD o la riga di comando del runtime:

ENTRYPOINT ["executable", "param1", "param2"]

In questo caso, executable è il comando principale e param1 e param2 sono argomenti dell’eseguibile.

ENTRYPOINT in azione

Assembliamo un semplice comando ENTRYPOINT per un Dockerfile per vedere come funziona. Non possiamo testarlo senza avviare il nostro container perché le sue istruzioni vengono elaborate in fase di esecuzione, non in fase di compilazione.

Ecco un esempio che utilizza il modulo exec:

ENTRYPOINT ["python", "app.py"]

Quando questo container si avvia, lancia un interprete Python ed esegue lo script app.py come comportamento predefinito del container.

Per ripetere questo esempio con il modulo shell, dovremo apportare una piccola modifica:

ENTRYPOINT python app.py

Questo esempio avvia l’interprete Python da un comando di shell invece di eseguirlo direttamente.

ENTRYPOINT Con CMD

CMD è un’istruzione di Dockerfile che fornisce gli argomenti predefiniti per un container in esecuzione. Questi possono assumere la forma di un comando eseguibile o servire come parametri aggiuntivi per l’istruzione ENTRYPOINT. Quando si avvia un container, è possibile ignorare questi parametri fornendo argomenti al comando docker run.

Come ENTRYPOINT, possiamo scrivere CMD sia in forma exec che in forma shell. La differenza principale è che CMD imposta dei comandi o dei parametri predefiniti che possiamo modificare dalla riga di comando. Al contrario, ENTRYPOINT configura i contenitori come eseguibili, il che significa che non possiamo modificare il comando dalla riga di comando.

Possiao usare CMD per estendere le funzionalità di ENTRYPOINT e dare all’immagine una maggiore flessibilità. La combinazione di questi due metodi permette di personalizzare il comportamento dell’immagine, con i valori di CMD che agiscono come argomenti predefiniti per l’istruzione ENTRYPOINT. Questo metodo permette di impostare un comando predefinito tramite ENTRYPOINT e degli argomenti predefiniti tramite CMD.

A differenza dell’uso del solo ENTRYPOINT, questo approccio permette di sovrascrivere i parametri passati durante il comando docker run.

Per rendere l’esempio precedente più flessibile, possiamo includere un comando CMD:

ENTRYPOINT ["python", "app.py"]
CMD ["--help"]

In questo esempio, l’avvio di un container Docker senza fornire alcun argomento della riga di comando significa che python app.py --help verrà eseguito per impostazione predefinita. Tuttavia, fornendo degli argomenti all’avvio del container (come ad esempio docker run <image> --version), gli argomenti predefiniti di CMD verranno sostituiti e il risultato sarà python app.py --version. Questo approccio offre una maggiore flessibilità nell’esecuzione dei container.

Casi d’uso di ENTRYPOINT in Docker

L’uso più comune di ENTRYPOINT è quello di creare immagini per applicazioni o servizi specifici. Ad esempio, se creiamo un’immagine per eseguire un’applicazione Python, possiamo usare ENTRYPOINT per specificare che l’interprete Python deve essere eseguito.

Possiamo usare ENTRYPOINT anche per creare immagini Docker per le pipeline di Integrazione Continua e Distribuzione Continua (CI/CD). Possiamo usare queste immagini per incapsulare l’ambiente necessario per ogni fase e garantire la coerenza. Ad esempio, Possiamo creare un’immagine Docker con ENTRYPOINT impostato su uno script di test. Questa immagine esegue automaticamente i test ogni volta che viene eseguita per fornire un ambiente di test coerente e ripetibile.

ENTRYPOINT è utile anche per il debug delle applicazioni containerizzate. Avviando una sessione di shell con ENTRYPOINT, è possibile interagire con l’ambiente applicativo all’interno del container. Queste interazioni includono l’esecuzione di comandi, l’esplorazione di file e l’ispezione dello stato dell’applicazione. Una volta risolto il problema, possiamo ricostruire l’immagine Docker con l’appropriato ENTRYPOINT per eseguire l’applicazione.

Come sovrascrivere ENTRYPOINT

È possibile sovrascrivere l’indirizzo ENTRYPOINT di un’immagine Docker in fase di esecuzione per ottenere una maggiore flessibilità. Possiamo farlo fornendo un comando dopo il nome dell’immagine nel comando docker run.

Ad esempio, se l’immagine ha uno script Python come ENTRYPOINT, ma vogliamo aprire una shell all’interno del container, possiamo eseguire il comando:

docker run --entrypoint <image> “/bin/bash”

Questo script sovrascrive l’applicazione predefinita ENTRYPOINT e avvia una shell bash.

Allo stesso modo, per eseguire un altro script Python, possiamo fornire tale script come comando. Questa tattica dà la flessibilità di eseguire il container con parametri diversi da quelli originariamente indicati nel Dockerfile ENTRYPOINT.

Best practice per l’utilizzo di ENTRYPOINT in Docker

Poiché ENTRYPOINT è un comando fondamentale per Docker, è importante seguire queste best practice per massimizzarne l’uso.

Mantenere i container focalizzati su un’unica responsabilità

ENTRYPOINT specifica le responsabilità del container Docker. Come per i microservizi, ogni container dovrebbe concentrarsi su una singola responsabilità, servizio o parte dell’applicazione. Questo approccio aumenta la modularità e la scalabilità dell’applicazione, rendendola più facile da sviluppare, testare e mantenere.

Assicurarsi che gli script ENTRYPOINT siano eseguibili e formattati correttamente

Se gli script di ENTRYPOINT sono eseguibili e formattati correttamente, si possono evitare problemi come errori di sintassi e di autorizzazione.

Per assicurarci che gli script ENTRYPOINT siano eseguibili, possiamo utilizzare la seguente istruzione RUN chmod +x:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Questo esempio copia lo script entrypoint.sh nel container e utilizza l’istruzione RUN chmod +x per renderlo eseguibile. Poi definisce l’istruzione ENTRYPOINT per utilizzare lo script entrypoint.sh.

Possiamo anche utilizzare un linter come ShellCheck per controllare la sintassi e lo stile degli script e garantire una formattazione corretta.

Evitare la codifica rigida dei valori negli script ENTRYPOINT

L’uso di variabili d’ambiente o di argomenti della riga di comando invece di una codifica rigida può rendere gli script più flessibili. Inoltre, permette di configurare il percorso dei file dall’esterno del container.

Ad esempio, invece di inserire un percorso di file nello script ENTRYPOINT come questo:

#!/bin/bash
echo "Starting my application..."
./my-app -f /path/to/my/file.txt

Possiamo utilizzare una variabile come questa:

#!/bin/bash
echo "Starting my application..."
./my-app -f "${MY_FILE}"

L’uso delle variabili offre all’immagine una maggiore personalizzazione al volo, consentendo di fare di più senza dover riscrivere il Dockerfile.

Docker e Kinsta lavorano insieme

Kinsta offre una piattaforma potente e flessibile per la distribuzione di applicazioni web con Docker. Aiuta a creare e distribuire immagini Docker personalizzate per ottenere un maggiore controllo e flessibilità sull’ambiente di hosting.

Sia che stiate costruendo un ambiente di hosting personalizzato o che stiate scalando la vostra applicazione per gestire un traffico maggiore, Kinsta fornisce gli strumenti e il supporto necessari per avere successo.

Riepilogo

ENTRYPOINT è uno strumento essenziale per la configurazione dei container Docker. Imposta il comando predefinito che viene eseguito all’avvio di un container da un’immagine, definendone la funzione principale. Si può utilizzare ENTRYPOINT per eseguire applicazioni specifiche, per aiutare le pipeline CI/CD o per combinarlo con CMD per un comportamento più flessibile dei container.

Docker è attualmente lo strumento più popolare per gli sviluppatori, il che lo rende fondamentale per le diverse distribuzioni containerizzate. Per saperne di più su Docker, consultate gli articoli di Kinsta e date un’occhiata a Kinsta per l’hosting delle vostre applicazioni containerizzate.

Kinsta rende il flusso di lavoro di sviluppo più semplice ed efficiente. Caratteristiche come le applicazioni containerizzate su infrastruttura GCP in esecuzione su macchine C2 con 37 data center disponibili, l’integrazione premium con Cloudflare per un CDN ad alte prestazioni che serve il sito da 260+ Points of Presence (PoPs), la protezione DDoS del firewall di livello enterprise, l’Edge Caching e il monitoraggio dell’uptime (con garanzia di uptime del 99%), assicurano che le applicazioni vengano eseguite in modo veloce, sicuro e siano disponibili in modo affidabile su internet.

Marcia Ramos Kinsta

Sono l'Editorial Team Lead di Kinsta. Sono un'appassionata di open source e amo il coding. Con più di 7 anni di esperienza in scrittura tecnica e di editing per l'industria tecnologica, amo collaborare con le persone per creare contenuti chiari e concisi e migliorare i flussi di lavoro.