Packaging pour la production — Déploiement sur Railway
Dans ce chapitre, vous apprendrez à configurer l'environnement de production, à déployer l'application de blog Django sur Railway et à obtenir un lien d'accès public.
Configuration de l'environnement de production
Dans l'environnement de développement, DEBUG=True, et Django affiche des informations d'erreur détaillées et des pages de débogage.
Dans l'environnement de production, DEBUG doit être désactivé, et les options de sécurité doivent être correctement configurées.
configuration de production settings.py
Exemple
import os
# Lire la clé secrète à partir d'une variable d'environnement (ne pas la coder en dur dans le code)
SECRET_KEY = os.environ.get('SECRET_KEY', 'Clé secrète par défaut de l'environnement de développement')
# DEBUG est contrôlé via des variables d'environnement.
DEBUG = os.environ.get('DEBUG', 'True').lower() == 'true'
# Noms d'hôtes autorisés
ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '127.0.0.1,localhost').split(',')
# Répertoire de collecte des fichiers statiques
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') # staticfiles/ dans le répertoire racine du projet
STATIC_URL = '/static/'
SECRET_KEYIl s'agit de la clé de sécurité la plus importante de Django, utilisée pour chiffrer les sessions, les jetons CSRF, etc. Elle ne doit jamais être codée en dur dans le code ni être commitée dans Git. En environnement de production, elle est injectée via des variables d'environnement.
Gestion des dépendances et requirements.txt
Générez une liste de dépendances ; la plateforme de déploiement l'utilise pour installer les paquets requis par le projet.
(venv) $ pip freeze > requirements.txt
Vérifiez le contenu du fichier pour vous assurer que les dépendances clés suivantes sont incluses :
Django>=5.0,<6.0 gunicorn>=21.0 # 生产级 WSGI 服务器 whitenoise>=6.0 # 静态文件服务(可选)
Si gunicorn n'est pas présent, installez-le d'abord :
(venv) $ pip install gunicorn (venv) $ pip freeze > requirements.txt
Configurer Gunicorn + Whitenoise
Intégré à DjangorunserverNe convient pas à un environnement de production.
GunicornIl s'agit d'un serveur WSGI Python de qualité production qui gère les requêtes concurrentes.
WhitenoisePermet à Gunicorn de servir directement les fichiers statiques (CSS, JS, images).
Exemple
# Le middleware Whitenoise doit être placé après SecurityMiddleware et avant les autres middlewares.
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'whitenoise.middleware.WhiteNoiseMiddleware', # Ajouter : middleware pour les fichiers statiques
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
Créer dans le répertoire racine du projetProcfileindiquer à Railway comment démarrer l'application :
web: gunicorn blog_project.wsgi --log-file -
Collecter les fichiers statiques
Dans l’environnement de production, Django ne sert pas automatiquement les fichiers statiques ; vous devez utilisercollectstaticRegroupez dans un répertoire unifié.
(venv) $ python manage.py collectstatic
Cette commande copiera les fichiers statiques du backend Admin et de l'application blog versSTATIC_ROOTRépertoire (staticfiles/).
Dans un environnement de développement, vous n'avez généralement pas besoin d'exécuter collectstatic (Django trouve automatiquement le répertoire statique de chaque application). Cependant, il doit être exécuté avant le déploiement pour garantir que tous les fichiers statiques soient regroupés dans un seul répertoire à utiliser par le serveur web.
Poussez le projet vers GitHub
Créez .gitignore
Assurez-vous que les fichiers sensibles et les fichiers temporaires ne soient pas commités :
venv/ __pycache__/ *.pyc db.sqlite3 staticfiles/ .env
Poussez vers GitHub
$ git init $ git add . $ git commit -m "初始化 Django 博客项目" $ git branch -M main $ git remote add origin https://github.com/你的用户名/django-blog.git $ git push -u origin main
Déploiement sur Railway
RailwayIl s'agit d'une plateforme de déploiement cloud émergente qui prend bien en charge les applications full-stack telles que Django.
Étapes de déploiement
- Visitezrailway.app, connectez-vous avec un compte GitHub
- Cliquez sur « Nouveau projet » → « Déployer depuis le dépôt GitHub » → Sélectionnez le dépôt django-blog
- Railway détecte automatiquement le Procfile et reconnaît la commande de démarrage.
- Définissez les variables d'environnement dans Variables.
- Cliquez sur Déployer et attendez que la compilation et le déploiement soient terminés.
Configuration des variables d'environnement
| Nom de la variable | Valeur | Description |
|---|---|---|
| SECRET_KEY | Longue chaîne générée aléatoirement | Clé de sécurité Django |
| DEBUG | False | Désactivez le mode débogage |
| ALLOWED_HOSTS | .railway.app | Autoriser l'accès depuis le domaine Railway. |
Générer rapidement SECRET_KEY :
$ python -c "import secrets; print(secrets.token_urlsafe(50))"
Après un déploiement réussi, vous obtiendrez un lien comme :https://django-blog.up.railway.app
L'offre gratuite de Railway est limitée (5 $ par mois ou 500 heures). Si vous êtes juste en train de tester ou d'apprendre, pensez à mettre le projet en pause après l'avoir épuisé. Heroku a annulé son plan gratuit, donc ce tutoriel recommande Railway comme alternative.
Prochaine orientation d'apprentissage
| Orientation d'apprentissage | Pour qui est-ce destiné | Point de départ recommandé |
|---|---|---|
| Django REST Framework (DRF) | Besoin de construire un backend API pour les frameworks front-end (Vue3/React). | Apprendre Serializer + ViewSet pour transformer le blog en service API |
| PostgreSQL | Une base de données de niveau production est nécessaire | Remplacer SQLite et utiliser django-environ pour gérer la configuration de la base de données |
| Tâche asynchrone Celery | Besoin de tâches en arrière-plan (envoi d'e-mails, génération de rapports). | Intégrer Redis + Celery pour implémenter une file d'attente de tâches asynchrone. |
| Séparation front-end/back-end Django + Vue3/React | Besoin d'une architecture séparée front-end/back-end | Construire le backend API avec DRF, construire le frontend avec Vue3/React, et communiquer via fetch |
Résumé du chapitre
Dans ce chapitre, vous avez terminé l'étape finale : configuration de l'environnement de production (SECRET_KEY/DEBUG/ALLOWED_HOSTS), génération de requirements.txt, configuration de Gunicorn + Procfile, publication sur GitHub, et déploiement en un clic sur Railway.
autres extensions