Déployer Django.Gardez les paramètres et les versions explicites.
Mettez en production un projet Django en réunissant le processus WSGI de production, les paramètres d’exécution, les identifiants de la base de données, les contrôles de santé, la gestion des ressources statiques et les éléments de vérification de la version.
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios
Version candidate
Django
Opérationnel
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source reçue
02Compilation terminée
03Environnement d’exécution démarré
04Vérification de santé réussie
Route promue en production
production.adios.run
Une mise en production adaptée à
DjangoGunicornWSGIPostgreSQLRessources statiques
Le parcours de mise en production
Même opérationnel, un projet Django doit être mis en production en toute sécurité.
L’application ou le service ne représente qu’une partie de la production. Les résultats de compilation, l’état d’exécution, les contrôles de santé, les secrets, les journaux, les routes et la version promue doivent pouvoir être examinés ensemble.
Conservez votre méthode de compilation Django
Installez les dépendances Python et effectuez la préparation propre à votre projet. Gardez les choix concernant collectstatic et les migrations explicites, au lieu de les masquer derrière un bouton du tableau de bord.
Promouvoir la version dont les contrôles de santé réussissent
Démarrez l’application WSGI avec Gunicorn, écoutez sur le port déclaré et utilisez une route de contrôle de santé qui confirme la disponibilité du processus web sans modifier les données.
Relier la production au code source
Les résultats de compilation, les journaux d’exécution, l’état de santé, les secrets, les domaines et la version promue restent associés au projet au lieu d’être dispersés entre des outils indépendants.
Du code source à la mise en production
Trois étapes vous permettent de vérifier le parcours de déploiement.
Utilisez le code source et le fonctionnement en production déjà définis pour le projet. Le manifeste décrit ce que la plateforme doit compiler ou provisionner et les critères à remplir pour que le résultat soit prêt.
01
Commencer par la source ou un modèle
Importez le dépôt existant, ou examinez et déployez l’une des variantes de modèles précisément référencées ci-dessous.
$adios login
02
Revoir le contrat de déploiement
Consignez dans adios.yaml les commandes, la version de l’environnement d’exécution ou du service, les critères de santé et les références aux secrets.
$git diff -- adios.yaml
03
Déployer et inspecter le résultat
Suivez les résultats de compilation et d’exécution, vérifiez la version candidate, puis ouvrez la route ou la connexion de service promue en production.
Vérifier la charge de travail.Puis promouvez la version en production.
Pour sécuriser la première mise en production, partez d’une compilation ou d’une configuration de service reproductible et d’un aperçu qui sollicite les dépendances réellement utilisées en production.
Prêt quand...
La configuration de production n’active pas DEBUG.
ALLOWED_HOSTS et les origines de confiance CSRF incluent le domaine de production.
Les fichiers statiques et les fichiers téléversés disposent d’un chemin de stockage explicite.
Les clés de la base de données et de signature proviennent de secrets.
Prévisualiser quand...
Une migration de schéma modifie ou verrouille des données de production.
collectstatic dépend d’un service distant de ressources statiques.
Le projet utilise des bibliothèques Python natives ou de traitement d’images.
Les réponses à vos questions
Ce qu’il faut savoir avant de déployer Django.
Vérifiez les limites de l’environnement d’exécution ou du service, le chemin du modèle, le comportement en cas d’échec et les contrôles de production avant de créer la première version.
Adios peut-il déployer un projet Django existant ?
Oui. Exécutez la CLI Adios depuis la racine du projet, conservez votre dépôt et vos fichiers de dépendances et ajoutez un fichier adios.yaml décrivant la compilation de production, la commande de démarrage, le port et le chemin de contrôle de santé.
Ai-je besoin de Docker pour déployer Django ?
Pas pour un environnement d’exécution standard pris en charge. Utilisez les commandes de production habituelles du projet dans adios.yaml. Si la compilation nécessite des packages système inhabituels ou des bibliothèques natives, vérifiez ces dépendances dans un aperçu avant la promotion en production.
Les migrations Django doivent-elles s’exécuter à chaque compilation ?
Traitez les modifications du schéma de production comme une étape explicite de mise en production. Testez-les sur des données représentatives et choisissez une stratégie d’approbation ou de workflow, plutôt que d’associer chaque compilation à une migration automatique.
Comment servir les fichiers statiques Django ?
Définissez une stratégie de production explicite : ressources collectées et servies par l’application, stockage d’objets ou autre mode de diffusion statique. Vérifiez les en-têtes de cache et les URL sur le domaine de prévisualisation.
Que se passe-t-il si la compilation ou le contrôle de santé échoue ?
La version candidate conserve ses résultats de compilation et d’exécution pour vérification. Ses contrôles de santé doivent réussir avant sa promotion comme version desservant la route de l’application.
Puis-je partir d’un modèle plutôt que d’un dépôt existant ?
Oui. Cette page référence les modèles Adios officiels les plus proches pour Django. Examinez la variante exacte du code source, déployez-la dans la console ou clonez-la localement et exécutez adios up.