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 :

• Django avec Apache et mod_wsgi
• Authentification sur la base de données des utilisateurs de Django depuis Apache
• Déploiement de Django avec Gunicorn
• Déploiement de Django avec uWSGI

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 intergiciels WSGI de tierce partie n’appellent pas close sur la réponse après avoir traité une requête. 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.