NGINX veröffentlicht die Versionen NGINX Unit 1.23.0 und 1.24.0. NGINX Unit gehört neben NGINX Plus, NGINX App Protect, NGINX Controller und NGINX Amplify zum Portfolio der NGINX Reihe und basiert auf der Open-Source-Software.
Unter anderem sind in dem neuesten Release folgende Funktionen:
TLS: SNI- und Konfigurationsbefehle
Die erste Veränderung dreht sich um die Implementierung des TLS-Protokolls. Version 1.23.0 führt eine Unterstützung für die Server Name Indication (SNI)- Erweiterung für TLS ein und bietet damit eine unkomplizierte Möglichkeit, Zertifikate zwischen mehreren Standorten und Domänen zuzuordnen, die über eine einzige NGINX Unit Bereitstellung aus bedient werden können.
In Version 1.4.0 wurde die Unterstützung für TLS hinzugefügt und folgendes war möglich: Das bündeln von Zertifikatsketten, die über die Kontroll-API hochgeladen wurden und anschließend als Bündel den Hörern zugwiesen wurden. Soweit so gut, dennoch hatte die Zuordnung zwischen Bündel und Hörer ihre Grenzen. Durch das Update ist es möglich, ein Array von Bündel in einem einzelnen Listener anzugeben.
{
"*:80": {
"pass": "routes",
"tls": {
"certificate": [
"bundleA",
"bundleB",
"bundleC"
]
}
}
}
NGINX Unit trifft für jede eingehende Anfrage die am besten geeignete Wahl, indem die gemeinsamen und alternativen Namen der Zertifikate in jedem Paket verwendet werden. Wenn der Client einen Servernamen angibt, antwortet NGINX Unit mit einem Zertifikat aus dem entsprechenden Paket. Wenn der Namen mit mehreren Bündel übereinstimmt, haben genaue Übereinstimmungen Vorrang vor Platzhaltern, bspw. *.example.com. Bei Unklarheiten sowie im Falle keiner Übereinstimmung oder keinem Servernamen, verwendet NGINX Unit das erste Paket auf der Liste.
Schließlich werden diejenigen, die mit NGINX ssl_conf_commandund ssl_ciphersDirektiven vertraut sind, sich wahrscheinlich darüber freuen, dass die NGINX Unit jetzt auch die Bereitstellung eines Satzes von OpenSSL-Konfigurationsbefehlen pro Listener ermöglicht:
{
"tls": {
"certificate": "bundle",
"conf_commands": {
"ciphersuites": "TLS_AES_128_GCM_SHA2566",
"minprotocol": "TLSv1.3"
}
}
}
Statischer Inhalt: MIME-Filterung
Die Fähigkeit von NGINX Unit im Umgang mit Inhalten wurde in der Version 1.24.0 maßgeblich verbessert. Die von NGINX Unit unterstützten integrierten und anpassbaren MIME-Typen können jetzt in Ihren Routing Schemata verwendet werden. So einfach das auch erscheinen mag, es räumt Routing-Schemata auf, die eine statische Inhaltsfreigabe beinhalten. Betrachten Sie diesen routeTeil:
{
"share": "/www/data/",
"types": [
"!application/x-httpd-php"
],
"fallback": {
"pass": "applications/php"
}
}
Hier trennen wir statische Inhalte effektiv von .php- Skripten in einer einzigen share Aktion und erreichen, was zuvor zwei verschiedene Routenschritte erforderte.
Das types Array unterstützt den gleichen Mustermechanismus , den auch die Routenbedingungen verwenden, sodass wir die von NGINX bereitgestellten statischen Inhaltstypen mit etwas Tricks einschränken können. Wenn die NGINX-Unit den MIME-Typ einer angeforderten Datei nicht ableiten kann, betrachtet sie den Typ als leer. Daher kann Unit so konfiguriert werden, dass nur Dateien bereitgestellt werden, deren MIME-Typen es erkennt, indem die negierte leere Zeichenfolge ( "!") – was bedeutet, dass keine Dateien mit leeren MIME-Typen bereitgestellt werden – in das typesArray eingeschlossen wird :
{
"share": "/www/data/known-types-only/",
"types": [
"!"
]
}
Zu beachten ist, dass auch benutzerdefinierte MIME-Typen definiert werden können, um zu steuern, welche Dateitypen von Unit bereitgestellt werden. In diesem Beispiel wird der Satz von Dateinamen und Erweiterungen mit dem Typ text/plain definiert, den Unit erkennt und im types Array verwendet:
{
"settings": {
"http": {
"static": {
"mime_types": {
"text/plain": [
".log",
"README",
"CHANGES"
]
}
}
}
}
}
Dies zeigt, wie die globale mime_types Option verwenden werden kann, um die Funktionen der typesOption über die integrierten Funktionen hinaus zu erweitern und sie an Ihre Routing-Zwecke anzupassen.
Statischer Inhalt: Chrooting und Pfadbeschränkungen
NGINX Unit 1.24.0 führt drei neue Optionen zur Feinabstimmung der Art und Weise ein, wie Unit statische Inhalte auf Servern bereitstellt, auf denen Linux-Kernel Version 5.6 und höher ausgeführt wird. Sie sollen einen versehentlichen oder vorsätzlichen Missbrauch der Mechanismen von NGINX-Unit für die Bereitstellung statischer Inhalte verhindern. Die erste Option ist chroot:
{
"action": {
"share": "/www/data/static/",
"chroot": "/www/data/"
}
}
Diese Option legt das Stammverzeichnis für die Pfadnamenauflösung innerhalb des von der share Option benannten Verzeichnisses fest. Ein bemerkenswerter Effekt ist, dass symbolische Links zu absoluten Pfadnamen innerhalb des share Verzeichnisses relativ zum neuen Root behandelt werden. Wenn beispielsweise in der obigen Konfiguration ein symbolischen Link in /www/data/static/ zu /log/app.log erstellt wird, wird dieser als /www/data/log/app.log aufgelöst. Beachtet werden muss jedoch, dass die Behandlung symbolischer Links auch von der Einstellung der follow_symlinks Option beeinflusst wird, die im Folgenden erläutert wird.
Die beiden verbleibenden Optionen follow_symlinksund traverse_mountssteuern die Einstellung der NGINX-Unit zu symbolischen Links und Mount-Punkten:
{
"action": {
"share": "/www/data/static/",
"follow_symlinks": false,
"traverse_mounts": false
}
}
Wenn diese Optionen auf false gesetzt sind (der Standardwert ist true), schlagen Anfragen fehl, wenn sie die Auflösung eines symbolischen Links oder Mount-Punkts innerhalb des share Verzeichnisses erfordern (hier /www/data/static/ ); Die Unit ist innerhalb der Grenzen des share Verzeichnisses effektiv gesperrt .
Die Interaktion chroot mit follow_symlinks und traverse_mounts kann etwas kompliziert sein, also nehmen wir uns einen Moment Zeit, um die zusammengeführte Konfiguration zu betrachten:
{
"action": {
"share": "/www/data/static/",
"chroot": "/www/data/",
"follow_symlinks": false,
"traverse_mounts": false
}
}
Wenn chroot gesetzt ist, wirken sich die Werte von follow_symlinks und traverse_mounts nur auf Teile des Pfads nach der neuen Wurzel aus. Dies bedeutet, dass Unterverzeichnisse, die Teil des chroot-Pfads sind (hier www/ und data/ ), symbolische Links oder Mount-Punkte sein können, aber alle symbolischen Links oder Mount-Punkte jenseits des letzten Elements im chroot Pfad (hier, einschließlich statischer/ ) werden nicht aufgelöst.
Node.js Überschreibung
Erfreulicherweise ist es nicht mehr notwendig für Node.js®-Apps Codeänderungen vorzunehmen, um in NGINX Unit zu laufen. Dies wird mit einem neuen Loader-Modul ( unit-http/loader.mjs ) erreicht, das beim Start der Anwendung hinter den Kulissen arbeitet und alle notwendigen Grundlagen für eine wirklich serverunabhängige App legt:
{
"type": "external",
"executable": "/usr/bin/env",
"arguments": [
"node",
"--loader",
"unit-http/loader.mjs",
"--require",
"unit-http/loader",
"app.js"
]
}
Python Ziele
NGINX Unit 1.24.0 erweitert auf Python-Apps die Granularität, die zuvor nur PHP-Apps gewährt wurde. Mehrere Skripte können in einer einzigen App konfiguriert werden, um Ihr Routing und die Anwendungseinrichtung zu vereinfachen:
{
"applications": {
"python-app": {
"type": "python",
"targets": {
"foo": {
"module": "foo.wsgi",
"callable": "foo"
},
"bar": {
"module": "bar.wsgi",
"callable": "bar"
}
}
}
}
}
In diesem Beispiel werden zwei Module foo/wsgi.py und bar/wsgi.py in den Kontext einer einzelnen App und ihrer Prozesse gestellt, wodurch Systemressourcen geschont werden, die ansonsten durch die Ausführung mehrerer Skripts verbraucht werden, die eine einzelne App umfassen. An anderer Stelle in der Konfiguration können Anforderungen an diese Teile Ihrer App ganz unabhängig weitergeben werden:
{
"listeners": {
"127.0.0.1:8080": {
"pass": "applications/python-app/foo"
}
...
},
"routes": [
...
{
"action": {
"pass": "applications/python-app/bar"
}
}
]
}
Weitere ausführliche Informationen zum neuen NGINX Unit Update sind im offiziellen Beitrag zu finden.