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

# Chemin du fichier : blog_project/settings.py
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

# Chemin du fichier : blog_project/settings.py

# 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

  1. Visitezrailway.app, connectez-vous avec un compte GitHub
  2. Cliquez sur « Nouveau projet » → « Déployer depuis le dépôt GitHub » → Sélectionnez le dépôt django-blog
  3. Railway détecte automatiquement le Procfile et reconnaît la commande de démarrage.
  4. Définissez les variables d'environnement dans Variables.
  5. Cliquez sur Déployer et attendez que la compilation et le déploiement soient terminés.

Configuration des variables d'environnement

Nom de la variableValeurDescription
SECRET_KEYLongue chaîne générée aléatoirementClé de sécurité Django
DEBUGFalseDésactivez le mode débogage
ALLOWED_HOSTS.railway.appAutoriser 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'apprentissagePour 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
PostgreSQLUne base de données de niveau production est nécessaireRemplacer SQLite et utiliser django-environ pour gérer la configuration de la base de données
Tâche asynchrone CeleryBesoin 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/ReactBesoin d'une architecture séparée front-end/back-endConstruire 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