TOC

Comment servir les applications Django avec uWSGI et Nginx sur Ubuntu 16.04

introduction

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

Dans ce guide, nous montrerons comment installer et configurer certains composants sur Ubuntu 16.04 pour prendre en charge et servir les applications Django. Nous allons configurer le serveur de conteneur d’application uWSGI pour l’interface avec nos applications. Nous allons ensuite configurer Nginx pour inverser le proxy sur uWSGI, nous donnant ainsi accès à ses fonctionnalités de sécurité et de performances pour servir nos applications.

Prérequis et objectifs

Afin de compléter ce guide, vous devez disposer d’une nouvelle instance de serveur Ubuntu 16.04 avec un utilisateur non root avec les privilèges + sudo + configurés. Vous pouvez apprendre à le configurer en parcourant notre https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 guide de configuration du serveur initial].

Nous installerons Django dans deux environnements virtuels différents. Cela permettra à vos projets et à leurs exigences d’être traités séparément. Nous allons créer deux exemples de projets afin de pouvoir suivre les étapes dans un environnement multi-projets.

Une fois que nous avons nos applications, nous allons installer et configurer le serveur d’application uWSGI. Cela servira d’interface avec nos applications, qui traduira les demandes des clients utilisant HTTP en appels Python que notre application peut traiter. Nous installerons ensuite Nginx devant uWSGI pour tirer parti de ses mécanismes de traitement des connexions hautes performances et de ses fonctionnalités de sécurité faciles à mettre en œuvre.

Commençons.

Installer et configurer VirtualEnv et VirtualEnvWrapper

Nous installerons nos projets Django dans leurs propres environnements virtuels pour isoler les exigences de chacun. Pour ce faire, nous allons installer + virtualenv +, qui peut créer des environnements virtuels Python, et + virtualenvwrapper +, qui ajoute des améliorations en termes de convivialité au flux de travail + virtualenv +.

Nous allons installer ces deux composants en utilisant + pip +, le gestionnaire de paquets Python. Nous pouvons installer cet utilitaire à partir des référentiels Ubuntu.

Si vous construisez vos projets Django avec * Python 2 *, tapez:

sudo apt-get update
sudo apt-get install python-pip

Si vous utilisez * Python 3 *, tapez:

sudo apt-get update
sudo apt-get install python3-pip

Maintenant que + pip est installé, nous pouvons installer` + virtualenv` et + virtualenvwrapper globalement. Nous allons également mettre à jour + pip vers la dernière version en utilisant` + pip` lui-même.

Si vous utilisez * Python 2 *, tapez:

sudo -H pip install --upgrade pip
sudo -H pip install virtualenv virtualenvwrapper

Si vous utilisez * Python 3 *, tapez:

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv virtualenvwrapper

Avec ces composants installés, nous pouvons maintenant configurer notre shell avec les informations nécessaires pour fonctionner avec le script + virtualenvwrapper +. Nos environnements virtuels seront tous placés dans un répertoire de notre dossier de départ appelé + Env + pour un accès facile. Ceci est configuré via une variable d’environnement appelée + WORKON_HOME +. Nous pouvons l’ajouter à notre script d’initialisation du shell et pouvons générer le script wrapper de l’environnement virtuel.

Si vous utilisez * Python 3 * et la commande + pip3 +, vous devrez également ajouter une ligne supplémentaire à votre script d’initialisation du shell:

echo "export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3" >> ~/.bashrc

Quelle que soit la version de Python que vous utilisez, vous devez exécuter les commandes suivantes:

echo "export WORKON_HOME=~/Env" >> ~/.bashrc
echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

Maintenant, sourcez votre script d’initialisation du shell pour pouvoir utiliser cette fonctionnalité dans votre session actuelle:

source ~/.bashrc

Vous devriez maintenant avoir un répertoire appelé + Env + dans votre dossier de départ qui contiendra les informations sur l’environnement virtuel.

Créer des projets Django

Maintenant que nous avons nos outils d’environnement virtuel, nous allons créer deux environnements virtuels, installer Django dans chacun d’eux et démarrer deux projets.

Créer le premier projet

Nous pouvons créer facilement un environnement virtuel en utilisant certaines commandes que le script + virtualenvwrapper + met à notre disposition.

Créez votre premier environnement virtuel avec le nom de votre premier site ou projet en tapant:

mkvirtualenv

Cela créera un environnement virtuel, y installera Python et + pip +, et activera l’environnement. Votre invite changera pour indiquer que vous opérez maintenant dans votre nouvel environnement virtuel. Cela ressemblera à quelque chose comme ceci: + () @: ~ $ +. La valeur entre parenthèses est le nom de votre environnement virtuel. Tous les logiciels installés via + pip + seront désormais installés dans l’environnement virtuel plutôt que sur le système global. Cela nous permet d’isoler nos packages projet par projet.

Notre première étape sera d’installer Django lui-même. Nous pouvons utiliser + pip pour cela sans` + sudo` puisque nous l’installons localement dans notre environnement virtuel:

pip install django

Avec Django installé, nous pouvons créer notre premier exemple de projet en tapant:

cd ~
django-admin.py startproject

Cela créera un répertoire appelé «++» dans votre répertoire personnel. Il contient un script de gestion permettant de gérer divers aspects du projet et un autre répertoire du même nom contenant le code du projet.

Déplacez-vous dans le répertoire de premier niveau afin que nous puissions commencer à définir les exigences minimales pour notre projet exemple.

cd ~/

Commencez par migrer la base de données pour initialiser la base de données SQLite que notre projet utilisera. Vous pouvez configurer une base de données alternative pour votre application si vous le souhaitez, mais cela sort du cadre de ce guide:

~//manage.py migrate

Vous devriez maintenant avoir un fichier de base de données appelé + db.sqlite3 + dans votre répertoire de projet. Maintenant, nous pouvons créer un utilisateur administratif en tapant:

~//manage.py createsuperuser

À ce stade, votre répertoire de projet (+ ~ / + dans notre cas) devrait avoir le contenu suivant:

  • + ~ / firstsite / manage.py +: Un script de gestion de projet Django.

  • + ~ / firstsite / firstsite / +: Le package du projet Django. Cela devrait contenir les fichiers + init . Py +, + settings.py +, + urls.py + et + wsgi.py +.

  • + ~ / firstsite / db.sqlite3 +: Le fichier de base de données SQLite utilisé pour stocker les informations de votre site.

Ensuite, ouvrez le fichier de paramètres du projet avec votre éditeur de texte:

nano ~///settings.py

Commencez par localiser la directive + ALLOWED_HOSTS +. Ceci définit une liste des adresses du serveur ou des noms de domaines 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 cela pour empêcher une certaine classe de vulnérabilité de sécurité.

Entre les crochets, répertoriez les adresses IP ou les noms de domaine associés à votre serveur Django. Chaque élément doit être répertorié dans des citations avec des entrées séparées par une virgule. Si vous souhaitez des demandes pour un domaine entier et des sous-domaines, ajoutez une période au début de l’entrée. L’extrait ci-dessous contient quelques exemples commentés utilisés pour illustrer:

~ / firstsite / firstsite / settings.py

. . .
# 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 = ['', '', ]

Comme nous allons configurer Nginx pour servir notre site, nous devons configurer un répertoire qui contiendra les actifs statiques de notre site. Cela permettra à Nginx de les servir directement, ce qui aura un impact positif sur les performances. Nous dirons à Django de les placer dans un répertoire appelé + static + dans le répertoire de base de notre projet. Ajoutez cette ligne au bas du fichier pour configurer ce comportement:

~ / firstsite / firstsite / settings.py

. . .
STATIC_URL = '/static/'

Enregistrez et fermez le fichier lorsque vous avez terminé. Maintenant, collectez les éléments statiques de notre site et placez-les dans ce répertoire en tapant:

~//manage.py collectstatic

Vous pouvez être invité à taper «oui» pour confirmer l’action et collecter le contenu statique. Il y aura un nouveau répertoire appelé + static + dans le répertoire de votre projet.

Ensuite, nous pouvons ouvrir un port pour pouvoir accéder au serveur de développement Django. Si vous avez suivi le guide de configuration initiale du serveur, vous devez activer un pare-feu UFW. Autorisez les connexions au port 8080 en tapant:

sudo ufw allow 8080

Après tout cela, nous pouvons tester notre projet en démarrant temporairement le serveur de développement. Type:

~//manage.py runserver 0.0.0.0:8080

Cela démarrera le serveur de développement sur le port + 8080 +. Accédez au nom de domaine ou à l’adresse IP de votre serveur, suivi de «+ 8080 +» dans votre navigateur:

http://:8080

Vous devriez voir une page qui ressemble à ceci:

image: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/sample_site.png [exemple de site Django]

Ajoutez + / admin + à la fin de l’URL dans la barre d’adresse de votre navigateur et vous serez redirigé vers la page de connexion de l’administrateur:

image: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/admin_login.png [Connexion à l’administrateur Django]

À l’aide des informations d’identification de connexion administrative que vous avez sélectionnées avec la commande + createuperuser +, connectez-vous au serveur. Vous aurez alors accès à l’interface d’administration:

image: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/admin_interface.png [Interface d’administration Django]

Après avoir testé cette fonctionnalité, arrêtez le serveur de développement en tapant * CTRL-C * dans votre terminal. Nous pouvons maintenant passer à notre deuxième projet.

Créer le deuxième projet

Le deuxième projet sera créé exactement de la même manière que le premier. Nous allons abréger l’explication dans cette section, en vous rendant compte de la façon dont vous l’avez déjà réalisée.

Revenez dans votre répertoire personnel et créez un deuxième environnement virtuel pour votre nouveau projet. Installez Django dans ce nouvel environnement une fois qu’il est activé:

cd ~
mkvirtualenv
pip install django

Le nouvel environnement sera créé _ et_ remplacé par, laissant votre environnement virtuel précédent. Cette instance de Django est entièrement séparée de l’autre que vous avez configurée. Cela vous permet de les gérer indépendamment et de les personnaliser si nécessaire.

Créez le deuxième projet et accédez au répertoire du projet:

cd ~
django-admin.py startproject
cd ~/

Initialisez la base de données et créez un utilisateur administratif:

~//manage.py migrate
~//manage.py createsuperuser

Ouvrez le fichier de paramètres:

nano ~///settings.py

Définissez + ALLOWED_HOSTS + sur le domaine de votre deuxième projet, sur l’adresse IP du serveur ou sur les deux, exactement comme vous l’avez fait pour le premier projet:

ALLOWED_HOSTS = ['', '', ]

Ajoutez l’emplacement des fichiers statiques, comme vous l’avez fait dans le projet précédent:

~ / secondsite / secondsite / settings.py

. . .
STATIC_URL = '/static/'

Enregistrez et fermez le fichier. Maintenant, collectez les éléments statiques dans ce répertoire en tapant:

~//manage.py collectstatic

Enfin, démarrez le serveur de développement pour tester le site:

~//manage.py runserver 0.0.0.0:8080

Vous devriez vérifier le site habituel à:

http://:8080

Connectez-vous également au site d’administration:

http://:8080/admin

Lorsque vous avez confirmé que tout fonctionne comme prévu, tapez * CTRL-C * dans votre terminal pour arrêter le serveur de développement.

Sauvegarde de l’environnement virtuel

Puisque nous en avons terminé avec la partie Django du guide, nous pouvons désactiver notre deuxième environnement virtuel:

deactivate

Si vous avez à nouveau besoin de travailler sur l’un de vos sites Django, réactivez leurs environnements respectifs. Vous pouvez le faire en utilisant la commande + workon +:

workon

Or:

workon

Encore une fois, désactivez-le lorsque vous avez fini de travailler sur vos sites:

deactivate

Nous pouvons maintenant passer à la configuration du serveur d’applications.

Configuration du serveur d’applications uWSGI

Maintenant que deux projets Django sont configurés et prêts à fonctionner, nous pouvons configurer uWSGI. uWSGI est un serveur d’applications pouvant communiquer avec des applications via une interface standard appelée WSGI. Pour en savoir plus à ce sujet, lisez https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04 # définitions-et-concepts [cette section] de notre guide sur la configuration de uWSGI et Nginx sur Ubuntu 14.04.

Installer uWSGI

Contrairement au guide lié ci-dessus, dans ce tutoriel, nous installerons uWSGI globalement. Cela créera moins de friction dans la gestion de plusieurs projets Django. Avant de pouvoir installer uWSGI, nous avons besoin des fichiers de développement Python sur lesquels le logiciel repose. Nous pouvons l’installer directement à partir des dépôts d’Ubuntu.

Si vous utilisez Django avec * Python 2 *, tapez:

sudo apt-get install python-dev

Si vous utilisez * Python 3 *, tapez:

sudo apt-get install python3-dev

Maintenant que les fichiers de développement sont disponibles, nous pouvons installer uWSGI globalement via + pip +.

Si vous utilisez * Python 2 *, tapez:

sudo -H pip install uwsgi

Si vous utilisez * Python 3 *, tapez:

sudo -H pip3 install uwsgi

Nous pouvons rapidement tester ce serveur d’applications en lui transmettant les informations d’un de nos sites. Par exemple, nous pouvons lui dire de servir notre premier projet en tapant:

uwsgi --http :8080 --home /home//Env/ --chdir /home// -w .wsgi

Ici, nous avons dit à uWSGI d’utiliser notre environnement virtuel situé dans notre répertoire + ~ / / Env +, de passer dans le répertoire de notre projet et d’utiliser le fichier + wsgi.py + stocké dans notre répertoire ++ intérieur pour servir le fichier (en utilisant la syntaxe du module + firstsite.wsgi + Python). Pour notre démonstration, nous lui avons dit de servir HTTP sur le port + 8080 +.

Si vous accédez au nom de domaine ou à l’adresse IP du serveur dans votre navigateur, suivi de +: 8080 +, vous verrez votre site à nouveau (les éléments statiques de l’interface + / admin +, comme CSS, ne fonctionneront pas encore. ). Lorsque vous avez terminé de tester cette fonctionnalité, tapez CTRL-C dans le terminal.

Création de fichiers de configuration

L’exécution de uWSGI à partir de la ligne de commande est utile pour les tests, mais pas particulièrement pour un déploiement réel. Au lieu de cela, nous exécuterons uWSGI en «mode Emperor», ce qui permet à un processus maître de gérer des applications séparées automatiquement à partir d’un ensemble de fichiers de configuration.

Créez un répertoire qui contiendra vos fichiers de configuration. Comme il s’agit d’un processus global, nous allons créer un répertoire nommé + / etc / uwsgi / sites + pour stocker nos fichiers de configuration:

sudo mkdir -p /etc/uwsgi/sites

Dans ce répertoire, nous placerons nos fichiers de configuration. Nous avons besoin d’un fichier de configuration pour chacun des projets que nous servons. Le processus uWSGI peut prendre des fichiers de configuration dans divers formats, mais nous utiliserons les fichiers + .ini + en raison de leur simplicité.

Créez un fichier pour votre premier projet et ouvrez-le dans votre éditeur de texte:

sudo nano /etc/uwsgi/sites/.ini

A l’intérieur, nous devons commencer par l’en-tête de section + [uwsgi] +. Toutes nos informations iront sous cet en-tête. Nous allons également utiliser des variables pour rendre notre fichier de configuration plus réutilisable. Après l’en-tête, définissez une variable appelée + project + avec le nom de votre premier projet. Ajoutez une variable appelée + uid + qui contient votre nom d’utilisateur + sudo +.

Nous allons également ajouter une variable appelée + base + avec le chemin d’accès au répertoire de base de votre utilisateur. Ceci sera construit à partir du nom d’utilisateur que nous avons défini en utilisant la syntaxe +% (nom_variable) +. Ceci sera remplacé par la valeur de la variable lors de la lecture de la configuration:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

Ensuite, nous devons configurer uWSGI pour qu’il gère notre projet correctement. Nous devons passer au répertoire du projet racine en définissant l’option + chdir +. Nous pouvons combiner le répertoire personnel et le nom du projet en utilisant la même syntaxe de variable.

De manière similaire, nous indiquerons l’environnement virtuel de notre projet. En définissant le module, nous pouvons indiquer exactement comment s’interfacer avec notre projet (en important l’application appelable à partir du fichier + wsgi.py + dans notre répertoire de projet interne). La configuration de ces éléments ressemblera à ceci:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

Nous voulons créer un processus maître avec 5 ouvriers. Nous pouvons le faire en ajoutant ceci:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

Ensuite, nous devons spécifier comment uWSGI doit écouter les connexions. Dans notre test d’uWSGI, nous avons utilisé HTTP et un port réseau. Cependant, puisque nous allons utiliser Nginx en tant que proxy inverse, nous avons de meilleures options.

Au lieu d’utiliser un port réseau, tous les composants fonctionnant sur un seul serveur, nous pouvons utiliser un socket Unix. Ceci est plus sécurisé et offre de meilleures performances. Ce socket n’utilisera pas HTTP, mais implémentera le protocole + uwsgi + de uWSGI, qui est un protocole binaire rapide conçu pour la communication avec d’autres serveurs. Nginx peut utiliser un proxy natif en utilisant le protocole + uwsgi +, il s’agit donc de notre meilleur choix.

Nous allons également modifier la propriété et les autorisations du socket, car nous donnerons un accès en écriture au serveur Web. Nous allons paramétrer l’option + vacuum + pour que le fichier de socket soit automatiquement nettoyé à l’arrêt du service:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

Avec cela, la configuration de notre premier projet uWSGI est terminée. Enregistrez et fermez le fichier.

L’avantage de configurer le fichier à l’aide de variables est qu’il est extrêmement simple à réutiliser. Copiez le premier fichier de configuration de votre projet à utiliser comme base pour votre deuxième fichier de configuration:

sudo cp /etc/uwsgi/sites/.ini /etc/uwsgi/sites/.ini

Ouvrez le deuxième fichier de configuration avec votre éditeur de texte:

sudo nano /etc/uwsgi/sites/.ini

Nous n’avons besoin de changer qu’une seule valeur dans ce fichier pour que cela fonctionne pour notre deuxième projet. Modifiez la variable + projet + avec le nom que vous avez utilisé pour votre deuxième projet:

/etc/uwsgi/sites/secondsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

Enregistrez et fermez le fichier lorsque vous avez terminé. Votre deuxième projet devrait être prêt à partir maintenant.

Créer un fichier unité systemd pour uWSGI

Nous avons maintenant les fichiers de configuration dont nous avons besoin pour desservir nos projets Django, mais nous n’avons toujours pas automatisé le processus. Ensuite, nous allons créer un fichier unité systemd pour gérer le processus uWSGI emperor et démarrer automatiquement uWSGI au démarrage.

Nous allons créer le fichier d’unité dans le répertoire + / etc / systemd / system +, où les fichiers d’unité créés par l’administrateur sont conservés. Nous appellerons votre fichier + uwsgi.service:

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

Commencez par la section + [Unit] +, utilisée pour spécifier les métadonnées et les informations de commande. Nous allons simplement mettre une description de notre service ici:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

Ensuite, nous allons ouvrir la section + [Service] +. Nous allons utiliser la directive + ExecStartPre + pour configurer les éléments nécessaires à l’exécution de notre serveur. Cela garantira que le répertoire + / run / uwsgi + est créé et que notre utilisateur normal le possède avec le groupe + www-data + en tant que propriétaire du groupe. Les deux + mkdir + avec l’indicateur + -p + et la commande + chown + reviennent avec succès même si leur opération n’est pas nécessaire. C’est ce que nous voulons.

Pour la commande de démarrage réelle, spécifiée par la directive + ExecStart +, nous allons pointer sur l’exécutable + uwsgi +. Nous lui dirons de fonctionner en «mode Emperor», ce qui lui permettra de gérer plusieurs applications à l’aide des fichiers trouvés dans + / etc / uwsgi / sites +. Nous ajouterons également les éléments nécessaires à systemd pour gérer correctement le processus. Celles-ci sont extraites de la documentation uWSGI here.

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

Il ne reste plus qu’à ajouter la section + [Install] +. Cela nous permet de spécifier quand le service doit être démarré automatiquement. Nous allons lier notre service à l’état du système multi-utilisateur. Chaque fois que le système est configuré pour plusieurs utilisateurs (la condition de fonctionnement normale), notre service sera activé:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Nous ne pourrons pas démarrer le service avec succès à ce stade car il repose sur la disponibilité de l’utilisateur + www-data +. Nous devrons attendre le démarrage du service uWSGI après l’installation de Nginx.

Installer et configurer Nginx en tant que proxy inverse

Avec uWSGI configuré et prêt à fonctionner, nous pouvons maintenant installer et configurer Nginx en tant que proxy inverse. Ceci peut être téléchargé à partir des dépôts par défaut d’Ubuntu:

sudo apt-get install nginx

Une fois que Nginx est installé, vous pouvez créer un fichier de configuration de bloc de serveur pour chacun de nos projets. Commencez par le premier projet en créant un fichier de configuration de bloc de serveur:

sudo nano /etc/nginx/sites-available/

À l’intérieur, nous pouvons démarrer notre bloc de serveurs en indiquant le numéro de port et le nom de domaine où notre premier projet devrait être accessible. Le bloc + nom_serveur + doit correspondre à l’un des noms de domaine du serveur ou à son adresse IP; sinon, la page Nginx par défaut peut être utilisée à la place. Nous supposerons que vous avez un nom de domaine pour chacun:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;
}

Ensuite, nous pouvons dire à Nginx de ne pas s’inquiéter si elle ne peut pas trouver un favicon. Nous le signalerons également à l’emplacement de notre répertoire de fichiers statiques où nous avons collecté les éléments statiques de notre site:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;

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

Ensuite, nous pouvons créer un bloc d’emplacement fourre-tout qui transmettra toutes les requêtes supplémentaires directement à notre application. Nous allons inclure les paramètres + uwsgi + trouvés dans le + / etc / nginx / uwsgi_params + et transférer le trafic vers le socket que le serveur uWSGI configure:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;

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

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

Avec cela, notre premier bloc de serveur est terminé.

Nous nous en servirons comme base pour le fichier de configuration Nginx de notre deuxième projet. Recopiez-le maintenant:

sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/

Ouvrez le nouveau fichier dans votre éditeur de texte:

sudo nano /etc/nginx/sites-available/

Ici, vous devrez changer toute référence à ` avec une référence à `. Vous devrez également modifier le + nom_serveur + pour que votre deuxième projet réponde à un nom de domaine différent ou modifier le port si vous n’avez pas plus d’un nom de domaine ou adresse IP. Lorsque vous avez terminé, cela ressemblera à quelque chose comme ceci:

/ etc / nginx / sites-available / secondsite

server {
   listen 80;
   server_name .com www..com;

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

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, liez vos deux nouveaux fichiers de configuration au répertoire + sites + activé + de Nginx pour les activer:

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

Vérifiez la syntaxe de configuration en tapant:

sudo nginx -t

Si aucune erreur de syntaxe n’est détectée, vous pouvez redémarrer votre service Nginx pour charger la nouvelle configuration:

sudo systemctl restart nginx

Si vous vous en souvenez, nous n’avons jamais démarré le serveur uWSGI. Faites-le maintenant en tapant:

sudo systemctl start uwsgi

Supprimons la règle UFW sur le port + 8080 + et autorisons plutôt l’accès à notre serveur Nginx:

sudo ufw delete allow 8080
sudo ufw allow 'Nginx Full'

Vous devriez maintenant pouvoir atteindre vos deux projets en accédant à leurs noms de domaine respectifs. Les interfaces publique et administrative doivent fonctionner comme prévu.

Si cela se passe bien, vous pouvez permettre aux deux services de démarrer automatiquement au démarrage en tapant:

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

Dépannage de Nginx et de uWSGI

Si vous ne parvenez pas à accéder à votre application, vous devrez résoudre 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 de remplacer votre serveur par proxy, cela signifie généralement que vous devez ajuster le nom + nom_serveur + dans le fichier + / etc / nginx / sites-available / + pour qu’il pointe vers l’adresse IP de votre serveur. nom de domaine.

Nginx utilise le + nom_serveur + pour déterminer quel bloc de serveur utiliser pour répondre aux demandes. Si vous voyez la page Nginx par défaut, cela signifie que Nginx n’a pas été en mesure de faire correspondre la demande à un bloc de serveur de manière explicite. Il s’agit donc du bloc par défaut défini dans `+ / etc / nginx / sites-available / défaut + `.

Le + nom_serveur + du bloc serveur de votre projet doit être plus spécifique que celui du bloc serveur par défaut à sélectionner.

Nginx affiche une erreur de passerelle 502 incorrecte au lieu de l’application Django

Une erreur 502 indique que Nginx ne parvient pas à proxyer la demande. Une large gamme de problèmes de configuration s’expriment avec une erreur 502; il est donc nécessaire de disposer de plus d’informations pour résoudre correctement les problèmes.

Le principal endroit où rechercher plus d’informations est dans les journaux d’erreur de Nginx. En règle générale, cela vous indiquera quelles conditions ont causé des problèmes lors de l’événement de proxy. Suivez les journaux d’erreur 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 d’actualiser la page). Vous devriez voir un nouveau message d’erreur écrit dans le journal. Si vous regardez le message, il devrait vous aider à cerner le problème.

Vous pourriez voir certains des messages suivants:

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

Cela indique que Nginx n’a pas pu trouver le fichier de socket à l’emplacement indiqué. Vous devriez comparer les emplacements + uwsgi_pass + définis dans les fichiers + firstsite + et + secondsite + dans + / etc / nginx / sites-available + à l’emplacement réel des ` firstsite.sock + `et + secondsite.sock + `fichiers de socket dans le répertoire + / run / uwsgi + `.

Vérifiez l’existence des fichiers de socket dans le répertoire + / run / uwsgi + en tapant:

sudo ls /run/uwsgi

S’il n’y a pas de fichier de socket dans + / run / uwsgi +, cela signifie généralement que le processus + uwsgi + n’a pas pu le créer. Vérifiez l’état du processus + uwsgi + pour savoir s’il a pu démarrer:

sudo systemctl status uwsgi

Si la commande + systemctl status + indique qu’une erreur s’est produite ou si vous ne trouvez pas les fichiers de socket dans le répertoire, cela signifie que uWSGI n’a pas pu démarrer correctement. Vérifiez les journaux de processus d’uWSGI en tapant:

sudo journalctl -u uwsgi

Consultez les messages dans les journaux pour savoir où uWSGI a rencontré des problèmes. Vous pouvez avoir rencontré des problèmes pour de nombreuses raisons, mais souvent, si uWSGI n’a pas pu créer le fichier de socket, cela est dû à l’une des raisons suivantes:

  • Les fichiers de projet appartiennent à l’utilisateur + root + au lieu d’un utilisateur + sudo +

  • La ligne + ExecStartPre + dans le fichier + / etc / systemd / system / uwsgi.service + n’inclut pas la commande correcte pour créer le répertoire et attribuer la propriété.

  • Le chemin + uwsgi_pass + dans les fichiers de configuration du site du répertoire + / etc / nginx / sites-available + ne vise pas l’emplacement de socket correct

  • La configuration uWSGI définie dans les fichiers + .ini + du répertoire + / etc / uwsgi / sites + est incorrecte. Vérifiez les éléments suivants:

  • La directive + chdir +, une fois interpolée, pointe vers le répertoire principal du projet.

  • La directive + home +, une fois interpolée, pointe vers le répertoire de l’environnement virtuel.

  • La directive + module + utilise la syntaxe d’importation du module Python pour charger le fichier + wsgi.py + à partir du répertoire de projet interne.

  • La directive + socket + pointe un fichier dans le fichier + / run / uwsgi + (qui devrait être créé par la ligne + ExecStartPre + dans le fichier de service mentionné ci-dessus).

Si vous apportez des modifications au fichier + / etc / systemd / system / uwsgi.service +, rechargez le démon pour relire la définition du service et redémarrez le processus uWSGI en tapant:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

La résolution de ces problèmes devrait permettre à Nginx de trouver le fichier de socket correctement.

  • connect () à unix: /run/uwsgi/firstsite.sock a échoué (13: autorisation refusée) *

Cela indique que Nginx n’a pas pu se connecter au socket uWSGI en raison de problèmes d’autorisations. Cela se produit généralement lorsque le socket est créé dans un environnement restreint ou si les autorisations sont erronées. Bien que le processus uWSGI puisse créer le fichier de socket, Nginx n’est pas en mesure d’y accéder.

Cela peut se produire si les autorisations sont limitées à tout moment entre le répertoire racine (+ / +) du fichier de socket. Nous pouvons voir les autorisations et les valeurs de propriété du fichier de socket et de chacun de ses répertoires parents en transmettant le chemin absolu de notre fichier de socket à la commande + namei +:

namei -nom /run/uwsgi/firstsite.sock
Outputf: /run/uwsgi/firstsite.sock
drwxr-xr-x root  root     /
drwxr-xr-x root  root     run
drwxr-xr-x sammy www-data uwsgi
srw-rw---- sammy www-data firstsite.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), nous pouvons déterminer le type d’accès autorisé au fichier de socket.

Dans l’exemple ci-dessus, chacun des répertoires menant au fichier de socket possède des autorisations de lecture et d’exécution universelles (la colonne des autorisations des répertoires se termine par + r-x + au lieu de + + + +). Le groupe + www-data a la propriété du groupe sur le socket lui-même. Avec ces paramètres, le processus Nginx devrait pouvoir accéder au socket avec succès.

Si l’un des répertoires menant au socket n’appartient pas au groupe + www-data + ou ne dispose pas des droits de lecture et d’exécution du monde, Nginx ne pourra pas accéder au socket. Cela signifie généralement que les fichiers de configuration comportent une erreur.

Si les chemins d’accès aux répertoires sont trop restrictifs en termes d’autorisations ou de propriétés, examinez le fichier + / etc / systemd / system / uwsgi.service +. La directive + ExecStartPre + est responsable de la création du répertoire + / run / uwsgi + et de l’attribution de la propriété du groupe au groupe + www-data +. Si les commandes ici ne sont pas correctes, les chemins de répertoire peuvent être trop restrictifs.

Si le fichier de socket lui-même est inaccessible au processus Nginx, les paramètres définis dans les fichiers + .ini + dans + / etc / uwsgi / sites + peuvent être incorrects. Vérifiez les valeurs de + chown-socket + et + chmod-socket + pour vous assurer que le processus Web est autorisé à accéder aux fichiers.

Dépannage supplémentaire

Pour un dépannage supplémentaire, les journaux peuvent aider à réduire les causes profondes. Vérifiez chacune d’elles à tour de rôle et recherchez les messages indiquant les zones à problèmes.

Les journaux suivants peuvent être utiles:

  • Vérifiez les journaux de processus Nginx en tapant: + sudo journalctl -u nginx +

  • Consultez les journaux d’accès Nginx en tapant: + sudo less / var / log / nginx / access.log +

  • Vérifiez les journaux d’erreur Nginx en tapant: + sudo less / var / log / nginx / error.log +

  • Vérifiez les journaux de l’application uWSGI en tapant: + sudo journalctl -u uwsgi +

Lors de la mise à jour de votre configuration ou de 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 uWSGI pour prendre en compte les modifications en tapant:

sudo systemctl restart uwsgi

Si vous modifiez le fichier de service systemd + uwsgi +, rechargez le démon et redémarrez le processus en tapant:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

Si vous modifiez la configuration de bloc du serveur Nginx, testez-la, 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, nous avons configuré deux projets Django, chacun dans son propre environnement virtuel. Nous avons configuré uWSGI pour desservir chaque projet indépendamment à l’aide de l’environnement virtuel configuré pour chacun. Ensuite, nous avons configuré Nginx pour qu’il agisse en tant que proxy inverse pour gérer les connexions client et servir le projet approprié en fonction de la demande du client.

Django facilite la création de projets et d’applications en fournissant de nombreux éléments communs, vous permettant de vous concentrer sur des éléments uniques. En exploitant la chaîne d’outils générale décrite dans cet article, vous pouvez facilement desservir les applications que vous créez à partir d’un seul serveur.

Related