Hvordan fungerer Docker under panseret?

Question

Accepted Answer

Docker bruker Linux-kjernefunksjoner — **namespaces** (isolasjon), **cgroups** (ressurskontroll), og **union-filsystemer** (lagdelte bilder) — for å opprette lette containere. Å forstå de underliggende mekanismene forklarer hvordan containere oppnår isolasjon og effektivitet.

## Namespaces — isolasjon

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

```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-filsystem — lagdelte bilder

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

Å forstå hvordan Docker fungerer under panseret er verdifull senior-nivå-kunnskap fordi det **demystifiserer containere** og forklarer deres nøkkelegenskaper (isolasjon, effektivitet, ressurskontroll), noe som fordyper ens evne til å resonnere om, konfigurere og feilsøke containeriserte systemer.

Den avgjørende innsikten er at **containere ikke er VM-er — de er isolerte prosesser på verten** som bruker Linux-kjernefunksjoner, som er grunnen til at de er lette og raske (deler værtskjernen i stedet for å kjøre separate operativsystemer).

Å forstå de **tre kjernemekanismene** forklarer egenskapene: **namespaces** isolerer hva en prosess kan se (sitt eget prosesstræ, nettverk, filsystem, hostname — som er *hvorfor* en container føles som en separat maskin til tross for å dele kjernen), **cgroups** begrenser og regnskapsfører ressursbruk (som er *hvorfor* du kan angi CPU- og minnegrenser — kjernen håndhever dem), og **union/overlay-filsystemer** stacker bildeling (som er *hvorfor* bilder er lagdelt, bufret og delbar, og containere er lette — skrivebeskyttede lag som deles på tvers av containere med et tynt skrivbart lag på toppen).

Å forstå **arkitekturen** (CLI → daemon → containerd → runc, der daemonen administrerer alt) gir det fullstendige bildet av hvordan Docker opererer.

Denne dypere forståelsen hjelper med å resonnere om isolasjonsbegrensninger (og deres sikkerhetsimplikasjoner, siden containere deler kjernen), forklarer ytelses- og effektivitetskarakteristikker, og hjelper til med feilsøking.

Siden det å forstå de underliggende mekanismene (namespaces, cgroups, union-filsystemer) forklarer *hvorfor* containere oppfører seg som de gjør — deres isolasjon, effektivitet, ressurskontroll, og det viktige faktum at de deler værtskjernen (med sikkerhetsimplikasjoner) — og fordyper evnen til å arbeide med containeriserte systemer med tillitt, er å forstå hvordan Docker fungerer under panseret verdifull senior-nivå-kunnskap som løfter en fra å bruke Docker til virkelig å forstå det, et tema som reflekterer dybden som forventes for senior roller og som er nyttig for å resonnere om containeradferd, sikkerhetsbegrensninger og ytelse.