Faire tourner django avec nginx
Nous allons voir ici comment monter un serveur d'application django, avec nginx. Le tout dans la tradition python.
Comme pour le php, une page python n'est pas directement interprétée par le serveur http, mais par un service tiers.
Pour que tout se passe bien, il faut donc assurer une bonne communication entre django et le serveur http.
Au choix, soit on passe par un module CGI comme fastcgi, soit on utilise un serveur WSGI. La première solution est donnée comme moins efficace que la seconde. WSGI est un standard python.
Gunicorn est le serveur wsgi privilégié. c'est tout ? Non, car une instance gunicorn doit être démarrée, redémarrée, stoppée comme tout les services de la machine. On va donc utiliser une autre application pour s'occuper de ce travail : supervisor.
On a donc, nginx en serveur HTTP qui va faire du reverse proxy vers gunicorn. supervisor, va assurer le démarrage de notre instance gunicorn. Gunicorn va communiquer directement avec django.
Cette fois, c'est tout ? Non, toujours pas. Il n'est pas rare, qu'un développement nécessite une bibliothèque en version x, alors qu'un autre en version x+1. Pour cela, les développeurs python disposent de virtualenv. Virtualenv, permet de créer des environnement autonome. On peux voir ça comme un chroot applicatif.
Maintenant que l'on a fait le tour des applications et modules dont nous avons besoins, on passe à l'installation :
Installation, de supervisor et du gestionnaire de paquet python : pip
Installation des modules python
ou
Le minimum requis étant installé, il est temps de créer un premier projet django :
Nous avons donc crée un nouvel environnement virtuel test-django, et personnalisé le prompt afin qu'il affiche TEST.
On entre dans notre répertoire test-django, on charge notre environnement, on y install gunicorn et django. Initialisation du projet hello.
On va pouvoir tester que notre projet fonctionne en démarrant le serveur embarqué :
Miracle, si l'on tappe l'url dans notre navigateur tout fonctionne.
La même chose avec gunicorn ?
On rajoute nginx ?
Alors on va supprimer le site par defaut
On va créer notre fichier de configuration :
Et au démarrage, de nginx, une visite sur localhost doit nous donner le même résultât qu'avant.
Pour terminer, il nous reste plus qu'à configurer le lancement de gunicorn, via supervisor et nous serons prêt.
Il y a beaucoup de littérature sur le sujet. En gros il s'agit de créer dans chaque environnement un script qui se charge de lancer l'instance gunicorn avec les bons paramètres, et de demander à supervisor d'exécuter et surveiller ce script.
Plutôt de copier ici un script, ou de ré-inventer la roue, je vous renvoie à cette adresse :
http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
A lire également :
http://nvie.com/posts/a-successful-git-branching-model/
http://blog.sietch-tabr.com/index.php/post/2010/04/04/Heberger-des-projets-Django-avec-Nginx-et-Gunicorn
http://senko.net/en/django-nginx-gunicorn/
http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/
http://blog.sietch-tabr.com/index.php/post/2010/06/03/gestion-et-surveillance-de-processus-syst%C3%A8me-avec-supervisor-pour-gerer-des-projets-django-ruby-on-rails-wsgi
Comme pour le php, une page python n'est pas directement interprétée par le serveur http, mais par un service tiers.
Pour que tout se passe bien, il faut donc assurer une bonne communication entre django et le serveur http.
Au choix, soit on passe par un module CGI comme fastcgi, soit on utilise un serveur WSGI. La première solution est donnée comme moins efficace que la seconde. WSGI est un standard python.
Gunicorn est le serveur wsgi privilégié. c'est tout ? Non, car une instance gunicorn doit être démarrée, redémarrée, stoppée comme tout les services de la machine. On va donc utiliser une autre application pour s'occuper de ce travail : supervisor.
On a donc, nginx en serveur HTTP qui va faire du reverse proxy vers gunicorn. supervisor, va assurer le démarrage de notre instance gunicorn. Gunicorn va communiquer directement avec django.
Cette fois, c'est tout ? Non, toujours pas. Il n'est pas rare, qu'un développement nécessite une bibliothèque en version x, alors qu'un autre en version x+1. Pour cela, les développeurs python disposent de virtualenv. Virtualenv, permet de créer des environnement autonome. On peux voir ça comme un chroot applicatif.
Maintenant que l'on a fait le tour des applications et modules dont nous avons besoins, on passe à l'installation :
Installation, de supervisor et du gestionnaire de paquet python : pip
apt-get install python-pip python-dev nginx supervisor
Installation des modules python
pip install virtualenv setproctitle
ou
pip install virtualenv --proxy=http://user:pass@proxy:port
Le minimum requis étant installé, il est temps de créer un premier projet django :
virtualenv test-django --prompt TEST
cd test-django
source bin/activate
pip install gunicorn django
django-admin.py startproject hello
Nous avons donc crée un nouvel environnement virtuel test-django, et personnalisé le prompt afin qu'il affiche TEST.
On entre dans notre répertoire test-django, on charge notre environnement, on y install gunicorn et django. Initialisation du projet hello.
On va pouvoir tester que notre projet fonctionne en démarrant le serveur embarqué :
python manage.py runserver 0.0.0.0:8000
Miracle, si l'on tappe l'url dans notre navigateur tout fonctionne.
La même chose avec gunicorn ?
gunicorn_django -b 0.0.0.0:8000
On rajoute nginx ?
Alors on va supprimer le site par defaut
rm /etc/nginx/site-enabled/default
On va créer notre fichier de configuration :
vi /etc/nginx/site-available/test-django
server {
root /home/alexandre/test-django;
index index.html index.htm;
server_name localhost;
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
proxy_pass http://localhost:8000/;
}
}Et au démarrage, de nginx, une visite sur localhost doit nous donner le même résultât qu'avant.
Pour terminer, il nous reste plus qu'à configurer le lancement de gunicorn, via supervisor et nous serons prêt.
Il y a beaucoup de littérature sur le sujet. En gros il s'agit de créer dans chaque environnement un script qui se charge de lancer l'instance gunicorn avec les bons paramètres, et de demander à supervisor d'exécuter et surveiller ce script.
Plutôt de copier ici un script, ou de ré-inventer la roue, je vous renvoie à cette adresse :
http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
A lire également :
http://nvie.com/posts/a-successful-git-branching-model/
http://blog.sietch-tabr.com/index.php/post/2010/04/04/Heberger-des-projets-Django-avec-Nginx-et-Gunicorn
http://senko.net/en/django-nginx-gunicorn/
http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/
http://blog.sietch-tabr.com/index.php/post/2010/06/03/gestion-et-surveillance-de-processus-syst%C3%A8me-avec-supervisor-pour-gerer-des-projets-django-ruby-on-rails-wsgi
