Ankündigung von NGINX Plus R12

NGINX | 14. März 2017

Owen GarrettSenior Director, Produktmanagement

[Redaktion – Dieser Beitrag wurde aktualisiert und verweist nun auf die NGINX Plus API, welche die in der ursprünglichen Version des Beitrags behandelten separaten Module für dynamische Konfiguration und Status ersetzt und als veraltet kennzeichnet.]

Wir freuen uns, heute bekannt geben zu können, dass NGINX Plus R12 allen NGINX Plus-Abonnenten als kostenloses Upgrade zur Verfügung steht. NGINX Plus ist eine leistungsstarke Softwareplattform für die Anwendungsbereitstellung, die einen Load Balancer, einen Content-Cache und einen Webserver umfasst. NGINX Plus R12 ist ein bedeutendes Release mit neuen Funktionen, deren Schwerpunkte auf Clustering, Anpassung und Monitoring liegen.

Weitere Informationen zu NGINX Plus R12 erhalten Sie in unserem On-Demand-Webinar.

Unternehmenskunden profitieren von der neuen Clustering-Funktion, die die Verwaltung hochverfügbarer Cluster aus NGINX Plus-Servern vereinfacht. Allen Benutzern kommt die offizielle Unterstützung für nginScript zugute, eine schlanke und leistungsstarke Skriptsprache, die direkt in die NGINX-Konfiguration eingebettet ist. Verbesserungen bei Überwachung und Instrumentierung, Caching und Systemdiagnosen erhöhen die Zuverlässigkeit und Leistung von Anwendungen.

Konfigurationsfreigabe – Ein unterstütztes Skript zur Konfigurationsfreigabe ermöglicht es Ihnen, die Konfiguration zuverlässig von einer primären NGINX Plus-Instanz auf mehrere Peer-Instanzen zu übertragen. Dabei werden Sicherungen erstellt und die Gültigkeit der Konfiguration auf jeder entfernten Peer-Instanz überprüft, bevor die Konfiguration übernommen und der nginx-Prozess der Peer-Instanz neu geladen wird.
Allgemeine Verfügbarkeit des NGINX-JavaScript-Moduls – Das NGINX-JavaScript-Modul<.htmla> ermöglicht Ihnen, mit NGINX Plus und der vertrauten JavaScript-Syntax anspruchsvolle Lösungen zur Verarbeitung von Datenverkehr zu erstellen. [Das Modul hieß früher nginScript; in diesem Beitrag werden beide Bezeichnungen synonym verwendet.] JavaScript-Code kann in die NGINX Plus-Konfiguration eingebettet werden, um benutzerdefinierte Aktionen für HTTP-, TCP- und UDP-Datenverkehr auszuführen.
Neue Statistiken – Transparenz ist entscheidend, um Anwendungen stabil und leistungsfähig zu halten. NGINX Plus R12 bietet mit zusätzlichen Metriken wie Serverantwortzeiten, der Auslastung gemeinsam genutzter Speicherbereiche und Fehlercodes für TCP-/UDP-Dienste einen besseren Einblick in die Anwendungsleistung. Zeigen Sie die neuen Statistiken im integrierten Dashboard zur Live-Aktivitätsüberwachung an oder exportieren Sie sie im JSON-Format in Ihr bevorzugtes Monitoring-Tool.
Verbessertes Caching – Holen Sie noch mehr Leistung aus Ihrem Cache heraus. NGINX Plus R12 unterstützt die in stale-while-revalidate und stale-if-error definierten Cache-Erweiterungen gemäß RFC 5861. Die Cache-Revalidierung kann im Hintergrund erfolgen, sodass Benutzer nicht warten müssen, bis die Anfrage an den Ursprungsserver und dessen Antwort abgeschlossen sind.
Verbesserungen bei Integritätsprüfungen – Wenn neue Server über die NGINX Plus API oder DNS zu einem Load-Balancing-Pool hinzugefügt werden, kann NGINX Plus den Datenverkehr zu ihnen so lange verzögern, bis sie die regulär konfigurierte Integritätsprüfung bestanden haben, und anschließend mithilfe der Slow-Start-Funktion den Datenverkehr zu ihnen schrittweise erhöhen. Darüber hinaus erleichtert eine neue, einfachere Integritätsprüfung für UDP die Bereitstellung zuverlässiger UDP-Dienste für Ihre Benutzer.

Weitere Verbesserungen umfassen die Clientzertifikatsauthentifizierung für TCP-Dienste, die Möglichkeit, benutzerdefinierte Felder in OAuth-JWTs zu prüfen, die Unterstützung des WebP-Formats im Image-Filter-Modul sowie eine Reihe von Leistungs- und Stabilitätsverbesserungen.

Wir empfehlen allen Abonnenten, umgehend auf NGINX Plus R12 zu aktualisieren, um von den Leistungs-, Funktions- und Zuverlässigkeitsverbesserungen dieser Version zu profitieren. Lesen Sie vor dem Update unbedingt die im nächsten Abschnitt aufgeführten Verhaltensänderungen.

Verhaltensänderungen

NGINX Plus R12 führt einige Änderungen am Standardverhalten und an den internen Abläufen von NGINX Plus ein, die Sie beim Upgrade beachten müssen:

Cache-Metadatenformat – Das Format des internen Cache-Metadaten-Headers wurde geändert. Beim Upgrade auf NGINX Plus R12 wird der Cache auf dem Datenträger ungültig, und NGINX Plus aktualisiert ihn bei Bedarf automatisch. Alte Cache-Einträge werden automatisch gelöscht.
SSL-„DN“-Variablen – Das Format der Variablen $ssl_client_s_dn und $ssl_client_i_dn wurde geändert. Als Feldtrennzeichen dient nun das Komma ( , ) anstelle des Schrägstrichs ( / ); es wird gemäß den RFCs 2253 und 4514 maskiert. Um weiterhin das Format X509_NAME_oneline mit dem Schrägstrich als Feldtrennzeichen zu verwenden, verwenden Sie die Variablen $ssl_client_s_dn_legacy und $ssl_client_i_dn_legacy.
Warteschlange für die maximale Anzahl von Verbindungen – Die queue-Direktive weist NGINX Plus an, Verbindungen zu Upstream-Servern in eine Warteschlange einzureihen, wenn diese überlastet sind. Aufgrund von Speicher- und Leistungsoptimierungen in R12 muss die queue-Direktive nun im upstream-Block unterhalb der Direktive stehen, die den Lastverteilungsalgorithmus angibt (hash, ip_hash, least_conn oder least_time).
Dynamische Module von Drittanbietern – Dynamische Module, die von NGINX, Inc. entwickelt oder zertifiziert wurden, sind in unserem Repository verfügbar. Damit Module von Drittanbietern weiterhin mit NGINX Plus R12 funktionieren, müssen sie für NGINX Open Source Version 1.11.10 neu kompiliert werden. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch.
Letzte Version für Betriebssystemversionen am Ende ihres Lebenszyklus – Ubuntu hat das Ende des Lebenszyklus für Ubuntu 12.04 LTS angekündigt, und Red Hat hat das Ende des Supports in der Produktionsphase für Red Hat Enterprise Linux 5.10+ angekündigt, jeweils mit Wirkung zum 31. März 2017. NGINX Plus R12 ist die letzte Version, die Pakete und Support für diese Betriebssystemversionen sowie für CentOS 5.10+ und Oracle Linux 5.10+ umfasst. Um auch nach NGINX Plus R12 weiterhin Updates und Support zu erhalten, aktualisieren Sie auf eine unterstützte Betriebssystemversion.

NGINX Plus R12-Funktionen im Detail

Konfigurationsfreigabe

NGINX Plus-Server werden häufig in einem Cluster aus zwei oder mehr Instanzen bereitgestellt, um Hochverfügbarkeit und Skalierbarkeit zu gewährleisten. Dadurch können Sie die Zuverlässigkeit Ihrer Dienste verbessern, indem Sie sie vor den Auswirkungen von Serverausfällen schützen, und zugleich horizontal skalieren, um große Datenverkehrsmengen zu bewältigen.

NGINX Plus bietet bereits eine unterstützte Möglichkeit, den Datenverkehr innerhalb eines Clusters entweder im Aktiv-Passiv- oder Aktiv-Aktiv-Modus zu verteilen. NGINX Plus R12 ergänzt eine weitere unterstützte Methode zur Synchronisierung der Konfiguration innerhalb eines Clusters. Mit dieser Funktion zur Konfigurationssynchronisierung kann ein Administrator einen „Cluster“ von NGINX Plus-Servern zentral konfigurieren. Diese Server verwenden einen gemeinsamen Teil ihrer Konfiguration.

Die NGINX Plus-Konfiguration wird vom primären Server an die Peer-Server übertragen

So synchronisieren Sie die Konfiguration:

Bestimmen Sie einen oder mehrere „primäre“ Knoten im Cluster.
Installieren Sie das neue nginx-sync-Paket auf den primären Knoten.
Wenden Sie Konfigurationsänderungen auf einen primären Knoten an.
Rufen Sie den Prozess zur Synchronisierung der Konfiguration nginx-sync.sh auf, der im Paket nginx-sync enthalten ist, um alle anderen Server im Cluster (die Peers) zu aktualisieren. Der Synchronisierungsprozess führt auf jedem Peer die folgenden Schritte aus:
1. Überträgt die aktualisierte Konfiguration über ssh oder rsync an den Peer.
2. Überprüft, ob die Konfiguration für den Peer gültig ist, und setzt sie andernfalls zurück.
3. Wendet die Konfiguration an, wenn sie gültig ist, und lädt die NGINX Plus-Server auf dem Peer neu.

Diese Funktion ist besonders hilfreich, wenn NGINX Plus auf einem hochverfügbaren Serverpaar (oder einer größeren Anzahl von Servern) bereitgestellt wird. Mit dieser Methode können Sie die zuverlässige Bereitstellung von Konfigurationen innerhalb eines Clusters vereinfachen oder Konfigurationen von einem Staging-Server auf einen Cluster von Produktionsservern übertragen.

Ausführliche Anweisungen finden Sie im NGINX Plus-Administratorhandbuch.

Allgemeine Verfügbarkeit des NGINX-JavaScript-Moduls

Mit NGINX Plus R12 freuen wir uns, bekannt geben zu können, dass das NGINX JavaScript-Modul nun allgemein als stabiles Modul sowohl für NGINX Open Source als auch für NGINX Plus verfügbar ist. [Das Modul hieß früher nginScript, und in diesem Beitrag werden beide Bezeichnungen synonym verwendet.] nginScript wird für Abonnenten von NGINX Plus vollständig unterstützt.

nginScript ist eine einzigartige JavaScript-Implementierung<.htmla> für NGINX und NGINX Plus, die speziell für serverseitige Anwendungsfälle und die Verarbeitung einzelner Anfragen entwickelt wurde. Damit können Sie die Konfigurationssyntax von NGINX Plus um JavaScript-Code erweitern, um anspruchsvolle Konfigurationslösungen umzusetzen.

Mit nginScript können Sie benutzerdefinierte Variablen mithilfe komplexer Logik protokollieren, die Auswahl von Upstream-Servern steuern, Lastverteilungsalgorithmen implementieren, die Sitzungspersistenz anpassen und sogar einfache Webdienste implementieren. In den nächsten Wochen werden wir in unserem Blog ausführliche Anleitungen für einige dieser Lösungen veröffentlichen und hier entsprechende Links hinzufügen, sobald sie verfügbar sind.

NGINX Plus R12 umfasst insbesondere die folgenden Verbesserungen:

Vorab-Lesephase im Stream-Modul
ECMAScript-6-Mathematikmethoden und -konstanten
Zusätzliche String-Methoden wie endsWith, includes, repeat, startsWith und trim
Gültigkeitsbereiche

Obwohl nginScript stabil ist, wird weiterhin daran gearbeitet, noch mehr Anwendungsfälle und JavaScript-Sprachfunktionen zu unterstützen. Weitere Informationen finden Sie in „Die Leistungsfähigkeit und Benutzerfreundlichkeit von JavaScript für jede Anfrage mit dem NGINX-JavaScript-Modul nutzen“<.htmla> in unserem Blog.

Neue Statistiken

Die Überwachungs- und Analysefunktionen von NGINX Plus bieten einen wichtigen Mehrwert und ermöglichen Ihnen tiefe Einblicke in die Leistung und das Verhalten sowohl von NGINX Plus als auch von Upstream-Anwendungen. Statistiken werden sowohl über unser integriertes grafisches Dashboard als auch im JSON-Format bereitgestellt, das in Ihr bevorzugtes Monitoring-Tool exportiert werden kann.

Das Dashboard zur Live-Aktivitätsüberwachung wurde für NGINX Plus R12 aktualisiert

NGINX Plus R12 bietet eine Reihe von Verbesserungen: mehr Informationen zur Leistung (Antwortzeit) von Servern mit Lastverteilung, Einblicke in den Betrieb von TCP- und UDP-Diensten sowie verschiedene interne Daten, die bei der Fehlerbehebung helfen, Probleme zu identifizieren und NGINX Plus für eine optimale Leistung zu optimieren.

Zu den neuen Statistiken in NGINX Plus R12 gehören:

Antwortzeit des Upstream-Servers – In NGINX Plus R11 und früheren Versionen wurde die Antwortzeit von Upstream-Servern nur bei Verwendung des Least-Time-Lastverteilungsalgorithmus berechnet. Ab NGINX Plus R12 wird die Antwortzeit für alle Algorithmen gemessen und sowohl in den JSON-Daten als auch im integrierten Dashboard angezeigt.
Antwortcodes für TCP/UDP-Upstreams im grafischen Dashboard – Das Stream-Modul für den TCP/UDP-Lastenausgleich generiert Pseudo-Statuscodes, die angeben, wie eine Verbindung geschlossen wurde (200 bedeutet „Erfolg“, 502 bedeutet „Upstream nicht verfügbar“ usw.), und stellt sie in der Variable $status bereit. NGINX Plus R12 fügt dem Dashboard mehrere Spalten hinzu, in denen die Anzahl der Antwortcodes für virtuelle TCP- und UDP-Server angezeigt wird, wie dies bereits für virtuelle HTTP-Server der Fall ist. Die Pseudo-Statuscodes können außerdem zur Integration in vorhandene Protokollanalysetools protokolliert werden.
Versionsinformationen zu NGINX Plus – Zur Unterstützung bei der Fehlerbehebung enthalten die JSON-Daten nun sowohl die NGINX Plus-Versionsnummer als nginx_build (zum Beispiel nginx-plus-r12) als auch die Versionsnummer von NGINX Open Source als nginx_version (zum Beispiel 1.11.10). Das Dashboard zeigt beide Werte im Feld oben links auf der Hauptregisterkarte an.
Upstream-Hostname – In den JSON-Daten identifiziert das Feld server einen Server in einer Upstream-Gruppe anhand seiner IP-Adresse und seines Ports. Das neue Feld name gibt den ersten Parameter der Direktive server im Konfigurationsblock upstream an. Dabei kann es sich neben einer IP-Adresse und einem Port auch um einen Domainnamen oder den Pfad eines UNIX-Domain-Sockets handeln. Im Dashboard zeigt die Spalte Name ganz links auf den Registerkarten Upstreams und TCP/UDP-Upstreams nun den Wert aus dem Feld name anstelle des Felds server an (das in NGINX Plus R11 und früher angezeigt wurde). Die neue Metrik erleichtert es, die JSON-Daten und das Dashboard Ihren Upstream-Servern zuzuordnen, wenn Sie diese mithilfe von DNS-Namen definieren. Dies gilt insbesondere für Namen, die in mehrere IP-Adressen aufgelöst werden.
Auslastung von Shared-Memory-Zonen in erweiterten Statusdaten – Shared-Memory-Zonen werden mit einer festen Größe konfiguriert. Dabei kann es schwierig sein, eine Größe zu wählen, die weder zu groß (Speicher wird zugewiesen, aber nie genutzt) noch zu klein ist (der Speicher ist erschöpft und zwischengespeicherte Elemente werden verworfen). Neue Messinstrumente in den Metriken liefern einen detaillierten internen Bericht über die Speichernutzung jeder Shared-Memory-Zone. So können Sie die Speichernutzung überwachen, und der technische Support von NGINX kann fundiertere Empfehlungen zur Optimierung der NGINX-Konfiguration geben.
JSON-konformes Escaping im Zugriffsprotokoll von NGINX Plus – Einige moderne Protokollanalysetools können JSON-formatierte Protokolldateien effizient einlesen und daraus leichter Erkenntnisse gewinnen als aus unformatierten Protokolldateien. Sie können eine JSON-Vorlage in der standardmäßigen NGINX-Plus-Direktive log_format definieren. Der neue optionale Parameter escape dieser Direktive erzwingt JSON-konformes Escaping, sodass die Protokollzeilen korrekt formatiert werden.

Weitere Informationen finden Sie unter „Überwachung der Live-Aktivität“.

Verbessertes Caching

NGINX Plus R12 verbessert die Caching-Engine von NGINX Plus erheblich.

Veraltete Inhalte während der Aktualisierung bereitstellen

NGINX Plus R12 unterstützt nun die in Cache-Control definierten Erweiterungen RFC 5861, stale-while-revalidate und stale-if-error. Sie können NGINX Plus jetzt so konfigurieren, dass diese Cache-Control-Erweiterungen berücksichtigt werden und weiterhin abgelaufene Ressourcen aus dem Cache bereitgestellt werden, während sie im Hintergrund aktualisiert werden, ohne die Latenz der Clientanfrage zu erhöhen. Ebenso kann NGINX Plus abgelaufene Ressourcen aus dem Cache bereitstellen, wenn der Upstream-Server nicht verfügbar ist – eine Technik zur Implementierung von Circuit-Breaker-Mustern in Microservices-Anwendungen.

Sofern NGINX Plus nicht so konfiguriert ist, dass der Cache-Control-Header ignoriert wird, berücksichtigt es die stale-Zeitangaben von Ursprungsservern, die RFC 5861-konforme Cache-Control-Header zurückgeben, wie in diesem Beispiel:

Cache-Control: max-age=3600 stale-while-revalidate=120 stale-if-error=900

Um die Unterstützung für die Cache-Control-Erweiterungen mit Aktualisierung im Hintergrund zu aktivieren, fügen Sie die hervorgehobenen Direktiven hinzu:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;

        # Serve stale content when updating
        proxy_cache_use_stale updating;
        
        # In addition, don’t block the first request that triggers the update
        # and do the update in the background
        proxy_cache_background_update on;

        proxy_pass http://my_upstream;
    }
}

Die Direktive proxy_cache_use_stale updating weist NGINX Plus an, während der Aktualisierung von Inhalten deren veraltete Version bereitzustellen. Wenn Sie nur diese Direktive verwenden, muss der erste Benutzer, der veraltete Inhalte anfordert, die Verzögerung durch einen „Cache Miss“ in Kauf nehmen. Das heißt, er erhält die Inhalte erst, nachdem NGINX Plus sie vom Ursprungsserver abgerufen und im Cache gespeichert hat. Benutzer, die die veralteten Inhalte anschließend während der Aktualisierung anfordern, erhalten sie sofort aus dem Cache, während der erste Benutzer warten muss, bis die aktualisierten Inhalte abgerufen und im Cache gespeichert wurden.

Mit der neuen proxy_cache_background_update-Direktive wird allen Benutzern, einschließlich des ersten Benutzers, der veraltete Inhalt bereitgestellt, während NGINX Plus ihn im Hintergrund aktualisiert.

Die neue Funktionalität ist auch in den Modulen FastCGI, SCGI und uwsgi verfügbar.

Byte-Range-Anfragen

Eine weitere Verbesserung der Caching-Engine ermöglicht es NGINX Plus, den Cache bei Bytebereichsanfragen zu umgehen, die mehr als eine konfigurierte Anzahl von Bytes nach dem Anfang einer nicht zwischengespeicherten Datei beginnen. Das bedeutet, dass bei großen Dateien wie Videoinhalten Anfragen nach einem weit hinten in der Datei liegenden Bytebereich die Latenz der Clientanfrage nicht erhöhen. In früheren Versionen von NGINX Plus erhielt der Client den angeforderten Bytebereich erst, nachdem NGINX Plus sämtliche Inhalte vom Anfang der Datei bis einschließlich des angeforderten Bytebereichs abgerufen und in den Cache geschrieben hatte.

Die neue Direktive „proxy_cache_max_range_offset“ gibt den Versatz vom Anfang der Datei an, ab dem NGINX Plus eine Bytebereichsanfrage direkt an den Ursprungsserver weiterleitet und die Antwort nicht zwischenspeichert. (Die neue Funktionalität ist auch in den Modulen FastCGI, SCGI und uwsgi verfügbar.)

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    location / {
        proxy_cache my_cache;

        # Bypass cache for byte range requests beyond 10 megabytes
        proxy_cache_max_range_offset 10m;

        proxy_pass http://my_upstream;
    }
}

Diese Verbesserungen festigen die Position von NGINX Plus als leistungsstarke, standardkonforme Caching-Engine weiter – geeignet für jede Umgebung, von der Beschleunigung der Anwendungsbereitstellung bis hin zum Aufbau vollwertiger Content Delivery Networks (CDNs).

Verbesserte Integritätsprüfungen

NGINX Plus R12 erweitert die Funktionen von NGINX Plus für aktive Systemdiagnosen weiter.

Integritätsprüfung für neu hinzugefügte Server

Mit der zunehmenden Verbreitung containerisierter Umgebungen und automatisch skalierter Anwendungsgruppen ist es unerlässlich, dass der Load Balancer proaktive Integritätsprüfungen auf Anwendungsebene durchführt und neuen Servern Zeit gibt, interne Ressourcen zu initialisieren, bevor sie ihre volle Leistung erreichen.

Vor NGINX Plus R12 wurde ein neuer Server, den Sie dem Loadbalancing-Pool hinzufügten (über die NGINX Plus API oder DNS), von NGINX Plus sofort als fehlerfrei eingestuft und umgehend mit Datenverkehr versorgt. Wenn Sie den neuen Parameter mandatory in die Direktive health_check (HTTP oder TCP/UDP) aufnehmen, muss der neue Server die konfigurierte Zustandsprüfung bestehen, bevor NGINX Plus Datenverkehr an ihn weiterleitet. In Kombination mit der Funktion slow‑start gibt der neue Parameter neuen Servern noch mehr Zeit, eine Verbindung zu Datenbanken herzustellen und sich „aufzuwärmen“, bevor sie ihren vollen Anteil am Datenverkehr verarbeiten müssen.

upstream my_upstream {     zone my_upstream 64k;
     server backend1.example.com slow_start=30s;
}

server {
    location / {
        proxy_pass http://my_upstream;
  
        # Require new server to pass health check before receiving traffic
        health_check mandatory;
    }
}

Hier sind sowohl der Parameter mandatory der Direktive health_check als auch der Parameter slow_start der Direktive server (HTTP oder TCP/UDP) enthalten. Server, die der Upstream-Gruppe über die API- oder DNS-Schnittstellen hinzugefügt werden, werden als fehlerhaft markiert und erhalten keinen Datenverkehr, bis sie die Integritätsprüfung bestehen. Anschließend erhalten sie über einen Zeitraum von 30 Sekunden schrittweise immer mehr Datenverkehr.

Konfigurationsfreie UDP-Systemdiagnose

Es ist ebenso wichtig, Integritätsprüfungen auf Anwendungsebene für UDP-Server wie für HTTP- und TCP-Server zu implementieren, damit kein Produktivdatenverkehr an Server gesendet wird, die nicht vollständig funktionsfähig sind. NGINX Plus unterstützt aktive Integritätsprüfungen für UDP. Vor NGINX Plus R12 mussten Sie jedoch einen match-Block erstellen, der die zu send Daten und die zu expect Antwort definierte. Bei Binärprotokollen oder Protokollen mit komplexen Handshakes kann es schwierig sein, die richtigen Werte zu ermitteln. Für solche Anwendungen unterstützt NGINX Plus R12 nun eine konfigurationsfreie Integritätsprüfung für UDP, die die Verfügbarkeit der Anwendung testet, ohne dass Sie Zeichenfolgen für „send“ und „expect“ definieren müssen. Fügen Sie für eine grundlegende UDP-Integritätsprüfung den Parameter udp zur Direktive health_check hinzu.

upstream udp_app {    server backend1.example.com:1234;
    server backend2.example.com:1234;
}

server {
    listen 1234 udp;
    proxy_pass udp_app;

    # Basic UDP health check
    health_check udp;
}

SSL-Updates – Client-Zertifikate für TCP-Dienste, aktualisierte Variablen

SSL-Clientzertifikate werden häufig verwendet, um Benutzer bei geschützten Websites zu authentifizieren. NGINX Plus R12 erweitert die bestehende HTTP-Unterstützung um die Authentifizierung für SSL-geschützte TCP-Dienste. Dies wird üblicherweise für die Maschine-zu-Maschine-Authentifizierung anstelle der Anmeldung von Endbenutzern eingesetzt und ermöglicht es Ihnen, NGINX Plus beim Load-Balancing von Layer-4-Protokollen sowohl für die SSL-Terminierung als auch für die Clientauthentifizierung zu verwenden. Ein Beispiel hierfür ist die Authentifizierung von IoT-Geräten für die Kommunikation über das MQTT-Protokoll.

Die Variable $ssl_client_verify enthält jetzt zusätzliche Informationen zu fehlgeschlagenen Clientauthentifizierungen. Dazu gehören Gründe wie „widerrufene“ und „abgelaufene“ Zertifikate.

Das Format der Variablen $ssl_client_i_dn und $ssl_client_s_dn wurde geändert, um den RFCs 2253 und 4514 zu entsprechen. Weitere Informationen finden Sie unter „Verhaltensänderungen“.

Verbesserte JWT-Validierung

Mit NGINX Plus R10 wurde die native Unterstützung von JSON Web Tokens (JWT) für OAuth 2.0 und OpenID Connect eingeführt. Einer der wichtigsten Anwendungsfälle besteht darin, dass NGINX Plus ein JWT validiert, die darin enthaltenen Felder prüft und sie als HTTP-Header an die Backend-Anwendung weiterleitet. Dadurch können Anwendungen problemlos in eine OAuth 2.0-Single-Sign-on-Umgebung (SSO) eingebunden werden, indem die Tokenvalidierung an NGINX Plus ausgelagert und die Benutzeridentität aus HTTP-Headern ausgelesen wird.

NGINX Plus R10 und höher können die in der JWT-Spezifikation definierten Felder prüfen. NGINX Plus R12 erweitert die JWT-Unterstützung, sodass auf jedes Feld in einem JWT (einschließlich benutzerdefinierter Felder) als NGINX-Variable zugegriffen werden kann und es somit für Proxying, Protokollierung oder Autorisierungsentscheidungen verwendet werden kann.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf Release 12 durchzuführen. Damit erhalten Sie zahlreiche 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 beachten Sie die oben beschriebenen Verhaltensänderungen, 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 einer API für erweiterte Überwachung und Konfigurationsverwaltung zu testen. Sie können noch heute kostenlos mit einer 30-tägigen Testversion beginnen und sich selbst davon überzeugen, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.