One place for hosting & domains

      Gunicorn

      Comment configurer Django avec Postgres, Nginx et Gunicorn sur Ubuntu 20.04


      Introduction

      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.

      Conditions prélables et objectifs

      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.

      Installation des paquets à partir des référentiels Ubuntu

      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.

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

      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 :

      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 :

      Postgres est maintenant configuré de manière à ce que Django puisse se connecter et gérer les informations de sa base de données.

      Création d’un environnement virtuel Python pour votre projet

      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 :

      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.

      Création et Configuration d’un nouveau projet Django

      Une fois nos composants Python installés, nous pouvons créer les fichiers du projet Django.

      Création 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.

      Ajustement des paramètres du projet

      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.

      ~/myprojectdir/myproject/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 = ['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 :

      ~/myprojectdir/myproject/settings.py

      . . .
      
      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 :

      ~/myprojectdir/myproject/settings.py

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

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Terminer la configuration initiale du projet

      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 :

      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 :

      Page d'index 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 :

      Connexion à l'interface d'administration de Django

      Une fois l’authentification terminée, vous pouvez accéder à l’interface admin par défaut de Django :

      Interface admin 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.

      Tester la capacité de Gunicorn à servir le projet

      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 :

      L’indicateur de l’environnement virtuel dans votre invite sera supprimé.

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

      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 :

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Ensuite, créez et ouvrez un fichier de service systemd pour Gunicorn avec 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 :

      /etc/systemd/system/gunicorn.service

      [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 :

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      

      Enfin, 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 :

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      
      [Install]
      WantedBy=multi-user.target
      

      Avec cela, 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érification du fichier de socket Gunicorn

      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 :

      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.

      Test d’activation de socket

      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.

      Configurer Nginx pour passer par proxy à Gunicorn

      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 :

      /etc/nginx/sites-available/myproject

      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 :

      /etc/nginx/sites-available/myproject

      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 :

      /etc/nginx/sites-available/myproject

      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 :

      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.

      Dépanner Nginx et Gunicorn

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

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

      Si Nginx affiche la page par défaut au lieu d’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é.

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

      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

      Output

      f: /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.

      Django affiche : “n’a pas pu se connecter au serveur : Connexion refusée”

      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.

      Autres dépannages

      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 :

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

      Lorsque vous mettez à jour votre configuration ou votre application, vous devrez probablement redémarrer les processus pour vous 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.

      Conclusion

      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.



      Source link

      Como configurar o Django com o Postgres, Nginx e o Gunicorn no Ubuntu 20.04


      Introdução

      O Django é um framework Web poderoso, que pode ajudar o seu aplicativo Python ou site a decolar. O Django inclui um servidor de desenvolvimento simplificado para testar seu código localmente, mas para qualquer coisa ligeiramente relacionada com produção, é necessário um servidor Web mais seguro e poderoso.

      Neste guia, vamos demonstrar como instalar e configurar alguns componentes no Ubuntu 20.04 para apoiar e servir aplicativos do Django. Vamos configurar um banco de dados PostgreSQL ao invés de usar o banco de dados padrão SQLite. Vamos configurar o servidor do aplicativo Gunicorn para interagir com nossos aplicativos. Então, vamos configurar o Nginx como proxy reverso do Gunicorn, dando-nos acesso aos seus recursos de segurança e desempenho para servir nossos aplicativos.

      Pré-requisitos e objetivos

      Para completar este guia, você deve ter uma nova instância de servidor Ubuntu 20.04 com um firewall básico e um usuário não root com privilégios sudo configurados. Você pode aprender como configurar isso examinando nosso guia de configuração inicial de servidor.

      Vamos instalar o Django em um ambiente virtual. Instalar o Django em um ambiente específico do seu projeto permitirá que seus projetos e seus requisitos sejam tratados separadamente.

      Assim que tivermos nosso banco de dados e aplicativo funcionando, vamos instalar e configurar o servidor do aplicativo Gunicorn. Isso servirá como uma interface para nosso aplicativo, traduzindo os pedidos do cliente de HTTP para chamadas Python que nosso aplicativo consegue processar. Então, vamos configurar o Nginx na frente do Gunicorn para aproveitar seus mecanismos de gerenciamento de conexão de alta performance e seus recursos de segurança fáceis de implementar.

      Vamos começar.

      Instalando os pacotes dos repositórios do Ubuntu

      Para começar o processo, vamos baixar e instalar todos os itens que precisamos dos repositórios do Ubuntu. Vamos usar o gerenciador de pacotes Python pip para instalar componentes adicionais um pouco mais tarde.

      Precisamos atualizar o índice de pacotes local apt e, em seguida, baixar e instalar os pacotes. Os pacotes que instalamos dependem da versão do Python que seu projeto usará.

      Se estiver usando o Django com o Python 3, digite:

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

      O Django 1.11 é a última versão do Django que suportará o Python 2. Se você estiver começando novos projetos, é altamente recomendado que escolha o Python 3. Se ainda for necessário usar o Python 2, digite:

      • sudo apt update
      • sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

      Isso instalará o pip, os arquivos de desenvolvimento do Python necessários para criar o Gunicorn mais tarde, o sistema de banco de dados Postgres e as bibliotecas necessárias para interagir com ele, e o servidor Web Nginx.

      Criando o banco de dados e o usuário PostgreSQL

      Vamos ir direto e criar um banco de dados e um usuário do banco de dados para nosso aplicativo Django.

      Por padrão, o Postgres usa um esquema de autenticação chamado de “autenticação por peer” para conexões locais. Basicamente, isso significa que se o nome de usuário do sistema operacional do usuário corresponder a um nome de usuário do Postgres válido, o usuário pode logar-se sem autenticação adicional.

      Durante a instalação do Postgres, um usuário do sistema operacional chamado postgres foi criado para corresponder ao usuário administrativo postgres do PostgreSQL. Precisamos usar este usuário para realizar tarefas administrativas. Podemos usar o sudo e passar o nome de usuário com a opção -u.

      Logue-se em uma sessão interativa do Postgres digitando:

      Você receberá um prompt do PostgreSQL onde podemos configurar nossos requisitos.

      Primeiramente, crie um banco de dados para seu projeto:

      • CREATE DATABASE myproject;

      Nota: toda declaração do Postgres deve terminar com um ponto e vírgula, portanto certifique-se de que o seu comando termine com um caso esteja experienciando problemas.

      Em seguida, crie um usuário do banco de dados para nosso projeto. Certifique-se de selecionar uma senha segura:

      • CREATE USER myprojectuser WITH PASSWORD 'password';

      Depois disso, vamos modificar alguns dos parâmetros de conexão para o usuário que acabamos de criar. Isso irá acelerar as operações do banco de dados para que os valores corretos não tenham que ser consultados e definidos cada vez que uma conexão for estabelecida.

      Estamos definindo a codificação padrão para UTF-8, que é a que o Django espera. Também estamos definindo o esquema padrão de isolamento de transação para “ler confirmados”, que bloqueia a leitura de transações não confirmadas. Por fim, vamos definir o fuso horário. Por padrão, nossos projetos Django serão configurados para usar o UTC. Essas são todas recomendações do projeto Django em si:

      • 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';

      Agora, podemos dar ao nosso novo usuário acesso para administrar nosso novo banco de dados:

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Quando tiver terminado, saia do prompt do PostgreSQL digitando:

      O Postgres agora está configurado para que o Django possa se conectar ao seu banco de dados e gerenciar suas informações.

      Criando um Ambiente Virtual Python para seu Projeto

      Agora que temos nosso banco de dados, podemos começar a preparar o resto dos nossos requisitos do projeto. Vamos instalar nossos requisitos do Python em um ambiente virtual para fácil gerenciamento.

      Para fazer isso, precisamos primeiro acessar o comando virtualenv. Podemos instalar isso com o pip.

      Se estiver usando o Python 3, atualize o pip e instale o pacote digitando:

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

      Se estiver usando o Python 2, atualize o pip e instale o pacote digitando:

      • sudo -H pip install --upgrade pip
      • sudo -H pip install virtualenv

      Com o virtualenv instalado, podemos começar a formar nosso projeto. Crie um diretório onde possamos manter nossos arquivos do projeto e vá até ele:

      • mkdir ~/myprojectdir
      • cd ~/myprojectdir

      Dentro do diretório do projeto, crie um ambiente virtual do Python digitando:

      Isso criará um diretório chamado myprojectenv dentro do seu diretório myprojectdir. Lá dentro, ele instalará uma versão local do Python e uma versão local do pip. Podemos usar isso para instalar e configurar um ambiente Python isolado para nosso projeto.

      Antes de instalarmos os requisitos Python do nosso projeto, precisamos ativar o ambiente virtual. Você pode fazer isso digitando:

      • source myprojectenv/bin/activate

      Seu prompt deverá mudar para indicar que você agora está operando em um ambiente virtual Python. Ele se parecerá com isso: (myprojectenv)user@host:~/myprojectdir$.

      Com seu ambiente virtual ativo, instale o Django, Gunicorn, e o adaptador do PostgreSQL psycopg2 com a instância local do pip:

      Nota: quando o ambiente virtual for ativado (quando seu prompt tiver (myprojectenv) antecedendo-o) use o pip em vez do pip3, mesmo se estiver usando o Python 3. A cópia da ferramenta do ambiente virtual é sempre chamada de pip, independentemente da versão do Python.

      • pip install django gunicorn psycopg2-binary

      Agora, você deve ter todos os softwares necessários para iniciar um projeto Django.

      Criando e Configurando um Projeto Django Novo

      Com nossos componentes Python instalados, podemos criar os arquivos do projeto Django em si.

      Criando o Projeto Django

      Como já temos um diretório de projeto, vamos dizer ao Django para instalar os arquivos aqui. Ele criará um diretório de segundo nível com o código real, o que é normal, e colocará um script de gerenciamento neste diretório. A chave para isso é que estamos definindo o diretório explicitamente ao invés de permitir que o Django tome decisões sobre nosso diretório atual:

      • django-admin.py startproject myproject ~/myprojectdir

      Neste ponto, o diretório do projeto (~/myprojectdir no nosso caso) deve ter o seguinte conteúdo:

      • ~/myprojectdir/manage.py: um script de gerenciamento de projeto Django.
      • ~/myprojectdir/myproject/: o pacote do projeto Django. Isso deve conter os arquivos __init__.py, settings.py, urls.py, asgi.py e wsgi.py.
      • ~/myprojectdir/myprojectenv/: o diretório do ambiente virtual que criamos anteriormente.

      Ajustando as configurações do Projeto

      A primeira coisa que devemos fazer com nossos arquivos de projeto recém-criados é ajustar as configurações. Abra as configurações no seu editor de texto:

      • nano ~/myprojectdir/myproject/settings.py

      Comece localizando a diretriz ALLOWED_HOSTS. Isso define uma lista dos endereços ou nomes de domínio do servidor que podem ser usados para se conectar à instância Django. Qualquer pedido recebido com um cabeçalho Host que não está nessa lista irá criar uma exceção. O Django exige que você defina isso para prevenir uma certa classe de vulnerabilidade de segurança.

      Dentro dos colchetes, liste os endereços IP ou nomes de domínio associados ao seu servidor do Django. Cada item deve ser listado entre aspas, com entradas separadas divididas por uma vírgula. Se você quiser pedidos para um domínio inteiro e quaisquer subdomínios, anteceda um período ao início da entrada. No trecho abaixo, há alguns exemplos comentados usados como demonstração:

      Nota: certifique-se de incluir o localhost como uma das opções, uma vez que usaremos proxy nas conexões através de uma instância local do Nginx.

      ~/myprojectdir/myproject/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 = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
      

      Em seguida, encontre a seção que configura o acesso ao banco de dados. Ela começará com DATABASES. A configuração no arquivo é para um banco de dados SQLite. Já criamos um banco de dados PostgreSQL para nosso projeto, então precisamos ajustar as configurações.

      Altere as configurações com as informações do seu banco de dados PostgreSQL. Diremos ao Django para usar o adaptador psycopg2 que instalamos com o pip. Precisamos fornecer o nome do banco de dados, o nome de usuário do banco de dados, a senha do usuário do banco de dados, e então especificar que o banco de dados está localizado no computador local. Você pode deixar a configuração PORT como uma string vazia:

      ~/myprojectdir/myproject/settings.py

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

      Em seguida, vá até o final do arquivo e adicione uma configuração indicando onde os arquivos estáticos devem ser colocados. Isso é necessário para que o Nginx possa lidar com pedidos para esses itens. A seguinte linha diz ao Django para colocá-los em um diretório chamado static no diretório base do projeto:

      ~/myprojectdir/myproject/settings.py

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

      Salve e feche o arquivo quando você terminar.

      Completando a Configuração Inicial do Projeto

      Agora, podemos migrar o esquema inicial do banco de dados para nosso banco de dados PostgreSQL usando o script de gerenciamento:

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

      Crie um usuário administrativo para o projeto digitando:

      • ~/myprojectdir/manage.py createsuperuser

      Você terá que selecionar um nome de usuário, fornecer um endereço e-mail, e escolher uma senha e confirmá-la.

      Podemos coletar todos o conteúdo estático no local do diretório que configuramos digitando:

      • ~/myprojectdir/manage.py collectstatic

      Você terá que confirmar a operação. Os arquivos estáticos serão então colocados em um diretório chamado static dentro do diretório do seu projeto.

      Se seguiu o guia de configuração inicial do servidor, você deve ter um firewall UFW protegendo seu servidor. Para testar o servidor de desenvolvimento, vamos ter que permitir o acesso à porta que iremos usar.

      Crie uma exceção para a porta 8000 digitando:

      Finalmente, você pode testar nosso projeto iniciando o servidor de desenvolvimento Django com este comando:

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      No seu navegador Web, visite o nome de domínio ou endereço IP do seu servidor seguido de :8000:

      http://server_domain_or_IP:8000
      

      Você deve receber a página de índice do Django:

      Página de índice do Django

      Se adicionar /admin no final do URL na barra de endereço, você será solicitado a colocar o nome de usuário administrativo e a senha que criou com o comando createsuperuser:

      Login de administrador no Django

      Após a autenticação, você pode acessar a interface de admin do Django padrão:

      Interface de administrador do Django

      Quando você terminar de explorá-la, aperte CTRL-C na janela do terminal para fechar o servidor de desenvolvimento.

      Testando a capacidade do Gunicorn para servir o projeto

      A última coisa que queremos fazer antes de deixar nosso ambiente virtual é testar o Gunicorn para garantir que ele possa servir o aplicativo. Podemos fazer isso entrando no nosso diretório de projeto e usando o gunicorn para carregar o módulo WSGI do projeto:

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

      Isso irá iniciar o Gunicorn na mesma interface em que o servidor de desenvolvimento do Django estava sendo executado. Você pode voltar e testar o aplicativo novamente.

      Nota: a interface administrativa não terá nenhum dos estilos aplicados, já que o Gunicorn não sabe como encontrar o conteúdo CSS estático responsável por isso.

      Passamos um módulo ao Gunicorn especificando o caminho de diretório relativo para o arquivo wsgi.py do Django, que é o ponto de entrada para nosso aplicativo, usando a sintaxe do módulo do Python. Dentro deste arquivo, é definida uma função chamada de application, que é usada para se comunicar com o aplicativo. Para aprender mais sobre a especificação WSGI, clique aqui.

      Quando terminar os testes, aperte CTRL-C na janela do terminal para interromper o Gunicorn.

      Agora, acabamos de configurar nosso aplicativo Django. Podemos sair do nosso ambiente virtual digitando:

      O indicador do ambiente virtual no seu prompt será removido.

      Criando arquivos de socket e de serviço systemd para o Gunicorn

      Nós testamos que o Gunicorn pode interagir com nosso aplicativo Django, mas devemos implementar uma maneira mais robusta de começar e parar o servidor do aplicativo. Para isso, vamos fazer arquivos de serviço e de socket do systemd.

      O socket Gunicorn será criado no boot e escutará as conexões. Quando ocorrer uma conexão, o systemd irá iniciar o processo Gunicorn automaticamente para lidar com a conexão.

      Comece criando e abrindo um arquivo de socket do systemd para o Gunicorn com privilégios sudo:

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

      Dentro, vamos criar uma seção [Unit] para descrever o socket, uma seção [Socket] para definir a localização do socket e uma seção [Install] para garantir que o socket seja criado no momento certo:

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Salve e feche o arquivo quando você terminar.

      Em seguida, crie e abra um arquivo de serviço do systemd para o Gunicorn com privilégios sudo no seu editor de texto. O nome do arquivo de serviço deve corresponder ao nome do arquivo do socket com exceção da extensão:

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

      Comece com a seção [Unit], que é usada para especificar os metadados e dependências. Vamos colocar uma descrição do nosso serviço aqui e dizer ao sistema init para iniciar isso somente após o objetivo da rede ter sido alcançado. Uma vez que nosso serviço se baseia no socket do arquivo do socket, precisamos incluir uma diretriz Requires para indicar essa relação:

      /etc/systemd/system/gunicorn.service

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

      Em seguida, vamos abrir a seção [Service]. Nós especificaremos o usuário e o grupo em que queremos que o processo seja executado. Vamos dar à nossa conta de usuário regular a posse do processo uma vez que ela possui todos os arquivos relevantes. Vamos atribuir a posse de grupo ao grupo www-data para que o Nginx possa se comunicar facilmente com o Gunicorn.

      Então, vamos mapear o diretório em funcionamento e especificar o comando a ser usado para iniciar o serviço. Neste caso, precisaremos especificar o caminho completo para o executável do Gunicorn, que está instalado dentro do nosso ambiente virtual. Vamos ligar o processo ao socket Unix que criamos dentro do diretório /run para que o processo possa se comunicar com o Nginx. Nós registramos todos os dados na saída padrão para que o processo journald possa recolher os registros do Gunicorn. Também podemos especificar quaisquer ajustes opcionais no Gunicorn aqui. Por exemplo, especificamos 3 processos de trabalho neste caso:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      

      Finalmente, adicionaremos uma seção [Install]. Isso dirá ao systemd o que ligar a este serviço se nós habilitarmos que ele seja iniciado no boot. Queremos que este serviço comece quando o sistema regular de vários usuários estiver funcionando:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      
      [Install]
      WantedBy=multi-user.target
      

      Com isso, nosso arquivo de serviço systemd está completo. Salve e feche-o agora.

      Agora, podemos iniciar e habilitar o socket do Gunicorn. Isso criará o arquivo do socket em /run/gunicorn.sock agora e na inicialização do sistema. Quando uma conexão for feita no socket, o systemd irá iniciar o gunicorn.service automaticamente para lidar com ela:

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

      Podemos confirmar que a operação foi bem sucedida verificando o arquivo do socket.

      Verificando o arquivo de socket do Gunicorn

      Verifique o status do processo para descobrir se ele foi capaz de iniciar:

      • sudo systemctl status gunicorn.socket

      Você deve receber um resultado como este:

      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

      Em seguida, verifique a existência do arquivo gunicorn.sock dentro do diretório /run:

      Output

      /run/gunicorn.sock: socket

      Se o comando systemctl status indicou que um erro ocorreu ou se você não encontrou o arquivo gunicorn.sock no diretório, é uma indicação de que o socket do Gunicorn não foi criado corretamente. Verifique os registros do socket do Gunicorn digitando:

      • sudo journalctl -u gunicorn.socket

      Veja novamente o seu arquivo /etc/systemd/system/gunicorn.socket para corrigir qualquer problema antes de continuar.

      Testando a ativação do socket

      Até aqui, se tiver iniciado apenas a unidade gunicorn.socket, o gunicorn.service ainda não estará ativo, já que o socket ainda não recebeu nenhuma conexão. Você pode verificar isso digitando:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead)

      Para testar o mecanismo de ativação do socket, podemos enviar uma conexão para o socket através do curl digitando:

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

      Você deve receber a saída HTML do seu aplicativo no terminal. Isso indica que o Gunicorn foi iniciado e conseguiu servir seu aplicativo Django. Você pode verificar se o serviço Gunicorn está funcionando digitando:

      • 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

      Se o resultado do curl ou o resultado do systemctl status indicar que um problema ocorreu, verifique os registros para mais detalhes:

      • sudo journalctl -u gunicorn

      Verifique seu arquivo /etc/systemd/system/gunicorn.service quanto a problemas. Se fizer alterações no arquivo /etc/systemd/system/gunicorn.service, recarregue o daemon para reler a definição do serviço e reinicie o processo do Gunicorn digitando:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn

      Certifique-se de que você tenha resolvido os problemas acima antes de continuar.

      Configurar o Nginx para passagem de proxy para o Gunicorn

      Agora que o Gunicorn está configurado, precisamos configurar o Nginx para passar o tráfego para o processo.

      Inicie criando e abrindo um novo bloco de servidor no diretório sites-available do Nginx:

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

      Lá dentro, abra um novo bloco de servidor. Vamos começar especificando que este bloco deve escutar a porta normal 80 e que ele deve responder ao nome de domínio ou endereço IP do nosso servidor:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      }
      

      Em seguida, vamos dizer ao Nginx para ignorar todos os problemas ao encontrar um favicon. Também vamos dizer a ele onde encontrar os ativos estáticos que coletamos no nosso diretório ~/myprojectdir/static. Todos esses arquivos têm um prefixo URI padrão “/static”, então podemos criar um bloco de localização para corresponder a esses pedidos:

      /etc/nginx/sites-available/myproject

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

      Por fim, vamos criar um bloco location / {} para corresponder a todos os outros pedidos. Dentro deste local, vamos incluir o arquivo proxy_params padrão incluído na instalação do Nginx e então vamos passar o tráfego diretamente para o socket do Gunicorn:

      /etc/nginx/sites-available/myproject

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

      Salve e feche o arquivo quando você terminar. Agora, podemos habilitar o arquivo ligando-o ao diretório sites-enabled:

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

      Teste sua configuração do Nginx para erros de sintaxe digitando:

      Se nenhum erro for reportado, vá em frente e reinicie o Nginx digitando:

      • sudo systemctl restart nginx

      Por fim, precisamos abrir nosso firewall para o tráfego normal na porta 80. Como já não precisamos mais acessar o servidor de desenvolvimento, podemos remover também a regra para abrir a porta 8000:

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

      Agora, você deve conseguir ir ao domínio ou endereço IP do seu servidor para ver seu aplicativo.

      Nota: depois de configurar o Nginx, o próximo passo deve ser proteger o tráfego para o servidor usando SSL/TLS. Isso é importante, pois sem ele, todas as informações, incluindo senhas são enviadas para a rede em texto simples.

      Se você tiver um nome de domínio, a maneira mais fácil de obter um certificado SSL para proteger seu tráfego é usando o Let’s Encrypt. Siga este guia para configurar o Let’s Encrypt com o Nginx no Ubuntu 20.04. Siga o procedimento usando o bloco de servidor do Nginx que criamos neste guia.

      Solucionando problemas do Nginx e do Gunicorn

      Se este último passo não mostrar o seu aplicativo, será necessário resolver o problema da sua instalação.

      Nginx está mostrando a página padrão ao invés do aplicativo Django

      Se o Nginx mostra a página padrão em vez de direcionar via proxy para o seu aplicativo, isso geralmente significa que você precisa ajustar o parâmetro server_name dentro do arquivo /etc/nginx/sites-available/myproject para apontar para o endereço IP ou nome de domínio do seu servidor.

      O Nginx usa o server_name para determinar qual bloco de servidor usar para responder aos pedidos. Se você estiver vendo a página padrão do Nginx, é um sinal de que o Nginx não conseguiu corresponder ao pedido a um bloco de servidor explicitamente, então ele está recorrendo ao bloco padrão definido em /etc/nginx/sites-available/default.

      O server_name no bloco de servidor do seu projeto deve ser mais específico do que aquele no bloco de servidor padrão para ser selecionado.

      Nginx está exibindo um erro 502 Bad Gateway ao invés do aplicativo Django

      Um erro 502 indica que o Nginx é incapaz de atuar como proxy para o pedido com sucesso. Uma ampla gama de problemas de configuração se expressam com um erro 502, então é necessário mais informações para resolver o problema corretamente.

      O primeiro lugar para procurar mais informações é nos registros de erro do Nginx. Geralmente, isso irá dizer-lhe quais condições causaram problemas durante o evento de proxy. Vá até os registros de erro do Nginx, digitando:

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

      Agora, faça outro pedido no seu navegador para gerar um novo erro (tente atualizar a página). Você deve receber uma nova mensagem de erro escrita no registro. Se olhar para a mensagem, ela deve ajudar você a estreitar o problema.

      Você pode receber a seguinte mensagem:

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

      Isso indica que o Nginx foi incapaz de encontrar o arquivo gunicorn.sock no local indicado. Você deve comparar a localização do proxy_pass definida dentro do arquivo /etc/nginx/sites-available/myproject com a localização real do arquivo gunicorn.sock gerado pela unidade systemd gunicorn.socket.

      Se você não puder encontrar um arquivo gunicorn.sock dentro do diretório /run, isso signica geralmente que o arquivo de socket do systemd foi incapaz de criá-lo. Volte para a seção sobre verificar o arquivo de socket do Gunicorn para seguir as etapas de solução de problemas para o Gunicorn.

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

      Isso indica que o Nginx foi incapaz de se conectar ao socket do Gunicorn devido a problemas de permissão. Isso pode acontecer quando o procedimento é seguido usando o usuário root ao invés de um usuário sudo. Embora o systemd seja capaz de criar o arquivo de socket do Gunicorn, o Nginx é incapaz de acessá-lo.

      Isso pode acontecer se houver permissões limitadas em qualquer ponto entre o diretório root (/) e o arquivo gunicorn.sock. Podemos revisar as permissões e os valores de posse do arquivo de socket e cada um dos seus diretórios pais passando o caminho absoluto para nosso arquivo de socket pelo comando namei:

      • namei -l /run/gunicorn.sock

      Output

      f: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock

      O resultado mostra as permissões de cada um dos componentes do diretório. Ao olhar para as permissões (primeira coluna), proprietário (segunda coluna) e proprietário do grupo (terceiro coluna), podemos descobrir qual tipo de acesso é permitido ao arquivo de socket.

      No exemplo acima, o arquivo de socket e cada um dos diretórios que levam ao arquivo de socket têm permissões de leitura e execução global (a coluna de permissões para os diretórios termina com r-x ao invés de ---). O processo Nginx deve ser capaz de acessar o socket com sucesso.

      Se qualquer um dos diretórios que levam ao socket não tiverem permissão de leitura e execução global, o Nginx não poderá acessar o socket sem permitir permissões de leitura e execução globais ou garantir que o proprietário do grupo seja dado a um grupo do qual o Nginx faça parte.

      Django está exibindo: “could not connect to server: Connection refused”

      Uma mensagem que você pode receber do Django ao tentar acessar partes do aplicativo no navegador Web é:

      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?
      

      Isso indica que o Django é incapaz de se conectar ao banco de dados do Postgres. Certifique-se de que a instância do Postgres está sendo executada digitando:

      • sudo systemctl status postgresql

      Se não estiver, você pode iniciá-la e habilitá-la para iniciar automaticamente no boot (se ela ainda não estiver configurada para fazer isso) digitando:

      • sudo systemctl start postgresql
      • sudo systemctl enable postgresql

      Se ainda estiver tendo problemas, certifique-se de que as configurações do banco de dados definidas no arquivo ~/myprojectdir/myproject/settings.py estejam corretas.

      Soluções de problemas adicionais

      Para soluções de problemas adicionais, os registros podem ajudar a reduzir os problemas de raiz. Verifique cada um deles individualmente e procure mensagens que indiquem áreas de problemas.

      Os registros a seguir podem ser úteis:

      • Verifique os registros de processo do Nginx digitando: sudo journalctl -u nginx
      • Verifique os registros de acesso do Nginx digitando: sudo less /var/log/nginx/access.log
      • Verifique os registros de erro do Nginx digitando: sudo less /var/log/nginx/error.log
      • Verifique os registros do aplicativo Gunicorn digitando: sudo journalctl -u gunicorn
      • Verifique os registros do socket do Gunicorn digitando: sudo journalctl -u gunicorn.socket

      Conforme atualiza sua configuração ou aplicativo, provavelmente precisará reiniciar os processos para ajustá-los às suas alterações.

      Se atualizar seu aplicativo Django, você pode reiniciar o processo Gunicorn para aplicar as alterações, digitando:

      • sudo systemctl restart gunicorn

      Se alterar o socket ou arquivos de serviço do Gunicorn, recarregue o daemon e reinicie o processo, digitando:

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

      Se alterar a configuração do bloco de servidor do Nginx, teste a configuração e então o Nginx digitando:

      • sudo nginx -t && sudo systemctl restart nginx

      Estes comandos são úteis para aplicar as alterações conforme você ajusta sua configuração.

      Conclusão

      Neste guia, configuramos um projeto Django em seu próprio ambiente virtual. Configuramos o Gunicorn para traduzir pedidos de clientes para que o Django possa lidar com eles. Depois disso, configuramos o Nginx para agir como um proxy reverso para lidar com conexões de clientes e servir o projeto correto, dependendo da solicitação do cliente.

      O Django torna a criação de projetos e aplicativos simples, fornecendo muitas peças comuns, permitindo que você se concentre nos elementos únicos. Ao utilizar a cadeia de ferramentas geral descrita neste artigo, você pode servir facilmente os aplicativos que criar a partir de um único servidor.



      Source link

      Настройка Django с Postgres, Nginx и Gunicorn в Ubuntu 20.04


      Введение

      Django — это мощная веб-система, помогающая создать приложение или сайт Python с нуля. Django включает упрощенный сервер разработки для локального тестирования кода, однако для серьезных производственных задач требуется более защищенный и мощный веб-сервер.

      В этом руководстве мы покажем, как установить и настроить некоторые компоненты Ubuntu 20.04 для поддержки и обслуживания приложений Django. Вначале мы создадим базу данных PostgreSQL вместо того, чтобы использовать базу данных по умолчанию SQLite. Мы настроим сервер приложений Gunicorn для взаимодействия с нашими приложениями. Затем мы настроим Nginx для работы в качестве обратного прокси-сервера Gunicorn, что даст нам доступ к функциям безопасности и повышения производительности для обслуживания наших приложений.

      Предварительные требования и цели

      Для прохождения этого обучающего модуля вам потребуется новый экземпляр сервера Ubuntu 20.04 с базовым брандмауэром и пользователем с привилегиями sudo и без привилегий root. Чтобы узнать, как выполнить данные настройки, воспользуйтесь нашим руководством по начальной настройке сервера.

      Мы будем устанавливать Django в виртуальной среде. Установка Django в отдельную среду проекта позволит отдельно обрабатывать проекты и их требования.

      Когда база данных будет работать, мы выполним установку и настройку сервера приложений Gunicorn. Он послужит интерфейсом нашего приложения и будет обеспечивать преобразование запросов клиентов по протоколу HTTP в вызовы Python, которые наше приложение сможет обрабатывать. Затем мы настроим Nginx в качестве обратного прокси-сервера для Gunicorn, чтобы воспользоваться высокоэффективными механизмами обработки соединений и удобными функциями безопасности.

      Давайте приступим.

      Установка пакетов из хранилищ Ubuntu

      Чтобы начать данную процедуру, нужно загрузить и установить все необходимые нам элементы из хранилищ Ubuntu. Для установки дополнительных компонентов мы немного позднее используем диспетчер пакетов Python pip.

      Нам нужно обновить локальный индекс пакетов apt, а затем загрузить и установить пакеты. Конкретный состав устанавливаемых пакетов зависит от того, какая версия Python будет использоваться в вашем проекте.

      Если вы используете Django с Python 3, введите следующее:

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

      Версия Django 1.11 — это последняя версия Django с поддержкой Python 2. Если вы создаете новый проект, мы настоятельно рекомендуем использовать Python 3. Если же вам необходимо использовать Python 2, введите:

      • sudo apt update
      • sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

      Таким образом вы установите pip, файлы разработки Python для последующего построения сервера Gunicorn, СУБД Postgres и необходимые для взаимодействия с ней библиотеки, а также веб-сервер Nginx.

      Создание базы данных и пользователя PostgreSQL

      Вначале мы создадим базу данных и пользователя базы данных для нашего приложения Django.

      По умолчанию Postgres использует для локальных соединений схему аутентификации «peer authentication». Это означает, что если имя пользователя операционной системы совпадает с действительным именем пользователя Postgres, этот пользователь может войти без дополнительной аутентификации.

      Во время установки Postgres был создан пользователь операционной системы с именем postgres, соответствующий пользователю postgres базы данных PostgreSQL с правами администратора. Этот пользователь нам потребуется для выполнения административных задач. Мы можем использовать sudo и передать это имя пользователя с опцией -u.

      Выполните вход в интерактивный сеанс Postgres, введя следующую команду:

      Вы увидите диалог PostgreSQL, где можно будет задать наши требования.

      Вначале создайте базу данных для своего проекта:

      • CREATE DATABASE myproject;

      Примечание. Каждое выражение Postgres должно заканчиваться точкой с запятой. Проверьте, так ли заканчивается ваша команда, если у вас возникли проблемы с выполнением.

      Затем создайте пользователя базы данных для нашего проекта. Обязательно выберите безопасный пароль:

      • CREATE USER myprojectuser WITH PASSWORD 'password';

      Затем мы изменим несколько параметров подключения для только что созданного нами пользователя. Это ускорит работу базы данных, поскольку теперь при каждом подключении не нужно будет запрашивать и устанавливать корректные значения.

      Мы зададим кодировку по умолчанию UTF-8, чего и ожидает Django. Также мы зададим схему изоляции транзакций по умолчанию «read committed», которая будет блокировать чтение со стороны неподтвержденных транзакций. В заключение мы зададим часовой пояс. По умолчанию наши проекты Django настроены на использование стандарта времени UTC. Все эти рекомендации взяты непосредственно из проекта Django:

      • 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';

      Теперь мы предоставим созданному пользователю доступ для администрирования новой базы данных:

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Завершив настройку, закройте диалог PostgreSQL с помощью следующей команды:

      Теперь настройка Postgres завершена, и Django может подключаться к базе данных и управлять своей информацией в базе данных.

      Создание виртуальной среды Python для вашего проекта

      Мы создали базу данных, и теперь можем перейти к остальным требованиям нашего проекта. Для удобства управления мы установим наши требования Python в виртуальной среде.

      Для этого нам потребуется доступ к команде virtualenv. Для установки мы можем использовать pip.

      Если вы используете Python 3, обновите pip и установите пакет с помощью следующей команды:

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

      Если вы используете Python 2, обновите pip и установите пакет с помощью следующей команды:

      • sudo -H pip install --upgrade pip
      • sudo -H pip install virtualenv

      После установки virtualenv мы можем начать формирование нашего проекта. Создайте каталог для файлов нашего проекта и перейдите в этот каталог:

      • mkdir ~/myprojectdir
      • cd ~/myprojectdir

      Создайте в каталоге проекта виртуальную среду Python с помощью следующей команды:

      Эта команда создаст каталог myprojectenv в каталоге myprojectdir. В этот каталог будут установлены локальная версия Python и локальная версия pip. Мы можем использовать эту команду для установки и настройки изолированной среды Python для нашего проекта.

      Прежде чем установить требования Python для нашего проекта, необходимо активировать виртуальную среду. Для этого можно использовать следующую команду:

      • source myprojectenv/bin/activate

      Командная строка изменится, показывая, что теперь вы работаете в виртуальной среде Python. Она будет выглядеть примерно следующим образом: (myprojectenv)user@host:~/myprojectdir$.

      После запуска виртуальной среды установите Django, Gunicorn и адаптер PostgreSQL psycopg2 с помощью локального экземпляра pip:

      Примечание. Если виртуальная среда активирована (когда перед командной строкой стоит (myprojectenv)), необходимо использовать pip вместо pip3, даже если вы используете Python 3. Копия инструмента в виртуальной среде всегда имеет имя pip вне зависимости от версии Python.

      • pip install django gunicorn psycopg2-binary

      Теперь у вас должно быть установлено все программное обеспечение, необходимое для запуска проекта Django.

      Создание и настройка нового проекта Django

      Установив компоненты Python, мы можем создать реальные файлы проекта Django.

      Создание проекта Django

      Поскольку у нас уже есть каталог проекта, мы укажем Django установить файлы в него. В этом каталоге будет создан каталог второго уровня с фактическим кодом (это нормально) и размещен скрипт управления. Здесь мы явно определяем каталог, а не даем Django принимать решения относительно текущего каталога:

      • django-admin.py startproject myproject ~/myprojectdir

      Сейчас каталог вашего проекта (в нашем случае ~/myprojectdir) должен содержать следующее:

      • ~/myprojectdir/manage.py: скрипт управления проектом Django.
      • ~/myprojectdir/myproject/: пакет проекта Django. В нем должны содержаться файлы __init__.py, settings.py, urls.py, asgi.py и wsgi.py.
      • ~/myprojectdir/myprojectenv/: каталог виртуальной среды, который мы создали до этого.

      Изменение настроек проекта

      Прежде всего, необходимо изменить настройки созданных файлов проекта. Откройте файл настроек в текстовом редакторе:

      • nano ~/myprojectdir/myproject/settings.py

      Начните с директивы ALLOWED_HOSTS. Она определяет список адресов сервера или доменных имен, которые можно использовать для подключения к экземпляру Django. Любой входящий запрос с заголовком Host, не включенный в этот список, будет вызывать исключение. Django требует, чтобы вы использовали эту настройку, чтобы предотвратить использование определенного класса уязвимости безопасности.

      В квадратных скобках перечислите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в кавычках, отдельные записи должны быть разделены запятой. Если вы хотите включить в запрос весь домен и любые субдомены, добавьте точку перед началом записи. В следующем фрагменте кода для демонстрации в строках комментариев приведено несколько примеров:

      Примечание. Обязательно укажите localhost как одну из опций, поскольку мы будем использовать локальный экземпляр Nginx в качестве прокси-сервера.

      ~/myprojectdir/myproject/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 = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
      

      Затем найдите раздел, который будет настраивать доступ к базе данных. Он будет начинаться с DATABASES. Конфигурация в файле предназначена для базы данных SQLite. Мы уже создали базу данных PostgreSQL для нашего проекта, и поэтому нужно изменить настройки.

      Измените настройки, указав параметры базы данных PostgreSQL. Мы даем указания Django использовать адаптер psycopg2, который мы установили с помощью pip. Нам нужно указать имя базы данных, имя пользователя базы данных, пароль пользователя базы данных, и указать, что база данных расположена на локальном компьютере. Вы можете оставить для параметра PORT пустую строку:

      ~/myprojectdir/myproject/settings.py

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

      Затем перейдите в конец файла и добавьте параметр, указывающий, где следует разместить статичные файлы. Это необходимо, чтобы Nginx мог обрабатывать запросы для этих элементов. Следующая строка дает указание Django поместить их в каталог с именем static в базовом каталоге проекта:

      ~/myprojectdir/myproject/settings.py

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

      Сохраните файл и закройте его после завершения.

      Завершение начальной настройки проекта

      Теперь мы можем перенести начальную схему базы данных для нашей базы данных PostgreSQL, используя скрипт управления:

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

      Создайте административного пользователя проекта с помощью следующей команды:

      • ~/myprojectdir/manage.py createsuperuser

      Вам нужно будет выбрать имя пользователя, указать адрес электронной почты, а затем задать и подтвердить пароль.

      Мы можем собрать весь статичный контент в заданном каталоге с помощью следующей команды:

      • ~/myprojectdir/manage.py collectstatic

      Данную операцию нужно будет подтвердить. Статичные файлы будут помещены в каталог static в каталоге вашего проекта.

      Если вы следовали указаниям модуля по начальной настройке сервера, ваш сервер должен защищать брандмауэр UFW. Чтобы протестировать сервер разработки, необходимо разрешить доступ к порту, который мы будем использовать.

      Создайте исключение для порта 8000 с помощью следующей команды:

      Теперь вы можете протестировать ваш проект, запустив сервер разработки Django с помощью следующей команды:

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      Откройте в вашем браузере доменное имя или IP-адрес вашего сервера с суффиксом :8000:

      http://server_domain_or_IP:8000
      

      Вы должны получить страницу индекса Django по умолчанию:

      Страница индекса Django

      Если вы добавите /admin в конце URL в адресной строке, вам будет предложено ввести имя пользователя и пароль администратора, созданные с помощью команды createsuperuser:

      Окно входа в качестве администратора Django

      После аутентификации вы получите доступ к интерфейсу администрирования Django по умолчанию:

      Интерфейс администрирования Django

      Завершив тестирование, нажмите CTRL-C в окне терминала, чтобы завершить работу сервера разработки.

      Тестирование способности Gunicorn обслуживать проект

      Перед выходом из виртуальной среды нужно протестировать способность Gunicorn обслуживать приложение. Для этого нам нужно войти в каталог нашего проекта и использовать gunicorn для загрузки модуля WSGI проекта:

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

      Gunicorn будет запущен на том же интерфейсе, на котором работал сервер разработки Django. Теперь вы можете вернуться и снова протестировать приложение.

      Примечание. В интерфейсе администратора не применяются стили, поскольку Gunicorn не умеет находить необходимый для этого статичный контент CSS.

      Мы передали модуль в Gunicorn, указав относительный путь к файлу Django wsgi.py, который представляет собой точку входа в наше приложение. Для этого мы использовали синтаксис модуля Python. В этом файле определена функция application, которая используется для взаимодействия с приложением. Дополнительную информацию о спецификации WSGI можно найти здесь.

      После завершения тестирования нажмите CTRL-C в окне терминала, чтобы остановить работу Gunicorn.

      Мы завершили настройку нашего приложения Django. Теперь мы можем выйти из виртуальной среды с помощью следующей команды:

      Индикатор виртуальной среды будет убран из командной строки.

      Создание файлов сокета и служебных файлов systemd для Gunicorn

      Мы убедились, что Gunicorn может взаимодействовать с нашим приложением Django, но теперь нам нужно реализовать более надежный способ запуска и остановки сервера приложений. Для этого мы создадим служебные файлы и файлы сокета systemd.

      Сокет Gunicorn создается при загрузке и прослушивает подключения. При подключении systemd автоматически запускает процесс Gunicorn для обработки подключения.

      Создайте и откройте файл сокета systemd для Gunicorn с привилегиями sudo:

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

      В этом файле мы создадим раздел [Unit] для описания сокета, раздел [Socket] для определения расположения сокета и раздел [Install], чтобы обеспечить установку сокета в нужное время:

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Сохраните файл и закройте его после завершения.

      Теперь создайте и откройте служебный файл systemd для Gunicorn с привилегиями sudo в текстовом редакторе. Имя файла службы должно соответствовать имени файла сокета за исключением расширения:

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

      Начните с раздела [Unit], предназначенного для указания метаданных и зависимостей. Здесь мы разместим описание службы и предпишем системе инициализации запускать ее только после достижения сетевой цели. Поскольку наша служба использует сокет из файла сокета, нам потребуется директива Requires, чтобы задать это отношение:

      /etc/systemd/system/gunicorn.service

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

      Теперь откроем раздел [Service]. Здесь указываются пользователь и группа, от имени которых мы хотим запустить данный процесс. Мы сделаем владельцем процесса учетную запись обычного пользователя, поскольку этот пользователь является владельцем всех соответствующих файлов. Групповым владельцем мы сделаем группу www-data, чтобы Nginx мог легко взаимодействовать с Gunicorn.

      Затем мы составим карту рабочего каталога и зададим команду для запуска службы. В данном случае мы укажем полный путь к исполняемому файлу Gunicorn, установленному в нашей виртуальной среде. Мы привяжем процесс к сокету Unix, созданному в каталоге /run, чтобы процесс мог взаимодействовать с Nginx. Мы будем регистрировать все данные на стандартном выводе, чтобы процесс journald мог собирать журналы Gunicorn. Также здесь можно указать любые необязательные настройки Gunicorn. Например, в данном случае мы задали 3 рабочих процесса:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      

      Наконец, добавим раздел [Install]. Это покажет systemd, куда привязывать эту службу, если мы активируем ее запуск при загрузке. Нам нужно, чтобы эта служба запускалась во время работы обычной многопользовательской системы:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      
      [Install]
      WantedBy=multi-user.target
      

      Теперь служебный файл systemd готов. Сохраните и закройте его.

      Теперь мы можем запустить и активировать сокет Gunicorn. Файл сокета /run/gunicorn.sock будет создан сейчас, а также будет создаваться при загрузке. При подключении к этому сокету systemd автоматически запустит gunicorn.service для его обработки:

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

      Успешность операции можно подтвердить, проверив файл сокета.

      Проверка файла сокета Gunicorn

      Проверьте состояние процесса, чтобы узнать, удалось ли его запустить:

      • sudo systemctl status gunicorn.socket

      Вы должны получить следующий вывод:

      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

      Затем проверьте наличие файла gunicorn.sock в каталоге /run:

      Output

      /run/gunicorn.sock: socket

      Если команда systemctl status указывает на ошибку, а также если в каталоге отсутствует файл gunicorn.sock, это означает, что сокет Gunicorn не удалось создать корректно. Проверьте журналы сокета Gunicorn с помощью следующей команды:

      • sudo journalctl -u gunicorn.socket

      Еще раз проверьте файл /etc/systemd/system/gunicorn.socket и устраните любые обнаруженные проблемы, прежде чем продолжить.

      Тестирование активации сокета

      Если вы запустили только gunicorn.socket, служба gunicorn.service не будет активирована из-за отсутствия подключений к сокету. Для проверки можно ввести следующую команду:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead)

      Чтобы протестировать механизм активации сокета, мы можем установить подключение к сокету через curl с помощью следующей команды:

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

      Выводимые данные приложения должны отобразиться в терминале в формате HTML. Это показывает, что Gunicorn запущен и может обслуживать ваше приложение Django. Вы можете убедиться, что служба Gunicorn работает, с помощью следующей команды:

      • 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

      Если результаты выводов команд curl или systemctl status указывают на наличие проблемы, посмотрите подробные данные в журналах:

      • sudo journalctl -u gunicorn

      Проверьте файл /etc/systemd/system/gunicorn.service на наличие проблем. Если вы внесли изменения в файл /etc/systemd/system/gunicorn.service, выполните перезагрузку демона, чтобы заново считать определение службы, и перезапустите процесс Gunicorn с помощью следующей команды:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn

      Обязательно устраните вышеперечисленные проблемы, прежде чем продолжить.

      Настройка Nginx как прокси для Gunicorn

      Мы настроили Gunicorn, и теперь нам нужно настроить Nginx для передачи трафика в процесс.

      Для начала нужно создать и открыть новый серверный блок в каталоге Nginx sites-available:

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

      Откройте внутри него новый серверный блок. Вначале мы укажем, что этот блок должен прослушивать обычный порт 80, и что он должен отвечать на доменное имя или IP-адрес нашего сервера:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      }
      

      Затем мы укажем Nginx игнорировать любые проблемы при поиске favicon. Также мы укажем, где можно найти статичные ресурсы, собранные нами в каталоге ~/myprojectdir/static. Все эти строки имеют стандартный префикс URI «/static», так что мы можем создать блок location для соответствия этим запросам:

      /etc/nginx/sites-available/myproject

      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 / {} для соответствия всем другим запросам. В этот блок мы включим стандартный файл proxy_params, входящий в комплект установки Nginx, и тогда трафик будет передаваться напрямую на сокет Gunicorn:

      /etc/nginx/sites-available/myproject

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

      Сохраните файл и закройте его после завершения. Теперь мы можем активировать файл, привязав его к каталогу sites-enabled:

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

      Протестируйте конфигурацию Nginx на ошибки синтаксиса:

      Если ошибок не будет найдено, перезапустите Nginx с помощью следующей команды:

      • sudo systemctl restart nginx

      Нам нужна возможность открыть брандмауэр для обычного трафика через порт 80. Поскольку нам больше не потребуется доступ к серверу разработки, мы можем удалить правило и открыть порт 8000:

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

      Теперь у вас должна быть возможность перейти к домену или IP-адресу вашего сервера для просмотра вашего приложения.

      Примечание. После настройки Nginx необходимо защитить трафик на сервер с помощью SSL/TLS. Это важно, поскольку в противном случае вся информация, включая пароли, будет отправляться через сеть в простом текстовом формате.

      Если у вас имеется доменное имя, проще всего будет использовать Let’s Encrypt для получения сертификата SSL для защиты вашего трафика. Следуйте указаниям этого руководства, чтобы настроить Let’s Encrypt с Nginx в Ubuntu 20.04. Следуйте процедуре, используя серверный блок Nginx, созданный нами в этом обучающем модуле.

      Диагностика и устранение неисправностей Nginx и Gunicorn

      Если на последнем шаге не будет показано ваше приложение, вам нужно будет провести диагностику и устранение неисправностей установки.

      Nginx показывает страницу по умолчанию, а не приложение Django

      Если Nginx показывает страницу по умолчанию, а не выводит ваше приложение через прокси, это обычно означает, что вам нужно изменить параметр server_name в файле /etc/nginx/sites-available/myproject, чтобы он указывал на IP-адрес или доменное имя вашего сервера.

      Nginx использует server_name, чтобы определять, какой серверный блок использовать для ответа на запросы. Если вы увидите страницу Nginx по умолчанию, это будет означать, что Nginx не может найти явное соответствие запросу в серверном блоке и выводит блок по умолчанию, заданный в /etc/nginx/sites-available/default.

      Параметр server_name в серверном блоке вашего проекта должен быть более конкретным, чем содержащийся в серверном блоке, выбираемом по умолчанию.

      Nginx выводит ошибку 502 Bad Gateway вместо приложения Django

      Ошибка 502 означает, что Nginx не может выступать в качестве прокси для запроса. Ошибка 502 может сигнализировать о разнообразных проблемах конфигурации, поэтому для диагностики и устранения неисправности потребуется больше информации.

      В первую очередь эту информацию следует искать в журналах ошибок Nginx. Обычно это указывает, какие условия вызвали проблемы во время прокси-обработки. Изучите журналы ошибок Nginx с помощью следующей команды:

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

      Теперь выполните в браузере еще один запрос, чтобы получить свежее сообщение об ошибке (попробуйте обновить страницу). В журнал будет записано свежее сообщение об ошибке. Если вы проанализируете его, это поможет идентифицировать проблему.

      Вы можете получить следующее сообщение:

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

      Это означает, что Nginx не удалось найти файл gunicorn.sock в указанном расположении. Вы должны сравнить расположение proxy_pass, определенное в файле etc/nginx/sites-available/myproject, с фактическим расположением файла gunicorn.sock, сгенерированным блоком systemd gunicorn.socket.

      Если вы не можете найти файл gunicorn.sock в каталоге /run, это означает, что файл сокета systemd не смог его создать. Вернитесь к разделу проверки файла сокета Gunicorn и выполните процедуру диагностики и устранения неисправностей Gunicorn.

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

      Это означает, что Nginx не удалось подключиться к сокету Gunicorn из-за проблем с правами доступа. Это может произойти, если выполнять процедуру с использованием пользователя root вместо пользователя с привилегиями sudo. Хотя systemd может создать файл сокета Gunicorn, Nginx не может получить к нему доступ.

      Это может произойти из-за ограничения прав доступа в любой точке между корневым каталогом (/) и файлом gunicorn.sock. Чтобы посмотреть права доступа и владения файла сокета и всех его родительских каталогов, нужно ввести абсолютный путь файла сокета как параметр команды namei:

      • namei -l /run/gunicorn.sock

      Output

      f: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock

      Команда выведет права доступа всех компонентов каталога. Изучив права доступа (первый столбец), владельца (второй столбец) и группового владельца (третий столбец), мы можем определить, какой тип доступа разрешен для файла сокета.

      В приведенном выше примере для файла сокета и каждого из каталогов пути к файлу сокета установлены всеобщие права доступа на чтение и исполнение (запись в столбце разрешений каталогов заканчивается на r-x, а не на ---). Процесс Nginx должен успешно получить доступ к сокету.

      Если для любого из каталогов, ведущих к сокету, отсутствуют глобальные разрешения на чтение и исполнение, Nginx не сможет получить доступ к сокету без включения таких разрешений или без передачи группового владения группе, в которую входит Nginx.

      Django выводит ошибку: «could not connect to server: Connection refused»

      При попытке доступа к частям приложения через браузер Django может вывести сообщение следующего вида:

      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?
      

      Это означает, что Django не может подключиться к базе данных Postgres. Убедиться в нормальной работе экземпляра Postgres с помощью следующей команды:

      • sudo systemctl status postgresql

      Если он работает некорректно, вы можете запустить его и включить автоматический запуск при загрузке (если эта настройка еще не задана) с помощью следующей команды:

      • sudo systemctl start postgresql
      • sudo systemctl enable postgresql

      Если проблемы не исчезнут, проверьте правильность настроек базы данных, заданных в файле ~/myprojectdir/myproject/settings.py.

      Дополнительная диагностика и устранение неисправностей

      В случае обнаружения дополнительных проблем журналы могут помочь в поиске первопричин. Проверяйте их по очереди и ищите сообщения, указывающие на проблемные места.

      Следующие журналы могут быть полезными:

      • Проверьте журналы процессов Nginx с помощью команды: sudo journalctl -u nginx
      • Проверьте журналы доступа Nginx с помощью команды: sudo less /var/log/nginx/access.log
      • Проверьте журналы ошибок Nginx с помощью команды: sudo less /var/log/nginx/error.log
      • Проверьте журналы приложения Gunicorn с помощью команды: sudo journalctl -u gunicorn
      • Проверьте журналы сокета Gunicorn с помощью команды: sudo journalctl -u gunicorn.socket

      При обновлении конфигурации или приложения вам может понадобиться перезапустить процессы для адаптации к изменениям.

      Если вы обновите свое приложение Django, вы можете перезапустить процесс Gunicorn для адаптации к изменениям с помощью следующей команды:

      • sudo systemctl restart gunicorn

      Если вы измените файл сокета или служебные файлы Gunicorn, перезагрузите демона и перезапустите процесс с помощью следующей команды:

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

      Если вы измените конфигурацию серверного блока Nginx, протестируйте конфигурацию и Nginx с помощью следующей команды:

      • sudo nginx -t && sudo systemctl restart nginx

      Эти команды помогают адаптироваться к изменениям в случае изменения конфигурации.

      Заключение

      В этом руководстве мы создали и настроили проект Django в его собственной виртуальной среде. Мы настроили Gunicorn для трансляции запросов клиентов, чтобы Django мог их обрабатывать. Затем мы настроили Nginx в качестве обратного прокси-сервера для обработки клиентских соединений и вывода проектов, соответствующих запросам клиентов.

      Django упрощает создание проектов и приложений, предоставляя множество стандартных элементов и позволяя сосредоточиться на уникальных. Используя описанную в этой статье процедуру, вы сможете легко обслуживать создаваемые приложения на одном сервере.



      Source link