Obsługa zdalnych plików statycznych z symfony3

Question

Mam problem z moją konfiguracją Nginx. Mam 2 serwery, jeden z nginx i jeden z moim webApp w symfony3. Oto moja konfiguracja:

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; 

} 

stronie internetowej praca dla wszystkich skryptów PHP, ale wszystkich aktywów (statyczne) pliki są uszkodzone pliki. Nie rozumiem wystarczająco, jak działa Nginx, aby wskazać, czym są pliki statyczne i "powiedzieć" mojemu proxy, że nie są skryptami.

Answer 1

Dyrektywa try_files automatycznie próbuje znaleźć pliki statyczne i udostępnić je jako statyczne, zanim się poddadzą i pozwoli, aby żądanie zostało przesłane jako skrypt.

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

  sprawdza istnienie plików w określonej kolejności i stosuje pierwszy znaleziony plik do przetwarzania żądań; przetwarzanie odbywa się w obecnym kontekście. Ścieżka do pliku jest konstruowana z parametru pliku zgodnie z dyrektywami root i alias. Możliwe jest sprawdzenie istnienia katalogu przez podanie ukośnika na końcu nazwy, np. "$ Uri /". Jeśli żaden z plików nie został znaleziony, wykonywane jest wewnętrzne przekierowanie do uri podanego w ostatnim parametrze.

Należy zauważyć, że chociaż jesteś już przy użyciu try_files, wydaje się, że może twoja manipulacja ścieżka jest nie do spec.

---

Jak na swoją odpowiedź z tymczasowym rozwiązaniem, there's nothing wrong with using a rewrite or two, ale powiedział, że wygląda na to, że można korzystać z dyrektywy alias.

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

  Definiuje zastępstwo dla określonej lokalizacji.

Jednak nigdy nie wyjaśnił, dlaczego jesteś służąc rzeczy z /tmp. Uwaga: /tmp jest często automatycznie czyszczony przez niektóre skrypty cron, np., na OpenBSD skrypt automatycznie odtworzy pliki starsze niż około 7 dni (on a daily basis, jak sugeruje nazwa).

---

Podsumowując, należy najpierw dowiedzieć się, co jest właściwe odwzorowanie między widokiem internetowej systemu plików i systemu plików.

Następnie, jeśli prefiks zostanie znaleziony, po prostu użyj osobnego location dla zasobów, wraz z alias.

W przeciwnym razie znajdź ścieżki dla try_files, aby działały zgodnie z przeznaczeniem.

Answer 2

mam znaleźć bardzo brzydki rozwiązanie, dopóki nikogo znaleźć lepsze rozwiązanie, tutaj jest to, co mam zrobić:

• mam skopiowane wszystkie repozytorium aktywów i skopiowane go do mojego serwera proxy gdzie nginx jest.

Oto mój nowy 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; 

} 

A teraz to działa, cały js/css i zdjęcia są znalezione.

Jeśli ktoś myśli o "czystszej" odpowiedzi, jest bardziej niż gotowy do udzielenia odpowiedzi.