Déploiements Django sans temps d'arrêt : fichiers statiques et migrations

Cet article de blog est basé sur une présentation de produit par Antonis Kalipetis, ingénieur chez SymfonyCon 2023, sur l'expérience d'Upsun avec Nix. Nous avons utilisé ChatGPT pour la transcription et pour améliorer la grammaire et la syntaxe.

Les déploiements Django ont évolué depuis les débuts du framework. Alors que les migrations Django ont été introduites dans la version 1.6 pour nous simplifier la vie, les modèles de déploiement modernes, tels que les mises à jour progressives et la mise à l'échelle horizontale, ont introduit de nouvelles complexités que les développeurs doivent comprendre et anticiper. Lors d'un atelier en direct, Antonis a présenté ce qui ne fonctionne pas lors des déploiements et comment l'éviter.

Comprendre l'architecture de déploiement Django

Chaque déploiement d'application Django se compose de plusieurs éléments clés qui fonctionnent ensemble. À l'avant, vous avez un serveur proxy, généralement Nginx, Apache ou des options plus récentes comme Caddy et Traefik. Ce proxy gère la terminaison TLS, le routage de domaine et les redirections. Derrière lui se trouve votre serveur d'applications, généralement Gunicorn ou Uvicorn pour les applications asynchrones. Ceux-ci sont pris en charge par une couche de cache (telle que Redis ou Memcached) et une base de données (PostgreSQL, MySQL ou, de plus en plus, SQLite, pour certains cas d'utilisation).

Cette architecture fonctionne bien pour les déploiements sur un seul serveur, mais les applications modernes s'exécutent souvent sur plusieurs serveurs avec des mises à jour continues, ce qui crée des scénarios où différentes versions de votre application s'exécutent simultanément.

Le défi des ressources statiques

Lorsque vous développez des applications Django localement, manage.py runserver gère automatiquement le service des fichiers statiques. En production, cependant, cette approche devient problématique. Les serveurs d'applications Python sont conçus pour traiter une seule requête à la fois (à quelques exceptions près pour ASGI), ce qui les rend inadaptés au service de contenu statique, tel que CSS, JavaScript et images.

Le problème se multiplie avec l'échelle

Le véritable défi survient lorsque plusieurs serveurs d'applications exécutent différentes versions de votre code. Prenons l'exemple suivant : vous mettez à jour votre CSS avec une nouvelle couleur de marque et vous le déployez à l'aide de l'ManifestStaticFilesStorage de Django. Ce backend de stockage crée des noms de fichiers hachés, tels que app.a1b2c3d4.css, afin de permettre une mise en cache permanente.

Au cours d'un déploiement progressif, vous pouvez avoir :

• Le serveur A exécute l'ancienne version avec app.old123.css
• Le serveur B exécute la nouvelle version avec app.new456.css

Si la demande d'un utilisateur pour le nouveau fichier CSS est acheminée vers l'ancien serveur, il recevra une erreur 404, ce qui perturbera la mise en page.

Solutions pour la gestion des ressources statiques

Stockage externe : téléchargez les fichiers statiques vers des services tels qu'Amazon S3 ou un stockage cloud similaire. Cela garantit que toutes les versions de votre application peuvent accéder aux mêmes fichiers statiques.

Mise en cache au niveau du proxy : configurez votre serveur proxy (Nginx, etc.) pour mettre en cache les fichiers statiques pendant une durée raisonnable. Cela crée un tampon pendant les déploiements, où les anciens fichiers restent disponibles pendant que les nouveaux se propagent.

Systèmes de fichiers partagés : montez le répertoire statique sur tous les serveurs afin que les anciennes et les nouvelles versions de l'application puissent servir les fichiers à partir du même emplacement.

Middleware WhiteNoise : cette bibliothèque Python sert les fichiers statiques directement à partir de votre application Django avec des en-têtes de mise en cache efficaces, bien qu'elle utilise les ressources du serveur d'applications.

Complexité des migrations de schémas

Les migrations Django sont puissantes, mais elles nécessitent une planification minutieuse dans les environnements multi-versions. Le présentateur l'a démontré à l'aide d'un exemple pratique utilisant une application de signalement d'observations de Bigfoot.

Le problème de compatibilité

L'ajout d'un nouveau champ à un modèle semble simple, mais considérez ce qui se passe lorsque vous ajoutez un champ obligatoire avec une valeur par défaut :

# New field added

gdpr_accepted = models.BooleanField(default=False)

Après avoir exécuté les migrations, la nouvelle version de l'application reconnaît ce champ, mais pas l'ancienne version. Lorsque l'ancienne version tente d'enregistrer un enregistrement, elle échoue car la base de données attend le champ d'gdpr_accepted , mais l'ancien code ne le fournit pas.

Valeurs par défaut de la base de données de Django 5

Le présentateur a mis en avant le nouveau paramètre db_default de Django 5 comme solution :

gdpr_accepted = models.BooleanField(db_default=False)

Avec db_default , c'est la base de données elle-même qui gère la valeur par défaut, et non le code Python. Cela signifie que les anciennes versions de l'application peuvent enregistrer des enregistrements avec succès, même sans connaître le nouveau champ.

Meilleures pratiques en matière de stratégie de migration

• Compatibilité ascendante et descendante : concevez des migrations qui fonctionnent à la fois avec la version actuelle et les versions précédentes du code de votre application.
• Déploiements en plusieurs étapes : pour les modifications de schéma complexes, envisagez un déploiement en plusieurs étapes :

1. Ajoutez le nouveau champ comme pouvant être nul
2. Déployez le code qui gère à la fois l'ancien et le nouveau schéma
3. Remplissez les enregistrements existants
4. Rendez le champ non nul si nécessaire

• Considérations relatives à la migration des données : lorsque vous devez mettre à jour des données existantes, créez des migrations de données distinctes qui peuvent s'exécuter en toute sécurité parallèlement à l'ancien code de l'application.

Le défi de la mise à jour progressive

Les mises à jour progressives créent un état temporaire dans lequel plusieurs versions de votre application s'exécutent simultanément. Cela nécessite une coordination minutieuse entre :

• Le calendrier de migration : quand appliquer les modifications de la base de données
• Déploiement du code : garantir la compatibilité entre les versions
• Distribution des fichiers statiques : gestion des versions des ressources sur les serveurs
• Planification de la restauration : avoir une stratégie claire en cas de problème

Réalité des restaurations

Si Django semble simplifier la restauration des migrations grâce à manage.py migrate app_name 0001 , les restaurations en production sont rarement aussi simples. Le présentateur a souligné, d'après son expérience, que les restaurations rencontrent souvent des problèmes inattendus, ce qui rend la prévention par une planification minutieuse plus précieuse que le recours aux capacités de restauration.

Stratégies de déploiement pratiques

• Parité de l'environnement : assurez-vous que votre environnement de test reflète fidèlement la production, y compris les configurations multi-serveurs lorsque cela est possible.
• Indicateurs de fonctionnalités : utilisez des indicateurs de fonctionnalités pour déployer du code sans exposer immédiatement les nouvelles fonctionnalités, ce qui vous permet de séparer le déploiement du code de l'activation des fonctionnalités.
• Déploiements bleu-vert : maintenez deux environnements de production identiques et basculez le trafic entre eux, éliminant ainsi complètement la complexité liée à la gestion de plusieurs versions.
• Versions Canary : acheminez progressivement le trafic vers les nouvelles versions, ce qui vous permet de détecter les problèmes avant qu'ils n'affectent tous les utilisateurs.

Solutions de plateforme

Les fournisseurs modernes de plateformes en tant que service, tels que Upsun, répondent à bon nombre de ces défis grâce à :

• Gestion automatisée des fichiers statiques avec stockage partagé
• Migrations de bases de données gérées avec contrôles de synchronisation
• Des couches de mise en cache intégrées au niveau du proxy
• Des outils pour coordonner les déploiements multiservices

Cependant, il reste essentiel de comprendre les défis sous-jacents, même lorsque l'on utilise des plateformes gérées.

Points clés

Les outils intégrés de Django, tels que les migrations et la gestion des fichiers statiques, sont puissants, mais ils nécessitent une application réfléchie dans les environnements de production. La complexité augmente considérablement lorsque vous passez de déploiements sur un seul serveur à des applications à échelle horizontale et déployées en continu.

Pour réussir, il faut :

• Planifier les migrations pour assurer la compatibilité entre les versions des applications
• La mise en œuvre de stratégies robustes de service de fichiers statiques
• Comprendre le calendrier et la coordination des déploiements progressifs
• Disposer de procédures de retour en arrière réalistes
• Tester les processus de déploiement dans des environnements de test

À mesure que les applications Django se développent et que les modèles de déploiement deviennent plus sophistiqués, les développeurs doivent élargir leur compréhension au-delà des modèles de développement locaux. Le framework fournit les outils, mais pour réussir les déploiements en production, il faut orchestrer soigneusement ces outils dans le contexte spécifique de votre infrastructure.

Si Django continue de faciliter notre travail de développement, le déploiement en production reste un domaine où une planification minutieuse et une bonne compréhension des systèmes sous-jacents sont payantes en termes de fiabilité des applications et d'expérience utilisateur.