Docker ENTRYPOINT spiegato: utilizzo, sintassi e best practice

Docker ENTRYPOINT è un'istruzione del Dockerfile che definisce e controlla il comando predefinito eseguito ogni volta che il tuo container si avvia. Padroneggiare ENTRYPOINT semplifica lo sviluppo di container prevedibili, riproducibili e manutenibili che si comportano come previsto. 

Questa guida vuole aiutare DevOps di livello intermedio, sviluppatori backend e software engineer a usare con sicurezza ENTRYPOINT ed evitare gli errori più comuni.

Se sei alle prime armi con Docker, dai un'occhiata alla nostra introduzione al tutorial su Docker, perché questo tutorial presuppone una certa familiarità con Docker. Per fare pratica con Docker, prova il nostro corso Introduction to Docker. 

Che cos'è Docker ENTRYPOINT?

ENTRYPOINT definisce il comando eseguito per impostazione predefinita ogni volta che il tuo container Docker viene avviato. Diversamente da CMD, l'istruzione ENTRYPOINT garantisce coerenza fornendo comandi che vengono eseguiti ogni singola volta che il container parte.

Come funziona Docker ENTRYPOINT?

ENTRYPOINT in un Dockerfile definisce il comando principale che viene sempre eseguito quando avvii un container da un'immagine. È come dire: “Indipendentemente dagli argomenti passati dall'utente quando esegue questo container, inizia sempre con questo comando.”

Approfondiamo i Dockerfile nel nostro tutorial Come containerizzare un'applicazione con Docker. 

Per esempio, in un Dockerfile:

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

Ora, quando esegui:

docker run myimageOfferto da

Eseguirà sempre:

python app.pyOfferto da

Ecco un diagramma di flusso di come funziona ENTRYPOINT:

+---------------------------+

|       Dockerfile          |

+---------------------------+

|                           |

|  ENTRYPOINT ["app"]       |

|  CMD ["--default-arg"]    |

+---------------------------+

             |

             v

+---------------------------+

|   Build Docker Image      |

+---------------------------+

             |

             v

+---------------------------+

|    Run Container          |

|   (docker run image)      |

+---------------------------+

             |

             v

+---------------------------+

| Executed Command:         |

|   app --default-arg       |

+---------------------------+

Override CMD at Runtime:

(docker run image --custom-arg)

             |

             v

+---------------------------+

| Executed Command:         |

|   app --custom-arg        |

+---------------------------+

Override ENTRYPOINT at Runtime:

(docker run --entrypoint /bin/bash image)

             |

             v

+---------------------------+

| Executed Command:         |

|   /bin/bash               |

+---------------------------+Offerto da

Fondamenti di Docker ENTRYPOINT

Capire i fondamenti aumenterà notevolmente la tua sicurezza nell'usare ENTRYPOINT in modo efficace.

Quadro concettuale

ENTRYPOINT specifica l'eseguibile o lo script che viene eseguito automaticamente all'avvio del container. È il processo principale del tuo container e guida il comportamento del container in modo prevedibile.

Sintassi di base

La sintassi del Dockerfile per ENTRYPOINT è semplice e di solito viene usata insieme a CMD per fornire argomenti o parametri predefiniti. ENTRYPOINT definisce l'eseguibile, mentre CMD specifica gli argomenti di default che ENTRYPOINT utilizza.

Comprendere concetti Docker come ENTRYPOINT è fondamentale per brillare nei colloqui in data science. Esplora le domande più comuni nel nostro articolo Le 26 principali domande e risposte su Docker per il 2025. 

Forme di sintassi di ENTRYPOINT

Docker ENTRYPOINT esiste in due forme distinte: shell ed exec. Conoscere le differenze tra queste forme ti aiuta a scegliere con criterio.

Shell form

Esempio di sintassi: 

ENTRYPOINT /usr/bin/ping -c 3 localhost

La shell form consente un'integrazione semplice delle funzionalità della shell (sostituzione di variabili, manipolazione dell'ambiente).

Tuttavia, può portare a una gestione dei segnali inefficace; viene eseguita all'interno di un processo intermedio /bin/sh invece che direttamente come PID 1, causando problemi con l'arresto e il riavvio dei container.

PID 1 è il primo processo avviato durante il boot del sistema. In Docker, il processo PID 1 gestisce tutti gli altri processi dentro il container. 

Exec form

Esempio di sintassi: 

ENTRYPOINT ["/usr/bin/ping", "-c", "3"]

La exec form garantisce l'esecuzione diretta del comando come PID 1, con una gestione dei segnali più affidabile e un controllo migliore.

Tuttavia, non ha supporto diretto per la shell né espansione automatica delle variabili d'ambiente; richiede script aggiuntivi per un comportamento simile alla shell.

ENTRYPOINT vs CMD: differenze chiave e casi d'uso

Distinguere ENTRYPOINT da CMD evita confusione e abilita un comportamento del container prevedibile.

Precedenza di esecuzione

ENTRYPOINT imposta l'eseguibile che viene sempre eseguito, mentre CMD fornisce argomenti di default. Se ENTRYPOINT e CMD sono entrambi definiti, ENTRYPOINT ha la precedenza ed esegue usando i valori di CMD come argomenti, a meno che non vengano esplicitamente sovrascritti a runtime.

Scenario d'uso

ENTRYPOINT andrebbe usato quando vuoi un'esecuzione coerente e forzata a ogni avvio, ad esempio per container a comando singolo o script wrapper attorno ad applicazioni legacy. Al contrario, CMD è adatto a specificare argomenti predefiniti, consentendo più flessibilità con override a runtime.

Il nostro articolo Le 18 principali Docker Commands per creare, eseguire e gestire i container copre i comandi essenziali di Docker, dalle basi dei container ai volumi e al networking, così potrai gestire le applicazioni con sicurezza in diversi ambienti.

Esempio pratico

Una combinazione tipica di ENTRYPOINT e CMD è illustrata da questo Dockerfile:

FROM ubuntu
ENTRYPOINT ["/usr/bin/ping", "-c", "3"]
CMD ["localhost"]Offerto da

Questo container Docker invia sempre tre ping per impostazione predefinita a localhost. Gli utenti possono sovrascrivere facilmente il target predefinito a runtime con altri host, mantenendo comunque il comportamento prevedibile di ENTRYPOINT:

docker run ping-container google.comOfferto da

Puoi approfondire il deployment di applicazioni con Docker nel nostro corso Containerization and Virtualization with Docker and Kubernetes. 

Combinare ENTRYPOINT con CMD

Combinare correttamente ENTRYPOINT con CMD offre flessibilità senza sacrificare la coerenza.

CMD come argomenti predefiniti

Impostare ENTRYPOINT definisce in modo affidabile il comando principale; CMD fornisce parametri di default per permettere override semplici senza ricostruire le immagini.

Override degli argomenti a runtime

Gli argomenti specificati durante docker run sovrascrivono solo i valori di default definiti da CMD. ENTRYPOINT rimane coerente, semplificando così l'esperienza degli utenti.

Sovrascrivere ENTRYPOINT a runtime

Docker permette di sovrascrivere ENTRYPOINT direttamente a runtime, abilitando il debug senza ricostruire l'immagine del tuo Dockerfile.

Uso del flag entrypoint

Docker fornisce il flag semplice --entrypoint che cambia temporaneamente il comportamento del container.

docker run -it --entrypoint /bin/bash my-containerOfferto da

Gli override temporanei consentono di risolvere problemi di avvio usando la shell, senza rebuild dell'immagine o lunghi ritardi.

Personalizzare il comportamento di ENTRYPOINT

Docker offre flessibilità quando ENTRYPOINT richiede una personalizzazione più avanzata.

Sovrascrivere ENTRYPOINT a runtime

Puoi sovrascrivere dinamicamente il comando ENTRYPOINT a runtime usando docker run --entrypoint per fare debug o cambiare contesto rapidamente senza modificare ripetutamente il tuo Dockerfile.

ENTRYPOINT con argomenti

Gli argomenti passati ai container diventano parametri di ENTRYPOINT a runtime; le best practice suggeriscono di mantenere ENTRYPOINT il più semplice possibile insieme a CMD per massima chiarezza e controllo.

Script wrapper

Script Bash introdotti come comandi ENTRYPOINT possono eseguire logiche di avvio condizionali, attendere servizi dipendenti (come database), gestire task di setup e altro, mantenendo una sintassi del Dockerfile pulita.

Esempi e pattern reali

Applicazioni pratiche di ENTRYPOINT possono illustrare usi tipici e realistici. Vediamone alcune.

Container a comando singolo 

Per un setup di un'app Flask:

FROM python:3.11-alpine
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]Offerto da

Nel Dockerfile sopra:

• ENTRYPOINT ["python", "app.py"]  imposta l'eseguibile predefinito. È ciò che viene eseguito all'avvio del container.
• CMD ["--port", "8080"]  fornisce argomenti di default (--port 8080) al comando ENTRYPOINT.

Il comando predefinito completo eseguito sarà:

python app.py --port 8080Offerto da

 Se sovrascrivi CMD quando esegui il container (ad es., docker run myimage --port 9090), sostituirà --port 8080.

Script come ENTRYPOINT 

Questo è usato per impostare logiche condizionali di supporto: 

entrypoint.sh:

#!/bin/sh
until nc -z db_host 5432; do
  echo "Waiting for database to become available."
  sleep 2
done
exec python app.py "$@"Offerto da

Dockerfile:

FROM python:3.11-alpine
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
COPY entrypoint.sh .
RUN chmod +x entrypoint.sh
ENTRYPOINT ["./entrypoint.sh"]
CMD ["--port", "8080"]Offerto da

Nei file sopra:

• entrypoint.sh viene usato per attendere la connessione al database.
• exec python app.py "$@"  sostituisce il processo della shell corrente con python app.py, passando eventuali argomenti aggiuntivi. "$@" proviene dai parametri di CMD o di docker run.
• COPY entrypoint.sh  copia lo script entrypoint.sh nella directory /app del container.
• ENTRYPOINT ["./entrypoint.sh"] imposta entrypoint.sh come script di avvio predefinito quando il container viene eseguito.
• CMD ["--port", "8080"] fornisce argomenti predefiniti che verranno passati allo script entrypoint.sh e infine a python app.py. Il comando finale eseguito sarà simile a: python app.py --port 8080. 

Gestione dei segnali e PID 1

La forma di ENTRYPOINT influisce in modo significativo sulla capacità di Docker di gestire i segnali a causa dell'importanza del PID 1. Esploriamolo più in dettaglio: 

Exec form e PID 1

La exec form esegue i comandi direttamente come processo PID 1 di Docker, migliorando l'affidabilità dell'inoltro dei segnali e il comportamento corretto di stop o restart.

Limitazioni della shell form

La shell form aggiunge un processo di shell intermedio. Questo impedisce ai segnali di terminazione di raggiungere i processi applicativi, creando il rischio di container bloccati o non reattivi.

Debug del comportamento di ENTRYPOINT

Risolvi i problemi delle configurazioni di entrypoint più facilmente usando alcune tecniche e trucchi. Scopriamoli qui sotto. 

Uso di --entrypoint per il debug

Gli override temporanei consentono rapidamente shell interattive di debug all'interno dei tuoi container senza rebuild dell'immagine. Questo ti permette di testare diverse cose nella tua applicazione senza ricostruire l'immagine. 

Visualizzare i log di ENTRYPOINT

Controllare i log di output con docker logs semplifica la tracciatura della cronologia di esecuzione e l'individuazione chiara e rapida dei problemi di configurazione.

Evita di modificare il Dockerfile per test temporanei

Gli override di ENTRYPOINT a runtime, pensati per il debug, ti consentono di isolare e correggere i problemi senza modificare e ricostruire ripetutamente le immagini dei container.

Tecniche di ottimizzazione e best practice

Di seguito alcune ottimizzazioni consigliate per migliorare l'affidabilità e la manutenibilità di ENTRYPOINT.

Usa la exec form per la gestione dei segnali

Preferisci sempre la exec form per gestire correttamente i segnali di terminazione e migliorare l'affidabilità e la gestibilità complessiva del container.

Combina efficacemente ENTRYPOINT e CMD

Separa l'eseguibile (ENTRYPOINT) dagli argomenti di runtime predefiniti (CMD) e sfrutta gli override a runtime per massima flessibilità e semplicità di gestione.

Riduci la complessità in ENTRYPOINT

Mantieni ENTRYPOINT semplice, delegando logiche di avvio complesse o condizioni a script separati per gestire meglio la complessità e aumentare la chiarezza.

Casi d'uso e pattern avanzati

Esploriamo alcuni casi d'uso e pattern avanzati di ENTRYPOINT.

Build multi-stage con ENTRYPOINT

ENTRYPOINT negli stage finali del Dockerfile impone un'esecuzione affidabile, offrendo build più pulite su misura per i task in produzione all'interno di workflow CI/CD.

Script ENTRYPOINT dinamici

Gli script ENTRYPOINT possono adattare dinamicamente la logica di avvio in base alle variabili d'ambiente o agli argomenti di runtime forniti, adattandosi senza problemi a contesti applicativi diversi.

ENTRYPOINT per pipeline CI/CD

Sfruttare ENTRYPOINT  migliora la coerenza tra ambienti di test e di produzione, garantendo comportamenti a runtime prevedibili e ripetibilità. Ad esempio, puoi impostare ENTRYPOINT su uno script che esegue automaticamente i test. 

Altre applicazioni includono: 

• Un ENTRYPOINT che attende il database, poi esegue le migrazioni e infine avvia l'app.
• Un ENTRYPOINT che compila asset, esegue il linting del codice o valida automaticamente le configurazioni.
• Script ENTRYPOINT che rilevano gli ambienti (dev, staging, production) e regolano le impostazioni di conseguenza all'avvio del container. 

Ecco un esempio di immagine Docker che esegue automaticamente i test:

FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
ENTRYPOINT ["pytest"]Offerto da

Il file .gitlab-ci.yml potrebbe essere così:

build-test:
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myapp-test .
    - docker run myapp-test  # <-- No need to specify 'pytest', ENTRYPOINT does itOfferto da

Quando docker run viene eseguito, attiva automaticamente pytest dentro il container. Questo farà sì che tutti i test vengano trovati ed eseguiti immediatamente. 

Ci sono diversi vantaggi nell'usare ENTRYPOINT in CI/CD:

• Ogni container si avvia e si comporta nello stesso modo. 
• Semplifica gli script CI/CD perché non devi passare ogni volta i comandi completi. 
• Automatizza i controlli pre-avvio, l'esecuzione dei test e le migrazioni, riducendo l'errore umano. 

Errori comuni e troubleshooting

ENTRYPOINT presenta alcune insidie da evitare nei tuoi workflow.

Uso scorretto della shell form

La shell form ostacola i segnali e i gestori di container; preferisci sempre la exec form per una corretta gestione dei segnali, uscite pulite del container e arresti senza problemi.

Complicare eccessivamente ENTRYPOINT

Script complessi che mancano di chiarezza o affidabilità peggiorano durante il debug o la manutenzione continua. Configurazioni ENTRYPOINT semplici semplificano notevolmente il troubleshooting.

Conclusione

Capire e implementare efficacemente Docker ENTRYPOINT consente di creare container Docker prevedibili, affidabili e manutenibili per le tue applicazioni. Usato correttamente, ENTRYPOINT crea coerenza senza sacrificare flessibilità grazie al potente sistema di override di Docker. Sperimentare con attenzione con i pattern di ENTRYPOINT, seguendo le best practice descritte sopra, semplifica notevolmente l'uso di Docker e porta a cicli di deployment e gestione più fluidi in produzione.

Dai un'occhiata ai nostri corsi Docker per esplorare altri argomenti su Docker, come:

• Introduction to Docker
• Containerization and Virtualization Concepts 
• Containerization and Virtualization with Docker and Kubernetes
• Intermediate Docker