Docker- vs. native PHP-Bereitstellung: Was lässt sich einfacher patchen und warten?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Docker vs Native PHP Deployment: Which Is Easier to Patch and Maintain? - Zima Store Online

Docker kann die Laufzeitumgebung einer Anwendung durch ein Image reproduzierbar machen, während natives PHP gut zu einem gepflegten Paket-Workflow des Betriebssystems passen kann. Beides kann unkompliziert sein; beides kann schwierig werden, wenn die Update-Quelle nicht mehr gepflegt wird oder die Konfiguration undokumentiert ist.

Docker ist praktisch, wenn ein gepflegtes Anwendungs-Image eine unterstützte Laufzeitumgebung und einen wiederholbaren Austauschprozess bereitstellt. Native Pakete können gut zu einem distributionsverwalteten Server passen. Halte in jedem Fall die tatsächlich laufende Revision fest und prüfe den betroffenen Dienst nach dem Update.

Wartungseinheiten vergleichen

Bereich	PHP auf Docker-Basis	Natives PHP
Update-Einheit	Gepflegtes App-Image oder benutzerdefiniertes, neu erstelltes Image	Pakete aus der Distribution oder einem gepflegten Repository
Bereitstellungsschritt	Image-Verweis ersetzen und Dienste neu erstellen	Pakete aktualisieren und betroffene Dienste neu starten
Laufzeitnachweis	Image-Digest und Prüfungen des laufenden Dienstes	Paketrevision und Prüfungen des Web-Handlers
Persistente Daten	Volumes und externe Datenbanken müssen separat gesichert werden	Dateien und Datenbanken müssen separat gesichert werden
Häufiger blinder Fleck	Neues Image heruntergeladen; alter Container läuft noch	CLI aktualisiert; Web-Worker oder anderer Zweig übersehen
Einschränkung bei der Wiederherstellung	Altes Image ist möglicherweise nicht mit migrierten Daten kompatibel	Alte Pakete sind möglicherweise nicht mit migrierten Daten kompatibel

Wann Docker die Arbeit vereinfacht

Ein gepflegtes Anwendungs-Image kann eine bekannte Laufzeitumgebung und einen festgelegten Abhängigkeitssatz bündeln und so Unterschiede zwischen Rechnern verringern. Separate Dienste können unterschiedliche kompatible PHP-Versionen verwenden, ohne dieselbe Host-Installation gemeinsam zu nutzen.

Der Betreiber muss weiterhin neue Image-Versionen im Blick behalten, bei Bedarf Pins ändern, alle relevanten Dienste neu erstellen und Volume-Zuordnungen beibehalten. Ein benutzerdefiniertes Image bringt zusätzliche Build-Verantwortung mit sich: Das Aktualisieren eines Host-Pakets erstellt dein Image nicht neu, und das Bearbeiten eines laufenden Containers ist keine dauerhafte Image-Wartung.

Die Sicherheitshinweise von Docker beziehen auch die Konfiguration in die Schutzgrenze ein. Weitreichende Host-Einbindungen, übermäßige Berechtigungen oder die Kontrolle über den Daemon können die beabsichtigte Trennung aufheben. Bewerte diese Einstellungen unabhängig vom Komfort imagebasierter Updates.

Was wird bei einem Docker-Update genau ersetzt und was bei einem nativen Update?

Bei einem Docker-Workflow wird ein Dienst durch ein Image ersetzt, das Code und Abhängigkeiten bündelt. Bei einem nativen Workflow werden Pakete aktualisiert und anschließend die relevanten Prozesse nach dem von der Distribution unterstützten Verfahren neu gestartet oder neu geladen. In beiden Fällen kann weiterhin alter Code Anfragen bedienen, wenn dieser Schritt ausgelassen wird. Die Dokumentation zum Verhalten bei der Neuerstellung mit Compose beschreibt die Container-Seite; die native Seite hängt von Ihrer Distribution und Dienstkonfiguration ab.

Image-Tags sind praktische Namen, aber nicht immer unveränderliche Kennungen. Notieren Sie nach Möglichkeit die Kennung oder den Digest des laufenden Images. Bewahren Sie bei nativen Paketen die vollständige Paketrevision des Anbieters auf und nicht nur die Upstream-PHP-Versionsnummer. So lässt sich nachvollziehen, welches Artefakt verwendet wurde, wenn später ein Problem auftritt.

Wann natives PHP gut geeignet ist

Ein einfacher Host mit einer unterstützten Distribution und einer gut verstandenen Webserverkonfiguration kann einen direkten, paketbasierten Aktualisierungspfad haben. Der Paketmanager kann eine nachvollziehbare Revision und einen Sicherheitshinweis des Anbieters bereitstellen.

Dokumentieren Sie jeden installierten Zweig, das Repository, aus dem er stammt, und den von jeder Website verwendeten Handler. Die Standard-Binärdatei der Shell muss nicht diejenige sein, die die Website bedient. Durch Backports des Anbieters kann außerdem die Paketrevision wichtiger sein als eine Versionsnummer, die nach Upstream aussieht. Starten Sie die relevanten Dienste und lang laufenden Worker nach der Bereitstellung neu.

In beiden Fällen ist das Rollback ein Problem der Anwendung

Es ist nützlich, eine ältere Image- oder Paketversion aufzubewahren, aber das ist kein vollständiger Rollback-Plan. Eine Anwendungsaktualisierung kann das Datenbankschema, die Konfiguration oder Dateiformate ändern. Wird nur die ausführbare Datei wiederhergestellt, kann der Dienst inkonsistent bleiben.

Bewahren Sie einen kompatiblen Wiederherstellungssatz auf und befolgen Sie die Wiederherstellungsdokumentation der Anwendung. Wenn Sie vorübergehend zu anfälliger Software zurückkehren müssen, halten Sie sie isoliert und arbeiten Sie auf eine behobene, kompatible Version hin. Nehmen Sie einen Dienst nicht allein deshalb wieder in Betrieb, weil die vorherige Version startet.

Wie entscheiden Sie, wenn mehrere Apps PHP benötigen?

Situation	Überlegungen zu Docker	Überlegungen zu nativen Paketen
Apps benötigen unterschiedliche PHP-Versionen	Getrennte, gepflegte Images können Anforderungen isolieren	Mehrere Laufzeitumgebungen müssen möglicherweise ausdrücklich verwaltet werden
Die Laufzeitumgebung wird vom Herausgeber der App gepflegt	Befolgen Sie die Richtlinien für Image-Releases und Kompatibilität	Prüfen Sie, ob ein natives Paket unterstützt wird
Die Distribution stellt Sicherheits-Backports bereit	Host-Patches aktualisieren keine gebündelten Images	Die Überarbeitung durch den Anbieter ist ein wichtiger Beleg
Datenbankmigration wird durchgeführt	Ein altes Image allein macht das möglicherweise nicht rückgängig	Ein altes Paket allein macht das möglicherweise nicht rückgängig

Am einfachsten ist der Weg mit einer gepflegten Updatequelle und einer Person, die die Updates überprüfen kann. Container können die Paketierung von Abhängigkeiten vereinfachen, aber eingebundene Verzeichnisse und privilegierter Zugriff können weiterhin Hostdaten offenlegen. Die Dokumentation zu Docker-Bind-Mounts erläutert den Schreibzugriff auf den Host, über den ein Container verfügen kann.

Verwenden Sie die Abhängigkeitsübersicht, um gemeinsam genutzte und gebündelte Laufzeitumgebungen voneinander zu unterscheiden, und die Anleitung für Updates mit zustandsbehafteten Daten, um einen Rollback für Anwendungsdaten zu planen. Das Ersetzen eines Containers ist nicht dasselbe wie die Wiederherstellung einer Anwendung.

Was eignet sich für einen ZimaCube 2 Home-Server?

Wählen Sie Docker, wenn für Ihre bevorzugten Apps gepflegte Images verfügbar sind und Sie deren Konfiguration, Volumes und Updates verwalten können. Wählen Sie native Pakete, wenn für Ihr Betriebssystem und Ihre Anwendungen ein unterstützter Paketweg verfügbar ist, den Sie verstehen. Sind beide Optionen verfügbar, vergleichen Sie die tatsächlichen Maintainer und Belege für die Veröffentlichungen.

Unabhängig davon, welches Modell Sie auf ZimaCube 2 verwenden: Legen Sie fest, wer für Updates verantwortlich ist, und bewahren Sie unabhängige Wiederherstellungskopien auf. Die bessere Bereitstellung ist diejenige, die Sie unter realen Bedingungen patchen, überprüfen und wiederherstellen können.

Entdecken Sie die ZimaCube 2 Personal Cloud Home-NAS für Ihren privaten Speicher und Ihre selbst gehostete Anwendungsumgebung. Die Softwaresicherheit hängt von den installierten Diensten, ihrer Konfiguration und verifizierten Updates ab.

Die PHP-Sicherheitsreihe fortsetzen

Quellen und Umfang

Geprüft am 22. Oktober 2026. Deployment-Empfehlungen müssen auf Ihre Anwendung und die Dokumentation des Anbieters abgestimmt werden; aus diesen Artikeln lässt sich keine produktspezifische Gefährdung ableiten.