Comment configurer Django avec Postgres, Nginx et Gunicorn sur Debian 11

De Get Docs
Aller à :navigation, rechercher

Introduction

Django est un framework Web puissant qui peut vous aider à faire décoller votre application Python ou votre site Web. Django inclut un serveur de développement pour tester votre code localement, mais pour tout ce qui est même légèrement lié à la production, un serveur Web plus sécurisé et plus puissant est requis.

Dans ce guide, vous allez installer et configurer certains composants sur Debian 11 pour prendre en charge et servir les applications Django. Vous configurerez une base de données PostgreSQL au lieu d'utiliser la base de données SQLite par défaut. Vous allez configurer le serveur d'applications Gunicorn pour qu'il s'interface avec vos applications. Vous configurerez ensuite Nginx pour inverser le proxy vers Gunicorn, vous donnant accès à ses fonctionnalités de sécurité et de performance pour servir vos applications.

Prérequis et objectifs

Pour terminer ce guide, vous devez disposer d'une nouvelle instance de serveur Debian 11 avec un pare-feu de base et un utilisateur non root avec sudo privilèges configurés. Vous pouvez apprendre à le configurer en parcourant notre guide de configuration initiale du serveur.

Vous installerez Django dans un environnement virtuel. L'installation de Django dans un environnement spécifique à votre projet permettra à vos projets et à leurs exigences d'être traités séparément.

Une fois que votre base de données et votre application sont opérationnelles, vous installerez et configurerez le serveur d'applications Gunicorn. Cela servira d'interface avec notre application, traduisant les demandes des clients de HTTP en appels Python que notre application peut traiter. Vous configurerez ensuite Nginx devant Gunicorn pour profiter de ses mécanismes de gestion de connexion hautes performances et de ses fonctions de sécurité.

Commençons.

Installer les packages à partir des dépôts Debian

Pour commencer le processus, vous allez télécharger et installer tous les éléments dont vous avez besoin à partir des référentiels Debian. Plus tard, vous utiliserez le gestionnaire de packages Python pip pour installer des composants supplémentaires.

Vous devez d'abord mettre à jour le local apt index des packages, puis téléchargez et installez les packages.

sudo apt update
sudo apt install python3-venv python3-dev libpq-dev postgresql postgresql-contrib nginx curl

Cette commande installera un outil pour créer des environnements virtuels pour vos projets Python, les fichiers de développement Python nécessaires pour construire Gunicorn plus tard, le système de base de données Postgres et les bibliothèques nécessaires pour interagir avec lui, et le serveur Web Nginx.

Création de la base de données et de l'utilisateur PostgreSQL

Vous pouvez maintenant vous lancer et créer une base de données et un utilisateur de base de données pour notre application Django.

Par défaut, Postgres utilise un schéma d'authentification appelé "authentification par les pairs" pour les connexions locales. En gros, cela signifie que si le nom d'utilisateur du système d'exploitation de l'utilisateur correspond à un nom d'utilisateur Postgres valide, cet utilisateur peut se connecter sans autre authentification.

Lors de l'installation de Postgres, un utilisateur du système d'exploitation nommé postgres a été créé pour correspondre à la postgres Utilisateur administratif PostgreSQL. Vous devez utiliser cet utilisateur pour effectuer des tâches administratives. Vous pouvez utiliser sudo et transmettre le nom d'utilisateur avec le -u option.

Connectez-vous à une session Postgres interactive en tapant :

sudo -u postgres psql

Vous recevrez une invite PostgreSQL où vous pourrez configurer nos exigences.

Tout d'abord, créez une base de données pour votre projet :

CREATE DATABASE myproject;

Remarque : Chaque instruction Postgres doit se terminer par un point-virgule. Assurez-vous donc que votre commande se termine par un si vous rencontrez des problèmes.


Ensuite, créez un utilisateur de base de données pour notre projet. Assurez-vous de sélectionner un mot de passe sécurisé :

CREATE USER myprojectuser WITH PASSWORD 'password';

Ensuite, vous modifierez quelques paramètres de connexion pour l'utilisateur que vous venez de créer. Cela accélérera les opérations de base de données afin que les valeurs correctes n'aient pas à être interrogées et définies à chaque fois qu'une connexion est établie.

Vous allez définir le codage de caractères par défaut sur UTF-8, ce que Django attend. Vous définissez également le schéma d'isolement des transactions par défaut sur "lecture validée", qui bloque les lectures à partir de transactions non validées. Enfin, vous définissez le fuseau horaire. Par défaut, les projets Django seront configurés pour utiliser UTC. Ce sont toutes les recommandations de le projet Django lui-même :

ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
ALTER ROLE myprojectuser SET timezone TO 'UTC';

Maintenant, vous pouvez donner au nouvel utilisateur l'accès pour administrer la nouvelle base de données :

GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

Lorsque vous avez terminé, quittez l'invite PostgreSQL en tapant :

\q

Postgres est maintenant configuré pour que Django puisse se connecter et gérer ses informations de base de données.

Créer un environnement virtuel Python pour votre projet

Maintenant que vous avez une base de données prête, vous pouvez commencer à obtenir le rest des exigences de votre projet. Vous installerez les exigences Python dans un environnement virtuel.

Tout d'abord, créez et accédez à un répertoire dans lequel vous pouvez conserver vos fichiers de projet :

mkdir ~/myprojectdir
cd ~/myprojectdir

Dans le répertoire du projet, créez un environnement virtuel Python en tapant :

python3 -m venv myprojectenv

Cela créera un répertoire nommé myprojectenv au sein de votre myprojectdir annuaire. À l'intérieur, il installera une version locale de Python et une version locale de pip pour gérer les forfaits. Vous pouvez utiliser cette structure d'environnement virtuel pour installer et configurer un environnement Python isolé pour tout projet que vous souhaitez créer.

Avant d'installer les exigences Python de votre projet, vous devrez activer l'environnement virtuel. Vous pouvez le faire en tapant :

source myprojectenv/bin/activate

Votre invite devrait changer pour indiquer que vous travaillez maintenant dans un environnement virtuel Python. Cela ressemblera à ceci : (myprojectenv)[email protected]:~/myprojectdir$.

Avec votre environnement virtuel actif, installez Django, Gunicorn et le psycopg2 Adaptateur PostgreSQL avec l'instance locale de pip:

Remarque : Lorsque l'environnement virtuel est activé (lorsque votre invite a (myprojectenv) qui le précède), utilisez pip à la place de pip3, même si vous utilisez Python 3. La copie de l'environnement virtuel de l'outil est toujours nommée pip, quelle que soit la version de Python.


pip install django gunicorn psycopg2-binary

Vous devriez maintenant avoir tous les logiciels nécessaires pour démarrer un projet Django.

Créer et configurer un nouveau projet Django

Une fois vos composants Python installés, vous pouvez maintenant créer les fichiers de projet Django réels.

Création du projet Django

Puisque vous avez déjà un répertoire de projet, vous direz à Django d'installer les fichiers ici. Il créera un répertoire de second niveau avec le code réel, ce qui est normal, et placera un script de gestion dans ce répertoire. La clé de cela est que vous définissez explicitement le répertoire au lieu de permettre à Django de prendre des décisions relatives à notre répertoire actuel :

django-admin startproject myproject ~/myprojectdir

À ce stade, votre répertoire de projet (~/myprojectdir dans cet exemple) doit avoir le contenu suivant :

  • ~/myprojectdir/manage.py: Un script de gestion de projet Django.
  • ~/myprojectdir/myproject/: Le package du projet Django. Celui-ci doit contenir les __init__.py, settings.py, urls.py, asgi.py, et wsgi.py des dossiers.
  • ~/myprojectdir/myprojectenv/: Le répertoire de l'environnement virtuel que vous avez créé précédemment.

Réglage des paramètres du projet

La première chose que vous devez faire avec vos fichiers de projet nouvellement créés est d'ajuster les paramètres. Ouvrez le fichier de paramètres à l'aide de nano ou votre éditeur de texte préféré :

nano ~/myprojectdir/myproject/settings.py

Commencez par repérer le ALLOWED_HOSTS directif. Cela définit une liste d'adresses de serveur ou de noms de domaine pouvant être utilisés pour se connecter à l'instance de Django. Toute demande entrante avec un en-tête Host qui ne figure pas dans cette liste déclenchera une exception. Django exige que vous définissiez ceci pour empêcher une certaine classe de vulnérabilité de sécurité.

Entre crochets, indiquez les adresses IP ou les noms de domaine associés à votre serveur Django. Chaque élément doit être répertorié entre guillemets avec des entrées séparées par une virgule. Si vous souhaitez des demandes pour un domaine entier et des sous-domaines, ajoutez un point au début de l'entrée. Dans l'extrait ci-dessous, il y a quelques exemples commentés utilisés pour démontrer :

Remarque : Assurez-vous d'inclure localhost comme l'une des options, car vous utiliserez des connexions proxy via une instance locale de Nginx.


~/monprojetdir/monprojet/settings.py

. . .
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']

Ensuite, recherchez la section qui configure l'accès à la base de données. Cela commencera par DATABASES. La configuration dans le fichier est pour une base de données SQLite. Vous avez déjà créé une base de données PostgreSQL pour notre projet, vous devez donc ajuster les paramètres.

Modifiez les paramètres avec les informations de votre base de données PostgreSQL. Vous dites à Django d'utiliser le psycopg2 adaptateur que vous avez installé avec pip. Vous devez donner le nom de la base de données, le nom d'utilisateur de la base de données, le mot de passe de l'utilisateur de la base de données, puis spécifier que la base de données se trouve sur l'ordinateur local. Vous pouvez laisser le PORT définir comme une chaîne vide :

~/monprojetdir/monprojet/settings.py

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

. . .

Ensuite, descendez au bas du fichier et ajoutez un paramètre indiquant où les fichiers statiques doivent être placés. Cela est nécessaire pour que Nginx puisse gérer les demandes de ces éléments. La ligne suivante indique à Django de les placer dans un répertoire appelé static dans le répertoire du projet de base :

~/monprojetdir/monprojet/settings.py

. . .
STATIC_URL = 'static/'

# Default primary key field type
# https://docs.djangoproject.com/en/4.0/ref/settings/#default-auto-field

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

Enregistrez et fermez le fichier lorsque vous avez terminé. Si vous utilisez nano, presse Ctrl+X, puis lorsque vous y êtes invité, Y puis Entrée.

Terminer la configuration initiale du projet

Maintenant, vous pouvez migrer le schéma de base de données initial vers notre base de données PostgreSQL à l'aide du script de gestion :

~/myprojectdir/manage.py makemigrations
~/myprojectdir/manage.py migrate

Créez un utilisateur administratif pour le projet en tapant :

~/myprojectdir/manage.py createsuperuser

Vous devrez sélectionner un nom d'utilisateur, fournir une adresse e-mail, puis choisir et confirmer un mot de passe.

Vous pouvez collecter tout le contenu statique dans l'emplacement du répertoire que vous avez configuré en tapant :

~/myprojectdir/manage.py collectstatic

Vous devrez confirmer l'opération. Les fichiers statiques seront alors placés dans un répertoire appelé static dans votre répertoire de projet.

Si vous avez suivi le guide de configuration initiale du serveur, vous devriez avoir un pare-feu UFW protégeant votre serveur. Afin de tester le serveur de développement, vous devez autoriser l'accès au port que vous utiliserez.

Créez une exception pour le port 8000 en tapant :

sudo ufw allow 8000

Enfin, vous pouvez tester votre projet en démarrant le serveur de développement Django avec cette commande :

~/myprojectdir/manage.py runserver 0.0.0.0:8000

Dans votre navigateur Web, visitez le nom de domaine ou l'adresse IP de votre serveur suivi de :8000:

http://server_domain_or_IP:8000

Vous devriez recevoir la page d'index Django par défaut :

Si vous ajoutez /admin à la fin de l'URL dans la barre d'adresse, vous serez invité à entrer le nom d'utilisateur et le mot de passe administratifs que vous avez créés avec le createsuperuser commande:

Après authentification, vous pouvez accéder à l'interface d'administration par défaut de Django :

Lorsque vous avez terminé l'exploration, appuyez sur CTRL-C dans la fenêtre du terminal pour arrêter le serveur de développement.

Tester la capacité de Gunicorn à servir le projet

La dernière chose que vous devez faire avant de quitter votre environnement virtuel est de tester Gunicorn pour vous assurer qu'il peut servir l'application. Vous pouvez le faire en entrant dans le répertoire du projet et en utilisant gunicorn pour charger le module WSGI du projet :

cd ~/myprojectdir
gunicorn --bind 0.0.0.0:8000 myproject.wsgi

Cela démarrera Gunicorn sur la même interface que celle sur laquelle le serveur de développement Django fonctionnait. Vous pouvez revenir en arrière et tester à nouveau l'application dans votre navigateur.

Remarque : L'interface d'administration n'aura aucun style appliqué car Gunicorn ne sait pas comment trouver le contenu CSS statique responsable de cela.


Vous avez passé un module à Gunicorn en spécifiant le chemin d'accès relatif au répertoire de Django wsgi.py file, qui est le point d'entrée de votre application, en utilisant la syntaxe de module de Python. À l'intérieur de ce fichier, une fonction appelée application est défini, qui est utilisé pour communiquer avec l'application. Pour en savoir plus sur la spécification WSGI, cliquez ici.

Lorsque vous avez terminé les tests, appuyez sur CTRL-C dans la fenêtre du terminal pour arrêter Gunicorn.

Vous avez maintenant terminé la configuration de votre application Django. Vous pouvez sortir de notre environnement virtuel en tapant :

deactivate

L'indicateur d'environnement virtuel dans votre invite sera supprimé.

Création de fichiers de socket et de service systemd pour Gunicorn

Vous avez testé que Gunicorn peut interagir avec notre application Django, mais vous devez maintenant implémenter une manière plus robuste de démarrer et d'arrêter le serveur d'application. Pour ce faire, vous allez créer des fichiers de service et de socket systemd.

Le socket Gunicorn sera créé au démarrage et écoutera les connexions. Lorsqu'une connexion se produit, systemd démarre automatiquement le processus Gunicorn pour gérer la connexion.

Commencez par créer et ouvrir un fichier de socket systemd pour Gunicorn avec sudo privilèges :

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

A l'intérieur, vous créerez un [Unit] section pour décrire la prise, une [Socket] section pour définir l'emplacement du socket, et une [Install] section pour vous assurer que le socket est créé au bon moment :

/etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, créez et ouvrez un fichier de service systemd pour Gunicorn avec sudo privilèges dans votre éditeur de texte. Le nom du fichier de service doit correspondre au nom du fichier socket à l'exception de l'extension :

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

Commencez par le [Unit] section, qui est utilisée pour spécifier les métadonnées et les dépendances. Mettez une description du service ici et dites au système d'initialisation de ne le démarrer qu'une fois que la cible de mise en réseau a été atteinte. Étant donné que votre service repose sur le socket du fichier socket, vous devez inclure un Requires directive pour indiquer cette relation :

/etc/systemd/system/gunicorn.service

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

Ensuite, vous écrirez le [Service] section. Spécifiez l'utilisateur et le groupe sous lesquels vous souhaitez exécuter le traitement. Vous donnerez à votre compte d'utilisateur habituel la propriété du processus puisqu'il possède tous les fichiers pertinents. Vous donnerez la propriété du groupe au www-data groupe afin que Nginx puisse communiquer avec Gunicorn.

Ensuite, vous tracerez le répertoire de travail et spécifierez la commande à utiliser pour démarrer le service. Dans ce cas, vous devez spécifier le chemin complet vers l'exécutable Gunicorn, qui est installé dans notre environnement virtuel. Vous lierez ensuite le processus au socket Unix que vous avez créé dans le /run répertoire afin que le processus puisse communiquer avec Nginx. Vous consignez toutes les données dans la sortie standard afin que le journald processus peut collecter les journaux Gunicorn. Vous pouvez également spécifier ici les réglages facultatifs de Gunicorn. Par exemple, vous avez spécifié 3 processus de travail dans ce cas :

/etc/systemd/system/gunicorn.service

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

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

Enfin, vous ajouterez un [Install] section. Cela indiquera à systemd à quoi lier ce service si vous lui permettez de démarrer au démarrage. Vous souhaitez que ce service démarre lorsque le système multi-utilisateurs standard est opérationnel :

/etc/systemd/system/gunicorn.service

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

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

[Install]
WantedBy=multi-user.target

Avec cela, votre fichier de service systemd est terminé. Enregistrez et fermez-le maintenant.

Vous pouvez maintenant démarrer et activer le socket Gunicorn. Cela créera le fichier de socket à /run/gunicorn.sock maintenant et au démarrage. Lorsqu'une connexion est établie avec ce socket, systemd démarre automatiquement le gunicorn.service pour le manipuler :

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

Vous pouvez confirmer que l'opération a réussi en vérifiant le fichier socket.

Vérification du fichier Gunicorn Socket

Vérifiez l'état du processus pour savoir s'il a pu démarrer :

sudo systemctl status gunicorn.socket

Vous devriez recevoir une sortie comme celle-ci :

Output● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
     Active: active (listening) since Thu 2022-08-04 19:02:54 UTC; 5s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
     CGroup: /system.slice/gunicorn.socket

Apr 18 17:53:25 django systemd[1]: Listening on gunicorn socket.

Ensuite, vérifiez l'existence de gunicorn.sock dossier au sein du /run annuaire:

file /run/gunicorn.sock
Output/run/gunicorn.sock: socket

Si la systemctl status commande a indiqué qu'une erreur s'est produite ou si vous ne trouvez pas le gunicorn.sock fichier dans le répertoire, c'est une indication que le socket Gunicorn n'a pas pu être créé correctement. Vérifiez les logs du socket Gunicorn en tapant :

sudo journalctl -u gunicorn.socket

Jetez un autre regard sur votre /etc/systemd/system/gunicorn.socket fichier pour résoudre tout problème avant de continuer.

Test de l'activation du socket

Actuellement, si vous avez seulement commencé le gunicorn.socket unité, la gunicorn.service ne sera pas encore actif car le socket n'a pas encore reçu de connexion. Vous pouvez le vérifier en tapant :

sudo systemctl status gunicorn
Output○ gunicorn.service - gunicorn daemon
     Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● gunicorn.socket

Pour tester le mécanisme d'activation du socket, vous pouvez envoyer une connexion au socket via curl en tappant:

curl --unix-socket /run/gunicorn.sock localhost

Vous devriez recevoir la sortie HTML de votre application dans le terminal. Cela indique que Gunicorn a été démarré et a pu servir votre application Django. Vous pouvez vérifier que le service Gunicorn est en cours d'exécution en tapant :

sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
     Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-08-04 19:03:51 UTC; 5s ago
TriggeredBy: ● gunicorn.socket
   Main PID: 102674 (gunicorn)
      Tasks: 4 (limit: 4665)
     Memory: 94.2M
        CPU: 885ms
     CGroup: /system.slice/gunicorn.service
             ├─102674 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
             ├─102675 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
             ├─102676 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
             └─102677 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application

Apr 18 17:54:49 django systemd[1]: Started gunicorn daemon.
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Starting gunicorn 20.1.0
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Listening at: unix:/run/gunicorn.sock (102674)
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Using worker: sync
Apr 18 17:54:49 django gunicorn[102675]: [2022-04-18 17:54:49 +0000] [102675] [INFO] Booting worker with pid: 102675
Apr 18 17:54:49 django gunicorn[102676]: [2022-04-18 17:54:49 +0000] [102676] [INFO] Booting worker with pid: 102676
Apr 18 17:54:50 django gunicorn[102677]: [2022-04-18 17:54:50 +0000] [102677] [INFO] Booting worker with pid: 102677
Apr 18 17:54:50 django gunicorn[102675]:  - - [18/Apr/2022:17:54:50 +0000] "GET / HTTP/1.1" 200 10697 "-" "curl/7.81.0"

Si la sortie de curl ou la sortie de systemctl status indique qu'un problème s'est produit, consultez les journaux pour plus de détails :

sudo journalctl -u gunicorn

Vérifier votre /etc/systemd/system/gunicorn.service fichier pour les problèmes. Si vous apportez des modifications au /etc/systemd/system/gunicorn.service fichier, rechargez le démon pour relire la définition du service et redémarrez le processus Gunicorn en tapant :

sudo systemctl daemon-reload
sudo systemctl restart gunicorn

Assurez-vous de résoudre les problèmes ci-dessus avant de continuer.

Configurer Nginx pour proxy passer à Gunicorn

Maintenant que Gunicorn est configuré, vous devez configurer Nginx pour transmettre le trafic au processus.

Commencez par créer et ouvrir un nouveau bloc de serveur dans Nginx sites-available annuaire:

sudo nano /etc/nginx/sites-available/myproject

À l'intérieur, ouvrez un nouveau bloc de serveur. Vous commencerez par spécifier que ce bloc doit écouter sur le port normal 80 et qu'il doit répondre au nom de domaine ou à l'adresse IP de votre serveur :

/etc/nginx/sites-available/monprojet

server {
    listen 80;
    server_name server_domain_or_IP;
}

Ensuite, vous direz à Nginx d'ignorer tout problème lié à la recherche d'un favicon. Vous lui indiquerez également où trouver les actifs statiques que vous avez collectés dans votre ~/myprojectdir/static annuaire. Tous ces fichiers ont un préfixe URI standard de "/static", vous pouvez donc créer un bloc d'emplacement pour correspondre à ces requêtes :

/etc/nginx/sites-available/monprojet

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }
}

Enfin, créez un location / {} bloc pour correspondre à toutes les autres demandes. À l'intérieur de cet emplacement, vous incluez la norme proxy_params fichier inclus avec l'installation de Nginx, puis passez le trafic directement au socket Gunicorn :

/etc/nginx/sites-available/monprojet

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

Enregistrez et fermez le fichier lorsque vous avez terminé. Maintenant, vous pouvez activer le fichier en le liant au sites-enabled annuaire:

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

Testez votre configuration Nginx pour les erreurs de syntaxe en tapant :

sudo nginx -t

Si aucune erreur n'est signalée, continuez et redémarrez Nginx en tapant :

sudo systemctl restart nginx

Enfin, vous devez ouvrir votre pare-feu au trafic normal sur le port 80. Comme vous n'avez plus besoin d'accéder au serveur de développement, vous pouvez également supprimer la règle pour ouvrir le port 8000 :

sudo ufw delete allow 8000
sudo ufw allow 'Nginx Full'

Vous devriez maintenant pouvoir accéder au domaine ou à l'adresse IP de votre serveur pour afficher votre application.

Remarque : Après avoir configuré Nginx, l'étape suivante doit consister à sécuriser le trafic vers le serveur à l'aide de SSL/TLS. Ceci est important car sans cela, toutes les informations, y compris les mots de passe, sont envoyées sur le réseau en texte brut.

Si vous avez un nom de domaine, le moyen le plus simple d'obtenir un certificat SSL pour sécuriser votre trafic est d'utiliser Let's Encrypt. Suivez ce guide pour configurer Let's Encrypt avec Nginx sur Debian 11. Suivez la procédure en utilisant le bloc serveur Nginx que vous avez créé dans ce guide.


Dépannage de Nginx et Gunicorn

Si cette dernière étape ne montre pas votre application, vous devrez dépanner votre installation.

Nginx affiche la page par défaut au lieu de l'application Django

Si Nginx affiche la page par défaut au lieu d'envoyer un proxy à votre application, cela signifie généralement que vous devez ajuster le server_name au sein de la /etc/nginx/sites-available/myproject fichier pour pointer vers l'adresse IP ou le nom de domaine de votre serveur.

Nginx utilise le server_name pour déterminer quel bloc serveur utiliser pour répondre aux requêtes. Si vous recevez la page Nginx par défaut, c'est un signe que Nginx n'a pas été en mesure de faire correspondre explicitement la demande à un bloc de serveur, il se rabat donc sur le bloc par défaut défini dans /etc/nginx/sites-available/default.

La server_name dans le bloc serveur de votre projet doit être plus spécifique que celui du bloc serveur par défaut à sélectionner.

Nginx affiche une erreur 502 Bad Gateway au lieu de l'application Django

Une erreur 502 indique que Nginx n'est pas en mesure de transmettre correctement la requête. Un large éventail de problèmes de configuration s'expriment avec une erreur 502, donc plus d'informations sont nécessaires pour résoudre correctement les problèmes.

Le principal endroit où rechercher plus d'informations est dans les journaux d'erreurs de Nginx. Généralement, cela vous indiquera quelles conditions ont causé des problèmes lors de l'événement de proxy. Suivez les journaux d'erreurs Nginx en tapant :

sudo tail -F /var/log/nginx/error.log

Maintenant, faites une autre demande dans votre navigateur pour générer une nouvelle erreur (essayez de rafraîchir la page). Vous devriez recevoir un nouveau message d'erreur écrit dans le journal. Si vous regardez le message, cela devrait vous aider à cerner le problème.

Vous pourriez recevoir le message suivant :

connect() à unix:/run/gunicorn.sock a échoué (2 : aucun fichier ou répertoire de ce type)

Cela indique que Nginx n'a pas pu trouver le gunicorn.sock fichier à l'emplacement indiqué. Vous devriez comparer le proxy_pass emplacement défini dans /etc/nginx/sites-available/myproject fichier à l'emplacement réel du gunicorn.sock fichier généré par le gunicorn.socket unité systemd.

Si vous ne trouvez pas un gunicorn.sock dossier au sein du /run répertoire, cela signifie généralement que le fichier de socket systemd n'a pas pu le créer. Revenez à la section sur la vérification du fichier de socket Gunicorn pour parcourir les étapes de dépannage de Gunicorn.

connect() to unix:/run/gunicorn.sock a échoué (13 : autorisation refusée)

Cela indique que Nginx n'a pas pu se connecter au socket Gunicorn en raison de problèmes d'autorisations. Cela peut se produire lorsque la procédure est suivie en utilisant l'utilisateur root au lieu d'un sudo utilisateur. Alors que systemd est capable de créer le fichier de socket Gunicorn, Nginx ne peut pas y accéder.

Cela peut se produire s'il existe des autorisations limitées à tout moment entre le répertoire racine (/) la gunicorn.sock dossier. Vous pouvez consulter les autorisations et les valeurs de propriété du fichier socket et de chacun de ses répertoires parents en transmettant le chemin absolu de votre fichier socket au namei commande:

namei -l /run/gunicorn.sock
Outputf: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock

La sortie affiche les autorisations de chacun des composants du répertoire. En examinant les autorisations (première colonne), le propriétaire (deuxième colonne) et le propriétaire du groupe (troisième colonne), vous pouvez déterminer quel type d'accès est autorisé au fichier socket.

Dans l'exemple ci-dessus, le fichier socket et chacun des répertoires menant au fichier socket ont des autorisations universelles de lecture et d'exécution (la colonne des autorisations pour les répertoires se termine par r-x à la place de ---). Le processus Nginx devrait pouvoir accéder au socket avec succès.

Si l'un des répertoires menant au socket n'a pas d'autorisation de lecture et d'exécution universelles, Nginx ne pourra pas accéder au socket sans autoriser les autorisations universelles de lecture et d'exécution ou s'assurer que la propriété du groupe est attribuée à un groupe dont Nginx fait partie. de.

Django affiche : « impossible de se connecter au serveur : connexion refusée »

Un message que vous pouvez recevoir de Django lorsque vous tentez d'accéder à des parties de l'application dans le navigateur Web est :

OperationalError at /admin/login/
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

Cela indique que Django est incapable de se connecter à la base de données Postgres. Assurez-vous que l'instance Postgres est en cours d'exécution en saisissant :

sudo systemctl status postgresql

Si ce n'est pas le cas, vous pouvez le démarrer et lui permettre de démarrer automatiquement au démarrage (s'il n'est pas déjà configuré pour le faire) en tapant :

sudo systemctl start postgresql
sudo systemctl enable postgresql

Si vous rencontrez toujours des problèmes, assurez-vous que les paramètres de base de données définis dans le ~/myprojectdir/myproject/settings.py fichier sont corrects.

Dépannage supplémentaire

Pour un dépannage supplémentaire, les journaux peuvent aider à réduire les causes profondes. Vérifiez chacun d'eux à tour de rôle et recherchez les messages indiquant les zones problématiques.

Les journaux suivants peuvent être utiles :

  • Vérifiez les journaux de processus Nginx en tapant : sudo journalctl -u nginx
  • Vérifiez les journaux d'accès Nginx en tapant : sudo less /var/log/nginx/access.log
  • Vérifiez les journaux d'erreurs Nginx en tapant : sudo less /var/log/nginx/error.log
  • Vérifiez les journaux de l'application Gunicorn en tapant : sudo journalctl -u gunicorn
  • Vérifiez les journaux du socket Gunicorn en tapant : sudo journalctl -u gunicorn.socket

Lorsque vous mettez à jour votre configuration ou votre application, vous devrez probablement redémarrer les processus pour vous adapter à vos modifications.

Si vous mettez à jour votre application Django, vous pouvez redémarrer le processus Gunicorn pour récupérer les modifications en tapant :

sudo systemctl restart gunicorn

Si vous modifiez le socket Gunicorn ou les fichiers de service, rechargez le démon et redémarrez le processus en tapant :

sudo systemctl daemon-reload
sudo systemctl restart gunicorn.socket gunicorn.service

Si vous modifiez la configuration du bloc serveur Nginx, testez la configuration puis Nginx en tapant :

sudo nginx -t && sudo systemctl restart nginx

Ces commandes sont utiles pour prendre en compte les modifications lorsque vous ajustez votre configuration.

Conclusion

Dans ce guide, vous configurez un projet Django dans son propre environnement virtuel. Vous avez configuré Gunicorn pour traduire les demandes des clients afin que Django puisse les gérer. Ensuite, vous configurez Nginx pour agir en tant que proxy inverse pour gérer les connexions client et servir le projet correct en fonction de la demande du client.

Django aide à créer des projets et des applications en fournissant de nombreux éléments communs, vous permettant de vous concentrer sur les éléments uniques. En tirant parti de la chaîne d'outils générale décrite dans cet article, vous pouvez servir les applications que vous créez à partir d'un seul serveur.