Nginx
nginx {en} (gesprochen „engine x”) ist ein Webserver, der im Vergleich zu [:Apache:] (oder auch [wikipedia:Microsoft_Internet_Information_Services:IIS]) weniger Resourcen verbraucht und schnell ist
- Aufgrund seiner eingebauten [wikipedia:Reverse_Proxy:Reverse-Proxy Funktionalität] wird nginx auch gerne als vorgeschalteter Webserver für dahinter liegende Applikationsserver genutzt
nginx wird laut w3techs.com Statistik {en} von ca. 40% aller Websites genutzt (Stand: September 2017)
- Damit ist nginx der am zweithäufigsten eingesetzte Webserver
Neben der freien Version von nginx, welche auch unter eine freien Lizenz {en} steht, gibt es auch eine kostenpflichtige Variante namens nginx Plus {en}, für den die Firma nginx Inc. zusätzlichen Support und Module anbietet
Installation
sudo apt install nginx
Konfiguration
Alle Konfigurationsdateien von nginx liegen im Verzeichnis /etc/nginx/, die Grundkonfigurationsdatei ist nginx.conf
- Diese besteht aus den Sektionen `events { [...] }` und `http { [...] }`
- Kommentiert wird mit einer Raute (`#`)
- Jede Konfigurationszeile muss mit einem Semikolon `;` abgeschlossen werden
In dieser Datei kann z. B. fest gelegt werden, mit welchen Rechten nginx läuft, in welche Dateien geloggt wird und auch die Verwendung von SSL kann hier konfiguriert werden
Innerhalb der `http`-Sektionen können auch ein oder mehrere Sektionen `server { [...] }` angelegt werden, was im Kontext von nginx einem "virtuellen Server" entspricht (was das äquivalent zu "virtual hosts" beim Apache Server ist)
- In den `server` Sektionen erfolgt die Konfiguration von z. B. DocumentRoot, auf welcher IP-Adresse und auf welchem Port nginx lauscht, die Namensauflösung etc
Es muss mindestens eine `server` Sektion vorhanden sein
- Es können aber auch ohne weiteres mehrere Sektion aufgeführt werden
- nginx arbeitet die `server` Sektionen von oben nach unten ab
- Treffen die Bedingungen in der Sektion auf die Anfrage zu, werden die entsprechenden Daten ausgeliefert
- Bei komplexen Konfigurationen sollte man deshalb auf die Reihenfolge der verschiedenen `server` Sektionen achten
Standardmäßig werden diese Daten in einer oder mehreren Dateien im Verzeichnis /etc/nginx/sites-available abgelegt und aktiviert
- Das Aktivieren geschieht dadurch, dass man einen [:ln:symbolische Link] der Datei /etc/nginx/sites-available/NAME_DER_DATEI nach /etc/nginx/sites-enabled/ anlegt
In der Standardinstallation ist bereits die Datei default vorhanden und aktiviert
- Diese Datei kann man um eigene `server` Sektionen erweitern, wie im folgenden Beispiel gezeigt wird
Zum Deaktivieren reicht es, den entsprechenden symbolischen Link aus dem Verzeichnis /etc/nginx/sites-enabled zu löschen
Konfiguration
- Minimalbeispiel
Im folgenden Beispiel wird die vorhandene Konfigurationsdatei default um eine eigene Route erweitert, die eine einfache HTML-Seite ausgeben soll
Dazu öffnet man die Datei default mit einem Editor mit Root-Rechten[4][5] und fügt nach der Zeile `server_name: _;`
die folgenden Zeilen ein:
{{{
location /test { root /var/www/html/test;
try_files $uri $uri/ =404;
}
}}}
Erklärung:
* Die erste Zeile legt fest, dass der folgenden Block an Direktiven für die Route `/test` gilt * Die zweite Zeile legt das `root`-Verzeichnis, in dem nach (HTML-) Dateien gesucht wird, auf /var/www/html/test fest * Die dritte Zeile besagt, dass ein "404 - not found" zurückgeliefert werden soll, wenn keine passende (HTML) Datei gefunden wurde
Die Datei default sieht somit nach dem Hinzufügen (ohne Kommentarzeilen) wie folgt aus:
{{{ server { listen 80 default_server; listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location /test { root /var/www/html/test;
try_files $uri $uri/ =404;
}
location / { try_files $uri $uri/ =404; } } }}}
Jetzt muss man noch das Verzeichnis /var/www/html/test anlegen und darin eine HTML-Datei index.html erstellt werden
Die geänderte Konfigurationsdatei wird mit dem folgenden Befehl auf Fehler getestet:
{{{#!vorlage Befehl sudo nginx -t }}}
Der Aufruf von `http://localhost/test` sollte jetzt die selbst angelegte HTML-Seite anzeigen
Möchte man die Route `/test` in einer eigenen Konfigurationsdatei namens test hinterlegen, sollte die Datei so aussehen:
{{{ server {
listen 80; listen [::]:80;
root /var/www/html/test; index index.html;
server_name test;
location /test { try_files $uri $uri/ =404; } } }}}
Dann muss noch der symbolisch Link nach /etc/nginx/sites-enabled angelegt und die Konfiguration von nginx neu geladen werden:
{{{#!vorlage Befehl sudo nginx -s reload }}}
nginx als Reverse-Proxy
Der nginx Webserver ist auch recht beliebt zum Einsatz als "Reverse Proxy"
- Dabei nimmt der Server die Anfrage aus dem Internet an, leitet diese an einen lokal laufenden Applikationsserver weiter und liefert anschließend dessen Antwort aus
- So ist z. B. im [:Python:]-Umfeld der Einsatz von nginx als Reverse Proxy in Kombination mit dem (lokal laufenden) WSGI-Applikationsserver [:Gunicorn:] oder uwsgi eine durchaus beliebte Lösung
Im einfachsten Fall benötigt man in der `server` Konfiguration von nginx nur die folgenden beiden Zeilen:
{{{ location / {
proxy_pass http://127.0.0.1:8000;
} }}}
Damit werden alle Anfragen an diese `location` - im obigen Beispiel als das Root-Verzeichnis der Domäne - an `http://127.0.0.1:8000` weitergeleitet, wo dann ein Applikationsserver läuft
Trotz der Weiterleitung übergibt nginx den angesteuerten Pfad (z.B. `http://example.com/neu`, und nicht `http://127.0.0.1:8000/`)
Weiterführende Informationen findet man in der Dokumention {en} des Servers
Steuerung von nginx
Nginx bildet sich aus einem „Master”-Prozess und vielen „Slave”- bzw. „Client”-Prozessen
- Man steuert nginx mit dem Master-Prozess, den man mit dem Befehl `nginx` anspricht
- Dies geht nach folgendem Prinzip:
{{{#!vorlage Befehl nginx [-s signal] [-c filename] [-p prefix] [-g directives] }}}
Falls eine andere Konfigurationsdatei als /etc/nginx/nginx.conf, z. B. zu Testzwecken, verwendet werden soll, startet man nginx folgendermaßen:
{{{#!vorlage Befehl sudo nginx -c /pfad/der/konfigurationsdatei }}}
Nützlich ist auch die Option `-t`, welche die Konfiguration von nginx testet
- Nach jeder Änderung eine Konfigurationsdatei sollte man von daher
{{{#!vorlage Befehl sudo nginx -t }}}
aufrufen und schauen, ob Fehler in einer der Konfigurationsdateien vorliegen
- Wenn nicht, kann die Konfiguration neu eingelesen werden, so dass diese aktiv wird:
{{{#!vorlage Befehl sudo nginx -s reload }}}
Bei der Installation aus den Paketquellen wird nginx beim Systemstart über eine [:systemd:] Service Unit automatisch gestartet, welche über [:systemd/systemctl:systemctl] kontrolliert werden kann
Tipps & Tricks
Loadbalancing mit nginx
[wikipedia:Loadbalancing:] ist standardmäßig in nginx vorhanden und schlägt laut diesem Artikel {de} [wikipedia:Pound_(Software):Pound] deutlich
- Im folgenden Beispiel verteilt nginx die Last auf 3 Server:
{{{ http {
upstream loadbalancer { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; }
server { listen 80; server_name www.example.com example.com; location / { proxy_pass http://loadbalancer; } }
} }}}
Zur Erklärung: Im Upstream `loadbalancer` sind drei (Web-)Server vorhanden und mit ihren jeweiligen Daten (`IP:Port`) angegeben
- Im `server { [...] }`-Block hört nginx an den Domains `www.example.com` und `example.com` an Port 80 und leitet die Anfrage an den upstream weiter
Rewriting
nginx unterstützt URL-Rewriting nativ und kann mithilfe von Regex ([wikipedia:Regulärer Ausdruck:]) Anfragen umschreiben
- So kann zum Beispiel eine Domain `example.com/artikel.php?id=123` zu `example.com/artikel/123` vereinfacht werden, ohne dass der Nutzer weitergeleitet werden muss
- Das Rewriting kann im Hintergrund auf Server-Ebene geschehen
- Um Rewriting zu aktivieren, fügt man folgendes in seine Konfiguration in einem `server { [...] }`-Block ein:
{{{ rewrite ^/artikel/(.*)$ /artikel.php?id=$1? last; }}}
Der reguläre Ausdruck `^/artikel/(.*)$` bedeutet folgendes: Existiert in der aufgerufenen Domain an irgendeiner Stelle die Zeichenfolge `/artikel/` wird sämtliches hinter dieser an `artikel.php` als GET-Parameter `id` übergeben
Dieses Rewriting passiert mit der Flag `last` nur intern
- nginx bietet folgende Flags zur Auswahl an:
{{{#!vorlage Tabelle `last/break` Internes Rewriting ohne Weiterleitung +++ `redirect` Leitet den Nutzer auf die Seite weiter (HTTP 302 - Temporäre Weiterleitung) +++ `permanent` Leitet den Nutzer auf die Seite weiter (HTTP 301 - Dauerhafte Weiterleitung) }}}
{{{#!vorlage Warnung Ohne eine gesetzte Flag gibt nginx den Fehler HTTP 500 zurück }}}
Weitere Hilfe, Tipps und Tricks findet man im nginx-Wiki {en}
Absicherung von nginx
Man stelle sich vor, ein Hacker würde eine Datei via PHP/Perl/Python in das Verzeichnis /uploads/ hochladen
- Diese Datei ist mit Schadcode infiziert und würde bei der Ausführung dem Server schaden
- Wenn jetzt aber die Ausführung der Datei nicht verboten wird, könnte der Hacker seinen Angriff starten
- Um das zu verhindern, fügt man in den `server { [...] }`-Block folgendes ein:
{{{ if ($uri !~ "^/uploads/") {
fastcgi_pass 127.0.0.1:9000;
} }}}
Dies löst aus, dass alle Dateien, die sonst über die FastCGI-Schnittstelle an Port 9000 laufen würden, in allen Ordnern mit dem Namen uploads nicht mehr ausgeführt werden
nginx mit anderen Programmiersprachen
Die Nutzung von nginx in Kombination mit [:PHP:] ist im Artikel [:nginx/PHP:] beschrieben, die in Kombination mit [:Perl:] im Artikel [:nginx/Perl:]
Links
* nginx Wiki {en} - Dokumentation * nginx Docs {en} - Dokumentation für nginx Plus, welche aber auch in weiten Teil für die freie Variante von nginx zutrifft * Quellcode Repositry {en} von nginx bei Mercurial * Sichere SSL/TLS Konfiguration mit Nginx {de} - Ausführliche Anleitung * Hosting Websites with Nginx {en} - Weiterführende Konfiguration * Certificate Pinning mit Nginx {de} - Artikel zum "Public Key Pinning for HTTP" (RFC 7469) * VHOST example {en} - für das Heim-Netzwerk
- tag: Netzwerk, Internet, Server