Kannst du den veröffentlichten Port eines Containers ändern, ohne seine Datenbank neu zu erstellen?

Ja, Sie können den veröffentlichten Port eines Containers ändern, ohne seine Datenbank neu zu erstellen, sofern die Datenbank auf demselben verifizierten persistenten Speicher verbleibt.

Auf einem Heim-NAS oder Docker-Host gehört der sichtbare Port normalerweise zum kurzlebigen Anwendungscontainer, während Datensätze, Konten und Einstellungen in einem benannten Volume, einem Bind-Mount oder einem separaten Datenbankdienst gespeichert werden. Die sichere Vorgehensweise besteht daher darin, die Bereitstellungsdefinition und die persistenten Pfade beizubehalten, nur die hostseitige Veröffentlichungsregel zu ändern, den betroffenen Anwendungsdienst neu zu erstellen und anschließend jeden Proxy, jedes Lesezeichen, jeden Callback, jede Firewall-Regel und jede Zustandsprüfung zu überprüfen, die noch auf den alten Port verweist.

Den veröffentlichten Host-Port vom Listener des Containers trennen

Notieren Sie die aktuelle Zuordnung vor der Änderung als zwei verschiedene Endpunkte. Bei 8080:80 verbinden sich Clients mit Port 8080 auf dem Docker-Host, während die Anwendung im Container weiterhin auf Port 80 lauscht. Wenn Sie die linke Seite ändern, ändert sich dadurch weder der Anwendungsprozess noch seine Datenbankverbindung automatisch.

Ein Fall aus der Docker-Community zur Fehlerbehebung betont, dass Host-Zuordnung und interner Listener getrennt sind und ein neuer veröffentlichter Port nicht funktionieren kann, wenn intern nichts auf dem Zielport lauscht.

Überprüfen Sie die veröffentlichten Ports und lauschenden Sockets des laufenden Containers und testen Sie anschließend den internen Endpunkt aus dem Container oder seinem Netzwerk heraus. Lassen Sie den internen Port unverändert, sofern die Anwendung selbst nicht umgestellt werden muss. Dieser erste Test verhindert, dass aus einer einfachen Host-Port-Änderung eine unnötige Neukonfiguration der Anwendung wird.

Den aktuellen Datenbankpfad vor dem Neuerstellen des Dienstes schützen

Dokumentieren Sie die Compose-Datei, den Image-Tag oder Digest, Umgebungsdateien, benannten Volumes, Bind-Mounts, Netzwerknamen, Secrets und den Hostnamen der Datenbank. Ziel ist es, eindeutig festzustellen, welches Objekt den persistenten Zustand besitzt, bevor Docker den Anwendungscontainer ersetzt.

Das Ändern der Port-Veröffentlichung erfordert eine neue Container-Konfiguration, jedoch weder die Erstellung eines neuen Images noch einer neuen Datenbank. Eine praxisnahe Docker-Antwort unterscheidet die Neuerstellung des Containers vom erneuten Erstellen des Anwendungs-Images, wenn sich die Porteinstellungen ändern.

Erstellen Sie für wichtige Dienste ein aktuelles, anwendungskonsistentes Datenbank-Backup oder einen Snapshot und überprüfen Sie anschließend, dass sich der Datenbankpfad nicht innerhalb der beschreibbaren Ebene des Containers befindet. Brechen Sie ab, wenn die Mount-Liste unklar ist, der Volume-Name geändert wurde oder die aktuelle Anwendung offenbar eine unerwartete leere Datenbank verwendet.

Nur die hostseitige Zuordnung ändern und den Anwendungsdienst neu erstellen

Ändern Sie die Zuordnung des Anwendungsdienstes beispielsweise von 8080:80 in 8081:80. Lassen Sie Image, internen Port, Volumes, Datenbank-URL, Dienstnamen, Netzwerke und Benutzerzuordnung unverändert, sofern keine andere verifizierte Anforderung besteht.

Die Compose-Portsyntax wird vom Host zum Container interpretiert. Wenn Sie die Host-Seite ändern, lauscht der Prozess daher weiterhin auf seinem bestehenden internen Port. Ein Beispiel aus dem Docker-Forum erklärt, warum die linke Seite der Host-Port ist und die rechte Seite weiterhin zum Listener der Anwendung passen muss.

Erstellen Sie nur den Anwendungsdienst mit der aktualisierten Definition neu. Verwenden Sie keinen Stack-Befehl, der Volumes entfernt, initialisieren Sie die Datenbank nicht erneut und fügen Sie --build nur hinzu, wenn sich das Image selbst geändert hat. Überprüfen Sie nach der Neuerstellung die tatsächlich verwendeten Mounts und die Portzuordnung, bevor Sie Migrationen oder Hintergrundaufgaben ausführen lassen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Jeden vom alten Port abhängigen Client-Pfad aktualisieren

Ein Browser-Lesezeichen ist nur ein Nutzer des veröffentlichten Ports. Reverse-Proxys, Router-Weiterleitungen, lokale Firewalls, Überwachungsprüfungen, mobile Apps, Webhook-Ziele, OAuth-Callbacks, CORS-Positivlisten und generierte öffentliche URLs können weiterhin auf den vorherigen Endpunkt verweisen.

Einige selbst gehostete Anwendungen stellen Loopback-Anfragen oder erstellen Callback-URLs anhand ihrer konfigurierten öffentlichen Adresse. Eine Diskussion zu einem WordPress-Container zeigt, wie eine geänderte externe Zuordnung portabhängiges Loopback-Verhalten sichtbar machen kann, selbst wenn die Datenbank weiterhin fehlerfrei arbeitet.

Durchsuchen Sie das Compose-Projekt, die Proxy-Konfiguration, Umgebungsdateien und Anwendungseinstellungen nach dem alten Port. Aktualisieren Sie nur die Ebenen, die den Host-Endpunkt tatsächlich verwenden. Interne Container sollten normalerweise weiterhin den Dienstnamen und den internen Port verwenden, nicht den neu veröffentlichten Host-Port.

Die Datenbank auf ihrem privaten Containerpfad belassen

Ändern oder veröffentlichen Sie den Datenbank-Port nicht nur deshalb, weil sich der Host-Port der Webanwendung geändert hat. Eine Datenbank, die ausschließlich von Containern im selben Stack verwendet wird, kann weiterhin über ihren Dienstnamen und den internen Port erreichbar bleiben, ohne auf dem Host veröffentlicht zu werden.

Wenn der öffentliche Endpunkt der Anwendung mit der Datenbankverbindung verwechselt wird, kann ein zweiter Ausfall entstehen: Die Anwendung wird möglicherweise auf die NAS-Adresse und einen Host-Port verwiesen, obwohl die Datenbank in einem privaten Docker-Netzwerk bleiben soll. Diese Änderung führt zusätzliche Variablen wie Firewall, NAT und Authentifizierung ein, ohne den Zugriff des Browsers auf den Webdienst zu verbessern.

Lösen Sie im neu erstellten Anwendungscontainer den Namen des Datenbankdienstes auf, öffnen Sie dessen internen TCP-Port, authentifizieren Sie sich und führen Sie eine harmlose Leseabfrage aus. Wenn dieser Pfad unverändert ist, lassen Sie ihn unverändert. Schlägt der Datenbanktest fehl, stellen Sie die ursprüngliche Anwendungsdefinition wieder her, bevor Sie das separate Netzwerk- oder Anmeldedatenproblem untersuchen.

Den neuen Port überprüfen, ohne persistente Daten anzutasten

Testen Sie zunächst den neuen Host-Port direkt und anschließend den normalen Hostnamen oder die Reverse-Proxy-Route. Bestätigen Sie die Anmeldung, das Lesen von Datensätzen, einen reversiblen Schreibvorgang, Uploads, geplante Aufgaben, Integrationen und einen kontrollierten Neustart des Containers.

Der ZimaSpace-Leitfaden zum Abgleichen von Zustandsprüfungen mit tatsächlichen Anwendungspfaden ist der nächste Schritt, wenn der neue Browser-Endpunkt funktioniert, Docker den Dienst jedoch weiterhin als fehlerhaft meldet.

Die Änderung ist erst abgeschlossen, wenn der neue veröffentlichte Port eine Neuerstellung und einen Neustart übersteht, Proxy und Clients den alten Endpunkt nicht mehr verwenden, die Anwendung wieder eine Verbindung zur selben persistenten Datenbank herstellt und das Datenbank-Backup weiterhin verfügbar ist. Setzen Sie die Portzuordnung zurück, wenn die Anwendung mit einem neuen leeren Zustand startet oder eine unerwartete Migration durchführen möchte.