NGINX-Konferenz 2018: Konfigurieren der NGINX-Einheit für Produktionsanwendungen - Bereitstellen eines Django-Projekts

NGINX Unit ist ein vollständig dynamischer Anwendungsserver, der mehrere Sprachen sowie mehrere Versionen jeder Sprache unterstützen kann. Es ist in dem Sinne dynamisch, dass Sie die RESTful JSON API verwenden, um Änderungen an der Konfiguration im Speicher vorzunehmen, ohne dass es zu Dienstunterbrechungen oder Neuladen der Konfiguration kommt.

In meiner Präsentation auf der NGINX Conf 2018 im Oktober habe ich gezeigt, wie man eine neue Anwendung in einer bestehenden Produktionsumgebung konfiguriert. Konkret habe ich mit WordPress, das auf PHP läuft, eine Python-Anwendung bereitgestellt, die das Django-Framework verwendet. Ich habe auch gezeigt, wie Sie eine Konfiguration sowohl aus einer Datei als auch wie mit einem Argument angegeben in einen API-Aufruf laden können.

Dieses Blog enthält alle Befehle und Konfigurationscodes, die ich in der Demo verwendet habe, um Ihnen die Anpassung an Ihre eigene Bereitstellung zu erleichtern.

Voraussetzungen

Für die Demo bei NGINX Conf hatte ich die folgende Software installiert:

• Ubuntu 16.04
• NGINX Plus, aber Sie können NGINX Open Source verwenden, sofern nicht anders angegeben
• NGINX-Einheit mit allen installierten Sprachmodulen
• Python 3
• Django (nicht konfiguriert – darum geht es in der Demo und in diesem Blog)
• Root- Privilegien oder gleichwertiger Zugriff über sudo (das wir bei Bedarf verwenden)

Ich hatte auch PHP und WordPress als vorhandene Anwendung installiert.

Erstellen des Django-Projekts

1. Wechseln Sie in das Verzeichnis, in dem wir unser Django-Projekt erstellen:

   $ cd /var/www/

2. Verwenden Sie den Befehl django-admin startproject , um das neue Projekt zu initialisieren. Wir nennen es djapp .

   $ sudo django-admin startproject djapp

3. Wechsel in das Projektverzeichnis:

   $ cd djapp

4. Verwenden Sie das Skript manage.py , um die Datenbank für das Projekt zu migrieren, was für ein neu erstelltes Projekt erforderlich ist. Django verwendet standardmäßig SQLite und ich akzeptiere die Standardeinstellung in der Demo, aber Sie können jede beliebige Datenbank verwenden, die den Anforderungen Ihres Projekts entspricht.

   Das Skript manage.py wird durch den Befehl django-admin installiert, den wir in Schritt 2 ausgeführt haben. Es führt dieselben Befehle aus und akzeptiert dieselben Argumente wie django-admin , leitet aber automatisch einige projektspezifische Einstellungen ab und verwendet diese, was hilfreich ist. Einzelheiten finden Sie in der Django-Dokumentation .

   $ sudo python3 manage.py migrieren

5. Obwohl es für ein Beispielprojekt wie dieses nicht unbedingt erforderlich ist, empfehlen wir Ihnen, eine Django- Superuser- Identität zu erstellen:

   $ sudo python3 manage.py Superuser erstellen

6. Wechseln Sie in das Unterverzeichnis, das die Datei settings.py enthält, die mit dem Befehl django-admin startproject in Schritt 2 erstellt wurde.

   $ cd /var/www/djapp/djapp

7. Öffnen Sie settings.py mit Ihrem bevorzugten Texteditor. Hier verwenden wir Nano :

   $ sudo nanoeinstellungen.py

   Suchen Sie die Zeile ALLOWED_HOSTS und fügen Sie den Domänennamen, Hostnamen oder die IP-Adresse für die Anwendung hinzu:

   ALLOWED_HOSTS = [' Domänenname ']

   Fügen Sie am Ende der Datei außerdem die folgende Zeile hinzu, um das Verzeichnis zu benennen, in dem alle von der Anwendung bereitgestellten statischen Inhalte gespeichert werden (siehe Schritt 9).

   STATIC_ROOT = "/var/www/djapp/djapp/static"

8. Wechseln Sie zurück zum Hauptprojektverzeichnis (wo sich manage.py befindet).

   $ -CD ..

9. Führen Sie den Befehl manage.py collectstatic aus, um alle statischen Dateien im Django-Projekt zu sammeln und sie am in Schritt 7 definierten Speicherort STATIC_ROOT abzulegen.

   $ sudo python3 manage.py collectstatic

Konfigurieren von NGINX

Standardmäßig stellt Django selbst den statischen Inhalt für ein Projekt bereit, aber NGINX Open Source und NGINX Plus bieten eine bessere Leistung. Hier konfigurieren wir NGINX Plus, aber Sie können NGINX Open Source verwenden, mit Ausnahme einer unten aufgeführten Funktion.

1. Wechseln Sie zu /etc/nginx/conf.d , dem herkömmlichen Speicherort für funktionsspezifische (oder in unserem Fall anwendungsspezifische) HTTP-Konfigurationsdateien:

   $ cd /etc/nginx/conf.d

2. Erstellen Sie eine Datei namens django.conf (wir verwenden erneut nano ):

   $ sudo nano django.conf

   Fügen Sie die folgende Konfiguration ein, die das Caching aktiviert.

   Die Konfiguration umfasst außerdem zwei Funktionen, die exklusiv bei NGINX Plus verfügbar sind. Entfernen Sie die Kommentarzeichen aus den entsprechenden Anweisungen, wenn Sie NGINX Plus verwenden und die Funktionen nutzen möchten:

   • Erweiterte Metriksammlung, aktiviert für diesen virtuellen Server durch die Direktive „status_zone“ . Ich gehe davon aus, dass die NGINX Plus-API an anderer Stelle in der Konfiguration aktiviert ist.
   • Aktive Integritätsprüfungen , aktiviert durch die Direktive „health_check“ .

   Zu beachten ist, dass ich in der Demo bei NGINX Conf die IP-Adresse meines lokalen Computers als zweites Argument für die Direktive proxy_set_header angegeben habe. In einer Produktionsumgebung ist es sinnvoller, die Variable $host wie unten gezeigt zu verwenden.

   # Upstream-Gruppe für das Backend (NGINX Unit, auf der die Python-Anwendung ausgeführt wird)
   upstream django_unit {
   zone django_unit 64k;
   server 127.0.0.1:8000;
   }
   
   server {
   listen 8080;
   # Entfernen Sie das Kommentarzeichen, um Metriken zu erfassen, wenn Sie NGINX Plus und die NGINX Plus API verwenden
   #status_zone django;
   
   # Caching aktivieren
   proxy_cache django_cache;
   proxy_cache_valid 200 60m;
   
   # Stammverzeichnis für statische Dateien
   root /var/www/djapp/djapp;
   
   # Proxy zum NGINX Unit-Backend
   location / {
   proxy_pass http://django_unit;
   
   # Das zweite Argument muss mit Ihrem Produktionshostnamen und dem Wert von 
   # ALLOWED_HOSTS in settings.py übereinstimmen
   proxy_set_header Host $host; 
   
   # Entfernen Sie das Kommentarzeichen, um aktive Integritätsprüfungen zu aktivieren, wenn Sie NGINX Plus verwenden
   #health_check;
   }
   
   # Speicherort für die von Django gesammelten und von 
   # NGINX Plus bereitgestellten statischen Dateien; kann leer sein (wie hier), da es den Wert der 
   # 'root'-Direktive von seinem übergeordneten Block erbt
   location /static {
   }
   }

3. Überprüfen Sie die Konfiguration auf syntaktische Gültigkeit:

   $ sudo nginx –t

4. Nachdem Sie alle Fehler behoben haben, laden Sie die Konfiguration neu:

   $ sudo nginx -s neu laden

Konfigurieren der NGINX-Einheit

Zum Abschluss müssen wir die NGINX-Unit so konfigurieren, dass die Anfragen an die Anwendung bearbeitet werden können.

1. Führen Sie diesen Curl -Befehl aus, um die aktuelle NGINX-Unit-Konfiguration anzuzeigen, die für WordPress gilt, das auf PHP läuft. Ich zeige die Ausgabe hier nicht, aber die WordPress-Konfiguration wird in Schritt 6 unten zusammen mit der Konfiguration der Python-Anwendung angezeigt, die wir gleich hinzufügen.

   Beachten Sie, dass ich sudo für den Curl -Befehl verwende, was für die meisten Curl -Befehle möglicherweise nicht erforderlich ist. Hier ist es notwendig, da wir für den Zugriff auf den UNIX-Socket die Lese-/Schreibberechtigung benötigen, die Root darauf hat.

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

2. Wechseln Sie in das Verzeichnis für die NGINX-Unit-Konfigurationsdateien.

   Bedenken Sie, dass diese Dateien optional sind und lediglich eine praktische Möglichkeit darstellen, Konfigurationssammlungen zu laden, ohne alle Daten als Argument für einen Aufruf der NGINX Unit-API einzugeben. Da der Inhalt der Dateien (wie alle Konfigurationsdaten) über die API hochgeladen wird, kennt NGINX Unit keine Dateispeicherorte und kann Dateien beim Start nicht automatisch lesen (im Gegensatz zu NGINX Open Source und NGINX Plus). Stattdessen speichert die NGINX-Unit ihren Laufzeitstatus in einem separaten Verzeichnis.

   $ cd /etc/Einheit

3. Erstellen Sie eine Datei namens django.config (wir verwenden erneut nano ):

   $ sudo nano django.config

   Fügen Sie das folgende JSON hinzu, das unsere Python-Anwendung darstellt.

   {
   "Typ": "Python",
   "Prozesse": 5, „module“: „djapp.wsgi“, „path“: „/var/www/djapp“ }

4. Führen Sie diesen Curl -Befehl aus, um das in django.config enthaltene JSON als neues Anwendungsobjekt mit dem Namen djapp zu laden, das von der NGINX-Einheit verwaltet werden soll:

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

   In diesem Befehl:

   • Die HTTP- PUT -Methode erstellt ein neues NGINX-Unit-Konfigurationsobjekt an dem durch das letzte Argument (die URL) benannten Speicherort. Siehe den letzten Punkt unten.
   • Das Argument --data-binary weist curl an, den Inhalt von django.config genau wie angegeben zu laden, Zeilenumbrüche und Wagenrückläufe beizubehalten und keinerlei Verarbeitung durchzuführen.
   • Das Argument --unix-socket definiert, wo die NGINX Unit API lauscht. (Wir verwenden den Befehl sudo , weil wir den Standardbesitzer des Sockets, root , verwenden.)
   • Das letzte Argument lokalisiert und benennt das neue Anwendungsobjekt, das mit den JSON-formatierten Konfigurationsdaten in django.config gefüllt werden soll: config ist das NGINX-Unit-Konfigurationsobjekt der obersten Ebene, applications das übergeordnete Objekt für Anwendungsobjekte und djapp der Name des neuen Anwendungsobjekts.

5. Definieren Sie das Listener-Objekt für die Anwendung. Anstatt wie in Schritt 4 eine Datei mit Konfigurationsdaten zu laden, definieren wir die Daten direkt in der Curl -Befehlszeile und geben an, dass die djapp -Anwendung auf Port 8000 lauscht.

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

6. Wiederholen Sie den Curl -Befehl aus Schritt 1, um die NGINX-Unit-Konfiguration anzuzeigen, die jetzt unsere Python-Anwendung djapp enthält, die orange hervorgehoben ist:

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { "listeners": { "127.0.0.1:8090": { "Anwendung": "script_index_php" }, "127.0.0.1:8091": { "Anwendung": "direct_php" }, "*:8000": { "Anwendung": "djapp" } }, "Anwendungen": { "script_index_php": { "Typ": "php", "Prozesse": { "max": 20, "Ersatz": 5 }, "Benutzer": "www-data", "Gruppe": "www-data", "Stamm": "/var/www/wordpress", "Skript": "index.php" }, "direct_php": { "Typ": "php", "Prozesse": { "max": 5, "Ersatz": 0 }, "Benutzer": "www-data", "Gruppe": "www-data", "Stamm": "/var/www/wordpress", "Index": "index.php" }, "djapp": { "Typ": "Python", "Prozesse": 5, „module“: „djapp.wsgi“, „path“: „/var/www/djapp“ } } }

Zusammenfassung

In diesem Beitrag haben wir mit der NGINX Unit begonnen, die PHP-Anwendungen für WordPress in der Produktion ausführt, und eine Python-Anwendung hinzugefügt. In der Demo verwende ich das NGINX Plus-Dashboard, um zu zeigen, dass es bei der Hinzufügung einer neuen Anwendung zu keinen Störungen der vorhandenen Anwendungen kommt. Sie können zu diesem Zweck jedoch jedes beliebige Systemüberwachungstool verwenden, beispielsweise den Befehl ps . Die dynamische Natur der NGINX-Unit-Konfiguration spart Ressourcen für Ihre laufenden Anwendungen und gewährleistet null Ausfallzeiten bei neuen Bereitstellungen sowie einen reibungslosen Übergang zwischen Anwendungsversionen.

Weitere Informationen finden Sie unter unit.nginx.org .