¿Cuál es la diferencia entre ENTRYPOINT y CMD?

Question

Accepted Answer

**ENTRYPOINT** y **CMD** ambos definen qué se ejecuta cuando un contenedor inicia, pero sirven roles diferentes e interactúan de formas específicas. Entender la diferencia (y las dos formas — exec vs shell) es importante para escribir Dockerfiles que se comporten correctamente.

## Por qué es importante

```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` proporciona el **comando predeterminado**, que es **completamente anulado** por cualquier comando dado en `docker run`.

## ENTRYPOINT — el ejecutable fijo

```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` establece un **ejecutable fijo** que siempre se ejecuta; los argumentos en tiempo de ejecución son **anexados** como sus argumentos en lugar de reemplazarlo.

## Usarlos juntos (el patrón común)

```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.
```

## Forma exec vs forma shell

```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
```

## Por qué es importante

Entender la diferencia entre ENTRYPOINT y CMD es importante para **escribir Dockerfiles que se comporten correctamente**, por lo que es un conocimiento práctico valioso y un tema comúnmente confundido.

La distinción en el comportamiento importa: **CMD** proporciona un comando predeterminado que es **completamente anulado** por cualquier comando pasado a `docker run`, mientras que **ENTRYPOINT** establece un ejecutable fijo que siempre se ejecuta con argumentos en tiempo de ejecución **anexados** a él — comportamientos diferentes que afectan cómo el contenedor responde a los argumentos en tiempo de ejecución.

Entender el **patrón común de usarlos juntos** (`ENTRYPOINT` como el comando y `CMD` como argumentos predeterminados anulables) es un enfoque limpio e idiomático que hace que los contenedores se comporten como ejecutables configurables — una técnica ampliamente utilizada que vale la pena conocer.

Críticamente, entender la **forma exec vs forma shell** es importante para la corrección: la **forma exec** (array JSON, p. ej. `CMD ["node", "server.js"]`) es preferida porque ejecuta el ejecutable **directamente como PID 1**, por lo que **recibe señales como SIGTERM** correctamente, habilitando **shutdown graceful** — mientras que la **forma shell** (`CMD node server.js`) se ejecuta a través de un shell que se convierte en PID 1, a menudo causando que la aplicación **no reciba señales de shutdown correctamente** (conduciendo a terminación no graceful, trabajo en vuelo perdido, o paradas lentas).

Este problema de manejo de señales/shutdown graceful es un problema real y sutil que la forma exec evita.

Ya que definir qué se ejecuta cuando un contenedor inicia es fundamental para cada Dockerfile, y ya que la distinción ENTRYPOINT/CMD (y la preocupación de manejo de señales de forma exec-vs-shell) afecta directamente el comportamiento y corrección del contenedor (manejo de argumentos, shutdown graceful), entender ENTRYPOINT vs CMD — sus roles, cómo se combinan, y la práctica importante de forma-exec-para-señales — es conocimiento Docker valioso, prácticamente relevante, un tema comúnmente malentendido donde entender las diferencias previene problemas reales de comportamiento y shutdown.