nginx try_files, proxy_pass und Upstream

Ich baue eine dockerisierte Testplattform für PHP-Apps – speziell (im Moment) für WordPress. Ich verwende PHPFarm, um verschiedene Versionen von PHP auf verschiedenen Ports bereitzustellen. Mit nginx vorne habe ich viel davon funktioniert. ( https://github.com/richardtape/testit ist das Hauptrepo)

Das große Problem, mit dem ich jetzt konfrontiert bin, ist, die „hübschen Permalinks“ von WordPress zum Laufen zu bringen. In einem Standard-Nginx-Setup handelt es sich nur um etwas wie

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Aber um schöne URLs vom Host-Computer haben zu können und um eine Codebasis zu haben, verwende ich etwas in der folgenden Richtung:

server {
    listen 80;
    index index.php index.html index.htm;
    server_name 52.spaces.dev;

    location / {

        proxy_pass http://phpfarm_52;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
    root /var/www;
}

upstream phpfarm_52{
    server phpfarm:8052;
}

Das funktioniert so wie es aussieht. (Es gibt 5 weitere ähnliche Regeln für PHP 5.3, 5.4, 5.5, 5.6 und 7) Die Homepage wird auf jedem der verschiedenen server_names von der Hostmaschine geladen (und wenn Sie die PHP-Version auf jedem von ihnen ausgeben, können Sie sehen Sie, dass Sie eine andere PHP-Version erhalten).

Beim zweiten Mal wechsle ich jedoch zu einer „internen“ URL (oder einer beliebigen Nicht-Root-URL, dh http://52.spaces.dev/about/), erhalte ich eine 404. Ich habe etwas Ähnliches versucht

location / {
    try_files $uri $uri/ /index.php?$args
}

location ~ \.php$ {
    proxy_pass http://phpfarm_52;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
}

Ich erhalte eine Umleitungsschleife, abhängig von ein paar verschiedenen Möglichkeiten, die ich ausprobiert habe, war es entweder nur eine Reihe von 301-Umleitungen und die Seite wird nie geladen oder ein Fehler wie z

nginx_1      | 2016/04/08 20:31:29 [error] 5#5: *4 rewrite or internal redirection cycle while processing "/index.php", client: 192.168.99.1, server: 52.spaces.dev, request: "GET /favicon.ico HTTP/1.1", host: "52.spaces.dev", referrer: "http://52.spaces.dev/"

Ich stecke fest. Ich bin auch ziemlich neu in der nginx-Konfiguration (was offensichtlich sein mag), also mache ich vielleicht etwas völlig falsch und/oder dumm. Irgendwelche Vorschläge?

Das Problem, das Sie mit der Umleitungsschleife in Ihrer Frage haben, ist, dass im Grunde jede Anfrage, auch für statische Dateien, versucht, über Ihren index.php?$args-Block zu leiten.

Ich sehe hier 2 mögliche Lösungen. Wenn Sie bereit sind, das nginx-Setup mit einer einzelnen nginx-Instanz zu implementieren, sehen Sie sich zunächst diesen Thread an: NGINX try_files mit mehreren benannten Speicherorten und diesen Blogbeitrag http://linuxplayer.org/2013/06/nginx-try-files-on-multiple-named-location-or-server

Was passieren muss, ist, dass Sie zuerst testen müssen, ob die Ressource im Upstream vorhanden ist, wie sie ist (dh nicht 404 zurückgibt). Wenn dies der Fall ist, servieren Sie es so, wie es ist. Wenn dies nicht der Fall ist, rufen Sie den Rewrite-Block auf, der versucht, ihn als Parameter in index.php einzufügen. Sie würden also so etwas bekommen (sorry, ich habe nicht wirklich die Möglichkeit, das zu testen, aber hoffentlich gibt es eine Idee):

location / {
    try_files $uri $uri/ @phpproxy;
}

location @phpproxy {
    proxy_pass http://phpfarm_52;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @rewrite_proxy;
}

location @rewrite_proxy {
    rewrite ^/(.*)$ /index.php?$1 break;
    proxy_pass http://phpfarm_52;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
}

Die zweite Lösung (die ich persönlich bevorzugen würde) besteht darin, jedem Upstream ein eigenes Nginx voranzustellen. Dann wird die oberste Nginx, die allen anderen vorangeht, eine viel sauberere Struktur mit einfachen Proxy_Passs (+ vielleicht etwas statischem Inhalt) haben und das war’s. Es wird auch den Request-Roundtrip reduzieren, da Sie 404-Fehler, die von den Upstreams kommen, nicht auflösen müssten.