Docker lernen: Container im Arbeitsalltag

Docker ist anfangs verblüffend einfach: ein kurzer Befehl, schon läuft ein Container. Im Arbeitsalltag zeigt sich dann schnell, ob du die Grundlagen wirklich verstanden hast: Was ist der Unterschied zwischen Image und Container, wie baust du ein sauberes Dockerfile, wie speicherst du Daten dauerhaft, wie verbindest du Services und wie organisierst du das Ganze reproduzierbar?

Images vs. Container: das Fundament verstehen

Viele Probleme mit Docker entstehen, weil Images und Container durcheinandergeraten. Halte dir die Rollen klar auseinander:

• Ein Image ist ein unveränderliches Abbild, so etwas wie ein Installationsstand deines Services.
• Ein Container ist eine laufende Instanz dieses Images mit eigenem Dateisystem, eigenen Prozessen und eigenem Zustand.

Typischer Ablauf:

1. Du baust ein Image, zum Beispiel aus einem Dockerfile.
2. Du startest aus diesem Image einen Container.
3. Der Container bekommt Konfiguration, Daten, Logs.
4. Wenn du den Container löschst, sind seine internen Änderungen weg, das Image bleibt.

Damit ergeben sich ein paar Best Practices:

• Baue Images reproduzierbar und versioniert, etwa mit Tags wie meine-app:1.3.0.
• Behandle Container als kurzlebig. Konfig und Daten gehören nach außen, zum Beispiel in Volumes oder Umgebungsvariablen.
• Nutze docker ps, docker images und docker inspect, um zu verstehen, was gerade wirklich läuft.

Ein typisches Missverständnis: Du änderst Dateien im Container, alles läuft, dann startest du den Container neu und deine Änderungen sind weg. Das ist kein Bug, sondern genau der Punkt. Änderungen im Container sind flüchtig, Images definierst du über das Dockerfile.

Dockerfile: saubere Images bauen

Das Dockerfile ist deine Bauanleitung für Images. Hier entscheidet sich, ob deine Container später leichtgewichtig, sicher und wartbar sind oder zum Problem werden.

Ein einfaches Beispiel für eine Webanwendung:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .

ENV NODE_ENV=production
EXPOSE 3000

CMD ["node", "server.js"]

Wichtige Prinzipien:

• FROM: Wähle ein schlankes Basis-Image, etwa alpine-Varianten, wenn es zu deinem Stack passt.
• Schichten minimieren: Fasse zusammengehörige Schritte in einem RUN zusammen, um die Anzahl der Layer gering zu halten.
• Kein Build-Müll im finalen Image: Entferne temporäre Dateien, Caches und Tools, die nur beim Bauen gebraucht werden.
• Konfiguration über Umgebungsvariablen (ENV) statt hart codierter Pfade oder Zugangsdaten.

Für komplexere Setups lohnt sich ein Multi-Stage-Build, zum Beispiel für eine Go-Anwendung:

FROM golang:1.22-alpine AS build
WORKDIR /src
COPY . .
RUN go build -o app

FROM alpine:3.20
WORKDIR /app
COPY --from=build /src/app .
CMD ["./app"]

Damit trennst du Build-Umgebung und Laufzeitumgebung. Das Ergebnis ist kleiner und enthält nur das Nötigste.

Typische Stolperfallen im Alltag:

• Du baust Images „mal schnell“ interaktiv und vergisst, wie du dahin gekommen bist.
• Du installierst Tools im Container, die du eigentlich nur für Debugging brauchst.
• Du packst Konfiguration und Secrets direkt ins Image.

Besser: Alles, was reproduzierbar sein soll, ins Dockerfile. Alles, was sich je nach Umgebung ändert, über Umgebungsvariablen, Config-Files und Secrets von außen.

Volumes: Daten über Container-Lebensdauer hinaus sichern

Container sind wegwerfbar, deine Daten nicht. Volumes sind der Standardweg, um Daten dauerhaft zu speichern oder mit dem Host zu teilen.

Es gibt grob drei Varianten:

• Anonyme Volumes: docker run -v /var/lib/mysql mysql:latest
• Benannte Volumes: docker run -v dbdata:/var/lib/mysql mysql:latest
• Bind Mounts (Host-Pfad): docker run -v /home/user/app:/app node:22-alpine

Für den Arbeitsalltag sind benannte Volumes besonders sinnvoll:

• Sie werden von Docker verwaltet.
• Sie sind unabhängig vom Host-Dateisystem.
• Du kannst sie einfach sichern und auf andere Hosts übertragen.

Beispiele für sinnvolle Volume-Nutzung:

• Datenbanken: /var/lib/postgresql/data, /var/lib/mysql
• Logs: Spezielle Log-Verzeichnisse, wenn du sie außerhalb sammeln willst
• Konfiguration: Dateien, die du je nach Umgebung anpassen musst

Bind Mounts sind praktisch in der Entwicklung, etwa um deinen Quellcode direkt im Container zu nutzen. In der Produktion sind sie oft fehleranfälliger, weil du Pfade und Berechtigungen auf dem Host sauber im Griff haben musst.

Wichtige Punkte für Admins:

• Plane, wo deine Volumes liegen und wie du sie sicherst.
• Nutze docker volume ls und docker volume inspect, um Überblick zu behalten.
• Lösche alte Volumes bewusst, nicht pauschal mit docker system prune --volumes, sonst fehlen dir plötzlich Daten.

Netzwerke: Container sinnvoll verbinden

Standardmäßig landet jeder Container im bridge-Netzwerk, wenn du nichts anderes angibst. Für alles, was ein bisschen komplexer ist als „ein Service“, solltest du eigene Netzwerke definieren.

Ein eigenes Bridge-Netzwerk:

docker network create webnet
docker run -d --name web --network webnet nginx:alpine
docker run -d --name api --network webnet my-api:1.0.0

Vorteile:

• Container können sich per Namen erreichen, zum Beispiel http://api:8080.
• Du kannst Gruppen bilden, etwa ein internes Backend-Netz und ein öffentliches Frontend-Netz.
• Du minimierst Port-Kollisionen auf dem Host.

Typische Netzwerk-Typen in Docker:

• bridge: Standard für Ein-Host-Setups.
• host: Container teilt sich den Netzwerk-Stack mit dem Host, nützlich für spezielle Fälle, aber mit Vorsicht zu genießen.
• none: Kein Netzwerk, für isolierte Jobs oder spezielle Sicherheitsanforderungen.

Praxisbeispiele:

• Ein Nginx-Container als Reverse Proxy im Netzwerk frontend, die Backend-Services im Netzwerk backend. Der Proxy hängt in beiden Netzwerken und vermittelt.
• Eine Entwicklungsumgebung, in der du Datenbanken in einem eigenen Netzwerk zusammenfasst und nur ausgewählte Ports nach außen öffnest.

Nutze docker network inspect, um zu sehen, welche Container in welchem Netzwerk hängen und wie die IPs verteilt sind.

Docker Compose: Mehrere Container als Stack verwalten

Sobald du mehr als einen Container pro Anwendung hast, wird das reine Arbeiten mit docker run mühsam. Docker Compose beschreibt deine Services deklarativ in einer docker-compose.yml.

Ein typischer Stack für eine Webanwendung:

version: "3.9"

services:
 app:
 image: meine-app:1.3.0
 ports:
 - "8080:3000"
 environment:
 - NODE_ENV=production
 - DATABASE_URL=postgres://app:secret@db:5432/app
 depends_on:
 - db

 db:
 image: postgres:16
 environment:
 - POSTGRES_DB=app
 - POSTGRES_USER=app
 - POSTGRES_PASSWORD=secret
 volumes:
 - app-db:/var/lib/postgresql/data

volumes:
 app-db:

Vorteile von Compose:

• Ein Befehl zum Starten: docker compose up -d.
• Ein Befehl zum Stoppen und Aufräumen: docker compose down.
• Alle relevanten Einstellungen sind versioniert in einer Datei.
• Dienste kennen sich per Servicenamen, hier db.

Für Admins und Entwickler im Team ist Compose eine Art minimale Orchestrierung auf Ein-Host-Basis. Du bekommst reproduzierbare Stacks auf deinem Laptop, auf einem Testserver oder in einer kleinen Umgebung in deinem Rechenzentrum.

Ein paar Praxis-Tipps:

• Trenne Entwicklungs- und Produktionskonfiguration, etwa mit mehreren Compose-Dateien (docker-compose.dev.yml, docker-compose.prod.yml).
• Nutze .env-Dateien für sensible oder umgebungsspezifische Variablen.
• Beschreibe in README oder interner Doku, wie man den Stack startet, aktualisiert und debuggt.

Aktuelle Termine und passende Kurse zu Docker und Container-Technologien findest du bei cmt.de.

Registry: Images verteilen und versionieren

Eine Registry ist das Pendant zu einem Paket-Repository, nur für Container-Images. Docker Hub ist die bekannteste öffentliche Registry, in Unternehmen kommen häufig private Registries zum Einsatz, etwa:

• Selbst gehostete Docker Registry
• GitLab Container Registry
• GitHub Container Registry
• Registries großer Cloud-Anbieter wie Azure, AWS oder Google Cloud

Der Ablauf im Alltag:

1. Du baust lokal ein Image: docker build -t registry.example.com/meine-app:1.3.0 .
2. Du meldest dich an der Registry an: docker login registry.example.com
3. Du pushst das Image: docker push registry.example.com/meine-app:1.3.0
4. Auf anderen Hosts holst du es mit docker pull.

Wichtige Regeln:

• Nutze sinnvolle Tags, etwa 1.3.0, 1.3, latest für unterschiedliche Zwecke.
• Ändere nicht stillschweigend den Inhalt hinter einem Tag, ohne Versionsnummer zu erhöhen, sonst wird Debugging zur Qual.
• Definiere klar, welche Images produktiv sind und welche experimentell.

Für Admins in München oder anderswo ist eine eigene Registry oft der Punkt, an dem Docker im Unternehmen wirklich ankommt. Du kannst Builds aus der CI-Pipeline direkt in die Registry schieben und von dort auf Test- und Produktionssysteme verteilen.

Praxisnutzen für Admins und Entwickler

Wenn du Images, Container, Volumes, Netzwerke, Compose und Registry im Griff hast, ergeben sich im Alltag ganz konkrete Vorteile:

Für Systemadministration:

• Standardisierte Deployments: Ein neues System bekommt Docker, Registry-Zugriff und Compose-Datei, fertig.
• Schnellere Rollbacks: Altes Image aus der Registry ziehen, Container neu starten, Rollback erledigt.
• Bessere Isolation: Dienste laufen getrennt, Abhängigkeiten sind im Container, Konflikte auf dem Host werden seltener.

Für Entwicklung:

• Einheitliche Entwicklungsumgebung: „Es läuft bei mir“ wird viel seltener zum Problem, weil alle denselben Stack per Compose starten.
• Leichtere Tests: Du kannst schnell verschiedene Versionen eines Services parallel starten.
• Weniger manuelle Installationsschritte: Datenbanken, Message-Broker und andere Infrastruktur laufen als Container.

Gerade in gemischten Teams aus Admins und Entwicklern lohnt es sich, ein gemeinsames Verständnis dieser Docker-Grundlagen aufzubauen. Die Grenze zwischen „Betrieb“ und „Entwicklung“ verläuft dann weniger entlang von Werkzeugen, sondern entlang von Verantwortung: Wer baut das Image, wer betreibt es, wer überwacht es.

Fazit: Docker bewusst als Werkzeug einsetzen

Docker ist kein Zaubertrick, sondern ein solides Werkzeug. Wenn du die Bausteine Images, Container, Dockerfile, Volumes, Netzwerke, Compose und Registry klar auseinanderhältst und bewusst einsetzt, wird aus dem ersten „docker run“ ein verlässlicher Teil deines Arbeitsalltags.

Starte mit kleinen, überschaubaren Setups, dokumentiere deine Dockerfiles und Compose-Dateien und gewöhne dir an, Container als kurzlebig und Images als klar versioniert zu betrachten. Dann profitierst du sowohl als Admin als auch als Entwickler von reproduzierbaren, gut wartbaren Umgebungen, die sich von deinem Laptop bis zum Rechenzentrum in München sauber durchziehen.