#Nginx Reverse-Proxy unter #Ubuntu 10.04

Dieses Nginx Tutorial beschreibt die Installation & Konfiguration von Nginx als Reverse Proxy unter Ubuntu 10.04 . Ziel ist es am Ende des Howtos / Tutorials einen Nginx Reverse-Proxy transparent vor einem bereits existierenden Apache VirtualHost zu betreiben. Damit keine Probleme wie “duplicate content” auftreten, stellen wir über eine Nginx-spezifische Rewrite Regel sicher dass über einen einzigen Domainnamen zugegriffen wird. Zudem stellen wir noch sicher dass der Zugriff auf den existierenden Apache VirtualHost nur noch über den Nginx Reverse-Proxy möglich ist.

Inhalt

Warum Nginx?

Schön ist dass Nginx bewusst schlank gehalten und auf Performance optimiert wurde. Unter anderem auch deshalb werden weltweit mittlerweile ca. 7,5% der Webseiten von Nginx ausgeliefert. Hier ein Auszug von linuxjournal.com der ein ungefähres Gefühl für die Unterschiede von Apache und Nginx vermittelt:

[…]

The results indicate that Nginx outperforms Apache when serving static content. Both servers performed best with a concurrency of 100. Apache used four worker processes (threaded mode), 30% CPU and 17MB of memory to serve 6,500 requests per second. Nginx used one worker, 15% CPU and 1MB of memory to serve 11,500 requests per second.

[…]

Interessant ist Nginx aber nicht nur wegen geringerem Speicherverbrauch und dem Verzicht auf “unnötige” Features. Es sind vor allem die hervorragenden Qualitäten als HTTP Accelerator und HTTP Load-Balancer die Nginx für den Einsatz in verteilten Umgebungen interessant machen. Prominente Beispiele für derartige Nginx Installationen sind z.B. WordPress.com, Github und SourceForge. Ein Grund mehr Nginx einfach mal auszuprobieren.

NginX Installation unter Ubuntu 10.04

Wie von Ubuntu bzw. Debian zu erwarten ist die Grundinstallation denkbar einfach. Folgender Befehl installiert alle notwendigen Pakete:

$ sudo apt-get install nginx

Die mitgelieferte Konfiguration welche nun unter /etc/nginx hinterlegt ist dient als Grundlage. Weiter geht es mit dem anpassen der Grundkonfiguration.

Grundkonfiguration

Die Konfiguration von Nginx ist im Verzeichnis “/etc/nginx” hinterlegt. Wer unter Ubuntu bzw. Debian bereits mit Apache Erfahrungen gesammelt hat, wird die Unterverzeichnisse “sites-available” sowie “sites-enabled” erkennen. Auch bei NginX werden hier die VirtualHost Konfigurationen abgelegt. Allerdings wird wie mir scheint “ln -s” für dass Aktivieren und Deaktivieren von VirtualHost-Konfigurationen verwendet. Ein Nginx-Pendant zu a2ensite & co. habe ich nicht entdeckt.

Fangen wir mit dem Anpassen der Grundkonfiguration an. Hier folgenden zunächst die wichtigsten Einstellungen die ich für den Reverse Proxy geändert habe. Weiter unten sind noch einmal die kompletten Konfigurationsdateien zu sehen.

Ressourcen Limits

Ein sinnvolles Limit für Prozesse und Verbindungen ist vom Verhältnis Anforderungen der Webapplikation zu verfügbaren Ressourcen abhängig. Hier gibt es wie bei dem Apache auch keine Standardformel für die beste Einstellung, speziell wenn eine Webapplikation direkt von Nginx bereitgestellt wird. Da in diesem Beispiel jedoch keine Anfragen direkt auf dem System verarbeitet (z.B. durch PHP Skripte), ist die Auslastung des Systems deutlich geringer. Folgende Werte können angepasst werden, um die Limitierung anzupassen:

  • worker_processes:
    Anzahl der parallelen “Worker-Prozesse”, welche HTTP-Request bearbeiten.
  • worker_connections:
    Anzahl der maximalen Verbindungen pro Worker-Prozess. Stark abhängig von den Resourcen.

Mein Reverse-Proxy läuft auf einem virtuellen Ubuntu System mit 4 CPU Kernen und 2GB Ram. Ich habe dass Standard Limit der worker_connections auf 512 herabgesetzt, dafür aber die worker_processes auf 4 erhöht. Ich verspreche mir davon eine gleichmässige Verteilung von nicht zuviel Last auf 4 CPU Kerne. Bisher fahre ich damit ganz gut. Wenn hier jemand Erfahrungswerte hat, wäre ich dennoch interessiert!

Proxy Konfiguration

Der Reverse-Proxy tritt gegenüber dem Zielserver als HTTP Client auf. Dadurch sieht auf dem Zielserver jeder Request aus als käme dieser vom Reverse-Proxy. Die folgenden Optionen sorgen dafür dass dem Zielsystem Informationen über die ursprüngliche Anfrage zur Verfügung stehen:



...
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_max_temp_file_size 0;
 ...



Dann setze ich noch Timeouts und Werte für dass Caching:




...
 proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 90;



proxy_buffer_size 4k;
 proxy_buffers 4 32k;
 proxy_busy_buffers_size 64k;
 proxy_temp_file_write_size 64k;
 ...



Zudem habe ich mit ein paar weiteren Optionen experimentiert (bspw. tcp_nopush). Hier kann ich leider noch keine exakten Angaben zu möglichen Vorteilen machen. Zuletzt werden dann separate Konfigurationsdateien und die aktivierten VirtualHosts eingelesen (bereits in der Grundkonfiguration enthalten):

 ...
 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;
 ...
 

Der “default”-VHost wird dadurch aktiviert. Dieser muss nun ebenfalls noch angepasst werden, damit der Reverse Proxy wirklich greift.

VirtualHost Konfiguration

Ein Reverse-Proxy leitet Anfragen die an einen definierten Pfad innerhalb der URL gerichtet sind, an einen anderen Webserver oder VirtualHost weiter. In diesem Beispiel werden alle HTTP Anfragen an meine-domain.de/ an intern.meine-domain.de/ weitergeleitet. Der DNS Eintrag für meine-domain.de zeigt hierbei auf die IP der Nginx Maschine und intern.meine-domain.de zeigt auf die Maschine mit dem Apache VirtualHost.

Rewrite

Zunächst die Rewrite Regel welche eine permanente Weiterleitung (301) signalisiert:

 if ($host != 'meine-domain.de') {
 rewrite ^(.*)$ http://meine-domain.de$1 permanent;
 }



Der Pfad für welchen der Reverse-Proxy Anfragen weiterleiten soll wird in einem “location”-Block gesetzt. Mittels proxy_pass wird dann mitgeteilt von welcher Zielurl die Anfragen bearbeitet werden sollen. Möglich wäre auch nur Anfragen an an ein bestimmtes Verzeichnis weiterzuleiten, z.B. meine-domain.de/blog . In dem Fall würde hier statt “location /” einfach “location /blog” verwendet:

 location / {
 proxy_pass http://intern.meine-domain.de/;
 proxy_redirect default;
 }
 

Im folgenden Abschnitt sind noch einmal die von mir veränderten Konfigurationen als Ganzes hinterlegt.

Konfigurationsdateien im Überblick

Die Bedeutung der wichtigsten Optionen werden in den nachfolgenden Sektionen erläutert.

/etc/nginx/sites-available/default:

 server {
 listen 80 default;
 server_name meine-domain.de;



if ($host != 'meine-domain.de') {
 rewrite ^(.*)$ http://meine-domain.de$1 permanent;
 }



access_log /var/log/nginx/localhost.access.log;



location / {
 proxy_pass http://intern.meine-domain.de/;
 proxy_redirect default;
 }
 }
 

/etc/nginx/nginx.conf:

 user www-data;
 worker_processes 4;



error_log /var/log/nginx/error.log;
 pid /var/run/nginx.pid;



events {
 worker_connections 512;
 use epoll;
 }



http {
 server_names_hash_bucket_size 64;



include /etc/nginx/mime.types;
 access_log /var/log/nginx/access.log;



sendfile on;
 tcp_nopush on;



keepalive_timeout 5;
 tcp_nodelay off;



gzip on;
 gzip_disable "MSIE [1-6]\.(?!.*SV1)";



proxy_redirect 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;
 proxy_max_temp_file_size 0;



proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 90;



proxy_buffer_size 4k;
 proxy_buffers 4 32k;
 proxy_busy_buffers_size 64k;
 proxy_temp_file_write_size 64k;



include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;
 }
 

Fazit und weitere Informationen

Ich finde Nginx wirklich interessant, eigene Tests kann ich nur empfehlen. Ich werde im nächsten Artikel dann den Nginx Server um einen VirtualHost erweitern welcher über PHP-FPM auch PHP Applikationen verarbeiten kann. Weitere Informationen bieten für den Moment die externen Links weiter unten. Wer mehr detaillierte Informationen such, findet in dem Buch Nginx HTTP Server von PacktPublishing vermutlich einige Antworten. Aus meiner Sicht hätte man diverse Details zu Linux nicht benötig da ich Nginx Benutzer in das Unix / Linux Umfeld einordnen würde. Dennoch bietet der Nginx bezogene Teil des Buches wirklich wertvolle Informationen.

Vielen Dank für’s lesen und weiterempfehlen!

Externe Links