Nginx/Konfiguration

Nginx/Konfiguration - Nginx konfigurieren

Beschreibung

Konfigurationsdateien

/etc/nginx/

Grundkonfigurationsdatei

nginx.conf

Aufbau

Sektionen

Diese besteht aus den Sektionen `events { [...] }` und `http { [...] }`

Kommentare

Kommentiert wird mit einer Raute (`#`)

Zeilenende

Jede Konfigurationszeile muss mit einem Semikolon `;` abgeschlossen werden

Sektionen

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

`server` Sektion

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

sites-available

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

Minimalkonfiguration

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;
}

Erläuterung:

Die erste Zeile legt fest, dass der folgende 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:

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:

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

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 (Regulärer Ausdruck) Anfragen umschreiben

So kann etwa 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

Flag	Beschreibung
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)

Warnung: Ohne eine gesetzte Flag gibt nginx den Fehler HTTP 500 zurück

Weitere Hilfe, Tipps und Tricks findet man im nginx-Wiki

Dateien

Datei	Beschreibung

Anhang

Siehe auch

Dokumentation

Man-Page

prep(1)

Links

Projekt

Weblinks