BLOG | NGINX

Ankündigung von NGINX Plus R12

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Owen Garrett Miniaturbild
Owen Garrett
Veröffentlicht am 14. März 2017

[Editor – Dieser Beitrag wurde aktualisiert, um auf die NGINX Plus API zu verweisen, die die separaten dynamischen Konfigurations- und Statusmodule ersetzt und veraltet, die in der Originalversion des Beitrags besprochen wurden.]

Wir freuen uns, heute bekannt geben zu können, dass NGINX Plus R12 als kostenloses Upgrade für alle NGINX Plus-Abonnenten verfügbar ist. NGINX Plus ist eine leistungsstarke Bereitstellungsplattform für Softwareanwendungen, die einen Load Balancer, einen Inhaltscache und einen Webserver umfasst. NGINX Plus R12 ist eine wichtige Version mit neuen Funktionen mit Schwerpunkt auf Clustering, Anpassung und Überwachung.

Um mehr über NGINX Plus R12 zu erfahren, sehen Sie sich unser On-Demand-Webinar an.

Unternehmensbenutzer profitieren von der neuen Clusterfunktion, die die Verwaltung hochverfügbarer Cluster von NGINX Plus-Servern vereinfacht. Alle Benutzer profitieren von der offiziellen Unterstützung für nginScript, einer leichten und leistungsstarken Skriptsprache, die direkt in die NGINX-Konfiguration eingebettet ist. Verbesserungen bei der Überwachung und Instrumentierung, beim Caching und bei Integritätsprüfungen verbessern die Zuverlässigkeit und Leistung von Anwendungen.

Weitere Erweiterungen umfassen die Client-Zertifikatauthentifizierung für TCP-Dienste, die Möglichkeit zur Überprüfung benutzerdefinierter Felder in OAuth-JWTs, 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. Bevor Sie das Update durchführen, überprüfen Sie 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 Komponenten von NGINX Plus ein, die Sie beim Upgrade beachten müssen:

  • Cache-Metadatenformat – Das Format des internen Cache-Metadatenheaders hat sich geändert. Wenn Sie auf NGINX Plus R12 aktualisieren, wird der On-Disk-Cache ungültig und NGINX Plus aktualisiert den Cache bei Bedarf automatisch. Alte Cacheeinträge werden automatisch gelöscht.
  • SSL-„DN“-Variablen – Das Format der Variablen $ssl_client_s_dn und $ssl_client_i_dn hat sich geändert. Als Feldtrennzeichen dient jetzt das Komma ( , ) anstelle des Schrägstrichs ( / ) und wird gemäß RFCs maskiert.2253 Und4514 . Um weiterhin das Format X509_NAME_oneline mit dem Feldtrenner „Schrägstrich“ zu verwenden, verwenden Sie die Variablen $ssl_client_s_dn_legacy und $ssl_client_i_dn_legacy .
  • Warteschlange mit maximaler Verbindung – Die Warteschlangendirektive weist NGINX Plus an, Verbindungen zu Upstream-Servern in die Warteschlange zu stellen, wenn diese überlastet sind. Als Folge der Speicher- und Leistungsoptimierungen in R12 muss die Warteschlangendirektive jetzt im Upstream- Block unter der Direktive erscheinen, die den Lastausgleichsalgorithmus angibt ( hash , ip_hash , least_conn oder least_time ).
  • Dynamische Module von Drittanbietern – In unserem Repository werden von NGINX, Inc. erstellte oder zertifizierte dynamische Module bereitgestellt. Alle Module von Drittanbietern müssen mit NGINX Open Source Version 1.11.10 neu kompiliert werden, um weiterhin mit NGINX Plus R12 zu funktionieren. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch .
  • Letzte Veröffentlichung für veraltete Betriebssystemversionen – Ubuntu hat das Ende des Lebenszyklus für Ubuntu 12.04 LTS angekündigt und Red Hat hat das Ende des Lebenszyklus für den Produktionsphasen-Support von Red Hat Enterprise Linux 5.10+ angekündigt. Beide Versionen treten mit Wirkung zum 31. März 2017 in Kraft. NGINX Plus R12 ist die letzte Version, die Pakete für diese Betriebssystemversionen sowie für CentOS 5.10+ und Oracle Linux 5.10+ enthält und diese unterstützt. Um nach NGINX Plus R12 weiterhin Updates und Support zu erhalten, aktualisieren Sie auf eine unterstützte Betriebssystemversion.

NGINX Plus R12-Funktionen im Detail

Gemeinsame Nutzung von Konfigurationen

NGINX Plus-Server werden aus Gründen der Hochverfügbarkeit und Skalierbarkeit häufig in einem Cluster mit zwei oder mehr Instanzen eingesetzt. Auf diese Weise können Sie die Zuverlässigkeit Ihrer Dienste verbessern, indem Sie sie vor den Auswirkungen von Serverausfällen schützen. Darüber hinaus können Sie große Datenmengen skalieren und verarbeiten.

NGINX Plus bietet bereits eine unterstützte Möglichkeit, den Datenverkehr entweder aktiv/passiv oder aktiv/aktiv über einen Cluster zu verteilen. NGINX Plus R12 fügt eine weitere unterstützte Methode zur Synchronisierung der Konfiguration über einen Cluster hinweg hinzu. Mit dieser Konfigurationssynchronisierungsfunktion kann ein Administrator einen „Cluster“ von NGINX Plus-Servern von einem einzigen Standort aus konfigurieren. Diese Server nutzen eine gemeinsame Teilmenge ihrer Konfiguration.

Die NGINX Plus-Konfiguration wird vom Primärserver an die Peers übertragen.

So synchronisieren Sie die Konfiguration:

  1. Nominieren Sie einen oder mehrere „primäre“ Knoten im Cluster.
  2. Installieren Sie das neue nginx-sync- Paket auf den primären Knoten.
  3. Wenden Sie Konfigurationsänderungen auf einen primären Knoten an.

  4. Rufen Sie den Konfigurationssynchronisierungsprozess nginx-sync.sh auf, der im Paket nginx-sync enthalten ist, um alle anderen Server im Cluster (die Peers ) zu aktualisieren. Der Synchronisierungsvorgang führt auf jedem Peer diese 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 führt andernfalls ein Rollback durch.
    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 in einem fehlertoleranten Serverpaar (oder einer größeren Anzahl) bereitgestellt wird. Mit dieser Methode können Sie die zuverlässige Bereitstellung einer Konfiguration innerhalb eines Clusters vereinfachen oder eine Konfiguration 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 die Namen synonym verwendet.] nginScript wird für NGINX Plus-Abonnenten 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. Es ermöglicht Ihnen, die NGINX Plus-Konfigurationssyntax mit JavaScript-Code zu erweitern, um anspruchsvolle Konfigurationslösungen zu implementieren.

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

Insbesondere enthält NGINX Plus R12 die folgenden Verbesserungen :

  • Preread-Phase im Stream-Modul
  • ECMAScript 6 Mathematische Methoden und Konstanten
  • Zusätzliche String-Methoden wie endsWith , includes , repeat , startsWith und trim
  • Bereiche

Obwohl nginScript stabil ist, wird weiterhin an der Unterstützung noch weiterer Anwendungsfälle und der Abdeckung der JavaScript-Sprache gearbeitet. Weitere Informationen finden Sie in unserem Blog unter „Nutzen Sie die Leistung und den Komfort von JavaScript für jede Anforderung mit dem NGINX JavaScript-Modul<.htmla>“.

Neue Statistiken

Die Überwachung und Instrumentierung in NGINX Plus ist ein wichtiger Mehrwert, der Ihnen tiefe Einblicke in die Leistung und das Verhalten sowohl von NGINX Plus als auch von Upstream-Anwendungen gibt. Statistiken werden sowohl über unser integriertes grafisches Dashboard als auch im JSON-Format bereitgestellt, das in Ihr bevorzugtes Überwachungstool exportiert werden kann.

Das NGINX Plus Live-Aktivitätsüberwachungs-Dashboard mit Updates für Release 12
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 (Reaktionszeit) von Servern mit Lastenausgleich, Einblicke in den Betrieb von TCP- und UDP-Diensten und eine Reihe interner Daten, die bei der Fehlerbehebung zur Identifizierung von Problemen und bei der Feinabstimmung von NGINX Plus zur Optimierung der Leistung hilfreich sind.

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

  • Antwortzeit des Upstreamservers – In NGINX Plus R11 und früheren Versionen wurde die Antwortzeit von Upstreamservern nur berechnet, wenn der Least Time-Lastausgleichsalgorithmus verwendet wurde. Ab NGINX Plus R12 wird die Reaktionszeit für alle Algorithmen gemessen und sowohl in den JSON-Daten als auch auf dem integrierten Dashboard gemeldet.
  • Antwortcodes für TCP/UDP-Upstreams im grafischen Dashboard – Das Stream-Modul für TCP/UDP-Load-Balancing generiert Pseudostatuscodes, um zu identifizieren, wie eine Verbindung geschlossen wurde (200 bedeutet „Erfolg“,502 bedeutet „Upstream nicht verfügbar“ usw.) und meldet diese in der Variable „$status“ . NGINX Plus R12 fügt dem Dashboard eine Reihe von Spalten hinzu, um die Anzahl der Antwortcodes für virtuelle TCP- und UDP-Server anzuzeigen, wie sie bereits für virtuelle HTTP-Server bereitgestellt werden. Die Pseudostatuscodes können zur Integration in vorhandene Protokollanalysetools auch protokolliert werden.
  • NGINX Plus-Versionsinformationen – Um bei der Fehlerbehebung zu helfen, melden die JSON-Daten jetzt die NGINX Plus-Versionsnummer als nginx_build (z. B. nginx-plus-r12 ) sowie die NGINX Open Source-Versionsnummer als nginx_version (z. B.1.11.10 ). Das Dashboard zeigt beide Werte im oberen linken Feld auf der Hauptregisterkarte an.

  • Upstream-Hostname – In den JSON-Daten identifiziert das Serverfeld einen Server in einer Upstream-Gruppe anhand der IP-Adresse und des Ports. Das neue Namensfeld meldet den ersten Parameter an die Serverdirektive im Upstream- Konfigurationsblock. Dabei kann es sich um einen Domänennamen oder einen UNIX-Domänen-Socket-Pfad sowie eine IP-Adresse und einen Port handeln. Auf dem Dashboard meldet die Spalte „Name“ ganz links auf den Registerkarten „Upstreams“ und „TCP/UDP-Upstreams“ jetzt den Wert aus dem Namensfeld und nicht mehr aus dem Serverfeld (was in NGINX Plus R11 und früher gemeldet wurde).

    Die neue Metrik erleichtert die Korrelation der JSON-Daten und des Dashboards mit Ihren Upstream-Servern, wenn Sie sie mithilfe von DNS-Namen definieren, insbesondere Namen, die in mehrere IP-Adressen aufgelöst werden.

  • Nutzung gemeinsam genutzter Speicherzonen in erweiterten Statusdaten – Gemeinsam genutzte Speicherzonen werden mit einer festen Größe konfiguriert und es kann schwierig sein, eine Größe auszuwählen, die weder zu groß (Speicher wird zugewiesen, aber nie verwendet) noch zu klein (Speicher ist erschöpft und zwischengespeicherte Elemente werden verworfen) ist.

    Neue Instrumente in den Metriken bieten einen detaillierten internen Bericht über die Speichernutzung jeder gemeinsam genutzten Zone. So können Sie die Speichernutzung überwachen und der technische Support von NGINX kann Ihnen fundiertere Ratschläge zur Optimierung der NGINX-Konfiguration geben.

  • JSON-konformes Escapen im NGINX Plus-Zugriffsprotokoll – Einige moderne Protokollanalysetools können Protokolldateien im JSON-Format effizient aufnehmen und leichter Erkenntnisse daraus ziehen als aus unformatierten Protokolldateien. Sie können eine JSON-Vorlage in der standardmäßigen NGINX Plus-Direktive „log_format“ definieren, und der neue optionale Escape- Parameter der Direktive erzwingt JSON-konformes Escapen, sodass Protokollzeilen korrekt formatiert werden.

Weitere Informationen finden Sie unter Live-Aktivitätsüberwachung .

Verbessertes Caching

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

Während der Aktualisierung veraltete Inhalte bereitstellen

NGINX Plus R12 fügt Unterstützung für die in RFC 5861 definierten Cache-Control- Erweiterungen stale-while-revalidate und stale-if-error hinzu. Sie können NGINX Plus jetzt so konfigurieren, dass diese Cache-Control- Erweiterungen berücksichtigt werden und abgelaufene Ressourcen weiterhin aus dem Cache bereitgestellt werden, während sie im Hintergrund aktualisiert werden, ohne der Client-Anforderung Latenz hinzuzufügen. 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 es nicht so konfiguriert ist, dass der Cache-Control- Header ignoriert wird, beachtet NGINX Plus die veralteten Timer von Ursprungsservern, die RFC 5861-kompatible Cache-Control- Header zurückgeben, wie in diesem Beispiel:

Cache-Steuerung: maximales Alter = 3600, veraltet während der erneuten Validierung = 120, veraltet bei Fehler = 900

Um die Unterstützung für die Cache-Control- Erweiterungen mit Hintergrundaktualisierung zu aktivieren, schließen Sie die hervorgehobenen Anweisungen ein:

proxy_cache_path /Pfad/zum/Cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; # Beim Update veralteten Inhalt bereitstellen proxy_cache_use_stale updating ; # Außerdem nicht die erste Anfrage blockieren, die das Update auslöst # und das Update im Hintergrund durchführen proxy_cache_background_update on ; proxy_pass http://my_upstream; } }

Die Aktualisierungsanweisung proxy_cache_use_stale weist NGINX Plus an, während der Aktualisierung die veraltete Version des Inhalts bereitzustellen. Wenn Sie nur diese Anweisung einschließen, muss der erste Benutzer, der veraltete Inhalte anfordert, die „Cache-Miss“-Strafe zahlen – das heißt, er erhält die Inhalte erst, wenn NGINX Plus sie vom Ursprungsserver abgerufen und zwischengespeichert hat. Benutzer, die den veralteten Inhalt anschließend während der Aktualisierung anfordern, erhalten ihn sofort aus dem Cache, während der erste Benutzer nichts erhält, bis der aktualisierte Inhalt abgerufen und zwischengespeichert wurde.

Mit der neuen Direktive proxy_cache_background_update wird allen Benutzern, einschließlich dem ersten Benutzer, 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 für Byte-Bereichsanforderungen zu umgehen, die mehr als eine konfigurierte Anzahl von Bytes nach dem Start einer nicht zwischengespeicherten Datei beginnen. Dies bedeutet, dass bei großen Dateien, wie etwa Videoinhalten, Anforderungen für einen Bytebereich tief in der Datei keine zusätzliche Latenz für die Clientanforderung verursachen. In früheren Versionen von NGINX Plus erhielt der Client den angeforderten Bytebereich erst, wenn NGINX Plus den gesamten Inhalt vom Anfang der Datei bis zum angeforderten Bytebereich abgerufen und in den Cache geschrieben hatte.

Die neue Direktive proxy_cache_max_range_offset gibt den Offset vom Anfang der Datei an, nach dem NGINX Plus eine Byte-Range-Anforderung 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 /Pfad/zum/Cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { location / { proxy_cache my_cache; # Cache für Byte-Bereichsanforderungen über 10 Megabyte umgehen proxy_cache_max_range_offset 10m ; proxy_pass http://my_upstream; } }

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

Verbesserte Gesundheitschecks

NGINX Plus R12 verbessert die aktiven Integritätsprüfungsfunktionen von NGINX Plus weiter.

Integritätsprüfung neu hinzugefügter Server

Angesichts der zunehmenden Verbreitung von Containerumgebungen und automatisch skalierten Anwendungsgruppen ist es wichtig, dass der Load Balancer proaktive Integritätsprüfungen auf Anwendungsebene durchführt und neuen Servern Zeit gibt, interne Ressourcen zu initialisieren, bevor sie hochgefahren werden.

Wenn Sie vor NGINX Plus R12 einen neuen Server zum Lastausgleichspool hinzugefügt haben (mithilfe der NGINX Plus-API oder des DNS), hat NGINX Plus diesen sofort als fehlerfrei betrachtet und sofort Datenverkehr dorthin gesendet. Wenn Sie den neuen obligatorischen Parameter in die Direktive health_check ( HTTP oder TCP/UDP ) aufnehmen, muss der neue Server die konfigurierte Integritätsprüfung bestehen, bevor NGINX Plus Datenverkehr an ihn sendet. In Kombination mit der Slow-Start- Funktion gibt der neue Parameter neuen Servern noch mehr Zeit, sich mit Datenbanken zu verbinden und „aufzuwärmen“, bevor sie aufgefordert werden, ihren gesamten Verkehrsanteil zu bewältigen.

upstream my_upstream { zone my_upstream 64k; server backend1.example.com slow_start=30s ; } server { location / { proxy_pass http://my_upstream; # Neuer Server muss Integritätsprüfung bestehen, bevor er Datenverkehr empfängt health_check obligatorisch ; } }

Hier werden sowohl die obligatorischen Parameter zur health_check- Direktive als auch der slow_start- Parameter zur Server- Direktive ( HTTP oder TCP/UDP ) eingefügt. Server, die über die API- oder DNS-Schnittstellen zur Upstream-Gruppe hinzugefügt werden, werden als fehlerhaft markiert und empfangen keinen Datenverkehr, bis sie die Integritätsprüfung bestehen. Ab diesem Zeitpunkt beginnt die Datenverkehrsmenge über einen Zeitraum von 30 Sekunden allmählich zuzunehmen.

UDP-Integritätsprüfung ohne Konfiguration

Es ist ebenso wichtig, Integritätsprüfungen auf Anwendungsebene für UDP-Server wie für HTTP- und TCP-Server zu implementieren, damit kein Produktionsverkehr an Server gesendet wird, die nicht voll funktionsfähig sind. NGINX Plus unterstützt aktive Integritätsprüfungen für UDP, aber vor NGINX Plus R12 mussten Sie einen Match -Block erstellen, der die zu sendenden Daten und die zu erwartende Antwort definierte. Bei der Verwendung binärer Protokolle oder solcher mit komplexen Handshakes kann es schwierig sein, die richtigen Werte zu bestimmen. Für solche Anwendungen unterstützt NGINX Plus R12 jetzt eine „Zero Config“-Integritätsprüfung für UDP, die die Anwendungsverfügbarkeit testet, ohne dass Sie Sende- und Erwartungszeichenfolgen definieren müssen. Fügen Sie der Direktive health_check den Parameter udp für eine grundlegende UDP-Integritätsprüfung hinzu.

upstream udp_app { server backend1.example.com:1234; server backend2.example.com:1234; } server { listen 1234 udp; proxy_pass udp_app; # Grundlegende UDP-Integritätsprüfung health_check udp ; }

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

SSL-Client-Zertifikate werden häufig verwendet, um Benutzer gegenüber geschützten Websites zu authentifizieren. NGINX Plus R12 fügt der vorhandenen HTTP-Unterstützung Authentifizierungsunterstützung für SSL-geschützte TCP-Dienste hinzu. Dies wird im Gegensatz zur Endbenutzeranmeldung normalerweise für die Maschine-zu-Maschine-Authentifizierung verwendet und ermöglicht Ihnen, NGINX Plus sowohl für die SSL-Terminierung als auch für die Client-Authentifizierung beim Lastenausgleich von Layer-4-Protokollen zu verwenden. Beispiele hierfür sind die Authentifizierung von IoT-Geräten für die Kommunikation mit dem MQTT-Protokoll.

Die Variable $ssl_client_verify enthält jetzt zusätzliche Informationen zu fehlgeschlagenen Client-Authentifizierungsereignissen. Hierzu zählen etwa „widerrufene“ oder „abgelaufene“ Zertifikate.

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

Erweiterte JWT-Validierung

NGINX Plus R10 führte native JSON Web Token (JWT)-Unterstützung für OAuth 2.0- und OpenID Connect -Anwendungsfälle ein. Einer der primären Anwendungsfälle besteht darin, dass NGINX Plus ein JWT validiert, die darin enthaltenen Felder überprüft und sie als HTTP-Header an die Back-End-Anwendung übergibt. Auf diese Weise können Anwendungen problemlos an einer OAuth 2.0-Single-Sign-On-Umgebung (SSO) teilnehmen, indem die Token-Validierung auf NGINX Plus ausgelagert und die Benutzeridentität durch das Lesen von HTTP-Headern genutzt wird.

NGINX Plus R10 und höher können die in der JWT-Spezifikation definierten Felder überprü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 als Proxy verwendet, protokolliert oder zum Treffen von Autorisierungsentscheidungen verwendet werden kann.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 12 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und können uns so dabei helfen, Ihnen zu helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen 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 erweitertes Monitoring und Konfigurationsmanagement 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.

Weitere Blogbeiträge zu F5 NGINX lesen ›

„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."