En un Dockerfile, ¿qué diferencia hay entre CMD y ENTRYPOINT? ¿Cuándo usarías cada uno o ambos juntos? — pregunta de entrevista

Respuesta

ENTRYPOINT define el ejecutable principal del contenedor. CMD define el comando o los argumentos por defecto, y se reemplaza fácilmente desde

Código: bash

docker run

.

Comportamiento:

Si solo hay CMD,
Código: bash
```
docker run imagen otro-comando
```
lo reemplaza por completo.
Si hay ENTRYPOINT, lo que pasás en
Código: bash
```
docker run
```
se agrega como argumentos. Para cambiarlo hay que usar
Código: text
```
--entrypoint
```
.
Si están los dos, CMD funciona como argumentos por defecto de ENTRYPOINT.

Código: bash

ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]
# docker run img            -> python app.py --port 8080
# docker run img --port 9000 -> python app.py --port 9000

Forma exec frente a forma shell: conviene usar la forma exec, la del array JSON. Con la forma shell (

Código: text

CMD python app.py

) el PID 1 es

Código: text

/bin/sh -c

, que no reenvía SIGTERM a tu proceso. El resultado es que

Código: bash

docker stop

o Kubernetes esperan el timeout y terminan matando el contenedor con SIGKILL, sin un apagado ordenado.

Cuándo usar cada uno:

Imagen que se comporta como una herramienta (un CLI): ENTRYPOINT con el binario y CMD con un
Código: text
```
--help
```
o flags por defecto.
Imagen de propósito general, donde es útil entrar con
Código: text
```
bash
```
: solo CMD.
Script de inicialización (
Código: text
```
entrypoint.sh
```
) que prepara configuración: tiene que terminar con
Código: text
```
exec "$@"
```
para que el proceso real reemplace al shell y reciba las señales.

Errores comunes

Decir que son equivalentes o confundir cuál se sobrescribe con los argumentos de docker run. No mencionar el problema de señales de la forma shell, ni olvidar el exec "$@" en los scripts de entrypoint.

Redactado con el asistente Underc0de IA. Actualizado el 10/11/2026. ¿Ves un error? Contanos en el foro.