Nginx/Konfiguration

Nginx/Konfiguration - Nginx konfigurieren

Konfiguration

Konfigurationsdateien

/etc/nginx/

Grundkonfigurationsdatei

nginx.conf

Aufbau

• 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

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

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

Erläuterung:

1. Die erste Zeile legt fest, dass der folgende Block an Direktiven für die Route `/test` gilt
2. Die zweite Zeile legt das `root`-Verzeichnis, in dem nach (HTML-) Dateien gesucht wird, auf /var/www/html/test fest
3. 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 ([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:

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

---

• Nginx/Konfiguration/Loadbalancing
• Nginx/Konfiguration/Proxy/Reverse
• Nginx/Konfiguration/Reverse-Proxy
• Nginx/Konfiguration/Rewriting

Dokumentation

Man-Page

1. prep(1)