Hvordan fungerer Docker under motorhjelmen?

Question

Accepted Answer

Docker bruger Linux kernel-funktioner — **namespaces** (isolation), **cgroups** (ressourcekontrol) og **union filesystems** (lagdelte images) — til at skabe lette containere. Forståelse af de underliggende mekanismer forklarer, hvordan containere opnår isolation og effektivitet.

## Namespaces — isolation

```text
Linux NAMESPACES isolate what a process can SEE — giving each container its own view:
  PID namespace     → its own process tree (container sees only its processes)
  NET namespace     → its own network interfaces, IPs, ports
  MNT namespace     → its own filesystem mounts
  UTS namespace     → its own hostname
  IPC, USER namespaces → isolated IPC, user/group ID mapping
→ Namespaces are WHY a container feels like a separate machine (isolated view),
  while actually sharing the host kernel.
```

## cgroups — ressourcekontrol

```text
Control Groups (CGROUPS) LIMIT and account for resource usage per container:
  → CPU, memory, disk I/O, network bandwidth
→ cgroups are WHY you can set resource limits (-m, --cpus) — the kernel enforces them.
```

## Union filesystem — lagdelte images

```text
UNION/OVERLAY filesystems (overlayfs) stack image LAYERS:
  → read-only image layers + a thin writable container layer on top, merged into one view
  → layers are SHARED between images/containers (one copy on disk) → space-efficient
→ This is WHY images are layered, cached, and shareable, and containers are lightweight.
```

## Arkitekturen

```text
Docker CLI → Docker DAEMON (dockerd) → containerd → runc (creates containers using
  namespaces + cgroups). The daemon manages images, containers, networks, volumes.
→ Containers are just ISOLATED PROCESSES on the host (not VMs) — using kernel features,
  sharing the host kernel → lightweight and fast.
```

## Hvorfor det betyder noget

At forstå, hvordan Docker fungerer under motorhjelmen, er værdifuld viden på seniorplan, fordi det **demystificerer containere** og forklarer deres vigtigste egenskaber (isolation, effektivitet, ressourcekontrol), hvilket går i dybden med ens evne til at tænke over, konfigurere og fejlfinde containeriserede systemer.

Den afgørende indsigt er, at **containere ikke er VM'er — de er isolerede processer på værten** ved hjælp af Linux kernel-funktioner, hvilket er grunden til, at de er lette og hurtige (de deler værtskernen i stedet for at køre separate styresystemer).

Forståelse af de **tre kernemekanismer** forklarer egenskaberne: **namespaces** isolerer, hvad en proces kan se (sit eget processtræ, netværk, filsystem, værtsnavn — hvilket er *hvorfor* en container føles som en separat maskine trods deling af kernen), **cgroups** begrænser og redegør for ressourceforbrug (hvilket er *hvorfor* du kan angive CPU- og hukommelsesgrænser — kernen håndhæver dem), og **union/overlay filesystems** lagstakler image-lag (hvilket er *hvorfor* images er lagdelte, cachet og kan deles, og containere er lette — skrivebeskyttede lag delt på tværs af containere med et tyndt skrivbart lag øverst).

Forståelse af **arkitekturen** (CLI → daemon → containerd → runc, hvor daemonen administrerer alt) giver det fuldstændige billede af, hvordan Docker fungerer.

Denne dybere forståelse hjælper med at tænke over isolationsgrænserne (og deres sikkerhedsmæssige implikationer, da containere deler kernen), forklarer ydeevne- og effektivitetskarakteristika og hjælper med fejlfinding.

Da forståelse af de underliggende mekanismer (namespaces, cgroups, union filesystems) forklarer *hvorfor* containere opfører sig, som de gør — deres isolation, effektivitet, ressourcekontrol og det vigtige faktum, at de deler værtskernen (med sikkerhedsmæssige implikationer) — og går i dybden med evnen til at arbejde med containeriserede systemer med tillid, er forståelse af, hvordan Docker fungerer under motorhjelmen, værdifuld viden på seniorplan, der løfter en fra at bruge Docker til virkelig at forstå det, et emne, der afspejler den dybde, der forventes for seniorrollen og som er brugbar til at tænke over containerbehov, sikkerhedsgrænserne og ydeevnen.