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.
Für die Demo bei NGINX Conf hatte ich die folgende Software installiert:
Root-
Privilegien oder gleichwertiger Zugriff über sudo
(das wir bei Bedarf verwenden)Ich hatte auch PHP und WordPress als vorhandene Anwendung installiert.
Wechseln Sie in das Verzeichnis, in dem wir unser Django-Projekt erstellen:
$ cd /var/www/
Verwenden Sie den Befehl django-admin
startproject
, um das neue Projekt zu initialisieren. Wir nennen es djapp .
$ sudo django-admin startproject djapp
Wechsel in das Projektverzeichnis:
$ cd djapp
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
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
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
Ö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"
Wechseln Sie zurück zum Hauptprojektverzeichnis (wo sich manage.py befindet).
$ -CD ..
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
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.
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
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:
„status_zone“
. Ich gehe davon aus, dass die NGINX Plus-API an anderer Stelle in der Konfiguration aktiviert ist.„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 {
}
}
Überprüfen Sie die Konfiguration auf syntaktische Gültigkeit:
$ sudo nginx –t
Nachdem Sie alle Fehler behoben haben, laden Sie die Konfiguration neu:
$ sudo nginx -s neu laden
Zum Abschluss müssen wir die NGINX-Unit so konfigurieren, dass die Anfragen an die Anwendung bearbeitet werden können.
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/
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
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“ }
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:
PUT
-Methode erstellt ein neues NGINX-Unit-Konfigurationsobjekt an dem durch das letzte Argument (die URL) benannten Speicherort. Siehe den letzten Punkt unten.--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.--unix-socket
definiert, wo die NGINX Unit API lauscht. (Wir verwenden den Befehl sudo
, weil wir den Standardbesitzer des Sockets, root
, verwenden.)config
ist das NGINX-Unit-Konfigurationsobjekt der obersten Ebene, applications
das übergeordnete Objekt für Anwendungsobjekte und djapp
der Name des neuen Anwendungsobjekts.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'
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“ } } }
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 .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."