Seminar Flask Deployment mit WSGI, Reverse Proxy und Containern

Eine Flask-Anwendung ist erst produktionsreif, wenn Build, Konfiguration, WSGI-Server, Reverse Proxy, TLS, Secrets, Migrationen und Rückfallweg als zusammenhängender Betriebsprozess funktionieren.

Das Seminar führt von der installierbaren Anwendung über ein gehärtetes Container-Image bis zu einem kontrollierten Rollout. Worker-Modell, Proxy-Vertrauen und Zustandsprüfungen werden nicht als Rezept, sondern anhand messbarer Anforderungen konfiguriert.

Inhaltsübersicht

1. Paketstruktur und interne Abhängigkeiten
2. Konfigurationsstrategie für Entwicklung, Test und Produktion
3. Produktionsbetrieb mit WSGI-Servern
4. Reverse Proxy, TLS und Proxy-Vertrauen
5. Container-Image und reproduzierbare Laufzeit
6. Secrets, Umgebungswerte und Betriebsparameter
7. Health Checks, Migrationen und Rollback
8. Strukturiertes Logging und Korrelationskennungen
9. Metriken, Tracing und Anwendungsdiagnose
10. Praxisprojekt und Wissenssicherung

Lernziele

• Einen geeigneten WSGI-Server und ein passendes Worker-Modell konfigurieren.
• Reverse Proxy, TLS und Forwarded Header sicher behandeln.
• Ein kleines, nicht privilegiertes Container-Image erstellen.
• Secrets und Umgebungsparameter kontrolliert bereitstellen.
• Health Checks, Migrationen, Rollout und Rollback praktisch absichern.

Zielgruppe

Flask-Entwickler, Administratoren, DevOps- und Plattformteams, die Anwendungen reproduzierbar und sicher in Produktion bringen.

Voraussetzungen

Sichere Flask-Grundlagen, Linux- beziehungsweise Servergrundkenntnisse und ein grundlegendes Verständnis von HTTP und Containern.

Seminarinhalte

1. Paketstruktur und interne Abhängigkeiten

Module werden so angeordnet, dass Importzyklen, globale Zustände und unklare Verantwortlichkeiten vermieden werden.

1. Schritt 1: Anwendungspaket, Konfiguration, Blueprints, Services, Modelle und Tests getrennt strukturieren.
2. Schritt 2: Öffentliche Schnittstellen über __init__-Module bewusst begrenzen.
3. Schritt 3: Abhängigkeitsrichtung festlegen und zyklische Importe durch Factory- oder Interface-Muster auflösen.
4. Schritt 4: Paket installierbar machen und Importverhalten in einer frischen Umgebung prüfen.

2. Konfigurationsstrategie für Entwicklung, Test und Produktion

Konfiguration wird früh geladen, validiert und nach Sensitivität sowie Umgebung getrennt.

1. Schritt 1: Nicht geheime Defaults versionieren und umgebungsspezifische Werte darüberlegen.
2. Schritt 2: Verschachtelte Umgebungsvariablen und Präfixe konsistent verwenden.
3. Schritt 3: Geheimnisse aus Dateien oder Secret Stores laden, ohne sie zu protokollieren.
4. Schritt 4: Startprüfung für Pflichtwerte, Datentypen und widersprüchliche Optionen implementieren.

3. Produktionsbetrieb mit WSGI-Servern

Der Entwicklungsserver wird durch einen belastbaren WSGI-Server mit passendem Worker-Modell ersetzt.

1. Schritt 1: Anwendungsimport beziehungsweise Factory-Aufruf für den Server eindeutig konfigurieren.
2. Schritt 2: Prozess-, Thread- und asynchrone Worker nach Lastprofil auswählen.
3. Schritt 3: Timeouts, Workeranzahl, Max-Requests und Graceful Shutdown festlegen.
4. Schritt 4: Start, Reload, Absturz und kontrolliertes Herunterfahren unter Last prüfen.

4. Reverse Proxy, TLS und Proxy-Vertrauen

Externe Verbindungen werden am HTTP-Server terminiert und vertrauenswürdige Weiterleitungsinformationen korrekt behandelt.

1. Schritt 1: Reverse-Proxy-Pfad, Host, Protokoll und Clientadresse als Datenfluss dokumentieren.
2. Schritt 2: Forwarded Header nur für die bekannte Anzahl vertrauenswürdiger Proxies auswerten.
3. Schritt 3: TLS, HSTS, Größenlimits und statische Dateien am vorgeschalteten Server konfigurieren.
4. Schritt 4: Direktzugriff, gefälschte Header und falsche Präfixe mit Integrationstests prüfen.

5. Container-Image und reproduzierbare Laufzeit

Die Anwendung wird als kleines, nicht privilegiertes und reproduzierbares OCI-Image bereitgestellt.

1. Schritt 1: Build- und Laufzeitabhängigkeiten trennen und einen festen Basisstand wählen.
2. Schritt 2: Anwendung als Paket installieren und Build-Cache sinnvoll nutzen.
3. Schritt 3: Nicht als root ausführen, Schreibpfade begrenzen und Konfiguration erst zur Laufzeit injizieren.
4. Schritt 4: Image lokal, in der CI und mit schreibgeschütztem Dateisystem testen.

6. Secrets, Umgebungswerte und Betriebsparameter

Geheime und veränderliche Werte werden außerhalb des Images verwaltet und beim Start geprüft.

1. Schritt 1: Schlüssel, Datenbankzugänge und Provider-Credentials inventarisieren.
2. Schritt 2: Secret-Dateien oder Secret-Store-Anbindung mit minimalen Dateirechten konfigurieren.
3. Schritt 3: Rotation vorbereiten und mehrere gültige Schlüssel während eines Übergangs unterstützen.
4. Schritt 4: Fehlende, abgelaufene oder versehentlich protokollierte Secrets erkennen.

7. Health Checks, Migrationen und Rollback

Bereitstellungen werden mit Zustandsprüfungen, kontrollierten Schemaänderungen und einem Rückweg abgesichert.

1. Schritt 1: Liveness, Readiness und fachliche Abhängigkeiten getrennt definieren.
2. Schritt 2: Datenbankmigrationen als eigenen, einmaligen Deployment-Schritt ausführen.
3. Schritt 3: Rolling-, Blue-Green- oder einfache Austauschstrategie passend zur Plattform wählen.
4. Schritt 4: Fehlgeschlagene Version anhand von Metriken erkennen und Rollback praktisch durchführen.

8. Strukturiertes Logging und Korrelationskennungen

Protokolle werden so gestaltet, dass technische Abläufe und einzelne Requests zuverlässig nachvollziehbar bleiben.

1. Schritt 1: Logger-Hierarchie, Level und Handler zentral konfigurieren.
2. Schritt 2: Request-, Benutzer- und Korrelationskennung als strukturierte Felder ergänzen.
3. Schritt 3: Sensible Daten, Tokens und vollständige Request-Körper konsequent filtern.
4. Schritt 4: Logausgabe für Entwicklung und zentrale Sammlung getrennt testen.

9. Metriken, Tracing und Anwendungsdiagnose

Latenz, Durchsatz, Fehler und Abhängigkeiten werden messbar gemacht, ohne unnötige Kardinalität zu erzeugen.

1. Schritt 1: Golden Signals und fachliche Kennzahlen für die Anwendung festlegen.
2. Schritt 2: Metriken an Request-Grenzen und kritischen Services erfassen.
3. Schritt 3: Trace-Kontext über HTTP-, Datenbank- und Queue-Grenzen weitergeben.
4. Schritt 4: Dashboards anhand realer Betriebsfragen statt dekorativer Diagramme strukturieren.

Praxisprojekt

Eine Beispielanwendung wird als Paket und Container gebaut, hinter einem Reverse Proxy betrieben und mit Health Checks versehen. Ein Schemawechsel sowie ein fehlgeschlagener Rollout werden einschließlich Rückkehr zur vorherigen Version geübt.

Methodik

Kurze fachliche Einordnungen wechseln mit Demonstrationen, geführten Umsetzungen, Fehleranalysen und eigenständigen Übungen. Jede größere Änderung wird durch einen Test, eine Diagnose oder eine betriebliche Prüfroutine abgesichert. Die Arbeitsstände werden schrittweise zu einem durchgängigen Beispielprojekt zusammengeführt.