Docker Betrieb

Docker-Betrieb

← Home · Zurück: Ports-und-Netzwerk

Das Repo hat zwei Betriebszweige: den systemd-Nativpfad (Hauptpfad, alle Skripte und Timer zielen darauf — siehe systemd-Referenz) und einen optionalen Docker-Zweig unter docker/. Diese Seite erklärt den Docker-Zweig 1:1 anhand der dortigen Dateien.

Wann Docker, wann systemd

Kriterium	systemd (Repo-Hauptpfad)	Docker (optionaler Zweig)
Repo-Unterstützung	Vollständig: alle 12 Skripte, Timer, Watchdog, Rollback	Nur docker-compose.yml + .env.docker.example
Isolation	Server läuft als eigener Systemuser	Container mit eigenem Namensraum, restart: unless-stopped
Einstiegshürde	make install + systemd-README	Vertraut, wenn Docker ohnehin vorhanden ist
Config-Pipeline	.env + Templates → envsubst → ini (siehe ENV-Variablen)	Image-bringt-eigene-Config-Logik mit (Heuristik, siehe unten)

Empfehlung (Heuristik dieses Wikis): Für den dauerhaften Coop-Betrieb ist der systemd-Pfad der Pfad der geringsten Überraschungen, weil Monitoring, Backups und Update-Rollback darauf gebaut sind. Docker lohnt sich, wenn der Host ohnehin container-zentriert administriert wird — oder im GCP-Failover, der genau dieses Compose-File nutzt (siehe GCP-Failover).

Setup

docker-compose.yml (1:1)

services:
  zomboid:
    image: danixu86/project-zomboid-dedicated-server:latest
    container_name: pz-server
    restart: unless-stopped
    env_file: .env
    environment:
      - SERVER_NAME=${SERVER_NAME:-servertest}
      - MAX_PLAYERS=${MAX_PLAYERS:-8}
      - XMX=${RAM_XMX:-12G}
    ports:
      - "16261:16261/udp"
      - "16262:16262/udp"
      - "27015:27015/tcp"
    volumes:
      - pz-data:/data/Zomboid
      - ../backups:/backups
    healthcheck:
      test: ["CMD-SHELL", "pgrep -f ProjectZomboid || exit 1"]
      interval: 60s
      timeout: 10s
      retries: 3

volumes:
  pz-data:

Im Einzelnen:

• Image: danixu86/project-zomboid-dedicated-server:latest (Fremd-Image, nicht Teil des Repos — Updates des Images kommen vom Maintainer, nicht von SteamCMD; Heuristik: vor Produktivbetrieb das Image auf Funktionsfähigkeit mit aktueller B42 prüfen).
• Ports: 16261/udp + 16262/udp (Spiel, wie im systemd-Pfad; Details und den TCP/UDP-Quellenkonflikt siehe Ports-und-Netzwerk) und 27015/tcp (RCON, Repo-Default RCON_PORT=27015).
• env_file .env + drei explizite env-Variablen mit Fallbacks: SERVER_NAME (Default servertest), MAX_PLAYERS (Default 8), XMX (aus RAM_XMX, Default 12G) — alle Defaults (Repo-Default, 1:1 aus der Compose-Datei).
• Volumes: benanntes Volume pz-data auf /data/Zomboid (Spielstand überlebt Container-Neubau) und ../backups nach /backups (Bind-Mount in das backups/-Verzeichnis des Repos). Dieselben tar.gz liegen auch dem systemd-Pfad zur Verfügung — aber NUR, wenn BACKUP_DIR in der .env auf <repo>/backups zeigt; der Repo-Default ist /opt/pzserver/backups (Repo-Default, 1:1 aus .env.example und lib/common.sh), der außerhalb des Repos liegt.
• Healthcheck: pgrep -f ProjectZomboid alle 60 s, Timeout 10 s, nach 3 Fehlversuchen gilt der Container als unhealthy (1:1). Das ist NUR eine Docker-Statusanzeige — kein Watchdog, der neu startet; restart: unless-stopped startet nur bei beendetem Prozess neu.

.env.docker.example (1:1 — alle 5 Variablen)

SERVER_NAME=servertest
MAX_PLAYERS=8
RAM_XMX=12G
ADMIN_PASSWORD=CHANGE_ME
SERVER_PASSWORD=CHANGE_ME

Werte sind Beispielwerte der Vorlage (Repo-Vorlage, 1:1); CHANGE_ME sind Platzhalter. Weitere Variablen (RCON, Discord, …) entnimmt das Compose dem per env_file eingebundenen .env — die vollständige Referenz steht in ENV-Variablen.

Start und Stop

cd docker/
cp .env.docker.example .env     # und Werte setzen
docker compose up -d            # Start im Hintergrund
docker compose ps               # Status (inkl. Health-State)
docker compose logs -f          # Live-Logs des Containers
docker compose down             # Stop (Volume pz-data bleibt erhalten)

Unterschiede zum systemd-Pfad

Ehrliche Gegenüberstellung — die Repo-Skripte zielen auf den systemd-Pfad; im Docker-Pfad gelten Container-eigene Mechanismen. Was nicht direkt aus docker-compose.yml hervorgeht, ist als Heuristik gelabelt:

Thema	systemd-Pfad	Docker-Pfad
Config erzeugen	render-config.sh (envsubst aus Template) schreibt die ini	Kein Rendern im Repo-Umfang; das Image verarbeitet SERVER_NAME/MAX_PLAYERS/XMX selbst (Heuristik: Config-Kontrolle entspricht damit nicht dem Server-Konfiguration-Template)
Watchdog/Crash-Recovery	monitor.sh per Cron + .planned-stop	restart: unless-stopped — kein planned-stop-Konzept, kein Discord-Alert (Heuristik)
Backups	backup.sh per Timer + Rotation + Discord	Kein Backup-Job im Compose; Backup-Lauf des Hosts kann über das Bind-Mount ../backups zugreifen (Heuristik: Cron des Hosts ruft weiterhin make backup; landet nur im eingebundenen Verzeichnis, wenn BACKUP_DIR auf <repo>/backups zeigt — Default ist /opt/pzserver/backups)
Updates	update.sh mit Healthcheck + Auto-Rollback	docker compose pull + up -d zieht ein neues Image; kein Rollback-Mechanismus (Heuristik)
Monitoring/Alerts	healthcheck.sh + Discord-Notify	Docker-Healthcheck (nur Prozess), keine Discord-Anbindung (Heuristik)
RAM setzen	RAM_XMX in .env → systemd ExecStart -Xmx	XMX=${RAM_XMX} als Container-env (1:1 aus Compose)

Faustregel (Heuristik): Im Docker-Pfad ersetzt Docker-Boardmittel (restart-Policy, Healthcheck, pull) die Repo-Automatik — die Qualität der Alterung (Rollback, Discord) bleibt dabei auf der Strecke. Wer beides will, läuft die Skripte des Hosts gegen die gemounteten Verzeichnisse weiter.

Wichtige Hinweise

• Mods im Docker: Das Repo lädt Workshop-Mods nicht automatisch (install.sh/update.sh enthalten keinen Workshop-Download; manueller SteamCMD-Weg in der SteamCMD-Referenz). Im Docker-Pfad gilt: Was das Image an Mod-Support mitbringt, verwaltet es im Volume pz-data (Heuristik — aus dem Compose allein ist kein Mod-Download-Mechanismus ersichtlich). Die deklarative Modliste mods.yaml des Repos wirkt nur im systemd-Pfad über make mods (siehe Mods-Referenz).
• GCP-Failover nutzt genau dieses Compose: Das Failover-Startup-Skript klont das Repo, legt /data/Zomboid aus dem neuesten Backup an und fährt docker compose -f docker/docker-compose.yml up -d mit SLOTS=3 XMX=8G hoch (1:1 aus gcp/startup-script.sh). Details: GCP-Failover.
• Ports und Firewalls unterscheiden sich nicht vom systemd-Pfad — Freigaben und der 16261-Protokollkonflikt stehen in Ports-und-Netzwerk.

---

Weiter: GCP-Failover (dort läuft Docker im Notfall) · Wartung-und-Automatik · ENV-Variablen