Einführung dynamischer Module in NGINX 1.9.11

Heute haben wir die Open Source -Version 1.9.11 von NGINX veröffentlicht, mit einer neuen Funktion, die unserer Meinung nach große Auswirkungen auf Ihre Verwendung von NGINX und NGINX Plus haben wird: dynamische Module . Mit dynamischen Modulen können Sie optional separate gemeinsam genutzte Objektdateien zur Laufzeit als Module laden – sowohl Module von Drittanbietern als auch einige native NGINX-Module. Die neue Implementierung gewährleistet soweit wie möglich die Abwärtskompatibilität mit der Modul-API.

Editor – In NGINX 1.11.5 und höher (und NGINX Plus R11 und höher) können Sie dynamische Module kompilieren, ohne auch die vollständige NGINX-Binärdatei zu kompilieren. Anweisungen finden Sie unter „Kompilieren dynamischer Module für NGINX Plus“ .

Die nächste NGINX Plus-Version (NGINX Plus R9) wird auf dieser Funktion dynamischer Module aufbauen. Wir planen, ein verwaltetes NGINX-Modul-Repository mit einer Reihe von Drittanbietermodulen einzurichten, die wir für NGINX Plus getestet und zertifiziert haben. So können Sie gängige Erweiterungen einfacher und sicherer zu NGINX Plus hinzufügen. Wenn Sie Ihre Open Source- oder kommerziellen Module in unser Repository aufnehmen möchten, kontaktieren Sie uns bitte über den Link „Vertrieb kontaktieren“ .

Wenn Sie bisher ein Modul für NGINX erstellen wollten, mussten Sie es zusammen mit dem NGINX-Quellcode in eine NGINX-Binärdatei kompilieren. Das Modul wurde jedes Mal mit NGINX geladen, ob Sie es wollten oder nicht. Für Paketierer von Betriebssystemdistributionen war es dadurch sehr schwierig, für jeden Benutzer benutzerdefinierte NGINX-Binärdateien zu erstellen.

In der ersten Version dynamischer Module müssen Sie die optionalen NGINX-Module noch gleichzeitig mit der NGINX-Binärdatei kompilieren, Sie erstellen jedoch auch für jedes dynamisch geladene Modul ein separates gemeinsam genutztes Objekt und verwenden eine Direktive in der NGINX-Konfigurationsdatei, um das Laden des gemeinsam genutzten Objekts zur Laufzeit zu aktivieren und zu deaktivieren.

Dynamisches Laden von NGINX-Modulen

In der ersten Version können die folgenden NGINX-Module und Modulpakete dynamisch erstellt werden:

• GeoIP ( ngx_http_geoip_module )
• Bildfilter ( ngx_http_image_filter_module )
• Mail (umfasst alle Mail-Module: ngx_mail_{ core , auth , imap , pop3 , proxy , smtp , ssl }_module )
• Stream (umfasst alle Stream-Module: ngx_stream_{ core , access , limit_conn , proxy , ssl , upstream }_modul e)
• XSLT ( ngx_http_xslt_module )

Um die dynamisch ladbaren gemeinsam genutzten Objekte zu generieren, hängen Sie =dynamic an das Standardmodulargument --with_ an :

# ./Konfigurieren --with-http_geoip_module=dynamisch --with-http_image_filter_module=dynamisch --with-mail=dynamisch --with-stream=dynamisch --with-http_xslt_module=dynamisch

Wenn Sie den Quellcode von NGINX 1.9.11 installieren, gibt es ein neues Unterverzeichnis namens „Module“ , und der Build-Prozess platziert die binären gemeinsam genutzten Objekte dort. Standardmäßig lautet der Pfad /usr/local/nginx/modules .

Um ein Modul zur Laufzeit zu laden, schließen Sie die neue Direktive load_module in den Hauptkontext ein und geben Sie den Pfad zur gemeinsam genutzten Objektdatei für das Modul in Anführungszeichen an. Wenn Sie die Konfiguration neu laden oder NGINX neu starten, wird das dynamische Modul geladen. Sie können einen Pfad relativ zum Quellverzeichnis angeben, wie in diesen Beispielen, oder einen vollständigen Pfad.

lademodul "modules/ngx_http_geoip_module.so";lademodul "modules/ngx_stream_module.so";

Um ein Modul dynamisch zu „entladen“, kommentieren Sie seine load_module- Direktive aus oder entfernen Sie sie und laden Sie die NGINX-Konfiguration neu. Wenn sich andere Anweisungen in der Datei auf das Modul beziehen, das Sie entladen, denken Sie daran, diese ebenfalls auszukommentieren oder zu entfernen.

Konvertieren von Drittanbietermodulen

Für Entwickler vieler herkömmlicher Module von Drittanbietern ist die Umstellung auf dynamisches Laden mit sehr geringem Aufwand verbunden. In vielen Fällen müssen Sie nur die Konfigurationsdatei für Ihren Modulquellcode bearbeiten. Andere Module erfordern etwas mehr Arbeit. Das NGINX-Wiki enthält einen Leitfaden zur Modulkonvertierung und detaillierte Informationen zum Format der Quellkonfigurationsdatei des Moduls .

Um ein konvertiertes Drittanbietermodul zu kompilieren, verwenden Sie das neue Argument --add-dynamic-module und geben Sie den Pfad an:

# ./configure --add-dynamic-module= /Pfad/zur/Modulquelle

Wie bei NGINX-Modulen wird ein gemeinsam genutztes Objekt erstellt und im Unterverzeichnis „Module“ installiert, und Sie fügen der NGINX-Konfiguration eine load_module -Direktive dafür hinzu. Unser Developer-Relations-Team steht Ihnen bei der Konvertierung eines Moduls zur Seite. Kontaktieren Sie uns über die NGINX-Entwicklungs-Mailingliste .

Die Zukunft dynamischer Module

In zukünftigen Versionen planen wir, die Möglichkeit hinzuzufügen, Module zu kompilieren, nachdem die NGINX-Binärdatei kompiliert wurde. Wir sind außerdem dabei, die Modul-API zu dokumentieren. Sobald diese Dokumentation fertig ist, wird sie kostenlos im NGINX-Wiki verfügbar sein.

Um dynamische Module selbst auszuprobieren, laden Sie NGINX 1.9.11 herunter .

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.