Comment déployer avec WSGI

La plate-forme principale de déploiement Django est WSGI, le standard Python pour les serveurs et applications Web.

La commande de gestion startproject de Django définit par défaut une configuration WSGI simple pour vous, que vous pouvez ensuite adapter aux besoins de votre projet ; cette configuration est alors utilisable par tout serveur d’applications se conformant au standard WSGI.

Django contient de la documentation sommaire pour les serveurs WSGI suivants :

L’objet application

Le concept-clé dans le déploiement avec WSGI est l’objet exécutable application que le serveur d’applications utilise pour communiquer avec votre code. Ceci est généralement fourni par un objet nommé application dans un module Python accessible par le serveur.

La commande startproject crée un fichier <nom_de_projet>/wsgi.py qui contient l’objet exécutable application.

Il est utilisé aussi bien par le serveur de développement de Django que par les déploiements WSGI en production.

Les serveurs WSGI obtiennent le chemin vers l’exécutable application à partir de leur configuration. Les serveurs intégrés dans Django, à savoir les commandes runserver et runfcgi, lisent cette information à partir du réglage WSGI_APPLICATION. Par défaut, il est défini à <nom_du_projet>.wsgi.application qui pointe sur l’exécutable application dans <nom_du_projet>/wsgi.py.

Configuration du module de réglages (settings)

Lorsque le serveur WSGI charge une application, Django doit importer le module settings, c’est là où se trouve toute la configuration de votre application.

Django utilise la variable d’environnement DJANGO_SETTINGS_MODULE pour trouver le module settings approprié. Il doit contenir le chemin vers le module settings avec la syntaxe pointée. Il est possible d’utiliser une valeur différente entre le développement et la production ; tout dépend de la façon d’organiser les réglages.

Si cette variable n’est pas définie, le fichier wsgi.py par défaut la définit à monsite.settings, où monsite est le nom de votre projet. C’est comme cela que runserver trouve le fichier de réglages par défaut.

Note

Comme les variables d’environnement s’appliquent à tout un processus, cela ne marche pas lorsque vous exécutez plusieurs sites Django dans le même processus. Ceci peut se produire avec mod_wsgi.

Pour éviter ce problème, utilisez le mode « daemon » de mod_wsgi, chaque site ayant son propre processus « daemon », où surchargez la valeur de l’environnement en imposant os.environ["DJANGO_SETTINGS_MODULE"] = "monsite.settings" dans votre fichier wsgi.py.

Application des intergiciels WSGI

Pour appliquer un intergiciel WSGI, vous pouvez simplement encapsuler l’objet application. Par exemple, vous pouvez ajoutez ces lignes au bas du fichier wsgi.py:

from helloworld.wsgi import HelloWorldApplication
application = HelloWorldApplication(application)

Vous pourriez aussi remplacer l’application WSGI de Django avec une application WSGI personnalisée qui défère l’application WSGI de Django à plus tard, dans le cas où vous souhaitez combiner une application Django avec une application WSGI d’un autre système applicatif.

Note

Certains middlewares WSGI de tierce partie n’appellent pas close sur la réponse après avoir traité une requête, notamment le middleware de signalement d’erreurs de Sentry jusqu’à la version 2.0.7. Dans ces cas, le signal request_finished n’est pas envoyé. Par conséquent, il se peut que des connexions de base de données et de serveurs memcache puissent être laissées ouvertes.

Mise à jour à partir de Django < 1.4

Si vous mettez à jour votre projet depuis Django 1.3.x ou une version plus ancienne, vous ne possédez pas de fichier wsgi.py dans votre projet.

Vous pouvez simplement en ajouter un dans le paquet Python du premier niveau de votre projet (probablement en compagnie des fichiers settings.py et urls.py) avec le contenu ci-dessous :

import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

La ligne os.environ.setdefault ne fait que définir le module settings à utiliser par défaut, si vous n’avez pas explicitement défini la variable d’environnement DJANGO_SETTINGS_MODULE. Vous devrez éditer cette ligne pour remplacer mysite par le nom du paquet de votre projet, afin que le chemin vers votre module settings soit correct.

Ajoutez également WSGI_APPLICATION = "monsite.wsgi.application" dans vos réglages afin que runserver trouve l’exécutable application. Dans cette ligne, n’oubliez pas de remplacer monsite par le nom de votre projet.