Hva er forskjellen mellom ENTRYPOINT og CMD?

Question

Accepted Answer

**ENTRYPOINT** og **CMD** definerer begge hva som kjører når en container starter, men de har ulike roller og samhandler på spesifikke måter. Å forstå forskjellen (og de to formene — exec vs shell) er viktig for å skrive Dockerfiles som oppfører seg korrekt.

## CMD — standardkommandoen (kan overstyres)

```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` gir **standardkommandoen**, som blir **fullstendig overstyrt** av enhver kommando gitt på `docker run`.

## ENTRYPOINT — det faste kjørbare

```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` angir et **fast kjørbart** som alltid kjører; kjøringstidsargumenter blir **lagt til** som dets argumenter i stedet for å erstatte det.

## Å bruke dem sammen (det vanlige mønsteret)

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

## Hvorfor det spiller en rolle

Å forstå forskjellen mellom ENTRYPOINT og CMD er viktig for **å skrive Dockerfiles som oppfører seg korrekt**, så det er verdifull praktisk kunnskap og et ofte misforstått emne.

Forskjellen i oppførsel spiller en rolle: **CMD** gir en standardkommando som blir **fullstendig overstyrt** av enhver kommando som sendes til `docker run`, mens **ENTRYPOINT** angir et fast kjørbart som alltid kjører med kjøringstidsargumenter **lagt til** det — ulike oppførsler som påvirker hvordan containeren reagerer på kjøringstidsargumenter.

Å forstå **det vanlige mønsteret for å bruke dem sammen** (`ENTRYPOINT` som kommandoen og `CMD` som overstybar standardargumenter) er en ren, idiomatisk tilnærming som gjør containere oppfører seg som konfigurerbare kjørbare — en mye brukt teknikk som er verdt å kjenne.

Kritisk er det å forstå **exec-form vs shell-form** viktig for korrekthet: **exec-formen** (JSON-matrise, f.eks. `CMD ["node", "server.js"]`) er foretrukket fordi den kjører det kjørbare **direkte som PID 1**, så det **mottar signaler som SIGTERM** ordentlig, noe som muliggjør **grasiøs nedstengning** — mens **shell-formen** (`CMD node server.js`) kjører via et shell som blir PID 1, ofte forhindrer programmet fra å **motta nedstengningssignaler ordentlig** (fører til ugrasiøs terminering, tapt arbeid i gang, eller langsomme stopp).

Dette signal-håndterings-/grasiøs-nedstengnings-problemet er et reelt, subtilt problem som exec-formen unngår.

Siden definisjonen av hva som kjører når en container starter er grunnleggende for hver Dockerfile, og siden ENTRYPOINT/CMD-forskjellen (og exec-vs-shell-form signal-håndterings-bekymringen) direkte påvirker containeroppførsel og korrekthet (argument-håndtering, grasiøs nedstengning), å forstå ENTRYPOINT vs CMD — deres roller, hvordan de kombineres, og den viktige exec-form-for-signaler-praksis — er verdifull, praktisk relevant Docker-kunnskap, et ofte misforstått emne der å forstå forskjellene forhindrer reelle oppførsels- og nedstengningsbugs.