Ankündigung von NGINX Plus R13

NGINX | 29. August 2017

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 13 (R13) jetzt allen Abonnenten von NGINX Plus als kostenloses Upgrade zur Verfügung steht. NGINX Plus ist eine Kombination aus Webserver, Load Balancer und Content-Cache, die auf NGINX Open Source basiert. NGINX Plus R13 umfasst neue Funktionen mit Schwerpunkt auf dynamischen Bereitstellungen, erweiterten Debugging-Möglichkeiten sowie verbesserter Sicherheit und Leistung.

NGINX Plus R13 bietet jetzt Unterstützung für:

Eine neue NGINX Plus-API – Führen Sie dynamische Konfigurationen durch und rufen Sie erweiterte Statusmetriken über einen einzigen zentralen Endpunkt ab. Die API unterstützt außerdem Schlüssel-Wert-Speicher.
Anfragespiegelung – Senden Sie eine Kopie des gesamten eingehenden Datenverkehrs an einen dedizierten Server, auf dem Sie den Anwendungsdatenverkehr überwachen, untersuchen und protokollieren können, ohne die Leistung der Produktionsserver zu beeinträchtigen.
Verbesserungen am NGINX-JavaScript-Modul – Erweitern Sie NGINX Plus mithilfe des NGINX-JavaScript-Moduls, unserer eigenen JavaScript-Implementierung, um eine programmatische Konfiguration. [Das Modul hieß früher nginScript.] Die neue interaktive njs-Shell bietet eine Konsole, die alle integrierten JavaScript-Objekte anzeigt. Diese Objekte können genauer untersucht werden, um die verfügbaren Methoden und Primitive jedes Objekts anzuzeigen.
Build-Tool für dynamische Module – Mit unserem neuen Build-Tool können Sie installierbare Pakete für die zahlreichen verfügbaren Drittanbietermodule für NGINX und NGINX Plus erstellen.

Zu den weiteren Neuerungen gehören Verbesserungen an der Sticky-Learn-Methode für die Sitzungspersistenz, die Unterstützung von HTTP-Trailern und ein neues dynamisches Drittanbietermodul für HTTP-Ersetzungen.

Verhaltensänderungen

Veraltete Module – Die bisherigen APIs für erweiterte Statusinformationen und die dynamische Konfiguration von Upstream-Gruppen (die Module Status und Upstream Conf) sind veraltet und werden durch die einheitliche NGINX Plus API ersetzt. Die veralteten APIs werden noch mindestens sechs Monate lang zusammen mit der neuen NGINX Plus API in NGINX Plus enthalten sein. In einer zukünftigen Version von NGINX Plus werden die veralteten APIs entfernt.
Entfernte Direktive – Die Direktive sticky_cookie_insert wurde in NGINX Plus R13 entfernt, nachdem sie bereits in NGINX Plus R2 als veraltet eingestuft worden war.
Dynamische Module von Drittanbietern – Dynamische Module, die aus dem NGINX-Repository installiert wurden, werden automatisch auf R13 aktualisiert. Alle Module von Drittanbietern – also Module, die nicht im offiziellen NGINX-Repository enthalten sind – müssen für NGINX Open Source 1.13.4 neu kompiliert werden, damit sie weiterhin mit NGINX Plus R13 funktionieren. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch.
Direktive im ModSecurity-Modul wird nicht mehr unterstützt – Die SecRequestBodyInMemoryLimit-Direktive für ModSecurity wird nicht mehr unterstützt. Kunden können diese Direktive bedenkenlos entfernen, da das ModSecurity-Modul die in der NGINX-Konfiguration festgelegte Verarbeitung des Anfragekörpers befolgt.[Redaktion – Das NGINX ModSecurity WAF-Modul für NGINX Plus wurde zum 1. April 2022 offiziell aus dem Verkauf genommen und erreicht mit Wirkung zum 31. März 2024 sein Lebensende. Weitere Einzelheiten finden Sie im Beitrag F5 NGINX ModSecurity WAF erreicht das Lebensende<.htmla> in unserem Blog.]
Unterstützung für nicht mehr unterstützte Betriebssystemversionen eingestellt – NGINX Plus wird unter CentOS 5.10+, Red Hat Enterprise Linux 5.10+, Oracle Linux 5.10+, Ubuntu 12.04 LTS und 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 zusammengefasst ist. Frühere Versionen von NGINX Plus enthielten separate APIs für Upstream Conf und Extended Status. Die neue API vereint die Funktionen beider APIs und unterstützt außerdem das neue Key-Value-Store-Modul für verschiedene Anwendungsfälle der dynamischen Konfiguration (siehe Abschnitt „Key-Value Store“ weiter unten).

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

server {    listen 80;

    location /api {
        api write=on;
        # directives that allow access only by authorized users
    }
}

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

Führen Sie den folgenden Befehl aus, um alle Arten von Informationen anzuzeigen, die über den API-Endpunkt verfügbar sind:

$ curl http://localhost:80/api/1/ ["nginx","processes","connections","ssl","slabs","http","stream"]

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

connections – Metriken für die Gesamtzahl der Verbindungen anzeigen
http – Metriken für HTTP-Datenverkehr anzeigen und die HTTP-Upstream-Konfiguration ändern. Unter http gibt es außerdem zwei „Untertypen“:
- 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
processes – Informationen zu NGINX-Worker-Prozessen anzeigen
slabs – Informationen zum von NGINX zugewiesenen gemeinsamen Speicher anzeigen
ssl – Metriken für SSL/TLS-Clients in Echtzeit anzeigen
stream – Metriken für TCP/UDP-Datenverkehr anzeigen und die Konfiguration von TCP/UDP-Upstream-Servergruppen ändern (unter stream/upstreams)

Erweiterte Statusüberwachung

NGINX Plus stellt zusätzlich zu den in NGINX Open Source verfügbaren Metriken mehr als 40 exklusive Metriken bereit. Auf diese Metriken können Sie jetzt über die NGINX Plus API zugreifen. Verwenden Sie die API, um auf die für Sie wichtigen Metriken zuzugreifen.

Hängen Sie beispielsweise connections an den URI an, um eine Momentaufnahme des Verbindungsstatus auszugeben, die die Anzahl der akzeptierten, aktiven, verworfenen und inaktiven Clientverbindungen enthält.

$ curl http://localhost:80/api/1/connections{"accepted":3,"dropped":0,"active":1,"idle":0}

Ein weiteres Beispiel: Hängen Sie ssl an den URI an, um eine Momentaufnahme der SSL-Client-Statistiken 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üher konnten Sie die Direktive upstream_conf verwenden, um die dynamische Konfiguration vorhandener Upstream-Servergruppen zu ermöglichen, 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;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Um der Gruppe backend einen Server hinzuzufügen, verwenden Sie die Option -d in einer curl-Anfrage an /api/1/http/upstreams/backend/servers und übergeben Sie dabei JSON-Text, der die IP-Adresse des neuen Servers angibt (hier 10.10.10.6). Die Option -i bewirkt, dass die HTTP-Header in die Antwort aufgenommen werden. (Sie können -X POST weglassen, da dies bei Verwendung von -d die Standardmethode ist; wir geben sie jedoch an, um die Konsistenz mit anderen Methoden zu wahren.)

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/serversHTTP/1.1 201 Created
...

Ausführliche Informationen zu allen Optionen für die Konfiguration von Upstream-Gruppen finden Sie in der Referenzdokumentation zum Modul NGINX Plus API.

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 dynamisch in einer oder mehreren gemeinsam genutzten „keyval“-Speicherzonen erstellen, ändern und entfernen. Der Wert jedes Schlüssel-Wert-Paars kann anschließend als Variable ausgewertet und von anderen Funktionen von NGINX Plus verwendet werden.

Verwenden Sie zum Hinzufügen, Ändern, Lesen und Löschen von Einträgen im Schlüssel-Wert-Speicher die HTTP-Methoden POST, PATCH, GET bzw. DELETE. Der Schlüssel-Wert-Speicher bietet zahlreiche dynamische Konfigurationsmöglichkeiten für die Echtzeitintegration mit externen Systemen.

Beispiele für Anwendungsfälle:

Dynamische Sperrung von IP-Adressen (siehe NGINX Plus-Administratorhandbuch)
Weiterleitung von URIs an Backend-Server
Verwalten von Listen zulässiger URIs pro Benutzer
Weiterleitungsregeln verwalten (siehe folgendes Beispiel)

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

keyval_zone zone=redirects:1M state=state/redirects.json;  # Save key-val pairs to filekeyval $uri $target zone=redirects;                        # $uri is the key, $target is the value

server {
    listen 80;

    location /api {
        api write=on; # Enable the NGINX Plus API (secure this location in production environments)
    }

    if ($target) {          # True when $uri exists in the 'redirects' keyval zone
        return 301 $target; # Redirect client to the matching value for the $uri
    }

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

In der keyval-Direktive wird als Schlüssel der URI des entfernten Rechners festgelegt, der die HTTP-Anfrage sendet. Wenn $uri ein Schlüssel im Schlüssel-Wert-Speicher ist, wird der diesem Schlüssel zugeordnete Wert einer neuen Variablen namens $target zugewiesen. Wenn $target vorhanden ist, leitet NGINX Plus den Client anschließend an den zu $uri gehörenden Wert weiter.

Um den Schlüssel-Wert-Speicher mit einer ersten Vanity-URL zu befüllen, senden wir die als JSON codierten Daten an den URI der NGINX Plus API.

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 201 Created
...

Clients, die jetzt /conf anfordern, werden zu /conf2017 weitergeleitet.

$ curl -i http://localhost/confHTTP/1.1 301 Moved Temporarily
Location: http://localhost/conf2017

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

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 204 No Content
...

Sie können mehrere separate Schlüssel-Wert-Speicher konfigurieren, indem Sie mit der keyval-Direktive für jeden Speicher eine eigene Shared-Memory-Zone definieren. Weitere Informationen finden Sie in der Referenzdokumentation zum Modul Key-Value Store.

Swagger-Dokumentation

Die neue NGINX Plus API umfasst eine Swagger-Spezifikation, mit der Sie die API erkunden und sich mit den Funktionen der einzelnen Ressourcen vertraut machen können. Die Swagger-Dokumentation ist im Lieferumfang von NGINX Plus enthalten und kann unter http://nginx-host/swagger-ui/ aufgerufen werden.

Für den interaktiven Teil der Swagger-Benutzeroberfläche muss die NGINX Plus-API aktiviert sein. Entfernen Sie dazu die Auskommentierung des Standortblocks „/api/“ in der Datei „conf.d/default.conf“.

# enable /api/ location with appropriate access control in order# to make use of NGINX Plus API
#
#location /api/ {
#    api write=on;
#    allow 127.0.0.1;
#    deny all;
#}

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

Hinweis: Die gesamte NGINX Plus API, einschließlich der erweiterten Statusmetriken, der Upstream-Konfiguration und des neuen Key-Value-Store-Moduls, ist ausschließlich in NGINX Plus verfügbar.

Anfragespiegelung

Mit NGINX Plus R13 können Sie die Spiegelung von HTTP-Anfragen aktivieren. Dabei werden HTTP-Anfragen, die an eine Upstream-Gruppe weitergeleitet werden, dupliziert und zusätzlich an ein anderes Ziel gesendet. Die ursprüngliche Anfrage wird wie gewohnt verarbeitet, Antworten auf die duplizierte Anfrage werden jedoch ignoriert. Die Anfragespiegelung bietet zahlreiche Anwendungsmöglichkeiten, darunter:

Integration mit Web Application Firewalls (WAFs) bei der Bereitstellung im Lernmodus, sodass typische Anfragemuster analysiert werden können, ohne den Produktivdatenverkehr zu beeinträchtigen
Risikofreie Leistungsoptimierung anhand von Live-Produktivdatenverkehr
Duplizieren von Datei-Uploads auf einem Backup-Server, um die Replikation des Dateisystems zwischen Webservern zu vermeiden

Die Aktivierung der Anfragespiegelung hat nur vernachlässigbare Auswirkungen auf den Gesamtdurchsatz und die Leistung des Systems. Der folgende Konfigurationsausschnitt zeigt, wie die neue mirror-Direktive verwendet wird, um Anfragen zu duplizieren und an einen separaten Upstream-Server weiterzuleiten.

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

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

Anfragen werden zur regulären Verarbeitung an die Upstream-Gruppe „backend“ weitergeleitet. Außerdem werden sie dupliziert und an eine separate Upstream-Gruppe namens „test_backend“ weitergeleitet, wobei der URI der ursprünglichen Anfrage beibehalten wird.

Hinweis: Request Mirroring wurde erstmals 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 zentrale Funktionen der JavaScript-Sprache erweitert. Mit dieser Version führen wir die Unterstützung für Hexadezimalzahlen (wie 0x7b) und die wissenschaftliche Notation (wie 512e10) ein. Außerdem wurden grundlegende Methoden für die Klasse Object implementiert.

NGINX JavaScript bietet jetzt auch eine interaktive Shell, die mit dem Befehl njs aufgerufen wird und die Entwicklung von NGINX-JavaScript-Code erleichtert.

Das folgende Shell-Beispiel zeigt, wie Sie die interaktive NGINX JavaScript-Shell aufrufen, einen Ausdruck definieren, der ein zufälliges Datum innerhalb der nächsten 30 Sekunden erzeugt, und die Summe zweier Zahlen berechnen.

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

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

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

Build-Tool für dynamische Module

Mit NGINX 1.11.5 und NGINX Plus R11 wurde die Unterstützung für das Kompilieren dynamischer Module unabhängig von NGINX selbst eingeführt. Dadurch können Benutzer von NGINX und NGINX Plus die offiziellen Builds aus den Repositorys von NGINX, Inc. verwenden und nur die dynamischen Module laden, die sie benötigen.

Mit NGINX Plus R13 stellen wir ein Build-Tool bereit, mit dem sich ein dynamisches Modul als installierbares Modul kompilieren und paketieren lässt, wobei die Abhängigkeit zwischen diesem Modul und der zugrunde liegenden NGINX-Version, mit der es verknüpft ist, erhalten bleibt und berücksichtigt wird.

Ausführliche Informationen zum Build-Tool finden Sie im Beitrag „Installierbare Pakete für dynamische Module erstellen“ in unserem Blog.

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

Schnellere Sitzungspersistenz mit Sticky Learn

Die Sitzungspersistenz ist eine sehr nützliche Funktion des Lastenausgleichs von NGINX Plus. Damit können Sie alle Anfragen eines bestimmten Clients an denselben Server senden. Es gibt mehrere Möglichkeiten, Sitzungspersistenz herzustellen. Bei der Methode „Sticky Learn“ prüft NGINX Plus, ob ein bestimmtes Cookie vorhanden ist, und bindet den Client an denselben Server, sobald dieses Cookie in einer Anfrage enthalten ist.

Mit NGINX Plus R13 können Sie nun eine persistente Sitzung einrichten, sobald der Upstream-Server die Header seiner Antwort gesendet hat, anstatt zu warten, bis die vollständigen Antwortdaten eingegangen sind. Dadurch kann NGINX Plus die persistente Sitzung so früh wie möglich an den Client senden. Fügen Sie der Direktive header den neuen Parameter sticky learn hinzu:

upstream backends {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
   
    sticky learn create=$upstream_cookie_sessionid
                 lookup=$cookie_sessionid
                 zone=client_sessions:1m
                 header;
 }

Der Parameter header ist besonders nützlich, wenn eine Anwendung fehleranfällig ist und der Client fehlgeschlagene Anfragen erneut an denselben Upstream-Server senden soll.

Hinweis: Die Sticky-Learn-Sitzungspersistenz ist ausschließlich in NGINX Plus verfügbar.

Zusätzliche Funktionen

NGINX Plus R13 bietet die folgenden zusätzlichen Funktionen:

HTTP-Trailer – Mit der Direktive add_trailer können beliebige Trailer am Ende von HTTP-Antworten hinzugefügt werden. Das Trailer-Antwortheaderfeld ermöglicht es dem Absender, am Ende von in Blöcken übertragenen Nachrichten zusätzliche Felder einzufügen, um Metadaten bereitzustellen, die möglicherweise dynamisch während der Übertragung des Nachrichtentexts generiert werden, beispielsweise eine Integritätsprüfung der Nachricht oder eine digitale Signatur.
Dynamisches Modul für Substitutionsfilter – Das dynamische Community-Modul HTTP Substitutions Filter wird jetzt unterstützt und ist in unseren NGINX Plus-Distributionen enthalten. Das Modul kann Ersetzungen sowohl anhand regulärer Ausdrücke als auch fester Zeichenfolgen auf Antworttexte anwenden. Es durchsucht den Puffer der Ausgabekette und sucht Zeile für Zeile nach Übereinstimmungen. Sie können das Modul auch über die Seite Dynamische Module aufrufen.
Ordnungsgemäßes Herunterfahren von Worker-Prozessen – Verwenden Sie die Direktive worker_shutdown_timeout, um ein Zeitlimit festzulegen, damit Worker-Prozesse schneller ordnungsgemäß heruntergefahren werden können. Wenn das Zeitlimit nach dem Empfang eines Signals zum Herunterfahren oder Neustarten abläuft, versucht NGINX Plus, alle offenen Clientverbindungen zu schließen.

Führen Sie ein Upgrade auf R13 durch oder testen Sie NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf Release 13 durchzuführen. Damit erhalten Sie eine Reihe von Fehlerbehebungen und Verbesserungen. Außerdem können wir Sie so besser unterstützen, falls Sie ein Support-Ticket erstellen müssen. Anweisungen zur Installation und zum Upgrade finden Sie im Kundenportal.

Bitte lesen Sie sich die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig durch, 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 zu testen. Starten Sie noch heute kostenlos mit einer 30-tägigen Testversion und überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.