Configuration de Django avec PostgreSQL, Nginx et Gunicorn sur Ubuntu 20.04

Django est un framework d'application web gratuit et open-source construit dans le langage de programmation Python . Django est ultra-rapide, sécurisé et hautement évolutif. Entre les mains d'un développeur qualifié, Django peut rapidement mettre en place un site web puissant. Il s'intègre parfaitement aux serveurs web populaires (Apache, Nginx), et aux bases de données (MySQL, MariaDB, PostgreSQL, Oracle, et SQLite), etc. Django propulse certains des plus grands sites web au monde comme Instagram, Mozilla et la NASA. Ce guide montre comment configurer la base d'une application web à l'aide de Django avec PostgreSQL, Nginx et Gunicorn sur Ubuntu 20.04.

Prérequis

Ce guide nécessite que vous utilisiez un serveur Ubuntu 20.04 configuré avec un pare-feu de base et un utilisateur non-root avec les privilèges sudo. Consultez ce guide détaillé sur la configuration d'un serveur Ubuntu. Suivez ce tutoriel pour configurer un utilisateur non-root avec les privilèges sudo. Vous pouvez également configurer un pare-feu Iptables en suivant les étapes de ce guide.

Nous installerons Django dans un environnement virtuel. Avoir un environnement spécifique au projet permet de gérer plus facilement plusieurs projets depuis le même serveur. Une fois les bases de données et les applications en place, nous déploierons le serveur d'application Gunicorn. Gunicorn sera l'interface d'application qui traduit les requêtes des clients de HTTP en appels Python que notre application peut utiliser. Ensuite, nous déploierons Nginx devant Gunicorn pour sa gestion rapide des connexions et ses fonctionnalités de sécurité faciles à mettre en œuvre.

Installation des paquets nécessaires

Tout d'abord, commencez par installer tous les paquets nécessaires. Heureusement, tous ces paquets sont directement disponibles dans les dépôts de paquets officiels d'Ubuntu. Ouvrez le terminal et mettez à jour le cache des paquets APT :

La liste des paquets dépend de si l'application web va utiliser Python 2 ou Python 3. Exécutez la commande suivante pour installer Django avec Python 3 :

Django 1.11 LTS est la dernière version de Django qui prendra en charge Python 2. Si vous avez l'intention d'utiliser Django avec Python 2, installez alors les paquets suivants :

Base de données et utilisateur PostgreSQL

En ce qui concerne la solution de base de données, nous utiliserons PostgreSQL. C'est un système de gestion de base de données relationnelle-objet puissant et open-source. PostgreSQL offre fiabilité, robustesse et performance. Pour des étapes détaillées sur la configuration de PostgreSQL, consultez ce guide sur la configuration de PostgreSQL sur le serveur Ubuntu. Pour ce guide, nous allons configurer une base de données et un utilisateur dédiés pour notre application Django.

Par défaut, PostgreSQL implémente l'« authentification par pair » (peer authentication) comme schéma d'authentification pour les connexions locales. En résumé, l'« authentification par pair » authentifiera la connexion si le nom d'utilisateur du système d'exploitation de l'utilisateur correspond à un nom d'utilisateur PostgreSQL valide. Lors de l'installation, PostgreSQL a configuré un utilisateur du système d'exploitation postgres pour correspondre à l'utilisateur administratif PostgreSQL postgres. Connectez-vous à la session interactive du shell PostgreSQL en tant que postgres en utilisant la commande suivante :

Vous arriverez sur l'invite de commande PostgreSQL. La première étape consiste à créer une base de données dédiée pour le projet. Pour la démonstration, la base de données sera nommée viktor_project:

L'étape suivante consiste à créer un utilisateur dédié pour la base de données du projet. L'utilisateur doit avoir un nom d'utilisateur fort. Pour la démonstration, le nom d'utilisateur sera viktor_project_user:

Maintenant, nous allons modifier certains paramètres :

• Certains paramètres de connexion. En bref, il ne sera pas nécessaire de demander et de définir les valeurs correctes à chaque fois qu'une connexion est établie. Cela améliore considérablement les performances de la base de données.
• Encodage par défaut sur UTF-8. C'est un encodage universel et Django s'y attend.
• Schéma d'isolation des transactions par défaut sur « read committed ». Cela bloque la lecture à partir de transactions non validées.
• Fuseau horaire sur UTC.

Toutes ces modifications de paramètres sont recommandées par le projet Django lui-même. Pour implémenter ces changements, exécutez les commandes suivantes. N'oubliez pas de remplacer le nom d'utilisateur de la base de données par le bon :

Changez l'administrateur de la base de données pour l'utilisateur de base de données dédié :

Notre travail avec PostgreSQL est terminé pour le moment. Quittez le shell interactif de PostgreSQL :

Environnement virtuel Python

Une fois la base de données préparée, nous pouvons maintenant nous concentrer sur la mise en place des autres exigences du projet. Pour une gestion plus facile, nous allons créer un environnement virtuel et y installer toutes les dépendances Python. Pour générer un environnement virtuel, nous avons besoin de virtualenv. Il peut être facilement installé avec pip.

Les commandes suivantes mettront à jour pip et installeront virtualenv. Pour Python 3, exécutez les commandes suivantes :

Pour Python 2, exécutez plutôt les commandes suivantes :

Une fois que virtualenv est installé, il est temps de créer un environnement virtuel. Ensuite, créez un répertoire dédié pour l'environnement virtuel :

Après cela, changez le répertoire actif actuel pour le répertoire dédié à l'environnement virtuel :

Dans le répertoire, exécutez la commande suivante. L'outil virtualenv créera un environnement virtuel avec le nom du projet :

Cela créera un sous-répertoire avec le nom du projet. Le sous-répertoire contiendra une version locale de Python et de pip. Cela offre la flexibilité d'installer et de configurer un environnement Python isolé pour le projet.

La commande suivante activera l'environnement virtuel :

L'invite du terminal changera pour indiquer que vous opérez dans un environnement virtuel Python. Maintenant que nous sommes dans l'environnement virtuel, nous allons installer les dépendances Python nécessaires. Nous avons besoin de Django, Gunicorn et psycopg2 (adaptateur PostgreSQL). La commande suivante demandera au pip local d'installer les composants :

Même si vous utilisez Python 3, pip est la commande correcte. C'est parce que dans l'environnement virtuel, pip3 est renommé en pip.

Nouveau projet Django

Une fois les composants Python en place, nous pouvons commencer à travailler avec les fichiers réels du projet Django.

• Création d'un projet Django

Le répertoire du projet est déjà établi. Nous allons dire à Django d'y installer ses fichiers. Cette procédure générera un répertoire de second niveau contenant le code réel. Le répertoire contiendra également un script de gestion. L'essentiel est que nous indiquons explicitement à Django le répertoire cible au lieu de le laisser décider du répertoire par rapport au répertoire actuel :

Django créera le projet en conséquence. Voici quelques-uns des fichiers et répertoires importants sur lesquels nous allons nous concentrer. Les noms de répertoires et de fichiers sont utilisés conformément à la démonstration.

• ~/viktor_project/manage.py: Le script de gestion de projet par Django.
• ~/viktor_project/viktor_project/: C'est le paquet contenant le projet Django. Il doit contenir les fichiers __init__.py, settings.py, urls.py, asgi.py et wsgi.py.

• Ajustement des paramètres du projet

Une fois le projet créé, la première chose à faire est d'ajuster sa configuration. Ouvrez settings.py dans un éditeur de texte :

La première directive que nous recherchons est ALLOWED_HOSTS. Elle définit les serveurs ou noms de domaine qui peuvent se connecter à l'instance Django. Si une requête entrante avec un en-tête Host ne correspond pas à la liste ALLOWED_HOSTS, cela générera une exception. Il est recommandé par Django d'éviter certains types de vulnérabilités de sécurité :

La section suivante sur laquelle nous allons nous concentrer est DATABASE. Elle gère l'accès à la base de données. Par défaut, elle contient la configuration pour le moteur de base de données SQLite. Cependant, nous allons utiliser la base de données PostgreSQL pour le projet. Django utilisera l'adaptateur psycopg2 pour communiquer avec PostgreSQL :

Maintenant, allez au bas du fichier. Ajoutez les lignes suivantes pour indiquer l'emplacement des fichiers statiques. Cela aide Nginx à gérer les requêtes pour ces éléments :

Notre travail avec settings.py est terminé pour le moment. Enregistrez le fichier et fermez l'éditeur.

• Finalisation de la configuration initiale du projet

Nous pouvons maintenant migrer le schéma de base de données initial vers la base de données PostgreSQL dédiée. Exécutez la commande suivante :

Ensuite, nous devons créer un superutilisateur pour le projet. Pour générer un superutilisateur, exécutez la commande suivante :

Rassemblez tous les fichiers statiques dans l'emplacement que nous avons spécifié dans settings.py. Les fichiers statiques seront collectés dans un répertoire séparé appelé « static » sous le répertoire du projet :

Maintenant, nous devons configurer le pare-feu du serveur. Si vous avez suivi le guide de configuration du serveur, vous avez déjà configuré et activé UFW. Nous allons créer une exception pour le port 8000. C'est le port par défaut utilisé par Django. Consultez ce guide pour en savoir plus sur les bases et l'utilisation du pare-feu UFW.

Ensuite, vérifiez l'action :

Enfin, nous pouvons tester le serveur en action. Démarrez le serveur de développement Django :

Si la configuration a réussi, le serveur de développement Django devrait démarrer et accepter les requêtes entrantes. Ouvrez un navigateur et accédez à l'IP/domaine de votre serveur sur le port 8000 :

Vous devriez arriver sur la page d'index par défaut de Django. Pour accéder au panneau d'administration, ajoutez /admin à l'URL. Le panneau d'administration n'est accessible que par le superutilisateur que nous avons créé auparavant :

Après vous être connecté, vous arriverez sur l'interface d'administration par défaut de Django :

Nous avons terminé les tests pour l'instant. Pour arrêter le serveur, appuyez sur « Ctrl + C » dans la fenêtre du terminal.

• Tester Gunicorn

Avant de quitter l'environnement virtuel, nous voulons nous assurer que Gunicorn peut servir les applications. La façon de le tester est d'utiliser Gunicorn pour charger le module WSGI du projet.

La commande Gunicorn est située dans le répertoire du projet :

Cela démarrera Gunicorn sur la même interface que celle sur laquelle Django s'exécutait. Nous pouvons tester à nouveau l'application depuis un navigateur web normal. Notez que l'interface d'administration n'aura aucun style appliqué car Gunicorn ne sait toujours pas comment trouver le contenu CSS statique :

Une fois terminé, appuyez sur « Ctrl + C » dans la fenêtre du terminal pour arrêter le serveur Gunicorn.

• Quitter l'environnement virtuel

La configuration de l'application Django est terminée. Exécutez la commande suivante pour quitter l'environnement virtuel :

Fichiers de socket et de service Gunicorn

Nous avons vérifié que Gunicorn peut interagir avec l'application Django. Cependant, nous avons besoin d'un moyen plus robuste pour gérer le serveur d'application. C'est là que systemd entre en jeu. Systemd est l'un des systèmes d'initialisation les plus populaires disponibles sur Linux. Voici un guide détaillé sur comment gérer les services et unités systemd.

Nous pouvons créer des fichiers de socket et de service pour Gunicorn afin de laisser systemd le gérer comme s'il s'agissait d'un service. Au démarrage, le socket Gunicorn sera généré. Le socket écoutera les connexions entrantes. Lorsqu'une connexion a lieu, systemd démarrera les processus Gunicorn pour gérer la connexion.

• Socket Gunicorn

Commençons par créer un socket Gunicorn. Le fichier doit être créé avec les privilèges sudo :

Saisissez le code suivant dans le fichier :

Comme vous pouvez le voir, le code comporte trois sections.

• [Unit]: Cette section décrit le socket.
• [Socket]: Elle définit l'emplacement du socket.
• [Install]: Cette partie garantit que systemd crée le socket au bon moment.

Enregistrez le fichier et fermez l'éditeur.

• Service Gunicorn

Ensuite, nous allons créer un fichier de service pour Gunicorn. Tout comme le fichier de socket, il doit également être créé avec les privilèges sudo :

Saisissez le code suivant :

Le code contient plusieurs sections :

• [Unit]: Cette section spécifie les métadonnées et les dépendances. Elle décrit également le démarrage uniquement après que la cible réseau est atteinte.
• [Service]: Cette section spécifie l'utilisateur et le groupe sous lesquels le processus s'exécutera. La propriété du groupe est définie sur « www-data » afin que Nginx puisse communiquer avec Gunicorn. Elle définit également les répertoires de travail et spécifie les commandes de démarrage.
• [Install]: Cette section indique à systemd à quoi lier ce service s'il est activé au démarrage. Il doit démarrer après le lancement du système multi-utilisateur standard.

Ensuite, enregistrez le fichier et fermez l'éditeur.

• Activation du socket Gunicorn

Le socket Gunicorn est prêt à l'emploi. Par conséquent, vous pouvez exécuter les commandes suivantes. Cela démarrera et activera le socket. Le fichier de socket sera créé dans /run/gunicorn.sock au démarrage. Lorsqu'une connexion est établie avec le socket, systemd démarrera le service Gunicorn pour la gérer :

Vérifiez le statut du socket Gunicorn :

Maintenant, vérifiez l'existence du fichier de socket :

Si le statut de systemctl indique une erreur ou si le fichier gunicorn.sock n'a pas été trouvé, cela signifie que le socket n'a pas été créé correctement. Consultez le journal détaillé pour obtenir des indices :

N'oubliez pas de jeter un autre coup d'œil au gunicorn.socket pour détecter d'éventuelles erreurs.

• Activation du socket

Nous avons démarré le gunicorn.socket jusqu'à présent. Cependant, sans aucune demande de connexion, gunicorn.service ne s'activera pas. Ensuite, vérifiez le statut de Gunicorn :

Nous pouvons tester le mécanisme d'activation du socket en envoyant une demande de connexion à l'aide de curl :

Vous devriez obtenir une sortie HTML de l'application. Cela indique que Gunicorn a démarré avec succès et a pu servir l'application Django. Vérifiez le statut actuel du service Gunicorn :

S'il y a un comportement ou une sortie inattendue (indiquant une erreur), consultez les journaux détaillés pour obtenir des indices :

Si des modifications ont été apportées au fichier gunicorn.service, vous devez recharger le démon pour relire la définition du service. Cela nécessite également de redémarrer le service Gunicorn :

Configuration de Nginx

Maintenant, nous allons configurer Nginx pour transmettre le trafic entrant au processus. Tout d'abord, créez un nouveau bloc de serveur dans Nginx :

Ensuite, saisissez le code suivant :

 

Voici plusieurs blocs dans la configuration :

• service: Ce bloc définit que le serveur doit écouter normalement sur le port 80 et doit répondre au nom de domaine ou à l'adresse IP du serveur.
• location: Il s'agit de la première entrée de localisation. Elle définit où trouver les ressources statiques.
• location: Il s'agit de la deuxième entrée de localisation. Ce bloc définit les paramètres de proxy standard et la manière de transmettre le trafic au socket Gunicorn.

Enregistrez le fichier et fermez l'éditeur. Liez le fichier au répertoire « sites-enabled » pour l'activer :

Après cela, testez s'il y a une erreur de syntaxe dans la configuration de Nginx :

Si vous n’avez pas trouvé d'erreur, redémarrez Nginx pour appliquer la modification :

Nous devons à nouveau modifier les règles UFW. Nous n'avons plus besoin d'accéder au serveur de développement, nous pouvons donc supprimer l'exception pour le port 8000. De plus, nous voulons ouvrir le port 80 pour le trafic normal :

Vérifiez ces modifications des règles du pare-feu :

Le serveur devrait maintenant être accessible depuis un navigateur web normal.

Procédures de dépannage

Si toutes les étapes ont été correctement suivies, l'application Django devrait être accessible via Internet. Si ce n'est pas le cas, cela indique que l'installation ne s'est pas déroulée comme prévu. Nous devons procéder à un dépannage pour identifier la source du problème.

• Nginx affiche la page par défaut

Si Nginx affiche la page par défaut au lieu du proxy de l'application, cela signifie généralement que le server_name a été mal configuré dans le bloc de serveur.

Dans cet exemple, the bloc de serveur est stocké à l'emplacement suivant :

L'entrée server_name détermine quel bloc de serveur Nginx utilisera pour répondre aux requêtes. Si la page par défaut s'affiche, c'est probablement parce que Nginx n'a pas pu faire correspondre la requête à un bloc de serveur explicite, il se rabat donc sur le bloc par défaut :

Vérifiez si le bloc de serveur de votre projet Django a un server_name.

• 502 Bad Gateway

L'erreur 502 indique que Nginx n'a pas pu relayer la requête avec succès. Un large éventail de problèmes de configuration possibles peut conduire à l'erreur 502, nous avons donc besoin d'indices pour dépanner correctement.

La principale source d'indices réside dans les journaux d'erreurs de Nginx. En général, ils indiquent les conditions qui ont causé les problèmes lors du proxy. Vérifiez le journal d'erreurs de Nginx à l'aide de la commande suivante :

Une fois le journal ouvert, essayez d'accéder à nouveau au serveur. Cela devrait générer un nouveau message d'erreur dans le journal. Cela peut aider à cibler le problème. Voici quelques messages possibles :

• connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

Cela indique que Nginx n'a pas pu trouver gunicorn.sock à l'emplacement défini dans la configuration. L'emplacement est décrit par la directive proxy_pass sous le bloc du site. Vérifiez si proxy_pass indique le bon emplacement de gunicorn.sock généré par l'unité systemd gunicorn.socket :

Si gunicorn.sock n'a pas été trouvé sous le répertoire /run, cela signifie que systemd n'a pas pu le générer. Vous devriez revérifier les étapes de configuration du fichier socket Gunicorn.

• connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

Cela indique que Nginx n'a pas pu se connecter au socket Gunicorn en raison de problèmes de permissions. Cela peut se produire si le processus a été exécuté en tant qu'utilisateur root au lieu d'un utilisateur sudo. Bien que systemd ait généré gunicorn.sock avec succès, Nginx n'est pas en mesure de l'utiliser.

Un coupable possible peut être des permissions limitées entre le répertoire racine (/) et le fichier gunicorn.sock. Vérifiez les permissions et la propriété du fichier socket et de chacun de ses répertoires parents :

La première colonne décrit les permissions du fichier. La deuxième colonne décrit l'utilisateur propriétaire, et la troisième colonne le groupe propriétaire. Si l'un des répertoires menant à gunicorn.sock n'a pas les permissions de lecture et d'exécution appropriées, Nginx ne parviendra pas à accéder au socket.

• Django affichant « could not connect to the server: Connection refused »

Cela indique que Django n'a pas réussi à se connecter au serveur PostgreSQL. Assurez-vous que le serveur PostgreSQL est opérationnel :

S'il n'est pas en cours d'exécution, exécutez les commandes suivantes pour le démarrer et l'activer :

Si vous rencontrez toujours cette erreur, assurez-vous que les identifiants de la base de données sont correctement définis sous settings.py:

Dépannage supplémentaire

Pour un dépannage supplémentaire, divers journaux sont mis en place. Ces journaux peuvent aider à identifier l'origine des problèmes.

Voici une liste de journaux qui peuvent vous aider :

• Journaux Nginx

• Journaux d'accès - Nginx

• Journaux d'erreurs - Nginx

•  Journaux d'application - Gunicorn

•  Journaux de socket - Gunicorn

Après avoir effectué une mise à jour de la configuration ou de l'application, vous devrez peut-être redémarrer les processus pour appliquer les modifications. Si l'application Django a été mise à jour, redémarrez le processus Gunicorn pour prendre en compte les modifications :
Dans le cas où des modifications sont apportées aux fichiers de socket ou de service Gunicorn, rechargez le démon et redémarrez les processus :
Si des modifications ont été apportées à la configuration du bloc serveur Nginx, elle doit être testée avant d'être mise en œuvre. Cela nécessite également le redémarrage de Nginx :

Dernières réflexions

Ce guide démontre avec succès comment poser les bases de Django. Django fournit de nombreux composants courants d'une application web, vous permettant de vous concentrer sur les éléments uniques. Le projet Django fonctionnera au sein de l'environnement virtuel. Gunicorn gère la communication entre les requêtes des clients et Django. Enfin, Nginx agit comme un proxy inverse pour gérer les connexions des clients.

Bonne programmation !