Aventuresdata

Deployer une application Django avec Gunicorn et Nginx

Le serveur de développement intégré de Django (python manage.py runserver) n’est pas conçu pour être utilisé en production car il manque de performance, de sécurité, et de fiabilité.
Gunicorn, en revanche, est conçu pour être un serveur de production. Gunicorn est capable de gérer de multiples requêtes simultanément de manière efficace ce qui est essentiel pour les applications web en production.

Gunicorn est souvent utilisé avec des serveurs web comme Nginx ou Apache.

Nginx agit comme un « bouclier » (Reverse Proxy) en première ligne pour intercepter les requêtes HTTP et servir les fichiers statiques, tandis que Gunicorn (serveur WSGI) fait tourner le code Python en arrière-plan.

Etape 1: Installez Gunicorn :

source .env/bin/activate
pip install gunicorn

Etape 2: Testez Gunicorn :

|-src
|   |-blog
|   |    |-wsgi.py
|   |    |-settings.py
|   |    |-urls.py
|   |    |-…
Placer vous dans le repertoire src/

gunicorn blog.wsgi:application --bind 127.0.0.1:8000

Avant d’automatiser Gunicorn, on vérifie qu’il arrive à lire le point d’entrée de l’application (blog.wsgi:application).
Si la mise en page n’est pas bonne, c’est que les fichiers statiques ne sont pas correctement servis par Django.

Ajoutez également ces lignes en bas du fichier blog/urls.py +.

if settings.DEBUG:
   urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
   urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_URL)

Ajoutez ces lignes d’importation en haut du fichier blog/urls.py.

from django.conf import settings # new
from django.conf.urls.static import static # new

Etape 3: Configurer Gunicorn :

Désactivez l’environnement virtuel:

deactivate

Au lieu de faire communiquer Nginx et Gunicorn via un port réseau (comme le port 8000), ils vont communiquer via un socket Unix (/run/gunicorn.sock).
C’est un fichier d’échange local beaucoup plus rapide et sécurisé qu’une connexion réseau interne.
Créez un fichier de socket système pour Gunicorn:

sudo nano /etc/systemd/system/gunicorn.socket

Copier le contenu ci-dessous et enregistrer le fichier:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

Ensuite, créez un fichier de service pour Gunicorn :

sudo nano /etc/systemd/system/gunicorn.service

Copier le contenu ci-dessous et enregistrer le fichier:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=your_user
Group=www-data
WorkingDirectory=/home/your_user/blogprojectdrf
ExecStart=/home/your_user/blogprojectdrf/env/bin/gunicorn \
   --access-logfile - \
   --workers 3 \
   --bind unix:/run/gunicorn.sock \
   blog.wsgi:application

[Install]
WantedBy=multi-user.target

–workers 3 : C’est le nombre de processus parallèles. La formule standard de Gunicorn est (2 x nombre de cœurs CPU) + 1. Avec 3 workers, vous exploitez parfaitement une instance EC2 dotée de 1 ou 2 cœurs.

User=your_user : Gunicorn doit tourner avec les privilèges de votre utilisateur système (ex: debian ou ubuntu), jamais en root pour des raisons évidentes de sécurité.

Le groupe www-data est généralement créé par défaut lors de l’installation de serveurs web tels qu’Apache ou Nginx.
On donne le groupe de Nginx (www-data) à Gunicorn pour qu’ils puissent tous les deux lire et écrire dans le fichier de socket commun.
Si vous avez installé l’un de ces serveurs, le groupe www-data devrait déjà exister. Vous pouvez vérifier si le groupe www-data existe déjà en utilisant la commande suivante :

getent group www-data

Ajouter l’utilisateur your_user au groupe www-data.
Nginx a besoin de naviguer dans votre dossier utilisateur pour aller chercher les fichiers statiques.
le chmod 750 permet au groupe www-data de lire votre répertoire sans pour autant donner l’accès au reste du monde:

sudo adduser your_user
sudo usermod -aG www-data your_user
sudo chown -R your_user:www-data /home/your_user/blogprojectdrf

Démarrez et activez le socket Gunicorn :

sudo systemctl start gunicorn.socket
sudo systemctl enable gunicorn.socket

Pour vérifier le statut de gunicorn :

sudo systemctl status gunicorn

Pour tester gunicorn :
Placez vous dans le repertoire src/

sudo gunicorn blog.wsgi:application --bind 127.0.0.1:8000

Etape 4: Installer Nginx :

sudo apt install nginx

Etape 5: Configurer Nginx pour Utiliser le Socket Gunicorn :

Avant de créer le fichier Nginx, avec cette commande, vous pouvez vérifier l’existence du fichier:

cd /etc/nginx/sites-enabled

Nginx est livré avec une configuration d’exemple (« Welcome to Nginx ») liée au port 80.
Si vous ne supprimez pas ce lien dans sites-enabled, il va entrer en conflit avec votre propre configuration Django qui veut elle aussi écouter sur le port 80.
Vous pouvez supprimer le fichier par défault à l’aide de cette commande :

sudo rm /etc/nginx/sites-enabled/default

Etape 6: Configurer Nginx comme proxy inverse :

Créez un fichier de configuration pour Nginx:

sudo touch /etc/nginx/sites-available/blog
sudo nano /etc/nginx/sites-available/blog

Copier le contenu ci-dessous et enregistrer le fichier:

server {
   listen 80 default_server;
   server_name your_domain_or_IP;;
   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
      alias /home/your_user/blogprojectdrf/static/;
   }
   location /media/ {
      alias /home/your_user/blogprojectdrf/media/;
   }
   location / {
      proxy_pass http://unix:/run/gunicorn.sock;
      proxy_set_header Host host;proxysetheaderX−Real−IPremote_addr;
      proxy_set_header X-Forwarded-For proxy_add_x_forwarded_for; 
       proxy_set_header X-Forwarded-Protoscheme;
   }
}

  • listen 80 default_server : Nginx écoute le trafic HTTP standard (port 80).
  • Les blocs location /static/ et location /media/ : C’est le secret de la performance. Quand une requête demande un fichier CSS ou une image, Nginx intercepte la demande et va chercher directement le fichier dans le dossier (alias), sans jamais déranger Django ni Gunicorn.
  • Le bloc location / (Le reste du trafic) : Tout ce qui n’est pas un fichier statique (les pages, l’administration, les requêtes API) est envoyé directement au socket Gunicorn via proxy_pass http://unix:/run/gunicorn.sock;.
  • Les proxy_set_header : Indispensables. Ils transmettent à Django les vraies informations de l’utilisateur (comme son adresse IP d’origine X-Real-IP), sinon Django croirait que toutes les requêtes proviennent localement de Nginx.
  • Le lien symbolique (ln -s) : Dans Nginx, sites-available contient les brouillons de vos configurations. Faire un lien symbolique vers sites-enabled équivaut à « activer » le site.
  • nginx -t : Le réflexe absolu. Cette commande valide la syntaxe de votre fichier avant de relancer le serveur, évitant ainsi de faire crasher Nginx en production à cause d’un point-virgule oublié.

Activez la configuration :

sudo ln -s /etc/nginx/sites-available/blog /etc/nginx/sites-enabled/

Tester la Configuration de Nginx:

sudo nginx -t

Testez un fichier statique:
si besoin accorder les droits de lecture au groupe www-data

sudo chown -R your_user:www-data /home/your_user/blogprojectdrf
sudo chmod 750 /home/your_user/blogprojectdrf

Redémarrez Nginx et Gunicorn :

sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo service gunicorn restart
sudo service nginx restart

Etape 7: Vérifier l’Accès au Site Localement :

Ouvrez votre navigateur et accédez à http://localhost ou http://127.0.0.1 pour vérifier que votre application Django est correctement déployée et fonctionne avec Gunicorn et Nginx.

Pour vérifier le statut de gunicorn :

sudo systemctl status gunicorn

Si Nginx ne parvient pas à joindre le socket de Gunicorn (souvent à cause d’un problème de droit sur le dossier /home/your_user), l’erreur exacte sera écrite dans les journaux d’erreurs de Nginx :

$ sudo tail -f /var/log/nginx/error.log

Pour vérifier si Nginx fonctionne correctement :

$ sudo systemctl status nginx
sudo fuser -k 8000/tcp
sudo lsof -t -i tcp:8000 | xargs kill -9

Cela permet de vérifier l’état de Nginx, d’arrêter tout processus utilisant le port 8000 et de tuer les connexions actives sur ce port.
Parfois, lors des phases de tests manuels précédents, un vieux processus Gunicorn peut rester « fantôme » et bloquer le port ou le socket. Ces commandes permettent de nettoyer la mémoire proprement pour repartir sur des bases saines avec Systemd.

Tags:
Previous Article
Next Article

Laisser un commentaire

Your email address will not be published. Required fields are marked *.

*
*