modules - optimizar nginx

Página de mantenimiento nginx con problema de contenido

Question

Para mostrar la página de mantenimiento durante la implementación, siempre he usado la siguiente configuración en nginx:

if (-f /home/shared/system/maintenance.html) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
root /home/shared/errors;
rewrite ^(.*)$ /maintenance.html break;
}

Y todo estuvo bien hasta que tuve que agregar contenido estático a la página de mantenimiento (imágenes, hojas de estilo, etc.)

El contenido estático no funciona con dichos registros en error.log:

2011/05/05 02:47:20 [notice] 13760#0: *6 "^(.*)$" matches "/some.jpg", client: x.x.x.x, server: server.com, request: "GET /some.jpg HTTP/1.1", host: "server.com"
2011/05/05 02:47:20 [notice] 13760#0: *6 rewritten data: "/maintenance.html", args: "", client: x.x.x.x, server: server.com, request: "GET /some.jpg 2 HTTP/1.1", host: "server.com"

Lo cual es lógico: si reescribo todo a maintenance.html, eso significa que el contenido estático no es una exclusión.

Pero no puedo encontrar una solución adecuada para redirigir a todos los archivos, excepto los que existen físicamente en la carpeta root /home/shared/errors .

PD. /home/shared/errors no comparte ningún recurso con la carpeta común del proyecto - esta es una carpeta completamente separada (incluso sin ningún enlace simbólico /current para el proyecto.

Answer 1

Intenté todas las sugerencias anteriores y desafortunadamente no funcionan como se esperaba. La única solución que me funciona es la siguiente:

location / {
if (-f /path/to/file/indicating/maintenance/mode) {
rewrite ^(.+)$ /maintenance/$1;
}
#... the rest of the "normal" logic
}
location /maintenance {
root /path/where/your/maintenance/root/is;
rewrite ^/maintenance/(.*)$ /$1 break;
try_files /$uri /index.html =404;
return 200;
}

Lo sé, crea la ubicación innecesaria / de mantenimiento en las condiciones normales, pero puedes imaginar otra ruta de ubicación, que tus usuarios nunca adivinen :).

Answer 2

Lo siento, Frank Farmer, pero esto no funciona.

Lo que funciona pero no tan limpio:

Y como funcionan las solicitudes ->

1. Yo uso la regla # 1

   if (-f /home/shared/system/maintenance.html) {
   return 503;
   }

   esta regla es compatible con la ubicación de location @maintenance y para el redireccionamiento común a /maintenance.html en root /home/shared/errors todo funciona.

2. esta página contiene e imagen some.jpg : para recibir esta imagen, el navegador inicia una nueva solicitud y esta nueva solicitud some.jpg nuevamente con la regla # 1

   Todo esto fue descrito en la pregunta inicial PERO

   si utilizo algo mágico en las respuestas de Frank Farmer, puedo señalar el servidor al archivo solicitado, PERO la respuesta HTTP será 503 y los navegadores (todos, excepto Safari, en mi prueba) arrojan errores en la consola de depuración y muestran la imagen pero no procesan CSS -archivos en la misma situación.

   Y esto es crítico.

3. Traté de resolver esto usando la magia de ubicación para mis nuevas solicitudes de contenido, eso significa que tengo que:

   1. NO return 503 para solicitudes de contenido y omita la ubicación con nombre.

   2. cambie la root /home/shared/errors porque el contenido de mantenimiento todavía está allí.

4. Finalmente, tengo la siguiente solución:

   1. cree maintenance-static carpeta de maintenance-static para todo el contenido estático y cambie las rutas en mi archivo maintenance.html y en las hojas de estilo estáticas de mantenimiento

   2. A continuación, utilice estas reglas (creo que son autodescriptivas) que reemplazan single if (-f /home/shared/system/maintenance.html) en la pregunta inicial:

      set $can503 0;
      if (-f /home/shared/system/maintenance.html) {
      set $can503 1;
      }
      if ($uri ~* /maintenance-static/) {
      set $can503 0;
      }
      location /maintenance-static/ {
      root /home/shared/errors;
      }
      if ($can503 = 1) {
      return 503;
      }

Esta solución funciona sin errores en todos los navegadores y para varias páginas en la carpeta de shared/errors , por ej. maintenance.html, error.html, overload.html, etc.

Esta solución no está muy clara. Probablemente pueda sugerirme cómo hacerlo más limpio, pero recordando que estamos tratando con solicitudes separadas (y procesos nginx separados para cada archivo / solicitud en caso de alta carga, etc.) para el código html inicial y su contenido no podemos usar la misma regla con 503 redireccionando para todos los archivos.

Answer 3

Pasé dos horas buscando una respuesta a este problema, y ​​finalmente encontré esta publicación. Parece que debería ser más común. Mi solución cayó en algún lugar entre Frank''s y Wile''s. Según lo declarado por Wile, ciertos navegadores (Chrome, por ejemplo) elegirán no presentar el CSS / JS de ningún archivo que se haya recuperado del 503, incluso si los recuperó completa y correctamente.

Pero hay una solución que es menos intrépida que lo que hizo Wile. ¡Simplemente devuelve 200!

Mi solución completa fue la siguiente:

error_page 503 @maintenance;
location @maintenance {
root /path_to_static_root;
if (!-f $request_filename) {
rewrite ^(.*)$ /rest_of_path/maintenance.html break;
}
return 200;
}

Trabajado como un encanto. :)

Answer 4

esta solución funciona con una sola instrucción if, y también es mucho más legible y comprensible:

upstream unicorn {
server unix:/path/to/unicorn.sock;
}
server {
listen 3000 default deferred;
proxy_read_timeout 3600;
client_max_body_size 4G;
set_real_ip_from 0.0.0.0/0;
root /path/to/current/public;
try_files $uri/index.html $uri.html $uri @unicorn;
error_page 404 /404.html;
error_page 500 502 504 /500.html;
error_page 503 /system/maintenance.html;
location /404.html {
internal;
}
location /500.html {
internal;
}
location @unicorn {
if (-f $document_root/system/maintenance.html) {
return 503;
}
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
proxy_redirect off;
proxy_pass http://unicorn;
}
}

Answer 5

location @maintenance {
root /home/shared/errors;
rewrite (some/.jpg|some2/.gif)$ /$1 break;
rewrite ^(.*)$ /maintenance.html break;
}

Esto podría funcionar sin enumerar los archivos de la lista blanca:

location @maintenance {
root /home/shared/errors;
if (!-f $request_filename) {
rewrite ^(.*)$ /maintenance.html break;
}
}

Answer 6

server {
listen 80;
server_name myserv.trunk;
autoindex off;
access_log /var/log/nginx/sitename-access.log;
location ^~ /static/ {
root /home/dev/myserv-site/;
}
location ~ /(?P<language>en)?/? {
uwsgi_pass unix:///tmp/uwsgi.sock;
include uwsgi_params;
error_page 502 @fallback;
error_page 503 @maintenance;
if (-f /home/dev/myserv-site/maintenance.active) {
return 503;
}
}
location @fallback {
root /home/dev/myserv-site/;
if ($language) {
rewrite ^(?!//static//)(.*)$ /static/html/502.$language.html break;
}
rewrite ^(?!//static//)(.*)$ /static/html/502.zh.html break;
}
location @maintenance {
root /home/dev/myserv-site/;
if ($language) {
rewrite ^(?!//static//)(.*)$ /static/html/503.$language.html;
}
rewrite ^(?!//static//)(.*)$ /static/html/503.zh.html break;
}
}

Aquí hay una muestra de la página de error de mantenimiento traducible (503) o 502. Si el usuario va a http://site.com/en/ se mostrará la página en inglés (cuando exista el archivo maintenance.active). dir estático está dentro de myserv-site dir.