Comment servir les applications Django avec uWSGI et Nginx sur CentOS 7

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 CentOS 7 afin de prendre en charge et de 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

Pour compléter ce guide, vous devez disposer d’une nouvelle instance de serveur CentOS 7 avec un utilisateur non root doté des privilèges sudo + configurés. Vous pouvez apprendre à configurer cela en parcourant notre initial initial guide de configuration du serveur.

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. Pour obtenir + pip +, nous devons d’abord activer le référentiel EPEL. Nous pouvons le faire facilement en tapant:

sudo yum install epel-release

Une fois que EPEL est activé, nous pouvons installer + pip + en tapant:

sudo yum install python-pip

Maintenant que + pip + est installé, nous pouvons installer + virtualenv + et + virtualenvwrapper + globalement en tapant:

sudo pip 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.

Pour ajouter les lignes appropriées à votre script d’initialisation du shell, vous devez exécuter les commandes suivantes:

echo "export WORKON_HOME=~/Env" >> ~/.bashrc
echo "source /usr/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

Vous devrez sélectionner un nom d’utilisateur, donner une adresse électronique à un contact, puis sélectionner et confirmer un mot de passe.

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

nano /settings.py

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:

STATIC_ROOT = os.path.join(BASE_DIR, "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 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.

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:

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

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

STATIC_ROOT = os.path.join(BASE_DIR, "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

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 cité ci-dessus, dans ce tutoriel, nous allons installer 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 avons également besoin d’un compilateur. Nous pouvons obtenir les deux en utilisant + yum +:

sudo yum install python-devel gcc

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

sudo pip 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. 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 +` ne fonctionnent 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 appelé + / etc / uwsgi / sites pour stocker vos fichiers de configuration. Déplacez-vous dans le répertoire après l’avoir créé:

sudo mkdir -p /etc/uwsgi/sites
cd /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 .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. Définissez une autre variable avec votre nom d’utilisateur habituel auquel appartiennent les fichiers de projet. Ajoutez une variable appelée + base + qui utilise votre nom d’utilisateur pour établir le chemin du répertoire de base de votre utilisateur:

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

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 les paramètres de répertoire de base et de nom de projet que nous avons définis précédemment en utilisant la syntaxe +% () +. Ceci sera remplacé par la valeur de la variable lors de la lecture de la configuration.

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 le répertoire de notre projet). La configuration de ces éléments ressemblera à ceci:

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

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:

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

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 communiquer avec d’autres serveurs. Nginx peut utiliser un proxy natif en utilisant le protocole + uwsgi +, il s’agit donc de notre meilleur choix.

Nous devons définir l’utilisateur qui exécutera le processus. Nous allons également modifier les autorisations et la propriété du socket, car nous donnerons un accès en écriture au serveur Web. Le socket lui-même sera placé dans le répertoire + / run / uwsgi + (nous allons créer ce répertoire un peu) où uWSGI et Nginx peuvent l’atteindre. Nous allons paramétrer l’option + vacuum + pour que le fichier de socket soit automatiquement nettoyé à l’arrêt du service:

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

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

master = true
processes = 5

uid = %(username)
socket = /run/uwsgi/%(project).sock
chown-socket = %(username):nginx
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:

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

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

master = true
processes = 5

uid = %(username)
socket = /run/uwsgi/%(project).sock
chown-socket = %(username):nginx
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 d’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. Nous allons ensuite créer un fichier d’unité Systemd pour 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’utilisateur 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. Nous allons simplement mettre une description de notre service ici:

[Unit]
Description=uWSGI Emperor service

Ensuite, nous ouvrirons 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 Nginx en tant que propriétaire du groupe. Les deux + mkdir + avec l’indicateur + -p + et la commande + chown + retournent avec succès même s’ils existent déjà. 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:

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/usr/bin/bash -c 'mkdir -p /run/uwsgi; chown :nginx /run/uwsgi'
ExecStart=/usr/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é:

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/usr/bin/bash -c 'mkdir -p /run/uwsgi; chown :nginx /run/uwsgi'
ExecStart=/usr/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 + nginx +. 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. Cela peut être téléchargé et installé en utilisant + yum +:

sudo yum install nginx

Une fois que Nginx est installé, nous pouvons continuer et éditer le fichier de configuration principal:

sudo nano /etc/nginx/nginx.conf

Dans ce fichier, à côté du bloc serveur existant, nous allons créer un bloc serveur supplémentaire pour chacun de nos sites:

http {

   . . .

   include /etc/nginx/conf.d/*.conf;







   server {
       listen 80 default_server;
       server_name localhost;

       . . .

Les blocs que nous avons créés conserveront la configuration de nos sites uWSGI. Nous allons couvrir les directives dont nous avons besoin dans le premier bloc de serveurs maintenant.

Premièrement, nous devons indiquer au bloc serveur le numéro de port et le nom de domaine auxquels il doit répondre. Nous supposerons que vous avez un nom de domaine pour chacun de vos sites:

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

Ensuite, nous dirons à Nginx que nous n’avons pas à nous soucier d’un favicon manquant. Nous spécifierons ensuite le répertoire dans lequel les actifs statiques de notre premier site ont été collectés au moment de la demande de ces fichiers. Nginx peut les remettre directement au client à partir de ce répertoire:

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

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

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

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

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

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

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

Le deuxième bloc de serveurs pour notre autre site sera presque le même. Vous pouvez copier et coller le bloc serveur que nous venons de créer pour commencer. Vous devrez modifier le nom de domaine auquel le site doit répondre, l’emplacement des fichiers statiques du site et le fichier de socket du site:

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;
   }
}

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

Vérifiez la syntaxe du fichier Nginx pour vous assurer que vous n’aurez aucune erreur:

sudo nginx -t

Si aucune erreur n’est signalée, notre fichier est en bon état.

Nous avons une tâche supplémentaire à accomplir pour que nos sites fonctionnent correctement. Étant donné que Nginx gère directement les fichiers statiques, il doit avoir accès aux répertoires appropriés. Nous devons lui donner des autorisations exécutables pour notre répertoire de base, qui est le seul bit d’autorisation qui lui manque.

Pour ce faire, le moyen le plus sûr consiste à ajouter l’utilisateur Nginx à notre propre groupe d’utilisateurs. Nous pouvons ensuite ajouter l’autorisation exécutable aux propriétaires de groupe de notre répertoire personnel, en donnant juste assez d’accès à Nginx pour servir les fichiers:

sudo usermod -a -G  nginx
chmod 710 /home/

Maintenant, nous pouvons démarrer le serveur Nginx et le processus uWSGI:

sudo systemctl start nginx
sudo systemctl start uwsgi

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

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.