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:

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 (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

---

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

Dokumentation

Man-Page

1. prep(1)