Annexes Déployer votre application en production

Tout au long du cours, nous avons utilisé le serveur de développement de Django. Cependant, ce serveur de développement n'est adapté que pour le développement, et pas du tout pour la mise en production dans une situation réelle.

Nous allons voir dans ce chapitre comment déployer un projet Django en production sur un serveur dédié Linux. Si vous ne disposez pas de serveur dédié, sachez qu'il existe certains hébergeurs qui proposent également l'installation et la gestion d'un projet Django, nous en avons listé quelques-uns à la fin de ce chapitre.

Le déploiement

Contrairement à ce que certains peuvent penser, le serveur de développement ne peut pas être utilisé en production. En effet, celui-ci n'apporte pas les conditions de sécurité et de performances suffisantes pour garantir un service stable. Le rôle d'un framework n'est pas de distribuer les pages web, c'est au serveur web qu'incombe ce travail.

Nous allons voir comment installer notre projet sur un serveur Apache 2 avec le mod_wsgi (cependant, tout autre serveur web avec le protocole WSGI peut faire l'affaire aussi) sur un serveur Linux dont vous devez avoir un accès root. Le protocole WSGI est une sorte de couche qui permet à un serveur web et une application web Python de communiquer ensemble.

Sachez que vous pouvez également déployer un projet Django sur certains hébergements mutualisés le supportant.

Généralement, une documentation de l'hébergeur sera mise à votre disposition pour vous indiquer comment le déployer sur leur infrastructure. Si vous souhaitez déployer Django sur votre propre serveur, ce chapitre vous expliquera tout ce que vous devrez savoir.

Par défaut, Django fournit un fichier wsgi.py qui s'occupera de cette liaison. Pour rappel :

Code : Autre crepes_bretonnes/ manage.py crepes_bretonnes/ __init__.py settings.py urls.py wsgi.py

Ce fichier n'a pas besoin d'être modifié. Il est normalement correctement généré selon les paramètres de votre projet.

Il faut savoir qu'un projet Django ne se déploie pas comme un projet PHP. En effet, si nous tentons d'héberger le projet sur un serveur Apache avec une configuration basique, voici le résultat :

Une liste de fichiers Python que nous ne pouvons que télécharger

Non seulement votre code n'est pas exécuté, mais il est lisible par tous. Il faut donc spécifier à Apache d'utiliser le protocole WSGI pour que Django puisse exécuter le code et renvoyer du HTML.

Dans un premier temps il va falloir installer le module WSGI. Sous la plupart des distributions Linux, un paquet existe pour nous simplifier la vie. Par exemple, pour Debian :

Code : Console

# aptitude install libapache2-mod-wsgi

N'oubliez cependant pas, si vous n'avez pas Django ou Apache2 d'installé, de les installer également ! Nous ne couvrirons pas l'installation d'Apache2, ni sa configuration basique. Sachez bien évidemment que vous pouvez utiliser d'autres serveurs HTTP : nginx, lighttpd, etc.

Ensuite, modifions le fichier /etc/apache2/httpd.conf pour indiquer où trouver notre application. Si ce fichier n'existe pas, créez-le. Voici la configuration à insérer :

Code : Autre WSGIScriptAlias / /chemin/vers/crepes_bretonnes/crepes_bretonnes/wsgi.py WSGIPythonPath /chemin/vers/crepes_bretonnes/ <Directory /chemin/vers/crepes_bretonnes/> <Files wsgi.py> Order deny,allow Allow from all </Files>

</Directory>

La première ligne, WSGIScriptAlias, indique que toutes les URLs commençant par « / » (qui indique la racine du serveur) devront utiliser l'application définie par le second argument, qui est ici le chemin vers notre fichier wsgi.py. La deuxième ligne, WSGIPythonPath, permet de rendre accessible votre projet via la commande import en Python. Ainsi, le module wsgi pourra lancer notre projet Django.

uniquement.

Sauvegardez ce fichier. Si vous souhaitez changer des informations sur le nom de domaine ou le port, il faudra passer par les VirtualHosts d'Apache (ce que nous ne couvrirons pas ici).

Nous allons pouvoir modifier les paramètres de notre projet (settings.py). Dans un premier temps, à la création de notre projet, nous avions défini quelques variables : base de données, chemin d'accès, etc. Il va falloir les adapter à notre serveur de production.

Voici les variables à modifier :

Passer la variable DEBUG à False pour indiquer que le site est désormais en production. Il est très important de le faire, sans quoi les erreurs et des données sensibles seront affichées !

Remplir la variable ALLOWED_HOSTS qui doit contenir les différentes adresses depuis lesquelles le site peut être accédé. Exemple : ALLOWED_HOSTS = ['www.crepes-bretonnes.com', '.super-crepes.fr']. Le point au début du deuxième élément de la liste permet d'indiquer que tous les sous-domaines sont acceptés, autrement dit, les domaines suivants seront accessibles : super-crepes.fr, www.super-crepes.fr, media.super-crepes.fr, coucou.super- crepes.fr, etc.

Adaptez la connexion à la base de données en fonction de ce que vous souhaitez utiliser en production. Nous vous conseillons d'utiliser MySQL ou PostgreSQL en production. N'oubliez pas d'installer les extensions nécessaires si vous souhaitez utiliser autre chose que SQLite.

Adaptez le chemin vers le dossier templates/ et les divers autres dossiers possibles.

Sauvegardez et relancez Apache (service apache2 reload ). Votre site doit normalement être accessible !

Si vous obtenez une erreur Internal Server Error, pas de panique, c'est sûrement dû à une erreur dans votre configuration. Pour traquer l'erreur, faites un tail -f /var/log/apache2/error.log et regardez l'exception lancée lors du chargement d'une page.