Compose-Dateien schreiben — dambmann.cloud

Worum geht’s

Im HomeLab und in der Systemintegration werden Dienst-Stacks deklarativ in einer docker-compose.yml beschrieben. Eine solche Datei lesen, verstehen und selbst schreiben zu können, ist die Grundvoraussetzung, um Multi-Service-Anwendungen reproduzierbar zu deployen und sauber zu versionieren — statt Container per Hand mit langen docker run-Zeilen zu starten.

Konzept

Eine Compose-Datei ist YAML — Einrückung mit Leerzeichen (keine Tabs!) bestimmt die Struktur. Die wichtigsten Bausteine je Service:

image: — welches Image (nginx:1.27, postgres:16). Tag fixieren statt latest, sonst ist der Stack nicht reproduzierbar.
ports: — "8080:80" als host:container. Nur hier gelistete Ports sind vom Host erreichbar; der Rest bleibt intern im Compose-Netz.
volumes: — Persistenz: daten:/var/lib/app (benanntes Volume) oder ./config:/etc/app (Bind-Mount eines Host-Pfads).
environment: — Konfiguration als Variablen (POSTGRES_PASSWORD=...).
depends_on: — Startreihenfolge: erst die Abhängigkeit, dann der Dienst.
Servicename = DNS: Container erreichen sich über den Servicenamen (db:5432), nie über localhost.

Grundgerüst:

services:
  web:
    image: nginx:1.27
    ports: ["8080:80"]
    depends_on: [db]
  db:
    image: postgres:16
    volumes: ["dbdata:/var/lib/postgresql/data"]
    environment:
      POSTGRES_PASSWORD: geheim
volumes:
  dbdata:

So ist ein Compose-File aufgebaut — jede Zeile mit ihrer Aufgabe:

docker-compose.yml

services: Wurzel — jeder Eintrag darunter ist ein Container

web: frei wählbarer Servicename (= Hostname im Netz)

image: nginx:1.27 Image + fester Tag — nie :latest in Prod

ports:

- "8080:80" Host-Port : Container-Port

volumes:

- ./html:/usr/share/nginx/html:ro Bind-Mount, :ro = nur lesen

environment:

- TZ=Europe/Berlin Konfiguration per Umgebungsvariable

depends_on: [db] Startreihenfolge — wartet NICHT auf „bereit"

restart: unless-stopped Neustart-Policy nach Absturz/Reboot

Beispiel-Fall

Gegeben: Eine App soll auf Host-Port 3000 laufen, eine Postgres-DB nutzen und ihre Daten einen Neustart überleben.

Zwei Services: app und db. app bekommt ports: ["3000:3000"].
db braucht ein Volume auf /var/lib/postgresql/data, sonst sind die Daten nach docker compose down weg.
app.environment zeigt mit DATABASE_HOST=db auf den Servicenamen.
depends_on: [db] sorgt dafür, dass die DB zuerst startet.
docker compose up -d startet beide; docker compose logs app prüft.

Lehre: Persistenz steckt im Volume, Erreichbarkeit nach außen in ports, die interne Verbindung im Servicenamen — drei verschiedene Felder, drei verschiedene Zwecke.

Anwenden

▶ Am Tool ausprobieren

Generiere einen Stack und übersetze jede Zeile in einen Satz: „Dieser Service nutzt dieses Image, veröffentlicht diesen Port, persistiert dort.” Verstehe jedes Feld, bevor du es produktiv nutzt.

Wähle im Generator einen Dienst plus eine Datenbank.
Lies in der erzeugten YAML, welche Felder ports, volumes und environment belegen.
Prüfe, ob die Indentierung konsistent mit Leerzeichen erfolgt — YAML toleriert keine Tabs.

Tool öffnen: /docker-compose ↗

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Schreibe (oder generiere und ergänze) eine Compose-Datei mit zwei Diensten, bei der die App ihre DB über den Servicenamen erreicht und die DB ein benanntes Volume nutzt. Belege im Generator, dass Port-Mapping, Volume und environment korrekt gesetzt sind, bevor du den Stack als reproduzierbar bezeichnest.

Tool öffnen: /docker-compose ↗