Führen Sie Docker auf einem VPS mit einem Produktionsbetriebsplan aus
Docker erleichtert das Verpacken einer Anwendung, aber ein erreichbarer Container ist nur der Anfang des Betriebs. Ein VPS benötigt weiterhin ein Ressourcenbudget, eine bewusste Netzwerkexposition, wiederherstellbare Daten und einen Release-Prozess, den jemand pflegen kann.
Das Wichtigste in Kürze
Behandeln Sie das Compose-Projekt als reproduzierbare Anwendungsdefinition, halten Sie persistente Daten explizit, veröffentlichen Sie nur die vorgesehenen Einstiegspunkte und testen Sie einen Wiederherstellungspfad, bevor Sie sich auf die Bereitstellung verlassen.
Beschreiben Sie die Anwendung und die Grenze des Einzelhosts
Beginnen Sie mit einem Diagramm, das den öffentlichen Reverse-Proxy, die Anwendung, die Datenbank, Worker und persistente Dateien enthält. Notieren Sie, welche Komponenten sich gegenseitig erreichen müssen und welche aus dem Internet zugänglich sein müssen. Eine kleine Compose-Bereitstellung kann ein praktisches Betriebsmodell für einen VPS sein. Sie wird nicht allein dadurch zu einem hochverfügbaren Cluster, dass mehrere Container laufen.
Identifizieren Sie die Aufgaben auf Host-Ebene: Betriebssystem-Updates, Docker-Wartung, administrativer Zugriff, Firewall-Richtlinie und Backup-Planung. Das Neustartverhalten von Containern kann helfen, einen gestoppten Prozess wiederherzustellen, aber es kann keine verlorenen Daten, nicht verfügbaren Speicher oder einen ausgefallenen Host reparieren. Legen Sie fest, was das Projekt tut, wenn der gesamte VPS nicht verfügbar ist und wie die Anwendung andernorts neu erstellt würde.
Prüfen Sie das ausgewählte Betriebssystem und die Architektur des Anwendungs-Images anhand der Software-Dokumentation. Halten Sie Entwicklungsannehmlichkeiten von Produktionsentscheidungen getrennt. Ein Bind-Mount für Quellcode, der Debug-Modus oder ein nur lokal gültiges Zugangsdatenobjekt, das auf einem Laptop nützlich war, sollte nicht allein deshalb Teil der öffentlichen Bereitstellung werden, weil es in derselben Compose-Datei steht.
Planen Sie Arbeitsspeicher, CPU und temporären Speicher gemeinsam
| Komponente | Beispielhafter Arbeitsspeicherbedarf | Was zu messen ist |
|---|---|---|
| Host und unterstützende Agenten | 1 GB | Betriebssystem und routinemäßiger betrieblicher Overhead |
| Datenbank | 2 GB | Puffer, gleichzeitige Verbindungen und reale Abfragelast |
| Anwendungsprozesse | 2 GB | Normale Last und realistische Anfragespitzen |
| Hintergrund-Worker | 1 GB | Importe, Bildverarbeitung und geplante Aufgaben |
| Nicht zugewiesener Spielraum | 2 GB | Release-Überlappung und ungewöhnliche betriebliche Aktivität |
Dieses beispielhafte 8 GB-Budget ist eine Planungsübung, keine gemessene Anforderung und kein Versprechen zur Hosting-Leistung. Bestätigen Sie die tatsächliche Nutzung mit der vorgesehenen Anwendung und konfigurieren Sie Ressourcenkontrollen passend zu Ihrem Docker-Setup. Eine Datenbank und ein Worker können gleichzeitig Spitzen erreichen, selbst wenn jede Komponente in separaten Tests komfortabel aussah. Eine Container-Anzahl ist kein sinnvoller Ersatz für eine Workload-Messung.
Die Speicherplanung erfordert mehr als die aktuelle Datenbankgröße. Berücksichtigen Sie Images, persistente Volumes, Anwendungs-Uploads, Logs und temporären Speicherplatz während Importen oder Anwendungs-Deployments. Halten Sie eine Reserve vor, die Untersuchungs- und Wiederherstellungsarbeiten ermöglicht. Wenn ein Deployment ein neues Image herunterladen muss, während das vorherige beibehalten wird, kann eine bereits fast volle Festplatte aus einem gewöhnlichen Update einen Ausfall machen.
Persistente Daten definieren und ihre Wiederherstellung nachweisen
Verwenden Sie explizit benannte Volumes oder sorgfältig dokumentierte Bind-Mounts für Daten, die das Ersetzen eines Containers überdauern müssen. Benennen Sie Eigentümer und Zweck jedes Mounts. Halten Sie Datenbankdateien, Uploads und entbehrliche Caches in den Betriebsnotizen unterscheidbar. Die beschreibbare Schicht innerhalb eines einzelnen Containers sollte nicht der einzige Ort sein, an dem ein Kundendokument existiert.
Ein Docker-Volume bleibt unabhängig von einem Container bestehen, aber Persistenz ist kein eigenständiges Backup. Wählen Sie eine unterstützte konsistente Sicherungsmethode für die Datenbank, erfassen Sie zugehörige Anwendungsdateien und testen Sie die Wiederherstellung in einem isolierten Deployment. Gehen Sie nicht davon aus, dass das Kopieren eines Live-Datenbank-Volumes einen nutzbaren Wiederherstellungspunkt ergibt. Dokumentieren Sie, wie Volume, Anwendungs-Release und Datenbankzustand bei der Wiederherstellung zueinander passen.
Bestätigen Sie vor dem Anhängen eines Mounts sowohl Quelle als auch Ziel. Das Einbinden eines Volumes über ein Verzeichnis kann bereits vorhandene Dateien an diesem Containerpfad verbergen. Wenn eine Anwendung nach einem Deployment unerwartet leer erscheint, prüfen Sie den tatsächlichen Mount und das ausgewählte Volume, bevor Sie eine destruktive Bereinigungsaktion durchführen. Die Daten befinden sich möglicherweise in einem anderen Volume und sind nicht verloren.
Einstiegspunkte bewusst veröffentlichen und extern testen
Üblicherweise ist der öffentliche Einstiegspunkt der Reverse-Proxy, während die Anwendungsdatenbank nur über den vorgesehenen internen Pfad erreichbar bleibt. Unterscheiden Sie einen zwischen Containern verwendeten Port von einem auf dem Host veröffentlichten Port. Vermeiden Sie es, Datenbank-, Administrations- und Metrik-Schnittstellen nur deshalb freizugeben, um einen Verbindungstest zu erleichtern. Schützen Sie den Verwaltungszugang getrennt von der öffentlichen Website.
Docker erstellt Netzwerk- und Firewallregeln auf Linux. Der Verkehr veröffentlichter Ports kann den Host-Firewallpfad umgehen, den ein Betreiber bei der Verwendung von ufw erwartet. Folgen Sie der Docker-Dokumentation für das installierte Netzwerk- und Firewall-Backend und überprüfen Sie das Ergebnis anschließend von außerhalb des VPS. Eine beruhigende Liste von Host-Regeln ist kein Beweis dafür, dass ein veröffentlichter Container-Port unerreichbar ist.
Listen Sie für die erste Produktionsprüfung jeden von außen erreichbaren Port auf und weisen Sie ihm einen Zweck zu. Prüfen Sie den Anwendungs-Hostnamen über HTTPS und bestätigen Sie, dass unbeabsichtigte administrative Pfade nicht öffentlich sind. Halten Sie private Konfiguration außerhalb von Image-Quellen und öffentlichen Repositories. Prüfen Sie die Berechtigungen, Mounts und Host-Schnittstellen, die jedem Dienst gewährt werden, statt jedem Container automatisch weitreichenden Zugriff zu geben.
Releases reproduzierbar und Logs begrenzt halten
Dokumentieren Sie für jedes Release eine explizite Image-Version oder einen Digest und bewahren Sie die zur Bereitstellung verwendete Konfiguration auf. Prüfen Sie produktionsspezifische Compose-Einstellungen, einschließlich Neustartverhalten, Ports, Umgebung und Mounts. Testen Sie die Ersatzanwendung, bevor Sie sie akzeptieren. Ein Rollback eines Images ist nur sicher, wenn etwaige Datenbankschema-Änderungen kompatibel bleiben oder ein eigenes eingeübtes Wiederherstellungsverfahren haben.
Legen Sie eine bewusste Logging-Richtlinie fest. Die Logging-Treiber von Docker unterscheiden sich, und die Standardkonfiguration json-file kann ohne Rotation unbegrenzt wachsen. Wählen Sie eine geeignete begrenzte Konfiguration und bestätigen Sie sie auf den tatsächlich laufenden Containern; das Ändern eines Daemon-Standardwerts konfiguriert bestehende Container nicht automatisch neu. Behalten Sie nützliche Anwendungsereignisse, ohne Passwörter, Tokens oder vollständige sensible Anfrageinhalte aufzuzeichnen.
- Die dokumentierte Image- und Compose-Konfiguration kann die Anwendung neu erstellen.
- Für persistente Daten besteht ein separates, getestetes Wiederherstellungsverfahren.
- Nur genehmigte Ports sind von außerhalb des VPS erreichbar.
- Für Logs besteht eine überprüfte Größen- und Aufbewahrungsrichtlinie.
- Ein benannter Verantwortlicher kümmert sich um Updates, Alarmprüfung und Kontrollen nach jedem Deployment.
Beginnen Sie mit einem Deployment, das klein genug ist, um es zu verstehen. Fügen Sie Orchestrierungskomplexität nur hinzu, wenn ein gemessener Bedarf sie rechtfertigt und das Team die zusätzlichen Komponenten betreiben kann. Ein klarer Wiederherstellungsplan für einen einzelnen Host ist nützlicher als eine Sammlung von Containern, deren Daten und Zuständigkeiten niemand nachvollziehen kann.
