Serving remote statische Dateien mit symfony3

Question

Ich habe ein Problem mit meiner Nginx-Konfiguration. Ich habe 2 Server, einen mit nginx und einen mit meiner WebApp in symfony3. Hier ist meine Konfiguration:

location /portal/mysite/ { 

    set $frontRoot /srv/data/apps/mysite-portal-stag/current/web; 
    set $sfApp app.php; # Change to app.php for prod or app_dev.php for dev 

    root /srv/data/apps/mysite-portal-stag/current/web; 

    rewrite ^/portal/mysite/(.*)$ /$1 break; 
    try_files $uri @sfFront; 

} 
location @sfFront { 

    root /srv/data/apps/mysite-portal-stag/current/web; 

    fastcgi_pass myserver:myport; 
    include fastcgi_params; 
    fastcgi_param SCRIPT_FILENAME $frontRoot/$sfApp; 

    fastcgi_param SCRIPT_NAME /portal/mysite/$sfApp; 

} 

Die Website Arbeit für alle PHP-Skripte, aber alle Vermögenswerte (statische Dateien) sind gebrochene Dateien. Ich verstehe nicht genug, wie Nginx arbeitet, um anzuzeigen, was die statischen Dateien sind, und meinem Proxy zu "sagen", dass sie kein Skript sind.

Answer 1

Die Direktive try_files versucht automatisch, statische Dateien zu finden und sie als statische Dateien zu verwenden, bevor sie aufgegeben werden, und die Anforderung als Skript verarbeiten zu lassen.

• http://nginx.org/r/try_files

  Prüft die Existenz der Dateien in der angegebenen Reihenfolge und verwendet die erste für Anforderungsverarbeitung gefunden Datei; Die Verarbeitung wird im aktuellen Kontext ausgeführt. Der Pfad zu einer Datei wird aus dem Dateiparameter gemäß den root- und alias-Anweisungen erstellt. Es ist möglich, die Existenz eines Verzeichnisses zu prüfen, indem ein Schrägstrich am Ende eines Namens, z. "$ Uri /". Wenn keine der Dateien gefunden wurde, wird eine interne Weiterleitung an die URL vorgenommen, die im letzten Parameter angegeben wurde.

Beachten Sie, dass obwohl Sie bereits try_files verwenden, scheint es, dass vielleicht Ihr Weg Handhabung spec nicht nach oben.

---

Was Ihre eigene Antwort mit einer temporären Lösung, there's nothing wrong with using a rewrite or two, aber das sagte, es sieht aus wie Sie von der alias Richtlinie profitieren würden.

• http://nginx.org/r/alias

  Definiert einen Ersatz für den angegebenen Ort.

Allerdings haben Sie noch nie erklärt, warum Sie Zeug aus /tmp sind zu dienen. Beachten Sie, dass /tmp oft automatisch durch einige cron Skripte, z.Unter OpenBSD würde das /etc/daily Skript automatisch find und Dateien entfernen, die älter als etwa 7 Tage sind (on a daily basis, wie der Name schon sagt).

---

Zusammengefasst, sollten Sie zunächst herausfinden, was die entsprechende Zuordnung zwischen der Web-Ansicht des Dateisystems und Dateisystem ist.

Anschließend, wenn ein Präfix gefunden wird, verwenden Sie einfach einen separaten location für die Assets, zusammen mit alias.

Sonst, herauszufinden, die Pfade für try_files wie vorgesehen funktionieren.

Answer 2

Ich habe eine sehr hässliche Lösung, bis jemand finden, eine bessere Lösung finden, hier ist das, was ich getan habe:

• ich kopiert haben alle Assets Repository und kopiert es zu meinem Proxy-Server, auf dem nginx ist.

Hier ist meine neue config:

location /portal/mysite/ { 

    set $frontRoot /srv/data/apps/mysite-portal-stag/current/web; 
    set $sfApp app.php; 

    root /srv/data/apps/mysite-portal-stag/current/web; 

    rewrite ^/portal/mysite/(.*)$ /$1 break; 
    try_files $uri @sfFront; 

} 
location /portal/mysite/asset { 
    root /tmp/mysite/asset; 
    rewrite ^/portal/mysite/asset/(.*)$ /$1 break; 
} 
location @sfFront { 

    set $frontRootWeb /srv/data/apps/mysite-portal-stag/current/web; 
    root /srv/data/apps/mysite-portal-stag/current/web; 

    fastcgi_pass myAdressWeb:myPort; 
    include fastcgi_params; 
    fastcgi_param SCRIPT_FILENAME $frontRoot/$sfApp; 

    fastcgi_param SCRIPT_NAME /portal/mysite/$sfApp; 

} 

Und jetzt ist es funktioniert, alle js/css und Bilder zu finden sind.

Wenn jemand an eine "sauberere" Antwort denkt, kann er gerne antworten.