Jaka jest różnica między ENTRYPOINT a CMD?

Question

Accepted Answer

**ENTRYPOINT** i **CMD** zarówno definiują, co uruchamia się przy starcie kontenera, ale pełnią różne role i wchodzą w interakcję w konkretny sposób. Zrozumienie różnicy (i dwóch form — exec vs shell) jest ważne dla pisania Dockerfiles'ów, które zachowują się prawidłowo.

## CMD — domyślna komenda (możliwa do zastąpienia)

```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` zapewnia **domyślną komendę**, która jest **całkowicie zastępowana** przez dowolną komendę podaną w `docker run`.

## ENTRYPOINT — stały plik wykonywalny

```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` ustawia **stały plik wykonywalny**, który zawsze się uruchamia; argumenty w czasie działania są **dołączane** jako jego argumenty, a nie go zastępują.

## Używanie ich razem (wspólny wzorzec)

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

## Dlaczego to ważne

Zrozumienie różnicy między ENTRYPOINT a CMD jest ważne dla **pisania Dockerfiles'ów, które zachowują się prawidłowo**, dlatego jest to cenna praktyczna wiedza i powszechnie mylony temat.

Różnica w zachowaniu ma znaczenie: **CMD** zapewnia domyślną komendę, która jest **całkowicie zastępowana** przez dowolną komendę przekazaną do `docker run`, natomiast **ENTRYPOINT** ustawia stały plik wykonywalny, który zawsze się uruchamia z argumentami w czasie działania **dołączanymi** do niego — różne zachowania, które wpływają na to, jak kontener reaguje na argumenty w czasie działania.

Zrozumienie **wspólnego wzorca ich używania razem** (`ENTRYPOINT` jako komenda i `CMD` jako zastępowalne domyślne argumenty) to czysty, idiomatyczny sposób, który sprawia, że kontenery zachowują się jak konfigurowalne pliki wykonywalne — powszechnie stosowana technika warta poznania.

Krytycznie, zrozumienie **formy exec vs formy shell** jest ważne dla poprawności: **forma exec** (tablica JSON, np. `CMD ["node", "server.js"]`) jest preferowana, ponieważ uruchamia plik wykonywalny **bezpośrednio jako PID 1**, dzięki czemu **odbiera sygnały takie jak SIGTERM** prawidłowo, umożliwiając **łagodne wyłączenie** — natomiast **forma shell** (`CMD node server.js`) uruchamia się poprzez shell, który staje się PID 1, często powodując, że aplikacja **nie odbiera sygnałów wyłączenia prawidłowo** (prowadzące do nieumyślnego przerwania, zagubionej pracy w trakcie lub powolnych zatrzymań).

Problem obsługi sygnałów/łagodnego wyłączenia to rzeczywisty, subtelny problem, którego forma exec unika.

Ponieważ definiowanie tego, co uruchamia się przy starcie kontenera, jest fundamentalne dla każdego Dockerfile'a, i ponieważ różnica ENTRYPOINT/CMD (i problem obsługi sygnałów exec-vs-shell-form) bezpośrednio wpływa na zachowanie i poprawność kontenera (obsługę argumentów, łagodne wyłączenie), zrozumienie ENTRYPOINT vs CMD — ich ról, jak się łączą, i ważnej praktyki exec-form-for-signals — jest cenna, praktycznie istotna wiedza o Dockerze, powszechnie źle rozumiana, gdzie zrozumienie różnic zapobiega rzeczywistym behawioralnym i błędom wyłączenia.