nginx: Default-Config (CatchAll, Routing, UpStreams)

Hier sind ein paar Standard Beispiele einer nginx Konfiguration um einen Catch All (Default) Server/Domain einzurichten, sowie ein Load Balacing mittels UpStream Server zu bestimmen.
Dies ermöglich unter anderem ein Load Balancing zwischen mehreren Apaches bzw. den Aufbau eines rudimentären CDN (Content Delivery Networks).

Folgende Config Datei (000-default.conf) im /etc/nginx/conf.d/ Verzeichnis bedient folgendes Szenario:

Alle Anfragen auf Port 80 mit der Domain:
– www.domain-A.de
– domain-A.de
– www.domain-B.de
– domain-B.de

werden auf sofort auf den Webserver mit dem Hostname web-server geleitet (siehe proxy_pass Directive).
Außerdem haben wir noch ein gzip konfiguriert.

server {
    listen       80;
    server_name  www.domain-A.de domain-A.de www.domain-B.de domain-B.de; 

    access_log  /var/log/nginx/access.log  main;
    error_log  /var/log/nginx/error.log;

    client_max_body_size 20M;

    location / {
     proxy_pass http://web-server;
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

     gzip on;
     gzip_types text/plain application/xml;
     gzip_disable "MSIE [1-6]\.";

   }
}

Nachfolgende Config zeigt ein etwas komplexeres Szenario:

Alle Anfragen auf Port 80 mit egal welcher Domain (Catch All) (siehe server_name _; Directive) werden von dieser Konfig behandelt.
Das “Routing” geschieht diesmal allerdings etwas anders.
Mittels location ~* /(res|libs|images|styles|scripts|favicon.ico) filtern wir alle Anfragen, welche in ihrer URL res, libs, images, styles, scripts, etc enthalten.
Diese Anfragen werden auf einen staticcontent-server (siehe proxy_pass Directive) geleitet.

Wir verwenden unseren web-server aus dem oberen Beispiel nun für alle Anfragen, die nicht von der ersten location Directive behandelt worden sind.
Somit können wir statischen Content wie Images, JavaScript und/oder CSS Dateien von einem anderen Webserver ausliefern.
Dies kann unter anderem die Performance und Stabilität der Webseite erhöhen, da die Arbeit nun von zwei Apaches geteilt wird.

server {
    listen       80;
    server_name  _; #catch all

    access_log  /var/log/nginx/access.log  main;
    error_log  /var/log/nginx/error.log;

    client_max_body_size 20M;

    location ~* /(res|libs|images|styles|scripts|favicon.ico) {
        proxy_pass http://staticcontent-server;

        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        gzip on;
        gzip_types text/plain application/xml;
        gzip_disable "MSIE [1-6]\.";
    } 

    location / {
        proxy_pass http://web-server;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        gzip on;
        gzip_types text/plain application/xml;
        gzip_disable "MSIE [1-6]\.";

   }
}

Gegebenenfalls möchte man die Ausfallsicherheit / Performance noch weiter erhöhen und mehrere Web-Server bzw- staticcontent-server betreiben. Das ist mit nginx und den upstream Server Directive kein Problem!

Wir definieren in unserer Konfig folgendes:

upstream cdn-nodes {
   server staticcontent-server1;
   server staticcontent-server2;
}
upstream web-nodes {
   server web-server1 weight=5;
   server web-server2 weight=5;
}

Nun sind wir in der Lage bei der proxy_pass Directive nicht mehr den direkten Hostnamen des Web-Servers anzugeben, sondern können den beim upstream definierten Namen benutzen. In diesem Fall also cdn-nodes oder web-nodes.

Hinter die Definitionen der upstream Hosts können weitere Parameter angegeben werden. Zum Beispiel kann ein Server mittels “down” vorrübergehend aus dem “Cluster” genommen werden.
Mittels “backup” kann definiert werden, dass dieser Host nur in Frage kommt, wenn alle anderen nicht mehr erreichbar sind.
Durch die Angabe einer Gewichtung (weight=N) kann eine Gewichtung der Webserver bestimmt werden.

upstream cdn-nodes {
   server staticcontent-server1 weight=5;
   server staticcontent-server2 weight=5;
   server staticcontent-server3 down;
   server staticcontent-server4 backup;
}