Qual è la differenza tra ENTRYPOINT e CMD?

Question

Accepted Answer

**ENTRYPOINT** e **CMD** definiscono entrambi cosa viene eseguito all'avvio di un container, ma svolgono ruoli diversi e interagiscono in modo specifico. Comprendere la differenza (e le due forme — exec vs shell) è importante per scrivere Dockerfile che si comportano correttamente.

## CMD — il comando predefinito (sovrescrivibile)

```dockerfile
CMD ["node", "server.js"]
# → the DEFAULT command when the container starts
# → but it's REPLACED if you pass a command at run time:
#   docker run myapp echo hello   → runs "echo hello" INSTEAD of node server.js
```

`CMD` fornisce il **comando predefinito**, che è **completamente sovrascritto** da qualsiasi comando fornito in `docker run`.

## ENTRYPOINT — l'eseguibile fisso

```dockerfile
ENTRYPOINT ["node", "server.js"]
# → ALWAYS runs; run-time arguments are APPENDED (not replacing it):
#   docker run myapp --port 8080   → runs "node server.js --port 8080"
# → makes the container behave like a specific executable
```

`ENTRYPOINT` imposta un **eseguibile fisso** che viene sempre eseguito; gli argomenti in fase di esecuzione sono **aggiunti** come suoi argomenti anziché sostituirlo.

## Utilizzarli insieme (il pattern comune)

```dockerfile
ENTRYPOINT ["node", "server.js"]   # the fixed command
CMD ["--port", "3000"]              # DEFAULT arguments (overridable)
# docker run myapp                  → node server.js --port 3000 (defaults)
# docker run myapp --port 8080      → node server.js --port 8080 (CMD overridden)
→ ENTRYPOINT = the command; CMD = default arguments you can override. A clean pattern.
```

## Exec form vs shell form

```text
EXEC form  → CMD ["node", "server.js"]  (JSON array) — PREFERRED:
  runs the executable DIRECTLY (PID 1) → receives signals (SIGTERM) → graceful shutdown
SHELL form → CMD node server.js  → runs via /bin/sh -c → the shell is PID 1,
  the app may NOT receive signals properly (shutdown issues) → avoid for the main process
```

## Perché è importante

Comprendere la differenza tra ENTRYPOINT e CMD è importante per **scrivere Dockerfile che si comportano correttamente**, quindi è una conoscenza pratica preziosa e un argomento comunemente frainteso.

La distinzione nel comportamento è rilevante: **CMD** fornisce un comando predefinito che è **completamente sovrascritto** da qualsiasi comando passato a `docker run`, mentre **ENTRYPOINT** imposta un eseguibile fisso che viene sempre eseguito con gli argomenti in fase di esecuzione **aggiunti** — comportamenti diversi che influenzano il modo in cui il container risponde agli argomenti in fase di esecuzione.

Comprendere il **pattern comune di utilizzarli insieme** (`ENTRYPOINT` come comando e `CMD` come argomenti predefiniti sovrescrivibili) è un approccio pulito e idiomatico che fa sì che i container si comportino come eseguibili configurabili — una tecnica ampiamente utilizzata che vale la pena conoscere.

Criticamente, comprendere la **exec form vs shell form** è importante per la correttezza: la **exec form** (array JSON, ad es. `CMD ["node", "server.js"]`) è preferita perché esegue l'eseguibile **direttamente come PID 1**, quindi **riceve correttamente segnali come SIGTERM**, abilitando l'**arresto elegante** — mentre la **shell form** (`CMD node server.js`) viene eseguita tramite una shell che diventa PID 1, spesso causando all'applicazione di **non ricevere correttamente i segnali di arresto** (portando a terminazione non elegante, lavoro in volo perso o arresti lenti).

Questo problema di gestione dei segnali/arresto elegante è un problema reale e sottile che la exec form evita.

Poiché la definizione di cosa viene eseguito all'avvio di un container è fondamentale per ogni Dockerfile, e poiché la distinzione ENTRYPOINT/CMD (e il problema di gestione dei segnali exec-vs-shell-form) influisce direttamente sul comportamento e la correttezza del container (gestione degli argomenti, arresto elegante), comprendere ENTRYPOINT vs CMD — i loro ruoli, come si combinano e la pratica importante di exec-form-for-signals — è una conoscenza Docker preziosa e praticamente rilevante, un argomento comunemente frainteso dove la comprensione delle differenze previene bug reali di comportamento e arresto.