Vilka är alternativen till Docker och containerekosystemet?

Question

Accepted Answer

Även om Docker populariserade containers har ekosystemet vuxit — med **standarder (OCI)**, alternativa runtimes (**containerd**, **CRI-O**), alternativa verktyg (**Podman**, **Buildah**), och orkestrering. Att förstå det bredare ekosystemet och standarderna klargör att containers är större än Docker produkten.

## Containers är standardiserade (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 och stacken

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

## Alternativa verktyg

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

## Varför det är viktigt

Att förstå alternativen till Docker och det bredare containerekosystemet är värdefull kunskap på senior-nivå eftersom det klargör att **containers är en öppen standard, inte synonymt med Docker produkten**, vilket är viktigt för att fatta välgrundade verktygsbeslut och förstå modern infrastruktur.

Nyckelinsikten är **OCI (Open Container Initiative) standardisering** av bild- och runtimeformat — vilket betyder att containers är **portabla mellan verktyg** och inte låsta till Docker; Docker-bilder är OCI-bilder som många verktyg kan bygga och köra utbytbart.

Att förstå **runtime-stacken** (runc som low-level runtime, containerd som higher-level runtime använd av både Docker och Kubernetes, CRI-O som ett Kubernetes-alternativ) avslöjar att Docker är byggt på lagerindelade, oberoende användbara komponenter — och noterbart att **Kubernetes använder containerd/CRI-O direkt** (har slutat använda Docker shim), så Docker produkten är inte nödvändig för att köra containers i Kubernetes, en viktig klarläggning som ofta orsakar förvirring.

Att känna till **alternativa verktyg** — **Podman** (daemonless, rootless-friendly med ett kompatibelt CLI och bättre säkerhetmodell), **Buildah** och **Kaniko** (bygga bilder utan daemon, användbar i CI/Kubernetes), **BuildKit** (Dockers moderna build-motor), och buildpacks (bygga utan Dockerfiles) — ger alternativ för olika behov, särskilt kring säkerhet (daemonless/rootless) och CI/CD.

Denna bredare förståelse informerar verktygsbeslut och klargör relationen mellan Docker, containers, standarder och orkestrering.

Eftersom containerekosystemet är större än Docker produkten (med öppna standarder och många interoperabla verktyg), och eftersom att förstå OCI-standarder, runtime-stacken och alternativ (Podman, etc.) klargör modern infrastruktur och informerar verktygsbeslut (särskilt kring säkerhet och Kubernetes), är förståelsen för Docker-alternativ och containerekosystemet värdefull kunskap på senior-nivå som återspeglar en mogen, korrekt förståelse av containers som en öppen, standardiserad teknik — användbar för arkitektur- och verktygsbeslut och för korrekt förståelse av hur containers passar in i moderna plattformar som Kubernetes.