Docker-Anwendung veröffentlichen

In der [[Docker Level 2 - Dockerfile und Compose|Übung mit Dockerfiles]] hast du ein Image erstellt und die App mit docker run gestartet. Falls du die optionale Übung [[App with Compose Level 1 - Starte und aktualisiere die App|mit Compose]] durchgeführt hast, kannst du stattdessen Compose verwenden. Hier sollst du dafür sorgen, dass dieselbe App über einen DNS-Namen und eine zugängliche Proxy antwortet. Du kannst deine eigene App oder die Test-App aus der Dockerfile-Übung verwenden.

Führe zunächst den direkten Test durch, dann HTTP über die Proxy. Die Grundroute ist abgeschlossen, wenn der Name die erwartete App-Antwort liefert und du die einzelnen Schritte erklären kannst. HTTPS und die Installation einer eigenen Proxy sind optional und haben ihre eigenen Voraussetzungen.

Wenn die Flask-Anwendung auf einem Server mit einem Port läuft, kann eine Reverse Proxy Anfragen im Namen der Anwendung entgegennehmen und sie an den richtigen Container weiterleiten. So können Benutzer einen Domainnamen statt IP-Adresse und Portnummer verwenden. Du benötigst einen DNS-Namen und eine Proxy, die du konfigurieren kannst, sowie ein Zertifikat, falls der Dienst HTTPS nutzen soll.

DNS beantwortet mit einer Adresse und transportiert nicht die Webseite. In der Abbildung beendet die Proxy die HTTPS-Verbindung und nutzt anschließend HTTP in einem abgegrenzten internen Netz. Der Browser erhält die Antwort über die Proxy.

Bevor Sie beginnen

Sie benötigen einen funktionierenden Container aus der Dockerfile-Aufgabe (oder der Compose-Aufgabe) und diese Informationen aus der Testumgebung:

• APP-VM-IP: die Adresse des virtuellen PCs, auf dem die App läuft; hier wird Port 5000 verwendet.
• PROXY-IP: die Adresse, unter der der Client den Proxy erreichen soll, mit HTTP auf Port 80.
• APP-NAME: ein DNS-Name, der auf den Proxy verweist. Die App und der Proxy können sich auf verschiedenen virtuellen PCs befinden.

Sie benötigen Zugriff zum Anlegen eines Hosts für Proxies in Nginx Proxy Manager sowie Berechtigung für die Verbindung vom Proxy zur App. Die Platzhalter oben müssen durch Ihre Werte ersetzt werden. Wenn DNS oder Proxy-Zugriff nicht verfügbar ist, führen Sie den lokalen Test durch und erläutern das Diagramm. Dies stellt keinen abgeschlossenen Veröffentlichungstest dar.

1. Prüfen Sie die App lokal

Arbeiten Sie im Projektordner auf dem App-VM. Die folgenden Befehle verwenden den Containernamen min-app aus der Dockerfile-Aufgabe. Mit der dortigen Portbindung sollte dieser Test die Hauptseite liefern:

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Sie können /status als festen Kontrollpunkt verwenden. Falls dieser Pfad nicht bereits existiert, fügen Sie ihn nach den anderen vollständigen Routenfunktionen und vor if __name__ == "__main__": in app.py ein:

@app.route("/status")
def status():
    return {"status": "ok"}

Bauen, starten und neu testen:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Wenn Sie Compose verwenden, ersetzen die drei ersten Befehle mit docker compose up -d --build.

Erwartet wird HTTP 200 und JSON mit "status": "ok". Falls die App bereits über /status verfügt, nutzen Sie dort die dokumentierte Antwort anstelle einer neuen Route mit demselben Namen zu erstellen. Dies prüft nur diese Route, nicht alle Funktionen der Anwendung.

2. App für den Proxy verfügbar machen

Das folgende Rezept verwendet die Netzwerkadresse der App-VM. Wenn der Port nur an 127.0.0.1 gebunden ist, starten Sie den Container mit der tatsächlichen Adresse der VM im Port-Mapping neu. Beschränken Sie den Netzwerkbereich auf notwendige Quellen; eine Adressbindung allein beschränkt nicht, welche Clients sich verbinden dürfen.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Wenn Sie Compose verwenden, ersetzen Sie stattdessen die Portzeile unter app in der compose.yaml durch "APP-VM-IP:5000:5000" und führen Sie docker compose up -d aus.

Führen Sie den Test auf dem App-VM-Dienstcomputer und aus der Netzwerkumgebung des Proxys oder von einem Testclient mit denselben erlaubten Zugriffsrechten durch. Die tatsächliche Verbindung des Proxys wird ebenfalls anhand des Namens im nächsten Abschnitt kontrolliert. Nach geänderter Bindung testen Sie die VM-Adresse, nicht 127.0.0.1. Öffnen Sie den Port nicht gegenüber dem gesamten Internet. [[Segmentierung Level 1 – VLAN und Netzwerkschnittstellen|Segmentierung]] unterstützt die Zugangsregel.

Von der Domain zur Container

Es passieren mehrere Dinge, wenn ein Benutzer einen Namen wie https://app.example.test öffnet. Dies ist ein Beispielnamen; ersetzen Sie ihn durch den Namen, der tatsächlich in Ihrer Testumgebung eingerichtet wurde:

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant P as Nginx Proxy Manager
    participant F as Flask-Container

    B->>D: IP-Adresse der Domain finden
    D-->>B: IP-Adresse des Proxys
    B->>P: Anfrage an die Domain
    P->>P: Richtigen Proxy-Host finden
    P->>F: An interne Port 5000 weiterleiten
    F-->>P: HTML-Seite zurückgeben
    P-->>B: Antwort zurückgeben

Es ist daher sinnvoll, eine Schicht nach der anderen zu testen, anstatt gleichzeitig DNS, Proxy und Flask zu debuggen.

Nginx Proxy Manager

Nginx Proxy Manager ist eine Web-Oberfläche für Nginx. Hier nutzen Sie eine vorhandene Installation und erstellen einen einzigen Proxi-Host. Sie müssen nicht für jede App einen neuen Proxy installieren.

Erstellen Sie einen Proxi-Host:

1. Geben Sie APP-NAME, den tatsächlich konfigurierten Namen des Dienstes, ein.
2. Wählen Sie http als Schema für die Verbindung von Nginx Proxy Manager zum Container aus.
3. Geben Sie APP-VM-IP als Weiterleitungshostname ein. 127.0.0.1 innerhalb einer Proxyccontainer bedeutet der Proxyccontainer selbst.
4. Geben Sie den veröffentlichten Port des Containers an, beispielsweise 5000.
5. Speichern Sie die Einstellungen und öffnen Sie http://APP-NAME/status vom Client aus.

Der Name muss auf PROXY-IP aufgelöst werden. Die Auflösung können Sie mit nslookup APP-NAME am Client überprüfen. Der HTTP-Test sollte dieselbe Statusantwort liefern wie der direkte Test. Das Anzeigen der Standardseite des Proxys zeigt nicht an, dass die Anfrage die App erreicht hat.

Wiederwahl: HTTPS

Wenn HTTP funktioniert und Sie ein gültiges Zertifikat für den Namen besitzen, öffnen Sie die SSL-Registerkarte, wählen das Zertifikat aus und testen https://APP-NAME/status. Ein interner Beispielsname wie app.example.test kann kein öffentliches Zertifikat von Let’s Encrypt erhalten; dann benötigen Sie ein Zertifikat von einem internen Aussteller, dem der Client vertraut. Die DNS-Auflösung allein richtet keine HTTPS-Einrichtung ein. Der HTTP-Basispfad ist eine lokale Übung; bei der Verarbeitung von Anmeldedaten oder anderen schützenswerten Daten benötigen Sie HTTPS.

Der Proxy muss den Port auf dem Server erreichen können. Wenn der Container auf einer anderen VM läuft, müssen Netzwerk und Firewall den Verkehr zwischen den VMs zulassen. Es ist nicht erforderlich, den Flask-Port direkt gegenüber dem gesamten Internet offenzulegen, wenn Nginx Proxy Manager der Einstiegspunkt ist; beschränken Sie den Zugriff gemäß der Einrichtung der Schule durch die Firewall.

Wiederwahl: Eigener Proxy

Installieren Sie nur einen eigenen Proxy, wenn Sie tatsächlich einen benötigen und über eine eigene Testumgebung verfügen. Verwenden Sie die Installationanleitung des Nginx Proxy Manager. Anschließend kehren Sie zur oben beschriebenen Erstellung eines Proxy-Hosts zurück. Dies ist ein eigenständiges Setup und keine Voraussetzung für die Verwendung einer vorhandenen Proxy-Lösung.

Fehlersuche

docker ps
docker logs -f min-app
ss -tulpn

Wenn Sie Compose verwenden, lauten die ersten beiden Befehle docker compose ps und docker compose logs -f. Führen Sie die Befehle nacheinander auf dem App-VM aus. Beenden Sie logs -f mit Strg+C. ps zeigt den Containerstatus an, das Protokoll (Log) zeigt die Meldungen der Anwendung und ss kann bei der Untersuchung von Lauschnittstellen helfen. Verwenden Sie das Ergebnis des konkreten HTTP-Tests zur Überprüfung des Zugriffs.

Testen Sie in dieser Reihenfolge:

1. Auf dem App-VM nach geänderter Bindung: curl --fail --show-error http://APP-VM-IP:5000/status.
2. Aus der Netzwerkperspektive des Proxys: dieselbe Adresse, derselbe Port und derselbe Pfad. Ein beliebiger Client kann andere Zugriffskontrollregeln haben.
3. Vom Client über den Namen: nslookup APP-NAME, dann http://APP-NAVN/status. Testen Sie HTTPS separat, falls konfiguriert.

Falls Punkt 1 fehlschlägt, untersuchen Sie Anwendung, Containerstatus, Adresse und Portbindung. Falls Punkt 1 funktioniert und Punkt 2 fehlschlägt, untersuchen Sie die Verbindung und die Zugriffskontrollregeln vom Proxy. Falls Punkt 2 funktioniert und Punkt 3 fehlschlägt, untersuchen Sie DNS, Proxy Host und das gewählte Protokoll. HTTP 404 bedeutet, dass ein HTTP-Server antwortete, aber der Pfad könnte falsch sein; 502 vom Proxy deutet auf Probleme mit der Verbindung oder der Antwort von der Anwendung hin. Dokumentieren Sie, was der Test eingrenzt, bevor Sie etwas ändern.

Nächster Schritt

Zeige die Statusantwort über den Namen an und erläutere den Unterschied zwischen der DNS-Auflösung und der Weiterleitung im Proxy. Weise auch in der Abbildung oder einer eigenen Skizze auf Client, Proxy und App hin. Du kannst dies mündlich oder schriftlich erklären. Gib die Testadresse sowie die erwartete/tatsächliche Antwort an und ob du HTTP oder HTTPS getestet hast. Bei Abweichungen verwendest du die oben genannte Testreihenfolge, bevor du fortfährst.

Sobald der Grundpfad funktioniert, kannst du das Setup weiter im Projekt verwenden. Docker - Container mit Workflow veröffentlichen ist eine weitere Schulung zur Automatisierung des Builds und der Veröffentlichung des Images.

Quellen: Docker: Portbindung, Nginx Proxy Manager und Flask: Routen und Antworten.