Docker für WordPress: Warum isolierte Container alles verändern

Herkömmliches WordPress-Hosting platziert mehrere Websites auf einem Server. Sie teilen sich PHP, sie teilen sich den Dateisystemzugriff und oft auch einen Datenbankserver. Das ist in Ordnung, bis es das nicht mehr ist – und wenn es das nicht mehr ist, ist es ein ernstes Problem.

PAGEnza stellt jede WordPress-Website in ihrem eigenen Docker-Container bereit. Dieser Beitrag erklärt, was das in der Praxis bedeutet und warum es für Agenturen, die mehrere Kunden-Websites verwalten, wichtig ist.

Das Problem des Shared Hostings

Auf einem typischen Shared-Hosting-Plan oder sogar einem einfachen VPS mit mehreren WordPress-Installationen:

Ressourcenkonflikte: Eine Website mit einem Traffic-Anstieg verlangsamt jede andere Website auf dem Server. Ein schlecht optimiertes Plugin auf Website A beeinträchtigt die Leistung von Website B.

Sicherheitsübertragung: Wenn eine WordPress-Installation kompromittiert wird – durch ein anfälliges Plugin, ein schwaches Passwort oder eine veraltete Kernversion –, kann ein Angreifer, der Zugriff auf das Dateisystem erhält, oft Dateien von anderen Websites auf demselben Server lesen.

PHP-Versionskonflikte: Website A benötigt PHP 7.4 für ein altes Plugin. Website B benötigt PHP 8.2 für ein neueres. Auf Shared Hosting wählt man eine.

Datenbankzugriff: Gemeinsame Datenbankserver bedeuten, dass eine falsch konfigurierte Benutzerberechtigung die Daten anderer Websites offenlegen kann.

Docker-Container lösen all diese Probleme auf der Infrastrukturebene.

Was ein Container tatsächlich ist

Ein Docker-Container ist ein leichtgewichtiger, isolierter Prozess, der über ein eigenes:

• Dateisystem (der Container kann keine Dateien außerhalb seiner Grenzen sehen)
• Netzwerk-Stack (eigene IP-Adresse, eigene Ports)
• Prozessraum (er kann die Prozesse anderer Container nicht sehen)
• Ressourcenlimits (CPU- und Speichergrenzen)

Er teilt sich den Host-Kernel mit anderen Containern, aber alles oberhalb des Kernels ist isoliert. Es ist keine vollständige virtuelle Maschine – er startet in Sekunden, nicht in Minuten, und verbraucht nur einen Bruchteil der Ressourcen.

Für WordPress läuft ein einzelner Container: Nginx, PHP-FPM und WordPress-Dateien. Die Datenbank läuft in einem separaten Container, der nur mit dem spezifischen WordPress-Container verbunden ist.

Wie PAGEnza eine Website bereitstellt

Wenn Sie in PAGEnza eine neue Kunden-Website erstellen, geschieht Folgendes in unter 45 Sekunden:

1. Ein neuer Docker-Container wird aus einem Basis-WordPress-Image gestartet.
2. WordPress wird mit einer frischen Datenbank auf der gemeinsamen MariaDB-Instanz konfiguriert (isoliert durch die Anmeldedaten des Containers).
3. Das PAGEnza-Plugin wird automatisch installiert und aktiviert.
4. Ein Nginx-Virtual-Host wird mit dem Subdomain des Kunden konfiguriert.
5. SSL wird über Let's Encrypt ausgestellt.
6. Der Container wird im Reverse-Proxy mit den richtigen Routing-Regeln registriert.

Der Kunde erhält eine URL wie clientname.pagenza.com, die 45 Sekunden nach dem Klicken auf „Website erstellen“ live ist. Keine manuelle Serverkonfiguration, kein SSH, keine Wartezeit für DNS (für die Subdomain – die DNS-Propagation für benutzerdefinierte Domains ist separat).

Container-Isolation in der Praxis

Speicherlimits: Jeder Container hat eine konfigurierbare Speicherbegrenzung. Wenn ein fehlerhaftes Plugin auf der Website eines Kunden zu einem Speicheranstieg führt, kann es nicht den anderen Containern zugewiesenen Speicher verbrauchen. Die Website kann sich verlangsamen oder einen 503-Fehler zurückgeben – aber andere Kunden werden nicht beeinträchtigt.

Dateisystem-Isolation: Die WordPress-Dateien von Kunde A sind für den Container von Kunde B vollständig unsichtbar. Ein kompromittiertes Plugin auf der Website von Kunde A hat keinen Zugriff auf die Dateien von Kunde B.

Netzwerk-Isolation: Container kommunizieren nur über definierte Netzwerkbrücken. Der Datenbankcontainer für Kunde A akzeptiert nur Verbindungen vom WordPress-Container von Kunde A – nicht von anderen Containern im System.

PHP pro Container: Da jeder Container seine eigene PHP-FPM-Instanz ausführt, können Sie unterschiedliche PHP-Versionen für verschiedene Kunden ausführen. Das Legacy-Plugin von Kunde A, das PHP 7.4 benötigt, läuft problemlos neben dem modernen Stack von Kunde B auf PHP 8.2.

Benutzerdefinierte Domains

Die Standardeinrichtung gibt jedem Kunden eine *.pagenza.com-Subdomain. Für Kunden, die ihre eigene Domain wünschen, ist der Prozess:

1. Der Kunde verweist den A-Record seiner Domain auf die PAGEnza-Server-IP.
2. Im PAGEnza-Dashboard geben Sie die benutzerdefinierte Domain ein.
3. Die Reverse-Proxy-Konfiguration wird automatisch aktualisiert.
4. SSL wird für die benutzerdefinierte Domain über Let's Encrypt ausgestellt.

Die WordPress-Optionen siteurl und home werden entsprechend aktualisiert. Aus Sicht des Kunden funktioniert seine Website einfach unter seiner Domain – keine Weiterleitung, keine für Besucher sichtbare Subdomain.

Was das für Agenturen bedeutet

Der praktische Nutzen für Agenturen, die mehrere Kunden-Websites betreiben:

Onboarding-Geschwindigkeit: Die Bereitstellung einer neuen Kunden-Website dauert weniger als eine Minute. Keine Server-Einrichtung, kein cPanel, keine manuelle WordPress-Installation.

Kunden-Trennung: Jede Kunden-Website ist wirklich isoliert. Ein Kunde, der ein problematisches Plugin installiert, beeinträchtigt nur seine eigene Website.

Skalierbarkeit: Das Hinzufügen eines neuen Kunden erfordert nicht die Bereitstellung eines neuen Servers. Die Container-Infrastruktur skaliert auf die Kapazität des Hosts, und das Hinzufügen weiterer Kapazitäten ist eine Frage des Hinzufügens weiterer Host-Knoten.

Notfallwiederherstellung: Da jede Website containerisiert ist, erfolgt die Sicherung und Wiederherstellung auf Container-Ebene. Die Wiederherstellung der Website eines einzelnen Kunden beeinträchtigt keine anderen Kunden.

Der Nachteil ist, dass Container-Hosting pro Website mehr kostet als Shared Hosting. Aber für Agenturen, bei denen die Zuverlässigkeit der Website und die Kunden-Trennung nicht verhandelbar sind, rechnet sich die Wirtschaftlichkeit – insbesondere wenn die Einsparungen bei der Bereitstellungszeit berücksichtigt werden.