Was ist Docker und warum sollten Entwickler es lernen?

Docker taucht ständig in Stellenausschreibungen und Setup-Anleitungen auf, und wenn du dich noch nie mit Containern beschäftigt hast, kann es sich anfühlen wie eine Mauer, die du erklimmen musst, bevor du echten Code schreiben darfst. Es ist nicht so kompliziert, wenn du erst mal die Fachbegriffe verstanden hast.

Was ein Container wirklich ist

Ein Container packt deine Anwendung zusammen mit allem, das sie zum Laufen braucht: den Code, die Runtime, die Systembibliotheken und die Konfigurationsdateien. Es ist keine virtuelle Maschine. Eine VM virtualisiert ein ganzes Betriebssystem, Kernel inklusive, was bedeutet, dass das Hochfahren eine Minute dauern kann und ein paar Gigabyte RAM verbraucht. Ein Container teilt sich den Kernel der Host-Maschine und isoliert nur den Prozess, daher startet er in unter einer Sekunde und verbraucht typischerweise nur Dutzende von Megabyte statt Gigabyte.

Dieser Unterschied ist der Grund, warum Docker die lokale Entwicklung und CI-Pipelines so schnell erobert hat. Du kannst auf einem Laptop eine Postgres-Datenbank, einen Redis-Cache und deinen App-Server starten, ohne sie direkt auf deinem OS zu installieren.

Die wichtigsten Konzepte

Es gibt vier Begriffe, die das meiste abdecken, womit du täglich zu tun hast:

• Image: eine schreibgeschützte Vorlage, die aus einem Dockerfile gebaut wird. Denk daran als ein Schnappschuss eines Dateisystems plus Metadaten darüber, wie man es ausführt.
• Container: eine laufende Instanz eines Image. Du kannst Container starten, stoppen und löschen, ohne das Image zu beeinflussen, von dem sie stammen.
• Dockerfile: eine Textdatei mit Anweisungen zum Erstellen eines Image, Zeile für Zeile.
• Registry: der Ort, wo Images gespeichert und heruntergeladen werden, meist Docker Hub.

Ein minimales Dockerfile für eine Node.js-App sieht so aus:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Bau es mit docker build -t my-app . und führe es aus mit docker run -p 3000:3000 my-app. Das -p-Flag mappt einen Port auf deiner Maschine auf einen Port innerhalb des Containers, so erreichst du die App tatsächlich von deinem Browser aus.

Befehle, die du ständig benutzt

Eine Handvoll Befehle deckt den meisten täglichen Betrieb ab:

• docker ps — listet laufende Container auf
• docker ps -a — listet alle Container auf, auch gestoppte
• docker images — listet Images auf deiner Maschine auf
• docker logs <container> — zeigt die Ausgabe eines laufenden oder abgestürzten Containers
• docker exec -it <container> sh — öffnet eine Shell in einem laufenden Container
• docker rm / docker rmi — räumt Container und Images auf, die du nicht mehr brauchst

Das letzte Paar ist wichtiger als viele denken. Docker lässt gerne Speicherplatz in alten Images und gestoppten Containern verschwinden. docker system prune gelegentlich auszuführen, gibt überraschend viel Platz frei.

Warum docker-compose den Workflow verändert

Die meisten echten Projekte brauchen mehr als einen Container: einen App-Server, eine Datenbank, vielleicht einen Cache. docker run-Befehle für jeden einzelnen aufzuschreiben wird schnell langweilig. docker-compose.yml lässt dich den ganzen Stack in einer Datei definieren:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: devpassword
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Führe docker compose up aus und beide Services starten zusammen, vernetzt so, dass web db über den Service-Namen erreichen kann. Das ist die Einrichtung, die du in fast jeder README von Open-Source-Repos siehst, und wenn du das verstehst, kannst du ein Projekt klonen und es in Minuten zum Laufen bringen, statt Postgres, Redis und was auch immer die App sonst noch braucht, manuell zu installieren.

Wo Anfänger früh hängenbleiben

Volumes verwirren fast jeden am Anfang. Ohne ein Volume verschwindet alles, das in einem Container geschrieben wird, wenn der Container entfernt wird, das ist ein Problem für Datenbanken. Der volumes-Abschnitt in der Compose-Datei oben mappt ein benanntes Volume auf einen Pfad innerhalb des Containers, so dass Daten Neustarts überstehen.

Ein anderes häufiger Fehler ist, node_modules oder .git in das Image zu kopieren, weil es keine .dockerignore-Datei gibt. Füge eine hinzu, genau wie eine .gitignore:

node_modules
.git
.env

Das hält Builds schneller und Images kleiner, was wichtig wird, wenn du Images zu einer Registry pushst oder zu Kubernetes bereitstellst.

Wohin es nach den Grundlagen geht

Wenn das Bauen und Ausführen von Containern sich normal anfühlt, sind die nächsten nützlichen Skills Multi-Stage Builds für kleinere Production-Images, das Verstehen von Docker-Netzwerkmodi und das Lesen einer docker inspect-Ausgabe, wenn etwas nicht verbunden wird. Nichts davon ist schwer, es ist nur unvertraut beim ersten Mal.

Für mehr über die Containerisierung von echten Anwendungen und deren Verbindung mit Cloud-Deployment-Pipelines, schau dir die DevOps- und Cloud-Segmente auf Korra Studio an.