5 Docker Projekte, die dich in 2026 wirklich besser machen

Die meisten lernen Docker, indem sie ein Dockerfile kopieren, docker compose up starten und hoffen, dass der Build grün bleibt.

Für Tag eins ist das okay. Aber wenn Docker sich nicht mehr wie Magie anfühlen soll, brauchst du Projekte, die dich an die Stellen bringen, die sonst gerne übersprungen werden: Layers, Image Size, Build Cache, Networking, Security und Deployment.

Als Docker Captain und Co-Founder von Sliplane sehe ich dasselbe Muster ständig: Entwickler können Container starten, aber hängen fest, sobald etwas langsam, unsicher, zu groß oder komisch in Production ist.

Diese fünf Projekte helfen genau dagegen.

1. Verkleinere ein echtes Docker Image, bis es weh tut

Nimm eine App, die du schon kennst. Eine Next.js App, eine FastAPI API, Rails, Go, egal.

Dein Ziel: Mach das Production Image so klein wie möglich, ohne die App zu zerlegen.

Starte mit der langweiligen Version:

FROM node:24-bookworm
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["npm", "start"]

Dann mach sie besser:

• Nutze einen Multi-Stage Build
• Kopiere nur das Build Output ins finale Image
• Entferne Dev Dependencies
• Vergleiche Debian slim, Alpine, distroless und scratch, wo es Sinn macht
• Check mit docker history, was sich verändert hat
• Schau dir das Filesystem mit einem Tool wie dive an

Du lernst, warum Images riesig werden, warum COPY . . teuer sein kann, wie Build Cache funktioniert und warum "so klein wie möglich" nicht automatisch "am besten für Production" heißt.

Hinweis für 2026: Wechsel nicht blind alles auf Alpine. Kleiner ist nett, aber native Modules, libc-Unterschiede, Debugging und Security Updates zählen auch.

2. Baue ein Image für AMD64 und ARM64

In 2026 ist Multi-Arch kein Bonus mehr. Dein Laptop kann ARM64 sein. Dein Server vielleicht AMD64. Dein CI Runner wieder etwas anderes.

Nimm eine kleine Web App und baue ein Image, das auf beiden häufigen Architekturen läuft.

Probier diesen Flow:

IMAGE="ttl.sh/docker-skill-lab-$(date +%s):1h"
docker buildx create --use
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t "$IMAGE" \
  --push \
  .
docker buildx imagetools inspect "$IMAGE"

Zieh und starte das Image danach auf einer anderen Architektur als der, auf der du gebaut hast.

Du lernst:

• Was buildx wirklich macht
• Warum Emulation langsam sein kann
• Welche Dependencies native Binaries mitbringen
• Warum offizielle Base Images meistens mehrere Architekturen unterstützen
• Warum "works on my machine" oft "works on my CPU" heißt

Bonus: Bau dieselbe App mit GitHub Actions und vergleich lokale Build-Zeit mit CI.

3. Zerleg und repariere ein Docker Compose Network

Docker Networking wirkt simpel, bis es das nicht mehr tut.

Bau eine Compose App mit drei Services:

• web
• api
• postgres

Dann mach sie absichtlich kaputt.

Beispiel:

services:
  web:
    image: nginx:1.29
    ports:
      - "8080:80"

  api:
    build: ./api
    environment:
      DATABASE_URL: postgres://postgres:postgres@localhost:5432/app

  postgres:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: app

Der Bug ist subtil, wenn Docker neu für dich ist: localhost im api Container zeigt auf den api Container selbst, nicht auf Postgres. Der Service Name ist der Hostname:

postgres://postgres:postgres@postgres:5432/app

Mach danach weiter:

• Entferne einen Port und schau, was zwischen Containern trotzdem erreichbar ist
• Füg ein eigenes Network hinzu
• Starte docker network inspect
• Füg einen Healthcheck für Postgres hinzu
• Lass die API sauber auf die Datenbank warten

Dieses Projekt spart dir später Stunden. Networking Bugs sind der Moment, in dem Docker nicht mehr niedlich wirkt.

4. Starte unsicheren Code und versuch, ihn einzusperren

Stell dir vor, deine App lässt User Code hochladen und in einem Container ausführen. Klingt nützlich. Ist auch ein bisschen gruselig.

Bau einen winzigen Runner Service, der ein hochgeladenes Script in einem Container ausführt. Dann mach ihn Schritt für Schritt sicherer.

Teste zum Beispiel:

• Als non-root User laufen
• Linux Capabilities droppen
• Filesystem read-only machen
• CPU und Memory limitieren
• Privilege Escalation verhindern
• Temporäres Working Directory nutzen
• Docker Socket nicht mounten

Flags zum Ausprobieren:

docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --memory=256m \
  --cpus=0.5 \
  --tmpfs /tmp:rw,noexec,nosuid,size=16m \
  --user=1000:1000 \
  alpine:3.22 \
  sh -c 'id && touch /tmp/test'

Dann versuch, dein eigenes Setup zu knacken.

Dabei lernst du eine unangenehme, aber wichtige Sache: Docker ist eine Container Runtime, keine vollständige Sandbox für feindlichen Code. Du kannst Risiko reduzieren, aber ernsthaftes Untrusted-Code-Execution braucht stärkere Isolation und ein echtes Threat Model.

5. Ship einen Container vom Laptop in Production

Das letzte Projekt ist simpel: Deploy etwas Echtes.

Kein Toy Container, der "hello world" ausgibt. Eine kleine App mit:

• Production Dockerfile
• Healthcheck
• Environment Variables
• Logs nach stdout
• Persistent Volume, falls nötig
• Datenbankverbindung, falls nötig
• Klarem Update-Weg

Bau sie lokal:

docker build -t my-app:2026 .
docker run --rm -p 3000:3000 my-app:2026

Dann deploy dieselbe App irgendwo außerhalb deines Laptops. Nutze einen VPS mit Docker Compose, Kubernetes, wenn du Cluster üben willst, oder Sliplane, wenn du Docker Deployments ohne Server-Wartung willst.

Dieses Projekt verbindet alles andere. Du merkst, ob dein Image zu groß ist, ob Config hardcoded ist, ob Logs helfen, ob deine App sauber beendet und ob dein "Production" Command wirklich funktioniert.

Bonus-Projekt: Lass die Docker CLI für einen Build weg

Docker ist das freundliche Frontend. Darunter liegen BuildKit, containerd, runc, OCI Images, Registries und viele Specs.

Für einen Nachmittag: Nimm nicht den normalen Weg.

• Bau mit buildctl
• Inspecte ein OCI Image Layout
• Push in eine Registry ohne docker push
• Lies das Image Manifest
• Vergleich den Digest lokal und remote

Du brauchst das nicht jeden Tag. Aber wenn du die Schichten unter Docker einmal gesehen hast, wird Debugging viel leichter.

Fazit

Wenn du diese Projekte durchziehst, fühlt sich Docker weniger wie eine Black Box an.

Du verstehst, warum Builds langsam sind, warum Images groß werden, warum Networking bricht, warum Security Flags wichtig sind und was sich ändert, wenn ein Container deinen Laptop verlässt.

Das ist der eigentliche Skill. Nicht Commands auswendig lernen. Sondern verstehen, was passiert, wenn der Command dich anlügt.