Hvad er forskellen mellem ENTRYPOINT og CMD?

Question

Accepted Answer

**ENTRYPOINT** og **CMD** definerer begge hvad der køres når en container starter, men de spiller forskellige roller og interagerer på specifikke måder. Det er vigtigt at forstå forskellen (og de to former — exec vs shell) for at skrive Dockerfiles, der opfører sig korrekt.

## CMD — standardkommandoen (kan overskrives)

```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` leverer **standardkommandoen**, som **fuldstændigt overskrives** af enhver kommando givet på `docker run`.

## ENTRYPOINT — den faste eksekverbar

```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` angiver en **fast eksekverbar**, der altid køres; køretidsargumenter **tilføjes** som dens argumenter i stedet for at erstatte den.

## Brug af dem sammen (det almindelige mønster)

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

At forstå forskellen mellem ENTRYPOINT og CMD er vigtig for **at skrive Dockerfiles, der opfører sig korrekt**, så det er værdifuld praktisk viden og et almindeligt misforstået emne.

Skellet i adfærd betyder noget: **CMD** leverer en standardkommando, der **fuldstændigt overskrives** af enhver kommando sendt til `docker run`, mens **ENTRYPOINT** angiver en fast eksekverbar, der altid køres med køretidsargumenter **tilføjet** til den — forskellige adfærd, der påvirker, hvordan containeren reagerer på køretidsargumenter.

At forstå **det almindelige mønster med brug af dem sammen** (`ENTRYPOINT` som kommandoen og `CMD` som overskrivelbare standardargumenter) er en ren, idiomatisk tilgang, der får containere til at opføre sig som konfigurerbare eksekverbarer — en udbredt teknik, der er værd at kende.

Kritisk er det vigtig at forstå **exec form vs shell form** for korrekthed: **exec form** (JSON-array, f.eks. `CMD ["node", "server.js"]`) foretrækkes, fordi den køres eksekverbaren **direkte som PID 1**, så den **modtager signaler som SIGTERM** korrekt, hvilket muliggør **graciøs nedlukning** — mens **shell form** (`CMD node server.js`) køres via et shell, der bliver PID 1, hvilket ofte bevirker, at applikationen **ikke modtager nedlukkningssignaler korrekt** (hvilket fører til ugraciøs afslutning, tabt arbejde på vej, eller langsomme stop).

Dette signal-håndterings-/graciøs-nedlukkings-problem er et reelt, subtilt problem, som exec form undgår.

Da det at definere hvad der køres, når en container starter, er grundlæggende for hver Dockerfile, og da ENTRYPOINT/CMD-skellet (og exec-vs-shell-form signal-håndteringsopmærksomheden) direkte påvirker containeradfærd og korrekthed (argumenthåndtering, graciøs nedlukning), er forståelse af ENTRYPOINT vs CMD — deres roller, hvordan de kombineres, og den vigtige exec-form-for-signaler praksis — værdifuld, praktisk relevant Docker-viden, et almindeligt misforstået emne, hvor forståelse af forskellene forhindrer reelle adfærds- og nedlukkningsfejl.