В чём разница между ENTRYPOINT и CMD?

Question

Accepted Answer

**ENTRYPOINT** и **CMD** оба определяют, что запускается при старте контейнера, но они служат разным целям и взаимодействуют определённым образом. Понимание различия (и двух форм — exec vs shell) важно для написания Dockerfiles, которые ведут себя правильно.

## CMD — команда по умолчанию (переопределяемая)

```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` предоставляет **команду по умолчанию**, которая **полностью переопределяется** любой командой, переданной в `docker run`.

## ENTRYPOINT — фиксированный исполняемый файл

```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` устанавливает **фиксированный исполняемый файл**, который всегда запускается; аргументы во время выполнения **добавляются** как его аргументы, вместо того чтобы его заменять.

## Использование их вместе (обычный паттерн)

```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 форма vs 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
```

## Почему это важно

Понимание различия между ENTRYPOINT и CMD важно для **написания Dockerfiles, которые ведут себя правильно**, поэтому это ценное практическое знание и часто вызывающая путаницу тема.

Различие в поведении имеет значение: **CMD** предоставляет команду по умолчанию, которая **полностью переопределяется** любой командой, переданной в `docker run`, тогда как **ENTRYPOINT** устанавливает фиксированный исполняемый файл, который всегда запускается с аргументами во время выполнения **добавляемыми** к нему — разные поведения, влияющие на то, как контейнер реагирует на аргументы во время выполнения.

Понимание **обычного паттерна их совместного использования** (`ENTRYPOINT` как команда и `CMD` как переопределяемые аргументы по умолчанию) — это чистый, идиоматический подход, который делает контейнеры похожими на настраиваемые исполняемые файлы — широко используемая техника, стоящая понимания.

Критически важно понимание **exec формы vs shell формы**: **exec форма** (JSON массив, например `CMD ["node", "server.js"]`) предпочтительна, потому что запускает исполняемый файл **непосредственно как PID 1**, поэтому он **получает сигналы, такие как SIGTERM** правильно, позволяя **корректное завершение** — тогда как **shell форма** (`CMD node server.js`) запускается через shell, который становится PID 1, часто вызывая то, что приложение **не получает сигналы завершения правильно** (ведя к некорректному завершению, потере текущей работы или медленным остановкам).

Эта проблема с обработкой сигналов/корректным завершением — реальная, тонкая проблема, которую избегает exec форма.

Поскольку определение того, что запускается при старте контейнера, является фундаментальным для каждого Dockerfile, и поскольку различие ENTRYPOINT/CMD (и проблема exec-vs-shell-form с обработкой сигналов) непосредственно влияет на поведение и корректность контейнера (обработка аргументов, корректное завершение), понимание ENTRYPOINT vs CMD — их ролей, того как они комбинируются и важной практики exec-form-for-signals — является ценным, практически релевантным знанием Docker, часто неправильно понимаемой темой, где понимание различий предотвращает реальные проблемы с поведением и завершением.