Senior Manager, DevEd
Django est un framework web puissant qui peut vous aider à lancer votre application ou votre site web en Python. Django comprend un serveur de développement simplifié pour tester votre code en local, mais pour tout ce qui est lié, même légèrement, à la production, un serveur web plus sécurisé et plus puissant est nécessaire.
Dans ce guide, nous allons montrer comment installer et configurer certains composants d’Ubuntu 20.04 pour soutenir et servir les applications Django. Nous allons mettre en place une base de données PostgreSQL au lieu d’utiliser la base de données SQLite par défaut. Nous allons configurer le serveur d’application Gunicorn pour qu’il s’interface avec nos applications. Nous allons ensuite mettre en place Nginx pour inverser le proxy à Gunicorn, nous donnant accès à ses fonctions de sécurité et de performance pour servir nos applications.
Afin de terminer ce guide, vous devez disposer d’une nouvelle instance de serveur Ubuntu 20.04 avec un pare-feu de base et un utilisateur non root avec des privilèges sudo
configurés. Vous pouvez apprendre à paramétrer cette configuration en suivant notre guide de configuration initiale du serveur.
Nous allons installer Django dans un environnement virtuel. L’installation de Django dans un environnement spécifique à votre projet permettra de traiter séparément vos projets et leurs exigences.
Une fois que notre base de données et notre application seront opérationnels, nous allons installer et configurer le serveur d’application Gunicorn. Cela servira d’interface à notre application, traduisant les requêtes des clients à partir de HTTP en appels Python que notre application peut traiter. Nous allons ensuite mettre en place Nginx en face de Gunicorn pour tirer parti de ses mécanismes très performants de gestion des connexions et de ses fonctionnalités de sécurité faciles à mettre en œuvre.
Commençons.
Pour démarrer le processus, nous allons télécharger et installer tous les éléments dont nous avons besoin à partir des référentiels Ubuntu. Nous utiliserons le gestionnaire de paquets Python pip
pour installer des composants supplémentaires un peu plus tard.
Nous devons mettre à jour l’index local du paquet apt
et ensuite télécharger et installer les paquets. Les paquets que nous installons dépendent de la version de Python votre projet utilisera.
Si vous utilisez Django avec Python 3, tapez :
- sudo apt update
- sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl
Django 1.11 est la dernière version de Django qui prendra en charge Python 2. Si vous démarrez de nouveaux projets, il est fortement recommandé de choisir Python 3. Si vous avez encore besoin d’utiliser Python 2, tapez :
- sudo apt update
- sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl
Cela installera pip
, 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 à l’interaction avec celui-ci, ainsi que le serveur web Nginx.
Nous allons tout de suite 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 système 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.
Au cours de l’installation de Postgres, un utilisateur du système d’exploitation nommé postgres
a été créé pour correspondre à l’utilisateur administratif postgres
de PostgreSQL. Nous devons utiliser cet utilisateur pour effectuer des tâches administratives. Nous pouvons utiliser sudo et passer dans le nom d’utilisateur avec l’option -u
.
Connectez-vous à une session interactive de Postgres en tapant :
- sudo -u postgres psql
Vous recevrez une invite PostgreSQL où nous pourrons configurer nos exigences.
Tout d’abord, créez une base de données pour votre projet :
- CREATE DATABASE myproject;
Remarque : chaque instruction de Postgres doit se terminer par un point-virgule, Assurez-vous donc que votre commande se termine bien par un point-virgule si vous rencontrez des problèmes.
Ensuite, créez un utilisateur de base de données pour votre projet. Sélectionnez un mot de passe sécurisé :
- CREATE USER myprojectuser WITH PASSWORD 'password';
Ensuite, nous allons modifier quelques-uns des paramètres de connexion de l’utilisateur que nous venons de créer. Cela accélérera les opérations de la base de données de sorte qu’il ne sera pas nécessaire d’interroger et de définir les valeurs correctes à chaque fois qu’une connexion sera établie.
Nous réglons l’encodage par défaut à UTF-8
, auquel Django s’attend. Nous définissons également le schéma d’isolement des transactions par défaut à « read committed », qui bloque les lectures de transactions non engagées. Enfin, nous définissons le fuseau horaire. Par défaut, nos projets Django seront configurés pour utiliser l’UTC
. Ce sont toutes les recommandations du 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';
Nous pouvons maintenant donner à notre nouvel utilisateur un accès pour administrer notre nouvelle base de données :
- GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;
Une fois terminé, quittez l’invite PostgreSQL en tapant :
- \q
Postgres est maintenant configuré de manière à ce que Django puisse se connecter et gérer les informations de sa base de données.
Maintenant que nous avons notre base de données, nous pouvons commencer à préparer le reste des exigences de notre projet. Nous allons installer nos exigences Python dans un environnement virtuel pour faciliter la gestion.
Pour ce faire, nous devons d’abord accéder à la commande virtualenv
. Nous pouvons l’installer avec pip
.
Si vous utilisez Python 3, mettez à niveau pip
et installez le paquet en tapant :
- sudo -H pip3 install --upgrade pip
- sudo -H pip3 install virtualenv
Si vous utilisez Python 2, mettez à niveau pip
et installez le paquet en tapant :
- sudo -H pip install --upgrade pip
- sudo -H pip install virtualenv
Une fois virtualenv
installé, nous pouvons démarrer à former notre projet. Créez et accédez à un répertoire où nous pouvons conserver nos fichiers de projet :
- mkdir ~/myprojectdir
- cd ~/myprojectdir
Dans le répertoire du projet, créez un environnement virtuel Python en tapant :
- virtualenv myprojectenv
Cela créera un répertoire appelé myprojectenv
dans votre répertoire myprojectdir
. Dans ce répertoire, il installera une version locale de Python et une version locale de pip
. Nous pouvons l’utiliser pour installer et configurer un environnement Python isolé pour notre projet.
Avant d’installer les exigences Python de notre projet, nous devons activer l’environnement virtuel. Vous pouvez le faire en saisissant :
- source myprojectenv/bin/activate
Votre invite devrait changer pour indiquer que vous travaillez maintenant dans un environnement virtuel Python. Cela ressemblera à quelque chose comme ceci : (myprojectenv)user@host:~/myproject$
.
Une fois votre environnement virtuel actif, installez Django, Gunicorn et l’adaptateur PostgreSQL psycopg2
avec l’instance locale de pip
:
Remarque : Lorsque l’environnement virtuel est activé (lorsque votre invite a (myprojetenv)
qui la précède), utilisez pip
au lieu de pip3
, même si vous utilisez Python 3. La copie de l’environnement virtuel de l’outil est toujours appelée pip
, quelle que soit la version de Python.
- pip install django gunicorn psycopg2-binary
Vous devriez maintenant disposer de tous les logiciels nécessaires pour démarrer un projet Django.
Une fois nos composants Python installés, nous pouvons créer les fichiers du projet Django.
Comme nous avons déjà un répertoire de projet, nous allons indiquer à Django d’installer les fichiers ici. Il va créer un répertoire de deuxième niveau avec le code réel, ce qui est normal, et y placera un script de gestion. L’essentiel est que nous définissions explicitement le répertoire au lieu de permettre à Django de prendre des décisions par rapport à notre répertoire actuel :
- django-admin.py startproject myproject ~/myprojectdir
À ce stade, votre répertoire de projet (~/myprojectdir
dans notre cas) devrait avoir le contenu suivant :
~/myprojectdir/manage.py
: un script de gestion de projet Django.~/myprojectdir/myproject/
: Le paquet du projet Django. Il devrait contenir les fichiers __init__.py
, settings.py
, urls.py
, asgi.py
, et wsgi.py
.~/myprojectdir/myprojectenv/
: Le répertoire de l’environnement virtuel que nous avons créé auparavant.La première chose que nous devons faire avec nos fichiers de projet nouvellement créés est d’ajuster les paramètres. Ouvrez le fichier de paramètres dans votre éditeur de texte :
- nano ~/myprojectdir/myproject/settings.py
Commencez par localiser la directive ALLOWED_HOSTS
. Cellle-ci définit une liste des adresses ou des noms de domaine du serveur pouvant être utilisés pour se connecter à l’instance Django. Toute requête entrante dont l’en-tête Host ne figure pas dans cette liste fera l’objet d’une exception. Django vous demande de la définir pour éviter une certaine classe de vulnérabilité de sécurité.
Dans les crochets , listez les adresses IP ou les noms de domaine associés à votre serveur Django. Chaque élément devrait être listé dans des guillemets avec les entrées séparées par une virgule. Si vous souhaitez des requêtes pour un domaine entier et des sous-domaines, faites précéder l’entrée d’un point. Dans l’extrait ci-dessous, quelques exemples commentés sont utliser pour démontrer :
Note : veillez à inclure localhost
parmi les options, car nous allons utiliser une instance locale de Nginx comme proxy pour les connexions.
. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
Ensuite, trouvez la section qui configure l’accès à la base de données. Elle commencera par des DATABASES
. La configuration du fichier concerne une base de données SQLite. Nous avons déjà créé une base de données PostgreSQL pour notre projet, nous devons donc ajuster les paramètres.
Modifiez les paramètres à l’aide des informations de votre base de données PostgreSQL. Nous disons à Django d’utiliser l’adaptateur psycopg2
que nous avons installé avec pip
. Nous devons indiquer 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 est située sur l’ordinateur local. Vous pouvez laisser le paramètre PORT
sous forme de chaîne vide :
. . .
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'myproject',
'USER': 'myprojectuser',
'PASSWORD': 'password',
'HOST': 'localhost',
'PORT': '',
}
}
. . .
Ensuite, passez au bas du fichier et ajoutez un paramètre indiquant où les fichiers statiques devraient être placés. Ceci est nécessaire pour que Nginx puisse traiter les requêtes pour 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 :
. . .
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
Enregistrez et fermez le fichier lorsque vous avez terminé.
Nous pouvons maintenant migrer le schéma de base de données initiale 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 électronique et choisir et confirmer un mot de passe.
Nous pouvons récupérer tout le contenu statique dans l’emplacement du répertoire que nous avons configuré en tapant :
- ~/myprojectdir/manage.py collectstatic
Vous devrez confirmer l’opération. Les fichiers statiques seront ensuite 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 disposer d’un pare-feu UFW qui protège votre serveur Afin de tester le serveur de développement, nous allons devoir autoriser l’accès au port que nous utiliserons.
Créez une exception pour le port 8000 en tapant :
- sudo ufw allow 8000
Enfin, vous pouvez tester notre 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, accédez au nom de domaine ou à l’adresse IP de votre serveur suivi(e) de :8000
:
http://server_domain_or_IP:8000
Vous devriez obtenir la page d’index par défaut de Django :
Si vous ajoutez /admin
à la fin de l’URL dans la barre d’adresse, vous serez invité à fournir le nom d’utilisateur et le mot de passe administratif que vous avez créé avec la commande createsuperuser
:
Une fois l’authentification terminée, vous pouvez accéder à l’interface admin par défaut de Django :
Quand vous avez fini d’explorer, appuyez sur CTRL-C dans la fenêtre de terminal pour fermer le serveur de développement.
La dernière chose que nous voulons faire avant de quitter notre environnement virtuel est de tester Gunicorn pour nous assurer qu’il peut servir l’application. Nous pouvons le faire en entrant dans notre répertoire de 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.
Remarque : l’interface admin ne bénéficiera d’aucun des styles appliqués puisque Gunicorn ne sait pas comment trouver le contenu CSS statique responsable de cela.
Nous avons passé un module à Gunicorn en spécifiant le chemin relatif du répertoire du fichier wsgi.py
de Django, qui est le point d’entrée de notre application, en utilisant la syntaxe du module Python. À l’intérieur de ce fichier, une fonction appelée application
est définie, qui est utilisée 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.
Nous avons maintenant fini de configurer notre application Django. Nous pouvons sortir de notre environnement virtuel en tapant :
- deactivate
L’indicateur de l’environnement virtuel dans votre invite sera supprimé.
Nous avons testé la capacité de Gunicorn à interagir avec notre application Django, mais nous devrions mettre en place un moyen plus solide de démarrer et d’arrêter le serveur d’application. Pour ce faire, nous allons créer des fichiers de socket et de service de systemd.
La socket de Gunicorn sera créée au démarrage et écoutera les connexions. Lorsqu’une connexion est établie, systemd démarrera automatiquement le processus de Gunicorn pour gérer la connexion.
Commencez par créer et ouvrir un fichier de socket de systemd pour Gunicorn avec les privilèges sudo
:
- sudo nano /etc/systemd/system/gunicorn.socket
À l’intérieur, nous allons créer une section [Unit]
pour décrire la socket, une section [Socket]
pour définir l’emplacement de la socket et une section [Install]
pour nous assurer que la socket est créée au bon moment :
[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 des privilèges sudo
dans votre éditeur de texte. Le nom de fichier de service devrait correspondre au nom de socket, à l’exception de l’extension :
- sudo nano /etc/systemd/system/gunicorn.service
Commencez par la section [Unit]
, qui est utilisée pour spécifier les métadonnées et les dépendances. Nous ajouterons une description de notre service et disons au système d’initialisation de ne le lancer qu’une fois que l’objectif de mise en réseau a été atteint. Comme notre service repose sur la socket du fichier de socket, nous devons inclure une directive Requires
pour indiquer cette relation :
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
Ensuite, nous allons ouvrir la section [Service]
. Nous indiquerons l’utilisateur et le groupe sous lequel nous voulons que le processus s’exécute. Nous allons donner à notre compte utilisateur habituel la propriété du processus puisqu’il possède tous les fichiers pertinents. Nous allons donner la propriété de groupe au groupe www-data
afin que Nginx puisse communiquer facilement avec Gunicorn.
Nous allons ensuite mapper le répertoire de travail et spécifier la commande à utiliser pour lancer le service. Dans ce cas, nous devrons spécifier le chemin complet de l’exécutable Gunicorn, qui est installé dans notre environnement virtuel. Nous allons lier le processus à la socket Unix que nous avons créée dans le répertoire /run
, afin que le processus puisse communiquer avec Nginx. Nous enregistrons toutes les données sur une sortie standard afin que le processus journald
puisse recueillir les journaux Gunicorn. Nous pouvons également spécifier tout ajustement optionnel de Gunicorn ici. Par exemple, nous avons spécifié 3 processus de travail dans ce cas :
[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, nous allons ajouter une section [Install]
. Cela indiquera à systemd à quoi lier ce service si nous autorisons son démarrage au boot. Nous voulons que ce service démarre lorsque le système multi-utilisateurs normal est opérationnel :
[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, notre fichier de service systemd est terminé. Enregistrez-le et fermez-le maintenant.
Nous pouvons maintenant démarrer et activer la socket Gunicorn. Cela créera le fichier de socket à /run/gunicorn.sock
maintenant et au démarrage. Lorsqu’une connexion se fait à cette socket, systemd démarrera automatiquement gunicorn.service
pour la gérer :
- sudo systemctl start gunicorn.socket
- sudo systemctl enable gunicorn.socket
Nous pouvons confirmer que l’opération a bien réussi en vérifiant le fichier de socket.
Vérifiez l’état du processus pour savoir s’il a pu démarrer :
- sudo systemctl status gunicorn.socket
Vous devriez recevoir un résultat semblable à celui-ci :
Output● gunicorn.socket - gunicorn socket
Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
Active: active (listening) since Fri 2020-06-26 17:53:10 UTC; 14s ago
Triggers: ● gunicorn.service
Listen: /run/gunicorn.sock (Stream)
Tasks: 0 (limit: 1137)
Memory: 0B
CGroup: /system.slice/gunicorn.socket
Ensuite, vérifiez l’existence du fichier gunicorn.sock
dans le répertoire /run
:
- file /run/gunicorn.sock
Output/run/gunicorn.sock: socket
Si la commande systemctl status
indique qu’une erreur s’est produite ou si vous ne trouvez pas le fichier gunicorn.sock
dans le répertoire, c’est une indication que la socket Gunicorn n’a pas pu être créée correctement. Vérifiez les journaux de la socket Gunicorn en tapant :
- sudo journalctl -u gunicorn.socket
Examinez à nouveau votre fichier /etc/systemd/system/gunicorn.socket
pour corriger tous les problèmes avant de continuer.
Actuellement, si vous n’avez démarré que l’unité gunicorn.socket
, le gunicorn.service
ne sera pas encore actif puisque la socket n’a pas encore reçu de connexion. Vous pouvez vérifier cela 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)
Pour tester le mécanisme d’activation de la socket, nous pouvons envoyer une connexion à la socket via curl
en tapant :
- curl --unix-socket /run/gunicorn.sock localhost
Vous devriez recevoir la sortie HTML de votre application dans le terminal. Cela indique que Gunicorn a démarré et a pu servir votre application Django. Vous pouvez vérifier que le service Gunicorn fonctionne 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 Fri 2020-06-26 18:52:21 UTC; 2s ago
TriggeredBy: ● gunicorn.socket
Main PID: 22914 (gunicorn)
Tasks: 4 (limit: 1137)
Memory: 89.1M
CGroup: /system.slice/gunicorn.service
├─22914 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunico>
├─22927 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunico>
├─22928 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunico>
└─22929 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunico>
Jun 26 18:52:21 django-tutorial systemd[1]: Started gunicorn daemon.
Jun 26 18:52:21 django-tutorial gunicorn[22914]: [2020-06-26 18:52:21 +0000] [22914] [INFO] Starting gunicorn 20.0.4
Jun 26 18:52:21 django-tutorial gunicorn[22914]: [2020-06-26 18:52:21 +0000] [22914] [INFO] Listening at: unix:/run/gunicorn.sock (22914)
Jun 26 18:52:21 django-tutorial gunicorn[22914]: [2020-06-26 18:52:21 +0000] [22914] [INFO] Using worker: sync
Jun 26 18:52:21 django-tutorial gunicorn[22927]: [2020-06-26 18:52:21 +0000] [22927] [INFO] Booting worker with pid: 22927
Jun 26 18:52:21 django-tutorial gunicorn[22928]: [2020-06-26 18:52:21 +0000] [22928] [INFO] Booting worker with pid: 22928
Jun 26 18:52:21 django-tutorial gunicorn[22929]: [2020-06-26 18:52:21 +0000] [22929] [INFO] Booting worker with pid: 22929
Si la sortie de curl
ou la sortie du statut systemctl
indique qu’un problème s’est produit, vérifiez les journaux pour obtenir des détails supplémentaires :
- sudo journalctl -u gunicorn
Vérifiez votre fichier /etc/systemd/system/gunicorn.service
pour tout problème. Si vous apportez des modifications au fichier /etc/systemd/system/gunicorn.service
, rechargez le démon pour relire la définition de 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.
Maintenant que Gunicorn est mis en place, nous devons configurer Nginx pour qu’il transmette le trafic au processus.
Commencez par créer et ouvrir un nouveau bloc serveur dans le répertoire sites-available
de Nginx :
- sudo nano /etc/nginx/sites-available/myproject
À l’intérieur, ouvrez un nouveau bloc serveur. Nous allons commencer par spécifier que ce bloc devrait écouter sur le port normal 80 et qu’il devrait répondre au nom de domaine ou à l’adresse IP de notre serveur :
server {
listen 80;
server_name server_domain_or_IP;
}
Ensuite, nous allons demander à Nginx d’ignorer tous les problèmes de recherche d’une favicon. Nous allons également lui dire où trouver les éléments statiques que nous avons recueillis dans notre répertoire ~/myprojectdir/static
Tous ces fichiers disposent d’un préfixe URI standard de “/static”, nous pouvons donc créer un bloc d’emplacement pour correspondre à ces requêtes :
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, nous allons créer un bloc location / {}
pour correspondre à toutes les autres requêtes. À l’intérieur de cet emplacement, nous allons inclure le fichier proxy_params
standard inclus avec l’installation Nginx et ensuite nous allons passer le trafic directement à la socket Gunicorn :
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é. Nous pouvons maintenant activer le fichier en le reliant au répertoire sites-enabled
:
- sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled
Testez votre configuration Nginx pour détecter 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, nous devons ouvrir notre pare-feu au trafic normal sur le port 80. Comme nous n’avons plus besoin d’accès au serveur de développement, nous pouvons supprimer la règle d’ouverture du port 8000 également :
- 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 voir votre application.
Note : Après avoir configuré Nginx, la prochaine étape devrait consister à sécuriser le trafic vers le serveur en utilisant SSL/TLS. Ceci est important car sinon, toutes les informations, y compris les mots de passe, seraient envoyées sur le réseau en texte clair.
Si vous disposez d’un nom de domaine, la manière la plus simple d’obtenir un certificat SSL pour sécuriser votre trafic consiste à utiliser Let’s Encrypt. Suivez ce guide pour configurer Let’s Encrypt avec Nginx sur Ubuntu 20.04. Suivez la procédure en utilisant le bloc serveur Nginx que nous avons créé dans ce guide.
Si cette dernière étape ne montre pas votre application, vous devrez dépanner votre installation.
Si Nginx affiche la page par défaut au lieu d’utiliser un proxy vers votre application, cela signifie généralement que vous devez ajuster le server_name
dans le fichier /etc/nginx/sites-available/myproject
pour qu’il pointe vers l’adresse IP ou le nom de domaine de votre serveur.
Nginx utilise le server_name
pour déterminer le 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 pu faire correspondre la requête à un bloc serveur explicitement, donc il revient au bloc par défaut défini dans /etc/nginx/sites-available/default
.
Le server_name
dans le bloc serveur de votre projet doit être plus spécifique que celui dans le bloc serveur par défaut pour être sélectionné.
Une erreur 502 indique que Nginx n’est pas en mesure de transmettre la requête. Un large éventail de problèmes de configuration s’expriment avec une erreur 502, de sorte que davantage d’informations sont nécessaires pour dépanner correctement.
L’endroit principal pour trouver plus d’informations se trouve dans les journaux d’erreur de Nginx. Généralement, cela vous indiquera les conditions qui ont causé des problèmes lors de l’événement de proxying. Suivez les journaux d’erreur Nginx en tapant :
- sudo tail -F /var/log/nginx/error.log
Maintenant, faites une autre requête 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 au journal. Si vous regardez le message, il devrait vous aider à cerner le problème.
Vous pourriez recevoir le message suivant :
connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)
Cela indique que Nginx n’a pas pu trouver le fichier gunicorn.sock
à l’endroit indiqué. Vous devriez comparer l’emplacement proxy_pass
, défini dans le fichier /etc/nginx/sites-available/myproject
à l’emplacement réel du fichier gunicorn.sock
généré par l’unité systemd gunicorn.socket
.
Si vous ne trouvez pas de fichier gunicorn.sock
dans le répertoire /run
, cela signifie généralement que le fichier systemd socket n’a pas pu le créer. Retournez à la section sur la vérification du fichier socket Gunicorn pour parcourir les étapes de dépannage pour Gunicorn.
connect() to unix:/run/gunicorn.sock failed (13: Permission denied)
Cela indique que Nginx n’a pas pu se connecter à la socket Gunicorn en raison de problèmes de permission. Cela peut se produire lorsque la procédure est suivie en utilisant un root user au lieu d’un utilisateur sudo
. Bien que systemd soit capable de créer le fichier de socket Gunicorn, Nginx n’est pas en mesure d’y accéder.
Cela peut se produire s’il existe des permissions limitées à un moment quelconque entre le répertoire root (/
) et le fichier gunicorn.sock
. Nous pouvons examiner les permissions et les valeurs de propriété du fichier socket et de chacun de ses répertoires parents en passant le chemin absolu de notre fichier socket à la commande namei
:
- 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 permissions de chacun des composants du répertoire. En examinant les permissions (première colonne), propriétaire (deuxième colonne) et groupe propriétaire (troisième colonne), nous pouvons comprendre '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 permissions de lecture et d’exécution mondiales (la colonne des permissions pour les répertoires se terminent par r-x
au lieu de ---
). Le processus Nginx devrait pouvoir accéder à la socket avec succès.
Si l’un des répertoires menant à la socket n’a pas de permission mondiale de lecture et d’exécution, Nginx ne pourra pas accéder à la socket sans autoriser les permissions de lecture et d’exécution mondiales ou sans s’assurer que la propriété du groupe est donnée à un groupe dont Nginx fait partie.
Un message que vous pouvez recevoir de Django lorsque vous essayez d’accéder à certaines 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 n’est pas en mesure de se connecter à la base de données Postgres. Assurez-vous que l’instance Postgres fonctionne en tapant :
- sudo systemctl status postgresql
Si ce n’est pas le cas, vous pouvez la démarrer, et lui permettre de démarrer automatiquement au démarrage (si elle n’est pas déjà configurée pour le faire) en tapant :
- sudo systemctl start postgresql
- sudo systemctl enable postgresql
Si les problèmes persistent, assurez-vous que les paramètres de la base de données définis dans le fichier ~/myprojectdir/myproject/settings.py
sont corrects.
Pour un dépannage supplémentaire, les journaux peuvent vous aider à cerner les causes profondes. Vérifiez chacune d’entre elles à tour de rôle et recherchez les messages indiquant les zones à problèmes.
Les journaux suivants peuvent être utiles :
sudo journalctl -u nginx
sudo less /var/log/nginx/access.log
sudo less /var/log/nginx/error.log
sudo journalctl -u gunicorn
sudo journalctl -u gunicorn.socket
Lorsque vous mettez à jour votre configuration ou votre application, vous devrez probablement redémarrer les processus pour vous ajuster à vos changements.
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 les fichiers de socket ou 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 et ensuite Nginx en tapant :
- sudo nginx -t && sudo systemctl restart nginx
Ces commandes sont utiles pour récupérer les modifications à mesure que vous ajustez votre configuration.
Dans ce guide, nous avons mis en place un projet Django dans son propre environnement virtuel. Nous avons configuré Gunicorn pour traduire les requêtes client de sorte que Django puisse les gérer. Ensuite, nous avons mis en place Nginx pour qu’il agisse en tant que proxy inverse afin de gérer les connexions client et servir le projet approprié, en fonction de la requête du client.
Django simplifie la création de projets et d’applications en fournissant un grand nombre d’éléments communs, ce qui vous permet de vous concentrer sur les éléments uniques. En exploitant la chaîne d’outils générale décrite dans cet article, vous pouvez facilement servir les applications que vous créez à partir d’un seul serveur.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Hi! How to serve media files with django and nginx.
in my settings.py file I have: … STATIC_URL = ‘/static/’ STATIC_ROOT = os.path.join(BASE_DIR, ‘static_files’)
MEDIA_URL = ‘/media/’ MEDIA_ROOT = os.path.join(BASE_DIR, ‘static_media’) …
I Have done a Custom user Model as MyUser.
class MyUser (models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) avatar = models.ImageField(upload_to=‘avatars/’, default=‘avatars/default.png’) sexe = models.CharField(max_length=5)
My problem: I can’t get avatar on server. but in localhost, the is no problem.