Django-Bereitstellungen ohne Ausfallzeiten: statische Dateien und Migrationen

Dieser Blogbeitrag basiert auf einer Produktpräsentation von Antonis Kalipetis, Staff Engineer bei SymfonyCon 2023, über die Erfahrungen von Upsun mit Nix. Wir haben ChatGPT für die Transkription und zur Verbesserung der Grammatik und Syntax verwendet.

Django-Bereitstellungen haben sich seit den Anfängen des Frameworks weiterentwickelt. Während Django-Migrationen in Version 1.6 eingeführt wurden, um uns das Leben zu erleichtern, haben moderne Bereitstellungsmuster wie rollierende Updates und horizontale Skalierung neue Komplexitäten mit sich gebracht, die Entwickler verstehen und einplanen müssen. In einem Live-Workshop ging Antonis darauf ein, was bei Bereitstellungen tatsächlich schiefgehen kann und wie man dies verhindern kann.

Die Django-Bereitstellungsarchitektur verstehen

Jede Django-Anwendungsbereitstellung besteht aus mehreren Schlüsselkomponenten, die zusammenarbeiten. An vorderster Front befindet sich ein Proxy-Server – in der Regel Nginx, Apache oder neuere Optionen wie Caddy und Traefik. Dieser Proxy übernimmt die TLS-Terminierung, das Domain-Routing und die Weiterleitungen. Dahinter befindet sich Ihr Anwendungsserver, in der Regel Gunicorn oder Uvicorn für asynchrone Anwendungen. Diese werden durch eine Cache-Schicht (wie Redis oder Memcached) und eine Datenbank (PostgreSQL, MySQL oder zunehmend SQLite für bestimmte Anwendungsfälle) unterstützt.

Diese Architektur eignet sich gut für Single-Server-Bereitstellungen, aber moderne Anwendungen laufen oft auf mehreren Servern mit rollierenden Updates, was zu Szenarien führt, in denen verschiedene Versionen Ihrer Anwendung gleichzeitig ausgeführt werden.

Die Herausforderung statischer Assets

Wenn Sie Django-Anwendungen lokal entwickeln, übernimmt manage.py runserver automatisch die Bereitstellung statischer Dateien. In der Produktivumgebung wird dieser Ansatz jedoch problematisch. Python-Anwendungsserver sind so konzipiert, dass sie jeweils nur eine Anfrage gleichzeitig bearbeiten können (mit einigen Ausnahmen für ASGI), wodurch sie für die Bereitstellung statischer Inhalte wie CSS, JavaScript und Bilder ungeeignet sind.

Das Problem vervielfacht sich mit der Größe

Die eigentliche Herausforderung entsteht, wenn mehrere Anwendungsserver unterschiedliche Versionen Ihres Codes ausführen. Stellen Sie sich folgendes Szenario vor: Sie aktualisieren Ihr CSS mit einer neuen Markenfarben und stellen es mit Djangos „ManifestStaticFilesStorage” bereit. Dieses Speicher-Backend erstellt gehashte Dateinamen wie app.a1b2c3d4.css, um permanentes Caching zu ermöglichen.

Während einer rollierenden Bereitstellung könnte Folgendes passieren:

• Server A läuft mit der alten Version mit „app.old123.css“
• Server B führt die neue Version mit „app.new456.css“ aus

Wenn die Anfrage eines Benutzers nach der neuen CSS-Datei an den alten Server weitergeleitet wird, erhält er einen 404-Fehler, wodurch das Seitenlayout beschädigt wird.

Lösungen für die Verwaltung statischer Assets

Externer Speicher: Laden Sie statische Dateien auf Dienste wie Amazon S3 oder ähnliche cloud-Speicher hoch. Dadurch wird sichergestellt, dass alle Versionen Ihrer Anwendung auf dieselben statischen Dateien zugreifen können.

Caching auf Proxy-Ebene: Konfigurieren Sie Ihren Proxy-Server (Nginx usw.) so, dass statische Dateien für einen angemessenen Zeitraum zwischengespeichert werden. Dadurch entsteht während der Bereitstellung ein Puffer, in dem alte Dateien verfügbar bleiben, während neue Dateien übertragen werden.

Gemeinsam genutzte Dateisysteme: Binden Sie das statische Verzeichnis auf allen Servern ein, damit sowohl alte als auch neue Anwendungsversionen Dateien vom selben Speicherort aus bereitstellen können.

WhiteNoise-Middleware: Diese Python-Bibliothek stellt statische Dateien direkt aus Ihrer Django-Anwendung mit effizienten Caching-Headern bereit, nutzt jedoch Ressourcen des Anwendungsservers.

Komplexität der Schemamigration

Django-Migrationen sind leistungsstark, erfordern jedoch in Umgebungen mit mehreren Versionen eine sorgfältige Planung. Der Referent demonstrierte dies anhand eines praktischen Beispiels mit einer Anwendung zur Meldung von Bigfoot-Sichtungen.

Das Kompatibilitätsproblem

Das Hinzufügen eines neuen Feldes zu einem Modell scheint einfach zu sein, aber bedenken Sie, was passiert, wenn Sie ein Pflichtfeld mit einem Standardwert hinzufügen:

# New field added

gdpr_accepted = models.BooleanField(default=False)

Nach der Ausführung der Migrationen erkennt die neue Anwendungsversion dieses Feld, die alte Version jedoch nicht. Wenn die alte Version versucht, einen Datensatz zu speichern, schlägt dies fehl, da die Datenbank das Feld „gdpr_accepted ” erwartet, der alte Code dieses jedoch nicht bereitstellt.

Datenbank-Standardeinstellungen in Django 5

Der Referent hob den neuen Parameter „db_default” von Django 5 als Lösung hervor:

gdpr_accepted = models.BooleanField(db_default=False)

Mit „db_default” verarbeitet die Datenbank selbst den Standardwert, nicht der Python-Code. Das bedeutet, dass alte Anwendungsversionen Datensätze auch ohne Kenntnis des neuen Feldes erfolgreich speichern können.

Bewährte Verfahren für Migrationsstrategien

• Vorwärts- und Rückwärtskompatibilität: Entwerfen Sie Migrationen, die sowohl mit der aktuellen als auch mit früheren Versionen Ihres Programms funktionieren.
• Mehrstufige Bereitstellungen: Bei komplexen Schemaänderungen sollten Sie eine Bereitstellung in mehreren Schritten in Betracht ziehen:

1. Fügen Sie das neue Feld als nullable hinzu
2. Stellen Sie ein Programm bereit, das sowohl alte als auch neue Schemata verarbeitet
3. Füllen Sie vorhandene Datensätze
4. Machen Sie das Feld bei Bedarf nicht nullfähig

• Überlegungen zur Datenmigration: Wenn Sie vorhandene Daten aktualisieren müssen, erstellen Sie separate Datenmigrationen, die sicher neben dem alten Programmcode ausgeführt werden können.

Die Herausforderung bei rollierenden Updates

Rolling Updates führen zu einem vorübergehenden Zustand, in dem mehrere Versionen Ihrer Anwendung gleichzeitig ausgeführt werden. Dies erfordert eine sorgfältige Koordination zwischen:

• Zeitpunkt der Migration: Wann sollen Datenbankänderungen angewendet werden?
• Code-Bereitstellung: Sicherstellung der Kompatibilität zwischen den Versionen
• Verteilung statischer Dateien: Verwaltung von Asset-Versionen über Server hinweg
• Rollback-Planung: Eine klare Strategie für den Fall, dass etwas schiefgeht

Realitätscheck zum Rollback

Während Django das Zurücksetzen von Migrationen mit „manage.py migrate app_name 0001” einfach erscheinen lässt, sind Rollbacks in der Produktivumgebung selten so unkompliziert. Der Referent betonte aus Erfahrung, dass Rollbacks oft mit unerwarteten Problemen verbunden sind, sodass eine sorgfältige Planung zur Vorbeugung wertvoller ist als das Verlassen auf Rollback-Funktionen.

Praktische Bereitstellungsstrategien

• Umgebungsgleichheit: Stellen Sie sicher, dass Ihre Staging-Umgebung die Produktivumgebung genau widerspiegelt, einschließlich Multi-Server-Setups, wenn möglich.
• Feature-Flags: Verwenden Sie Feature-Flags, um Code bereitzustellen, ohne neue Funktionen sofort offenzulegen, sodass Sie die Code-Bereitstellung von der Feature-Aktivierung trennen können.
• Blue-Green-Bereitstellungen: Unterhalten Sie zwei identische Produktionsumgebungen und schalten Sie den Datenverkehr zwischen ihnen um, wodurch die Komplexität mehrerer Versionen vollständig entfällt.
• Canary-Releases: Leiten Sie den Datenverkehr schrittweise auf neue Versionen um, damit Sie Probleme erkennen können, bevor sie alle Benutzer betreffen.

Plattformlösungen

Moderne Platform-as-a-Service-Anbieter wie Upsun begegnen vielen dieser Herausforderungen durch:

• Automatisierte Verarbeitung statischer Dateien mit gemeinsam genutztem Speicher
• Verwaltete Datenbankmigrationen mit Zeitsteuerung
• Integrierte Caching-Ebenen auf Proxy-Ebene
• Tools zur Koordinierung von Multi-Service-Bereitstellungen

Das Verständnis der zugrunde liegenden Herausforderungen bleibt jedoch auch bei der Verwendung verwalteter Plattformen von entscheidender Bedeutung.

Wichtige Erkenntnisse

Die integrierten Tools von Django, wie Migrationen und die Verwaltung statischer Dateien, sind leistungsstark, erfordern jedoch eine sorgfältige Anwendung in der Produktivumgebung. Die Komplexität steigt erheblich, wenn Sie von Einzelserver-Bereitstellungen zu horizontal skalierten, kontinuierlich bereitgestellten Anwendungen übergehen.

Erfolg erfordert:

• Planung von Migrationen für Kompatibilität zwischen Anwendungsversionen
• Implementierung robuster Strategien für die Bereitstellung statischer Dateien
• Verständnis für den Zeitpunkt und die Koordination von rollierenden Bereitstellungen
• Realistische Rollback-Verfahren
• Testen der Bereitstellungsprozesse in Staging-Umgebungen

Da Django-Anwendungen wachsen und Bereitstellungsmuster immer komplexer werden, müssen Entwickler ihr Verständnis über lokale Entwicklungsmuster hinaus erweitern. Das Framework stellt die Tools zur Verfügung, aber erfolgreiche Produktionsbereitstellungen erfordern eine sorgfältige Orchestrierung dieser Tools innerhalb Ihres spezifischen Infrastrukturkontexts.

Während Django unsere Entwicklungsarbeit weiterhin erleichtert, bleibt die Produktionsbereitstellung ein Bereich, in dem sorgfältige Planung und Verständnis der zugrunde liegenden Systeme sich in Bezug auf Anwendungszuverlässigkeit und Benutzererfahrung auszahlen.