Skip to main content

Docker & Container-Konzept in Pterodactyl

Pterodactyl basiert konsequent auf Docker und nutzt Container nicht nur als „Verpackung“, sondern als zentrales Isolations-, Sicherheits- und Ressourcensteuerungsinstrument.

Ein korrektes Verständnis dieses Konzepts ist entscheidend, um Performance-Probleme, Sicherheitslücken und instabile Game-Server zu vermeiden.

1. Warum Docker die Grundlage von Pterodactyl ist

Docker ermöglicht Pterodactyl:

  • saubere Isolation zwischen Game-Servern
  • exakte Ressourcenbegrenzung
  • reproduzierbare Server-Umgebungen
  • kontrollierte Ausführung fremden Codes (Mods, Plugins)

Ohne Docker wäre ein sicherer Multi-Tenant-Betrieb faktisch nicht möglich.

2. Container ≠ klassischer Docker-Betrieb

Pterodactyl nutzt Docker bewusst anders als typische Web-Stacks:

  • keine Docker Compose Stacks
  • keine Service-Orchestrierung
  • keine langlebigen System-Container

Jeder Container repräsentiert:

genau einen Game-Server

3. Container-Lifecycle eines Game-Servers

3.1 Erstellung

  • Panel definiert Server anhand eines Eggs
  • Wings erstellt Container aus festem Image
  • Volumes werden eingebunden

3.2 Laufzeit

  • Container läuft isoliert
  • Ressourcenlimits werden kernelbasiert enforced
  • Logs werden gestreamt

3.3 Stop / Neustart

  • Graceful Stop, wenn möglich
  • Kein Persistenzverlust durch Volumes

3.4 Löschung

  • Container wird entfernt
  • Daten bleiben nur erhalten, wenn explizit konfiguriert

4. Storage-Handling

Persistente Daten werden über Docker Volumes oder Bind-Mounts bereitgestellt.

4.1 Typische Inhalte in Volumes

  • World-Daten
  • Configs
  • Mods / Plugins

4.2 Risiken

  • Langsames Host-Storage → Lag
  • Keine Backups → Datenverlust

Container selbst sind immer als flüchtig zu betrachten.

5. Netzwerk-Handling

Pterodactyl nutzt Docker-Netzwerke, kombiniert mit direktem Port-Mapping:

  • Jeder Game-Server bindet definierte Ports
  • Keine internen Service-Netzwerke

Game-Server sind per Design öffentlich erreichbar, daher ist saubere Port-Kontrolle zwingend erforderlich.

6. Ressourcenbegrenzung (kritisch)

Pterodactyl nutzt Docker cgroups für:

  • CPU-Limits
  • RAM-Limits
  • IO-Limits (indirekt)

6.1 Wichtige Realität

  • RAM-Limit ≠ RAM-Nutzung
  • CPU-Limits schützen nicht vor Lag

Game-Server reagieren extrem empfindlich auf:

  • CPU-Contention
  • IO-Wait
  • RAM-Pressure

7. Sicherheitsimplikationen

7.1 Was Docker schützt

  • Host-Dateisystem
  • Andere Game-Server

7.2 Was Docker NICHT schützt

  • Überlastung des Hosts
  • Fehlkonfigurierte Netzwerke
  • Unsichere Eggs

"Docker ist ein Werkzeug – kein Allheilmittel."

8. Performance-Fallen aus der Praxis

  • Zu viele Container auf einem Node
  • CPU-Overcommitment
  • Shared Storage mit hoher Latenz
  • Swap aktiv

Diese Fehler führen fast immer zu:

  • Tick-Lag
  • Rubberbanding
  • Server-Crashes

9. Best Practices (Venasty Systems Standard)

  • Ein Node nur für Pterodactyl
  • Keine Fremdcontainer auf Nodes
  • Realistische Limits statt Marketing-Werte
  • Storage-Performance priorisieren

10. Fazit

Das Docker-Konzept von Pterodactyl ist technisch sauber, aber kompromisslos ehrlich:

  • schlechte Hardware bleibt schlecht
  • Überbuchung bleibt Überbuchung

Wer Docker und Ressourcenmanagement versteht, kann mit Pterodactyl stabile, sichere Game-Server betreiben.

Venasty Systems betrachtet das Container-Konzept als zentrale Entscheidungsgrundlage für jede Pterodactyl-Plattform.

Back to top