Conférence NGINX 2018 : Configuration de l'unité NGINX pour les applications de production - Service d'un projet Django

NGINX Unit est un serveur d'applications entièrement dynamique qui peut servir plusieurs langues ainsi que plusieurs versions de chaque langue. Il est dynamique dans le sens où vous utilisez l'API JSON RESTful pour apporter des modifications à sa configuration en mémoire, sans interruption de service ni rechargement de configuration.

Lors de ma présentation à NGINX Conf 2018 en octobre, j'ai montré comment configurer une nouvelle application dans un environnement de production existant. Plus précisément, avec WordPress fonctionnant sur PHP, j'ai déployé une application Python qui utilise le framework Django. J'ai également montré comment vous pouvez charger la configuration à la fois à partir d'un fichier et comme spécifié avec un argument à un appel d'API.

Ce blog inclut toutes les commandes et le code de configuration que j'ai utilisés dans la démo, pour vous permettre de vous adapter plus facilement à votre propre déploiement.

Prérequis

Pour la démonstration à la NGINX Conf, j'avais installé les logiciels suivants :

• Ubuntu 16.04
• NGINX Plus, mais vous pouvez utiliser NGINX Open Source sauf indication contraire
• Unité NGINX avec tous les modules de langue installés
• Python 3
• Django (non configuré – c'est le sujet de la démo et de ce blog)
• privilège root , ou accès équivalent via sudo (que nous utilisons si nécessaire)

J'avais également PHP et WordPress installés comme application existante.

Création du projet Django

1. Accédez au répertoire dans lequel nous créons notre projet Django :

   $ cd /var/www/

2. Utilisez la commande django-admin startproject pour initialiser le nouveau projet. Nous l'appelons djapp .

   $ sudo django-admin startproject djapp

3. Accédez au répertoire du projet :

   $ cd djapp

4. Utilisez le script manage.py pour migrer la base de données du projet, ce qui est nécessaire pour un projet nouvellement créé. Django utilise SQLite par défaut, et j'accepte la valeur par défaut dans la démo, mais vous pouvez utiliser n'importe quelle base de données qui répond aux besoins de votre projet.

   Le script manage.py est installé par la commande django-admin que nous avons exécutée à l'étape 2 ; il exécute les mêmes commandes et accepte les mêmes arguments que django-admin , mais dérive et utilise automatiquement certains paramètres spécifiques au projet, ce qui est utile. Pour plus de détails, consultez la documentation Django .

   $ sudo python3 manage.py migrer

5. Bien que cela ne soit pas strictement nécessaire pour un exemple de projet comme celui-ci, nous vous recommandons de créer une identité de superutilisateur Django :

   $ sudo python3 manage.py createsuperuser

6. Accédez au sous-répertoire contenant le fichier settings.py , créé par la commande django-admin startproject à l’étape 2.

   $ cd /var/www/djapp/djapp

7. À l’aide de votre éditeur de texte préféré, ouvrez settings.py . Ici, nous utilisons nano :

   $ sudo nano settings.py

   Recherchez la ligne ALLOWED_HOSTS et ajoutez le nom de domaine, le nom d'hôte ou l'adresse IP de l'application :

   ALLOWED_HOSTS = [' nom-de-domaine ']

   Ajoutez également la ligne suivante à la fin du fichier, pour nommer le répertoire qui stocke tout le contenu statique servi par l’application (voir l’étape 9).

   STATIC_ROOT = '/var/www/djapp/djapp/static'

8. Revenez au répertoire principal du projet (où réside manage.py ).

   $ cd ..

9. Exécutez la commande manage.py collectstatic pour collecter tous les fichiers statiques situés dans le projet Django et les placer dans l’emplacement STATIC_ROOT défini à l’étape 7.

   $ sudo python3 manage.py collectstatic

Configuration de NGINX

Par défaut, Django lui-même diffuse le contenu statique d'un projet, mais NGINX Open Source et NGINX Plus offrent des performances supérieures. Ici, nous configurons NGINX Plus, mais vous pouvez utiliser NGINX Open Source à l’exception d’une fonctionnalité mentionnée ci-dessous.

1. Accédez au répertoire /etc/nginx/conf.d , l'emplacement conventionnel des fichiers de configuration HTTP spécifiques à la fonction (ou dans notre cas, spécifiques à l'application) :

   $ cd /etc/nginx/conf.d

2. Créez un fichier appelé django.conf (encore une fois, nous utilisons nano ) :

   $ sudo nano django.conf

   Insérez la configuration suivante, qui active la mise en cache.

   La configuration comprend également deux fonctionnalités exclusives à NGINX Plus. Décommentez les directives concernées si vous utilisez NGINX Plus et souhaitez profiter des fonctionnalités :

   • Collecte de métriques étendue, activée pour ce serveur virtuel par la directive status_zone . Je suppose que l' API NGINX Plus est activée ailleurs dans la configuration.
   • Contrôles de santé actifs , activés par la directive health_check .

   Une chose à noter est que dans la démonstration de NGINX Conf, j'ai spécifié l'adresse IP de ma machine locale comme deuxième argument de la directive proxy_set_header . Dans un environnement de production, il est plus judicieux d'utiliser la variable $host comme indiqué ci-dessous.

   # Groupe en amont pour le backend (unité NGINX exécutant l'application Python)
   upstream django_unit {
   zone django_unit 64k;
   server 127.0.0.1:8000;
   }
   
   server {
   listen 8080;
   # Supprimer le commentaire pour collecter des métriques si vous utilisez NGINX Plus et l'API NGINX Plus
   #status_zone django;
   
   # activer la mise en cache
   proxy_cache django_cache;
   proxy_cache_valid 200 60m;
   
   # répertoire racine pour les fichiers statiques
   root /var/www/djapp/djapp;
   
   # proxy vers le backend de l'unité NGINX
   location / {
   proxy_pass http://django_unit;
   
   # Le deuxième argument doit correspondre à votre nom d'hôte de production et à la valeur de 
   # ALLOWED_HOSTS dans settings.py
   proxy_set_header Host $host; 
   
   # Supprimer le commentaire pour activer les contrôles de santé actifs si vous utilisez NGINX Plus
   #health_check;
   }
   
   # Emplacement des fichiers statiques collectés à partir de Django et servis par 
   # NGINX Plus; peut être vide (comme ici), car il hérite de la valeur de la 
   # directive 'root' de son bloc parent
   location /static {
   }
   }

3. Vérifiez la validité syntaxique de la configuration :

   $ sudo nginx –t

4. Après avoir corrigé les erreurs, rechargez la configuration :

   $ sudo nginx -s recharger

Configuration de l'unité NGINX

Pour terminer, nous devons configurer l’unité NGINX pour répondre aux requêtes de l’application.

1. Exécutez cette commande curl pour afficher la configuration actuelle de l'unité NGINX, destinée à WordPress exécuté sur PHP. Je ne montre pas la sortie ici, mais la configuration WordPress apparaît à l'étape 6 ci-dessous, ainsi que la configuration de l'application Python, que nous sommes sur le point d'ajouter.

   Notez que j'utilise sudo pour la commande curl , ce que vous n'aurez peut-être pas besoin de faire pour la plupart des commandes curl . Ici, c'est nécessaire car pour accéder au socket UNIX, nous avons besoin de l'autorisation de lecture-écriture dont root dispose.

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/

2. Accédez au répertoire des fichiers de configuration de l’unité NGINX.

   Gardez à l'esprit que ces fichiers sont facultatifs et constituent simplement un moyen pratique de charger des collections de configuration sans saisir toutes les données comme argument d'un appel à l'API NGINX Unit. Étant donné que le contenu des fichiers est téléchargé via l'API (comme toutes les données de configuration), NGINX Unit ne connaît pas l'emplacement des fichiers et ne peut pas lire automatiquement les fichiers au démarrage (contrairement à NGINX Open Source et NGINX Plus). Au lieu de cela, NGINX Unit enregistre son état d’exécution dans un répertoire séparé.

   $ cd /etc/unité

3. Créez un fichier appelé django.config (encore une fois, nous utilisons nano ) :

   $ sudo nano django.config

   Ajoutez le JSON suivant, qui représente notre application Python.

   {
   "type": "python",
   "processus": 5, "module": "djapp.wsgi", "chemin": "/var/www/djapp" }

4. Exécutez cette commande curl pour charger le JSON contenu dans django.config en tant que nouvel objet d'application à gérer par NGINX Unit, appelé djapp :

   $ sudo curl -X PUT --data-binary @/etc/unit/django.config --unix-socket /run/control.unit.sock http://localhost/config/applications/djapp

   Dans cette commande :

   • La méthode HTTP PUT crée un nouvel objet de configuration d'unité NGINX à l'emplacement nommé par l'argument final (l'URL). Voir le dernier point ci-dessous.
   • L'argument --data-binary indique à curl de charger le contenu de django.config exactement comme fourni, en préservant les nouvelles lignes et les retours chariot, et en n'effectuant aucun traitement.
   • L'argument --unix-socket définit où l'API NGINX Unit écoute. (Nous utilisons la commande sudo car nous utilisons le propriétaire par défaut du socket, root .)
   • L'argument final localise et nomme le nouvel objet d'application à remplir avec les données de configuration au format JSON dans django.config : config est l'objet de configuration de l'unité NGINX de niveau supérieur, applications le parent des objets d'application et djapp le nom du nouvel objet d'application.

5. Définissez l’objet écouteur pour l’application. Plutôt que de charger un fichier de données de configuration comme à l’étape 4, nous définissons les données directement sur la ligne de commande curl , en spécifiant que l’application djapp écoute sur le port 8000.

   $ sudo curl -X PUT --data-binary '{"application":"djapp"}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'

6. Répétez la commande curl de l'étape 1 pour afficher la configuration de l'unité NGINX, qui inclut désormais notre application Python, djapp , surlignée en orange :

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { "écouteurs": { "127.0.0.1:8090": { "application": "script_index_php" }, "127.0.0.1:8091": { "application": "direct_php" }, "*:8000": { "application": "djapp" } }, "applications": { "script_index_php": { "type": "php", "processus": { "max": 20, « de rechange » : 5 }, "utilisateur": "www-data", "groupe": "www-data", "racine": "/var/www/wordpress", "script": "index.php" }, "direct_php": { "type": "php", "processus": { "max": 5, « de rechange » : 0 }, "utilisateur": "www-data", "groupe": "www-data", "racine": "/var/www/wordpress", "index": "index.php" }, "djapp": { "type": "python", "processus": 5, "module": "djapp.wsgi", "chemin": "/var/www/djapp" } } }

Résumé

Dans cet article, nous avons commencé avec NGINX Unit exécutant des applications PHP pour WordPress en production et avons ajouté une application Python. Dans la démonstration, j’utilise le tableau de bord NGINX Plus pour montrer qu’il n’y a aucune interruption des applications existantes lorsqu’une nouvelle application est ajoutée, mais vous pouvez utiliser n’importe quel outil de surveillance du système, tel que la commande ps , à cette fin. La nature dynamique de la configuration de l'unité NGINX économise des ressources pour vos applications en cours d'exécution et garantit un temps d'arrêt nul sur les nouveaux déploiements et une transition en douceur entre les versions d'application.

Pour en savoir plus, visitez unit.nginx.org .