nginx als Proxy nur für bestimmte Subdomains

[rigo2]

Hi,

Ich habe Apache als Worker mit fgcid unter Ubuntu 9.04.
Meine domains sind domain1.tld, domain2.tld, domain3.tld und die Subdomains i1.domain1.tld to i4.domain1.tld. Wenn eine Besucher auf eine der Domains zugreift, bekommt er den dynamischen Content von z.B. domain2.tld (oder domain1.tld) und den statischen Content immer von i1.domain1.tld bis i4.domain1.tld.

Ich möchte jetzt nginx alle Anfragen an i1-i4.domain1.tld ausliefern lassen und alle anderen Anfragen die jeweiligen Domains an Apache weiterlieten (inkl. der Server-Vars wie ["REMOTE_ADDR"] etc.).

Wie kann ich für diesen Fall nginx und Apache konfigurieren/umkonfigurieren? Ich habe schon gegoogelt aber für diesen Fall noch nichts gefunden :(

cu
rivella

[Roger Wilco]

http://serversupportforum.de/forum/webs ... mains.html

[rigo2]

Darf man seine Fragen nicht in mehreren Foren formulieren?

[daemotron]

Darf man seine Fragen nicht in mehreren Foren formulieren?

Wenn man sparsam mit Crosspostings umgeht, darf man schon - eben vor allem, wenn man in einem Forum nach ein paar Tagen keine Reaktion erhält oder das Problem dort nicht gelöst werden konnte. Man sollte dann aber in seinem Posting darauf hinweisen, dass es ein Crossposting ist.

[rigo2]

Wenn man sparsam mit Crosspostings umgeht, darf man schon - eben vor allem, wenn man in einem Forum nach ein paar Tagen keine Reaktion erhält oder das Problem dort nicht gelöst werden konnte. Man sollte dann aber in seinem Posting darauf hinweisen, dass es ein Crossposting ist.

Ok. das war mir nicht bewusst. Danke für den Hinweis.

[Roger Wilco]

Wie kann ich für diesen Fall nginx und Apache konfigurieren/umkonfigurieren?

Ein ähnliches Setup wird unter http://www.debian-administration.org/ar ... ginx_proxy beschrieben, das einfach anzupassen sein sollte.

[rigo2]

Vielen Dank für den Link. Damit konnte ich das Problem (fast) vollständig lösen.

Die konfiguration ist für Nginx wie folgt:

Code: Select all

# Statische Seiten
server {
  listen 80;
  server_name  i1.domain1.tld i2.domain1.tld i3.domain1.tld i4.domain1.tld;
  access_log   /var/log/nginx/domain1/access.log;
  root         /var/www/domain1/;
}

Code: Select all

# Dynamische Seiten
server {
  listen 80;

  server_name  www.domain1.tld domain1.tld www.domain2.tld domain2.tld;
  access_log  /var/log/nginx/domain1/access.log;

  #
  # Proxy all remaining content to Apache
  #
  location / {

    proxy_pass         http://127.0.0.1:8080/;
    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;

    client_max_body_size       10m;
    client_body_buffer_size    128k;

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

Ein Kleinigkeit habe ich aber übersehen und komme jetzt nicht weiter:
Ich nutze zur Zusammenfassung und Komprimierung der JS- und CSS-Dateien Minify, welches ein PHP-Script ist. Auf der Seite werden dann z.B. die CSS-Dateien eingebunden mit

Code: Select all

<link type="text/css" rel="stylesheet" href="http://i1.domain1.tld/media/min/?f=/csspath/cssfile1.css,/csspath/cssfile2.css" />

Nginx gibt mir bei diesem Aufruf einen Fehler: 403 Forbidden, in den Logs steht dann z.B.

Code: Select all

2010/06/13 23:07:03 [error] 2393#0: *2 directory index of "/var/www/domain1/media/min/" is forbidden, client: 87.119.178.242, server: i1.domain1.tld, request: "GET / HTTP/1.1", host: "i1.domain1.tld"

Wenn ich in das Verzeichnis eine Datei "index.html" lege, bekomme ich diese angezeigt. Nginx soll aber in diesem Fall die dort befindliche "index.php" ausführen.

Wie bekomme ich es denn jetz hin, dass Nginx in diesem einen Verzeichnis PHP-Code ausführt und sonst nicht.

[Joe User]

PHP in nginx einbinden und statt .../?f=... direkt .../index.php?f=... aufrufen.

[Roger Wilco]

Wie bekomme ich es denn jetz hin, dass Nginx in diesem einen Verzeichnis PHP-Code ausführt und sonst nicht.

Du solltest vielleicht erst ueberlegen, ob das von dir geplante Setup in dieser Form ueberhaupt sinnvoll ist. Im ersten Post hast du beschrieben, dass nginx statische Inhalte ausliefern und die dynamischen Inhalte von einem Apache httpd im Backend generieren lassen soll. Das ist noch relativ sinnvoll.

Wenn du PHP im nginx aktivierst (derzeit nur ueber FastCGI unterstuetzt), brauchst du eigentlich den Apache httpd nicht mehr und koenntest dir die gesamte Proxy-Geschichte sparen.

Eine Alternative bestuende darin, die Assets statisch zu "minimieren" und ggf. gleich gzip-komprimiert auf dem Server abzulegen. Das beschleunigt u. a. auch die Auslieferung. Das lohnt sich vor allem bei Dateien, die sich nicht haeufig aendern.

[Roger Wilco]

eine lokale IP auf dem host zu definieren z.B. 172.0.0.1 oder 10.0.0.1 etc.
auf diese die dynamischen Inhalte des Apachen betreiben, extern einen 2. vHost laufen lassen mit mod_proxy und mod_cache in Kombination.

Bei diesem Setup kannst du auch komplett auf mod_proxy verzichten und einfach nur mod_(disk|file|mem)_cache fuer den VirtualHost verwenden, der die dynamischen Inhalte ausliefert. ;)

[rigo2]

Du solltest vielleicht erst ueberlegen, ob das von dir geplante Setup in dieser Form ueberhaupt sinnvoll ist. Im ersten Post hast du beschrieben, dass nginx statische Inhalte ausliefern und die dynamischen Inhalte von einem Apache httpd im Backend generieren lassen soll. Das ist noch relativ sinnvoll.

Wenn du PHP im nginx aktivierst (derzeit nur ueber FastCGI unterstuetzt), brauchst du eigentlich den Apache httpd nicht mehr und koenntest dir die gesamte Proxy-Geschichte sparen.

Eine Alternative bestuende darin, die Assets statisch zu "minimieren" und ggf. gleich gzip-komprimiert auf dem Server abzulegen. Das beschleunigt u. a. auch die Auslieferung. Das lohnt sich vor allem bei Dateien, die sich nicht haeufig aendern.

Du hast recht. Ich habe jetzt die conf für statischen Contend gelöscht und folgendes in die conf für dymanische Content eingefügt:

Code: Select all

   #
   # Serve directly:  /images/ + /css/ + /js/
   #
	location ^~ /(images|css|js) {
		root   /var/www/domain1/;
		access_log  /var/log/nginx/domain1/access.log ;
	}

	#
	# Serve directly: *.js, *.css, *.rdf,, *.xml, *.ico, & etc
	#
	location ~* \.(js|css|rdf|xml|ico|txt|gif|jpg|png|jpeg)$ {
		root   /var/www/domain1/;
		access_log  /var/log/nginx/domain1/access.log ;
	}

Wenn ich jetzt allerdings die Seite lade, steht auch bei dynamischen Inhalten im Header folgendes (Firebug):

Code: Select all

Antwort-Header
Server                  nginx/0.7.62
Date                    Mon, 14 Jun 2010 17:44:17 GMT
Content-Type            text/html; charset=utf-8
Transfer-Encoding       chunked
Connection              keep-alive
X-Powered-By            PHP/5.2.6-3ubuntu4.5
P3P                     CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires                 Mon, 1 Jan 2001 00:00:00 GMT
Cache-Control           no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma                  no-cache
Last-Modified           Mon, 14 Jun 2010 17:44:17 GMT
Vary                    Accept-Encoding
Content-Encoding        gzip

Sollte da dann nicht "Apache 2.2.11" statt "nginx/0.7.62" stehen?

[Roger Wilco]

Nein, der Apache httpd läuft nur im Backend. Tatsächlich ausgeliefert werden die Daten von nginx. Daher ist der Header korrekt.

[rigo2]

Vielen Dank, Roger!

[daemotron]

Nginx arbeitet mit non-blocking Sockets und arbeitet somit ähnlich wie Lighttpd asynchron mehrere Anfragen in einem Prozess bzw. Thread ab. Nginx nutzt aber zusätzlich mehrere Worker-Prozesse, was Lighty nicht so ohne weiteres kann. Apache hingegen arbeitet nicht mit non-blocking Sockets, sondern kann pro Worker-Thread (oder Prozess bei prefork) nur je eine Anfrage simultan bearbeiten. Nginx verwendet - genau wie Lighty und anders als Apache - keine POSIX Threads. Das macht den Code übersichtlicher und leichter zu debuggen und warten.

Warum sind non-blocking Sockets nun performanter als ein per-Thread-Handling der Requests? In erster Linie spart man vor allem Overhead für das Handling der Threads und damit Arbeitsspeicher. Performance holt man raus, weil select auf ein Socket-Subset natürlich schneller reagiert als ein Kontext-Wechsel im Scheduler des Kernels (was bei einem Worker-Thread oder -Prozess ja erforderlich wäre, zumindest solange es mehr Worker als CPU-Kerne gibt).

Den letzten Kick holen sich Lighty, Nginx & Co, weil sie das oben schon angesprochene generische select und poll nur als Fallback verwenden, wenn das OS selbst keine bessere Möglichkeit bereitstellt. Unter Linux wäre das z. B. epoll, unter FreeBSD kqueue und unter Solaris /dev/poll.

[daemotron]

Und genau an der Stelle Frage ich mich gerade, ob das wirklich so viel mehr bringt oder ob es nicht besser gewesen wäre, auf den Indinaer komplett zu verzichten.

War weiter oben Deine Idee nicht andersherum, auf Nginx zu verzichten?

Der Performance-Vorteil von non-blocking Sockets liegt in einem Bereich, der nicht mehr relevant ist, sobald dynamisch generierte Inhalte ins Spiel kommen. Insofern wäre es also egal, ob Apache oder Nginx den dynamischen Kram bereit stellt. Apache ist aber in der Hinsicht etwas stabiler als Nginx (FastCGI hat einfach immer noch Macken und Schwächen, gerade bei sehr hoher Load); von daher ist Apache gar keine so schlechte Idee - zumal Nginx als Reverse Proxy ja dafür sorgt, dass Apache nur mit einer gesitteten Anzahl simultaner Requests behelligt wird.

Auf Nginx wiederum würde ich in dem Setup nicht verzichten, weil er die statischen Inhalte sehr fix und ohne großen Memory Footprint rauspusten kann.

Kann man also drehen und wenden, wie man will. Für normale bis mittelgroße Setups würde ich sagen: völlig wurscht, ein Webserver reicht da eh. Wenn man so viel Load hat, dass man schon messbare Vorteile durch einen asynchron arbeitenden httpd hat, dann profitiert man auch von den minimalen Performance-Vorteilen, die mod_php, mod_python & Co. gegenüber FastCGI noch haben.