2013-08-01 15 views
23

Konfiguracja witryny dla mojego meteorytu aplikacja dyrektyw, które wygląda następująco:zaleca konfigurację Nginx dla meteor

server { 
    listen 443; 
    server_name XXX; 

    ssl on; 
    ssl_certificate XXX; 
    ssl_certificate_key XXX; 

    location/{ 
    proxy_pass http://localhost:3000; 
    proxy_set_header X-Real-IP $remote_addr; # http://wiki.nginx.org/HttpProxyModule 
    proxy_http_version 1.1; # recommended for keep-alive connections per http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version 
    proxy_set_header Upgrade $http_upgrade; 
    proxy_set_header Connection "upgrade"; 
    proxy_set_header Host $host; 
    } 
} 

czuję, że należy mówić nginx służyć zawartość static_cacheable i ustawienie nagłówka expires do max . Jak dokładnie to robię? Czy są jeszcze inne rzeczy, które powinienem tu dodać?

Odpowiedz

25

Chociaż nie jestem ekspertem od nginx, czuję, że mam o wiele lepsze zrozumienie, jak to zrobić teraz. Jak się dowiedzieć więcej, zaktualizuję tę odpowiedź.

Możliwym rozwiązaniem do mojego pierwotnego pytania to:

location ~* "^/[a-z0-9]{40}\.(css|js)$" { 
    root /home/ubuntu/app/bundle/programs/web.browser; 
    access_log off; 
    expires max; 
} 

który mówi: Każdy adres URL tej strony zawierającej ukośnik następnie 40 znaków alfanumerycznych + .js lub .css, można znaleźć w web.browser informator. Serwuj te pliki statycznie, nie zapisuj ich w dzienniku dostępu i nie informuj klienta, że ​​mogą być przechowywane w pamięci podręcznej na zawsze.

Ponieważ główne pliki css i js mają unikalną nazwę po każdej operacji pakowania, powinno to być bezpieczne.

Będę obsługiwał pełną wersję tego przykładu here. Warto również zauważyć, że korzystam z najnowszej wersji nginxa, która obsługuje WebSockets, o czym rozmawia here.

Wreszcie, nie zapomnij w pełni włączyć gzip w swojej konfiguracji nginx. Moja sekcja gzip wygląda następująco:

gzip on; 
gzip_disable "msie6"; 
gzip_vary on; 
gzip_proxied any; 
gzip_comp_level 6; 
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; 

Po wykonaniu wszystkich, że udało mi się dostać przyzwoity wynik na pagespeed.

Aktualizacja 17.09.2014:

Aktualizacja ścieżki dla meteor 0.9.2.1

+1

Jeśli zezwolisz na buforowanie wszystkich plików 'css' /' js', czy kopia użytkownika nadal będzie aktualizowana (jak w przypadku ponownego ładowania hot-code) po wprowadzeniu zmiany w plikach Meteor w katalogu 'client'? – Nyxynyx

+1

Tak. Za każdym razem, gdy pakujesz swoją aplikację, utworzy ona nową parę plików css i js o unikalnych nazwach. –

+0

W jaki sposób obchodzić się z utrzymywaniem połączeń sieci Web podczas wdrażania z użytkownikami na żywo w witrynie? Otrzymuję 502 błędy złą bramę i obecni użytkownicy muszą ponownie załadować aplikację. – deepwell

9

Zrobiłem kilka nowości i usprawnień do drugiej odpowiedzi. Konkretnie

  • nagłówek X-Forwarded-For musi być ustawiony na Meteor nowego IP address detection który odbywa się w this file. Nie wydaje się, aby użyto X-Real-IP.
  • ścieżka /nginx_status może być używana do monitorowania natężenia ruchu przychodzącego przez serwer proxy.

Zrobiłem to trochę i wymyśliłem następującą konfigurację. Popraw odpowiednio swoje pola.

Najpierw kompresja, która znacznie przyspiesza ładowanie.Należy zauważyć, że dyrektywa gzip_buffers zwykle jest automatycznie obliczana domyślnie przy użyciu systemu rozmiaru strony pamięci:

gzip on;                                     
gzip_disable "msie6";                                  
gzip_min_length 1100; 
gzip_vary on; 
gzip_proxied any; 
gzip_comp_level 6; 
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; 

config server sama:

server { 
    listen 443 ssl; 
    server_name my.domain.com; 

    ssl on; 
    ssl_certificate /etc/ssl/nginx/certificate.crt; 
    ssl_certificate_key /etc/ssl/nginx/certificate.key; 

    access_log /var/log/nginx/localhost.ssl_access_log main; 
    error_log /var/log/nginx/localhost.ssl_error_log info; 

    # Forward to meteor server                               
    location/{ 
     proxy_pass http://localhost:3000; 
     proxy_http_version 1.1; 
     proxy_set_header Upgrade $http_upgrade; 
     proxy_set_header Connection "upgrade"; 
     proxy_set_header Host $host; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 

    # copied from http://blog.kovyrin.net/2006/04/29/monitoring-nginx-with-rrdtool/ 
    location /nginx_status { 
     stub_status on; 
     access_log off; 
     allow 192.168.0.0/24; 
     deny all; 
    } 
} 

Wreszcie, jak wspomniano Dan, będzie trzeba ustawić HTTP_FORWARDED_COUNT Zmienna środowiskowa w Meteorolu, aby poprawnie odebrać adresy IP klienta z tyłu odwrotnego proxy.

+0

Dzięki Andrew. Kolejnym dobrym zasobem, jaki znalazłem, jest [h5bp/server-configs-nginx] (https://github.com/h5bp/server-configs-nginx). –

+0

Dzięki za aktualizację; skasowałem mój komentarz. Przetestowałem także X-Real-IP i X-Forwarded-For, a tylko ten ostatni odczytał Meteor. Zgodnie z oczekiwaniami na podstawie kodu [livesata_server] (https://github.com/meteor/meteor/blob/devel/packages/ddp-server/livedata_server.js#L824). –

+0

Env var HTTP_FORWARDED_COUNT jest nadal wymagany? czy http://www.meteorpedia.com/read/nginx jest aktualny? – Liko

Powiązane problemy