Ankündigung von NGINX Plus R13

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 13 (R13) jetzt als kostenloses Upgrade für alle NGINX Plus-Abonnenten verfügbar ist. NGINX Plus ist ein kombinierter Webserver, Lastenausgleich und Inhaltscache, der auf NGINX Open Source basiert. NGINX Plus R13 enthält neue Funktionen mit Schwerpunkt auf dynamischen Bereitstellungen, erweiterten Debugging-Funktionen sowie verbesserter Sicherheit und Leistung.

NGINX Plus R13 führt Unterstützung für:

• Eine neue NGINX Plus-API – Führen Sie dynamische Konfigurationen durch und erhalten Sie erweiterte Statusmetriken an einem einzigen konsolidierten Endpunkt. Die API bietet außerdem Unterstützung für Schlüssel-Wert-Speicher.
• Anforderungsspiegelung – Senden Sie eine Kopie des gesamten eingehenden Datenverkehrs an einen dedizierten Server, wo Sie den Anwendungsdatenverkehr überwachen, prüfen und protokollieren können, ohne die Leistung der Produktionsserver zu beeinträchtigen.
• Verbesserungen am NGINX JavaScript-Modul – Erweitern Sie NGINX Plus mit programmgesteuerter Konfiguration mithilfe des NGINX JavaScript-Moduls, unserer benutzerdefinierten Implementierung von JavaScript. [Das Modul hieß früher nginScript.] Die neue interaktive njs -Shell bietet eine Konsole, die alle integrierten Objekte für JavaScript anzeigt. Diese Objekte können weiter untersucht werden, um die verfügbaren Methoden und Grundelemente für jedes Objekt offenzulegen.
• Build-Tool für dynamische Module – Verwenden Sie unser neues Build-Tool, um installierbare Pakete für die vielen Drittanbietermodule zu erstellen, die für NGINX und NGINX Plus verfügbar sind.

Zu den weiteren Erweiterungen zählen Verbesserungen der Sticky-Learning-Methode zur Sitzungspersistenz, Unterstützung für HTTP-Trailer und ein neues dynamisches Drittanbietermodul für HTTP-Ersetzungen.

Verhaltensänderungen

• Veraltete Module – Die vorherigen APIs für erweiterten Status und dynamische Konfiguration von Upstream-Gruppen (die Module „Status“ und „Upstream Conf“ ) sind veraltet und werden durch die vereinheitlichte NGINX Plus-API ersetzt. Die veralteten APIs werden neben der neuen NGINX Plus-API noch mindestens 6 Monate lang mit NGINX Plus ausgeliefert. Die veralteten APIs werden in einer zukünftigen Version von NGINX Plus entfernt.
• Entfernte Direktive – Die Direktive sticky_cookie_insert wurde in NGINX Plus R13 entfernt, da sie in NGINX Plus R2 veraltet war.
• Dynamische Module von Drittanbietern – Aus dem NGINX-Repository installierte dynamische Module werden automatisch auf R13 aktualisiert. Alle Module von Drittanbietern – also Module, die nicht im offiziellen NGINX-Repo enthalten sind – müssen mit NGINX Open Source 1.13.4 neu kompiliert werden, um weiterhin mit NGINX Plus R13 zu funktionieren. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch .

• Direktive im ModSecurity-Modul wird nicht mehr unterstützt – Die Direktive SecRequestBodyInMemoryLimit für ModSecurity wird nicht mehr unterstützt. Kunden können diese Anweisung bedenkenlos entfernen, da das ModSecurity-Modul die in der NGINX-Konfiguration definierte Verarbeitung des Anforderungstexts befolgt.

  [ Anmerkung des Herausgebers – Der Verkauf des NGINX ModSecurity WAF- Moduls für NGINX Plus endete offiziell am 1. April 2022 , und mit Wirkung zum 31. März 2024 wird es nicht mehr unterstützt . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

• Unterstützung für veraltete Betriebssystemversionen wurde entfernt – NGINX Plus wird auf CentOS 5.10+, Red Hat Enterprise Linux 5.10+, Oracle Linux 5.10+, Ubuntu 12.04 LTS oder Ubuntu 16.10 nicht mehr unterstützt.

NGINX R13 Funktionen im Detail

NGINX Plus API

NGINX Plus R13 enthält eine neue REST- API, die unter einem einzigen Endpunkt vereint ist. Frühere Versionen von NGINX Plus enthielten separate Upstream Conf- und Extended Status- APIs. Die neue API kombiniert die Funktionalität beider und unterstützt auch das neue Key-Value-Store-Modul in einer Vielzahl von Anwendungsfällen für die dynamische Konfiguration (besprochen im Abschnitt „Key-Value-Store“ weiter unten).

Um die NGINX Plus-API zu aktivieren, fügen Sie die neue API- Direktive in einen Standortblock ein:

server { listen 80;

location /api {
api write=on;
# Anweisungen, die nur autorisierten Benutzern Zugriff gewähren
}
}

Standardmäßig bietet die NGINX Plus-API schreibgeschützten Zugriff auf Daten. Fügen Sie der API- Direktive den Parameter write=on hinzu, um Lese-/Schreibzugriff zu aktivieren, sodass Änderungen an Upstream-Servern und dem neuen Key-Value Store- Modul vorgenommen werden können. Wir empfehlen dringend, den Zugriff auf die API nur auf autorisierte Benutzer zu beschränken, insbesondere wenn der Lese-/Schreibmodus aktiviert ist.

Um alle Arten von Informationen anzuzeigen, die vom API-Endpunkt verfügbar sind, führen Sie diesen Befehl aus:

$ curl http://localhost:80/api/1/ ["nginx", "Prozesse", "Verbindungen", "SSL", "Slabs", "http", "Stream"]

Um Details zu einem bestimmten Informationstyp anzuzeigen, hängen Sie die entsprechende Zeichenfolge an die Anforderungs-URI an:

• Verbindungen – Zeigt Kennzahlen für die Gesamtzahl der Verbindungen an

• http – Metriken für HTTP-Verkehr anzeigen und HTTP-Upstream-Konfiguration ändern

  Es gibt auch zwei „Untertypen“ unter http :

  • http/server_zones – Informationen zu virtuellen HTTP-Servern anzeigen
  • http/upstreams – Informationen zu HTTP-Upstream-Servergruppen anzeigen und deren Konfiguration ändern
• nginx – Allgemeine Informationen zu NGINX anzeigen
• Prozesse – Informationen zu NGINX-Arbeitsprozessen anzeigen
• slabs – Informationen zum von NGINX zugewiesenen gemeinsam genutzten Speicher anzeigen
• ssl – Metriken für SSL/TLS-Clients in Echtzeit anzeigen
• stream – Zeigt Metriken für TCP/UDP-Verkehr an und ändert die Konfiguration von TCP/UDP-Upstream-Servergruppen (unter stream/upstreams )

Erweiterte Statusüberwachung

NGINX Plus meldet mehr als 40 exklusive Metriken zusätzlich zu dem, was in NGINX Open Source verfügbar ist. Sie können jetzt über die NGINX Plus-API auf diese Metriken zugreifen. Verwenden Sie die API, um auf die für Sie wichtigen Metriken zuzugreifen.

Hängen Sie beispielsweise Verbindungen an die URI an, um einen Snapshot des Verbindungsstatus auszugeben, der die Anzahl der akzeptierten, aktiven, unterbrochenen und inaktiven Clientverbindungen enthält.

$ curl http://localhost:80/api/1/connections {"akzeptiert":3,"gelöscht":0,"aktiv":1,"leerlauf":0}

Ein weiteres Beispiel: Hängen Sie „ssl“ an die URI an, um einen Snapshot der SSL-Clientstatistiken in Echtzeit auszugeben.

$ curl http://localhost:80/api/1/ssl {"handshakes":0,"handshakes_failed":0,"session_reuses":0}

Dynamische Konfiguration von Upstream-Servergruppen

In NGINX Plus R12 und früheren Versionen konnten Sie die Direktive upstream_conf verwenden, um die dynamische Konfiguration vorhandener Upstream-Servergruppen zu aktivieren, ohne NGINX Plus neu zu laden. Diese Funktionalität ist jetzt in die NGINX Plus-API integriert.

Dieser NGINX Plus-Konfigurationsausschnitt definiert zwei Server in der Upstream-Gruppe namens „backend“ und aktiviert die NGINX Plus-API unter /api :

Upstream-Backend { Zone Backends 64k;
Server 10.10.10.2; 
Server 10.10.10.4;
}

Server {
Listen 80;
Servername www.example.org;

Standort /API {
API Write=on;
}
}

Um einen Server zur Backend- Gruppe hinzuzufügen, schließen Sie die Option -d in eine Curl -Anfrage an /api/1/http/upstreams/backend/servers ein, mit JSON-Text, der die IP-Adresse des neuen Servers definiert (hier 10.10.10.6). Die Option -i bedeutet, dass HTTP-Header in die Antwort aufgenommen werden. (Sie können -X POST weglassen, da dies die Standardmethode mit -d ist, wir schließen es jedoch aus Konsistenzgründen mit anderen Methoden ein.)

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/servers HTTP/1.1 201 Erstellt …

Einzelheiten zu allen Optionen zum Konfigurieren von Upstream-Gruppen finden Sie in der Referenzdokumentation für das NGINX Plus-API- Modul.

Schlüssel-Wert-Speicher

NGINX Plus R13 führt ein neues Key-Value Store- Modul ein. Mit der NGINX Plus-API können Sie Schlüssel-Wert-Paare im Handumdrehen in einer oder mehreren gemeinsam genutzten „keyval“-Speicherzonen erstellen, ändern und entfernen. Der Wert jedes Schlüssel-Wert-Paares kann dann als Variable zur Verwendung durch andere NGINX Plus-Funktionen ausgewertet werden.

Um Einträge im Schlüssel-Wert-Speicher hinzuzufügen, zu ändern, zu lesen und zu löschen, verwenden Sie die HTTP-Methoden POST , PATCH , GET und DELETE . Der Schlüssel-Wert-Speicher bietet zahlreiche dynamische Konfigurationslösungen, um eine Echtzeitintegration mit externen Systemen zu ermöglichen.

Zu den Beispielanwendungsfällen gehören:

• Dynamische IP-Sperrliste (siehe NGINX Plus Admin Guide )
• Routing von URIs zu Backend-Servern
• Verwalten von Listen zulässiger URIs pro Benutzer
• Umleitungsregeln verwalten (siehe folgendes Beispiel)

Der folgende Konfigurationsausschnitt verwendet das Key-Value Store- Modul, um Vanity-URLs für eine Website zu verwalten.

keyval_zone zone=redirects:1M state=state/redirects.json; # Schlüssel-Wert-Paare in Datei speichernkeyval $uri $target zone=redirects; # $uri ist der Schlüssel, $target ist der Wert

server {
listen 80;

location /api {
api write=on; # NGINX Plus API aktivieren (diesen Standort in Produktionsumgebungen sichern)
}

if ($target) { # Wahr, wenn $uri in der Keyval-Zone „redirects“ vorhanden ist
return 301 $target; # Client zum passenden Wert für $uri weiterleiten
}

location / {
proxy_pass http://backend;
}
}

In der keyval- Direktive wird der Schlüssel auf die URI des Remotecomputers gesetzt, der die HTTP-Anforderung ausgibt. Wenn $uri ein Schlüssel im Schlüssel-Wert-Speicher ist, wird der mit dem Schlüssel verknüpfte Wert einer neuen Variablen namens $target zugewiesen. Wenn $target vorhanden ist, leitet NGINX Plus den Client zum passenden Wert von $uri weiter.

Um den Schlüssel-Wert-Speicher mit einer anfänglichen Vanity-URL zu füllen, senden wir die als JSON codierten Daten an die URI für die NGINX Plus-API .

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirects HTTP/1.1 201 Erstellt …

Jetzt werden Clients, die /conf anfordern, zu /conf2017 umgeleitet.

$ curl -i http://localhost/conf HTTP/1.1 301 Vorübergehend verschobener Standort: http://localhost/conf2017

Mit der PATCH -Methode können Sie dem Schlüssel-Wert-Speicher weitere Vanity-URL-Weiterleitungen hinzufügen und vorhandene Einträge dynamisch ändern.

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirects HTTP/1.1 204 Kein Inhalt ...

Sie können mehrere separate Schlüssel-Wert-Speicher konfigurieren, indem Sie mit der Direktive „keyval“ für jeden eine andere gemeinsam genutzte Speicherzone definieren. Weitere Informationen finden Sie in der Referenzdokumentation zum Key-Value Store- Modul.

Swagger-Dokumentation

Die neue NGINX Plus API verfügt über eine Swagger -Spezifikation, mit der Sie die API erkunden und die Funktionen der einzelnen Ressourcen verstehen können. Die Swagger-Dokumentation ist im Lieferumfang von NGINX Plus enthalten und kann unter http:// nginx-host /swagger-ui/ abgerufen werden.

Für den interaktiven Teil der Swagger-Benutzeroberfläche muss die NGINX Plus-API aktiviert sein. Dies kann durch Aufheben der Kommentierung des Standortblocks /api/ in der Datei conf.d/default.conf erreicht werden.

# /api/-Standort mit entsprechender Zugriffskontrolle aktivieren, um# die NGINX Plus API nutzen zu können
#
#location /api/ {
# api write=on;
# allow 127.0.0.1;
# deny all;
#}

Sie können auch die NGINX Plus API- Dokumentation unter https://demo.nginx.com/swagger-ui/ erkunden.

Notiz: Die gesamte NGINX Plus-API , einschließlich der erweiterten Statusmetriken, der Upstream-Konfiguration und des neuen Key-Value-Store-Moduls, ist exklusiv für NGINX Plus.

Spiegelung von Anfragen

Mit NGINX Plus R13 können Sie die Spiegelung von HTTP-Anforderungen aktivieren. Mit dieser Funktion werden HTTP-Anfragen, die an eine Upstream-Gruppe weitergeleitet werden, geklont und auch an ein anderes Ziel gesendet. Die ursprüngliche Anfrage wird wie gewohnt verarbeitet, aber alle Antworten der geklonten Anfrage werden ignoriert. Es gibt viele Anwendungsfälle für die Anforderungsspiegelung, darunter:

• Integration mit Web Application Firewalls (WAFs) bei Einsatz im Lernmodus, sodass typische Anfragemuster analysiert werden können, ohne den Produktionsverkehr zu beeinträchtigen
• Risikofreie Leistungsoptimierung durch Live-Produktionsverkehr
• Duplizieren von Datei-Uploads auf einem Backup-Server, um eine Dateisystemreplikation zwischen Webservern zu vermeiden

Das Aktivieren der Anforderungsspiegelung hat vernachlässigbare Auswirkungen auf den Gesamtsystemdurchsatz und die Leistung. Der folgende Konfigurationsausschnitt zeigt, wie Sie mit der neuen Mirror- Direktive Anfragen klonen und an einen separaten Upstream-Server weiterleiten.

Standort / { Spiegel /Spiegel;
Proxy-Passwort http://backend;
}

Standort /Spiegel {
intern;
Proxy-Passwort http://test_backend$request_uri;
}

Zur regulären Verarbeitung werden Anfragen an die Upstream-Gruppe des Backends weitergeleitet. Sie werden außerdem geklont und an eine separate Upstream-Gruppe mit dem Namen test_backend weitergeleitet, wobei die URI der ursprünglichen Anfrage erhalten bleibt.

Notiz: Die Anforderungsspiegelung wurde ursprünglich in NGINX Open Source 1.13.4 veröffentlicht.

Verbesserungen am NGINX JavaScript-Modul

Seit der allgemeinen Verfügbarkeit in NGINX Plus R12 wird das NGINX-JavaScript-Modul (früher nginScript genannt) kontinuierlich um Unterstützung für die Kernsprache JavaScript erweitert. Mit dieser Version führen wir Unterstützung für Hexadezimalzahlen (wie 0x7b) und wissenschaftliche Notation (wie 512e10) ein. Es wurden auch primitive Methoden für die Object -Klasse implementiert.

NGINX JavaScript bietet jetzt auch eine interaktive Shell, die mit dem Befehl njs aufgerufen wird, um bei der Entwicklung von NGINX JavaScript-Code zu helfen.

Der folgende Shell-Ausschnitt zeigt, wie Sie die interaktive JavaScript-Shell von NGINX aufrufen, einen Ausdruck definieren, der ein zufälliges Datum bis zu 30 Sekunden in der Zukunft erzeugt, und die Summe zweier Zahlen berechnen.

$ njs interaktives njscript >> Date.now() + Math.round(Math.random()*30*1000); 1500976350968 >> 0x7b + 512e10; 5120000000123 >>

Weitere Informationen finden Sie in der Einführung zu NGINX JavaScript<.htmla> in unserem Blog.

Notiz: NGINX JavaScript ist sowohl für NGINX Open Source als auch für NGINX Plus verfügbar.

Build-Tool für dynamische Module

NGINX 1.11.5 und NGINX Plus R11 führten die Unterstützung für das Kompilieren dynamischer Module unabhängig von NGINX selbst ein. Dies ermöglicht Benutzern von NGINX und NGINX Plus, die offiziellen Builds aus den Repositories von NGINX, Inc. zu verwenden und nur die dynamischen Module zu laden, die sie benötigen.

Mit NGINX Plus R13 stellen wir ein Build-Tool zum Kompilieren und Verpacken eines dynamischen Moduls als installierbares Modul bereit, das die Abhängigkeit zwischen ihm und der Basisversion von NGINX, mit der es verknüpft ist, bewahrt und berücksichtigt.

Ausführliche Informationen zum Build-Tool finden Sie unter „Erstellen installierbarer Pakete für dynamische Module“ in unserem Blog.

Notiz: Das Build-Tool ist sowohl für NGINX Open Source als auch für NGINX Plus verfügbar.

Schnellere Sticky-Learn-Sitzungspersistenz

Die Sitzungspersistenz ist eine sehr nützliche Funktion des Lastenausgleichs von NGINX Plus, mit der Sie alle Anfragen eines bestimmten Clients an einen Server senden können. Es gibt mehrere Möglichkeiten, die Sitzungspersistenz sicherzustellen. Mit der Methode „Sticky Learn“ sucht NGINX Plus nach dem Vorhandensein eines bestimmten Cookies und heftet den Client an denselben Server, wenn dieses Cookie in einer Anfrage enthalten ist.

Mit NGINX Plus R13 können Sie jetzt eine Sticky Session herstellen, sobald der Upstream-Server die Header seiner Antwort gesendet hat, anstatt zu warten, bis die vollständige Antwortnutzlast eingetroffen ist. NGINX Plus kann somit die Sticky Session zum frühestmöglichen Zeitpunkt an den Client senden. Fügen Sie den neuen Header- Parameter in die Sticky- Learn- Direktive ein:

Upstream-Backends { Zone Backends 64k;
Server 10.10.10.2; 
Server 10.10.10.4;

Sticky Learn Erstellen=$upstream_cookie_sessionid
Lookup=$cookie_sessionid
Zone=client_sessions:1m
Header;
}

Der Header- Parameter ist insbesondere dann nützlich, wenn eine Anwendung fehleranfällig ist und Sie möchten, dass der Client fehlgeschlagene Anfragen an denselben Upstream-Server erneut sendet.

Notiz: Die Sticky-Learn-Sitzungspersistenz ist exklusiv für NGINX Plus.

Zusätzliche Merkmale

NGINX Plus R13 führt die folgenden zusätzlichen Funktionen ein:

• HTTP-Trailer – Die Direktive „add_trailer“ ermöglicht das Hinzufügen beliebiger Trailer an das Ende von HTTP-Antworten. Der Trailer-Antwortheader ermöglicht es dem Absender, am Ende von Chunk-Nachrichten zusätzliche Felder einzufügen, um Metadaten bereitzustellen, die möglicherweise dynamisch generiert werden, während der Nachrichtentext gesendet wird, z. B. eine Prüfung der Nachrichtenintegrität oder eine digitale Signatur.
• Dynamisches Modul für Substitutionsfilter – Das dynamische Community-Modul „HTTP-Substitutionsfilter“ wird jetzt unterstützt und ist in unseren NGINX Plus-Distributionen enthalten. Das Modul kann sowohl reguläre Ausdrücke als auch feste Zeichenfolgen auf Antworttexte ersetzen. Es durchsucht den Puffer der Ausgabeketten und gleicht die Zeichenfolge zeilenweise ab. Sie können auch über die Seite „Dynamische Module“ auf das Modul zugreifen.
• Ordentliches Herunterfahren der Worker-Prozesse – Verwenden Sie die Direktive worker_shutdown_timeout, um ein Timeout festzulegen, das ein ordnungsgemäßes Herunterfahren der Worker-Prozesse ermöglicht und so ein schnelleres Abschließen ermöglicht. Wenn das Timeout nach dem Empfang eines Herunterfahren- oder Neustartsignals abläuft, versucht NGINX Plus, alle offenen Clientverbindungen zu schließen.

Upgrade auf R13 oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 13 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und können Ihnen so leichter helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen finden Sie im Kundenportal .

Bitte überprüfen Sie die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs auszuprobieren. Sie können noch heute kostenlos mit einer 30-tägigen Testversion beginnen und sich selbst davon überzeugen, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.