Hvad er alternativerne til Docker og container-økosystemet?

Question

Accepted Answer

Selvom Docker populariserede containere, er økosystemet vokset — med **standarder (OCI)**, alternative runtimes (**containerd**, **CRI-O**), alternative værktøjer (**Podman**, **Buildah**), og orkestrering. At forstå det bredere økosystem og standarder præciserer, at containere er større end Docker produktet.

## Containere er standardiserede (OCI)

```text
The OPEN CONTAINER INITIATIVE (OCI) standardizes container IMAGES and RUNTIMES:
  → OCI image format & runtime spec → images/containers are PORTABLE across tools
  → Docker images are OCI images; many tools can build/run them interchangeably
→ "Containers" are an open standard, not locked to Docker the company/product.
```

## Runtimes og stakken

```text
Docker itself is built on layers that can be used independently:
  runc       → low-level runtime that actually creates containers (OCI runtime)
  containerd → higher-level runtime managing images/containers (used by Docker AND K8s)
  CRI-O      → a lightweight runtime for Kubernetes (alternative to containerd)
→ Kubernetes uses containerd/CRI-O directly (it dropped the Docker shim) — Docker the
  product isn't required to RUN containers in K8s.
```

## Alternative værktøjer

```text
PODMAN  → daemonless, rootless-friendly Docker alternative (compatible CLI);
          no central daemon → better security model; popular in RHEL ecosystems
BUILDAH → builds OCI images (without a daemon); KANIKO → builds images in K8s/CI
BUILDKIT→ Docker's modern build engine (faster, better caching, build secrets)
Go-based: ko (build Go images); Nixpacks, Cloud Native Buildpacks (build without Dockerfiles)
```

## Hvorfor det betyder noget

At forstå alternativerne til Docker og det bredere container-økosystem er værdifuld viden på seniorniveau, fordi det præciserer, at **containere er en åben standard, ikke synonymt med Docker produktet**, hvilket betyder noget for at træffe informerede værktøjsbeslutninger og forstå moderne infrastruktur.

Nøglet indsigt er **OCI (Open Container Initiative) standardiseringen** af image- og runtime-formater — hvilket betyder, at containere er **portable på tværs af værktøjer** og ikke låst til Docker; Docker-billeder er OCI-billeder, som mange værktøjer kan bygge og køre indbyrdes udskifteligt.

At forstå **runtime-stakken** (runc som low-level runtime, containerd som higher-level runtime brugt af både Docker og Kubernetes, CRI-O som et Kubernetes-alternativ) afslører, at Docker er bygget på lagdelte, uafhængigt-brugbare komponenter — og bemærkelsesværdigt, at **Kubernetes bruger containerd/CRI-O direkte** (har droppet Docker-shimmen), så Docker produktet er ikke påkrævet for at køre containere i Kubernetes, en vigtig præcisering, som ofte forårsager forvirring.

At kende **alternative værktøjer** — **Podman** (daemonless, rootless-venlig med et kompatibelt CLI og bedre sikkerhedsmodel), **Buildah** og **Kaniko** (bygning af billeder uden en daemon, nyttigt i CI/Kubernetes), **BuildKit** (Dockers moderne build-engine), og buildpacks (bygning uden Dockerfiles) — giver muligheder for forskellige behov, især omkring sikkerhed (daemonless/rootless) og CI/CD.

Dette bredere syn informerer værktøjsvalg og præciserer forholdet mellem Docker, containere, standarder og orkestrering.

Da container-økosystemet er større end Docker produktet (med åbne standarder og mange interoperable værktøjer), og da at forstå OCI-standarderne, runtime-stakken og alternativerne (Podman osv.) præciserer moderne infrastruktur og informerer værktøjsbeslutninger (især omkring sikkerhed og Kubernetes), er det at forstå Docker-alternativer og container-økosystemet værdifuld viden på seniorniveau, som afspejler en moden, nøjagtig forståelse af containere som en åben, standardiseret teknologi — nyttigt for arkitektur- og værktøjsbeslutninger og for korrekt at forstå, hvordan containere passer ind i moderne platforme som Kubernetes.