nginx维护页面出现内容问题

问题描述

要在部署期间显示维护页面，我一直在nginx中使用下一个配置:

To show maintenance page during deploy I've always used next config in nginx:

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

error_page 503 @maintenance;

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

一切正常，直到我需要向维护页面添加静态内容(图像，样式表等)

And everything was ok until I needed to add static content to maintenance page (images, stylesheets, etc.)

没有静态内容可用于error.log中的此类日志:

No of static content work with such logs in 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"

这是合乎逻辑的-如果我将所有内容都重写为maintenance.html，则意味着不排除静态内容.

Which is logical - if I do rewrite everything to maintenance.html that means that static content is not exclusion.

但是，除了物理上存在于root /home/shared/errors文件夹中的文件之外，我找不到任何合适的解决方案来重定向到每个文件.

But I cannot find any proper solution to make redirect to every file except that ones which are physically existed in root /home/shared/errors folder.

PS. /home/shared/errors不会与公共项目文件夹共享任何资源-这是完全独立的文件夹(即使没有指向该项目的/current的符号链接.

PS. /home/shared/errors does not share any resources with common project folder - this is completely separate folder (even without any symlinks to /current for the project.

推荐答案

对不起，弗兰克·法默(Frank Farmer)，但这行不通.

I'm sorry, Frank Farmer, but this doesn't work.

有效但并非那么整洁的

以及请求的工作方式->

And how requests work ->

1. 我使用规则#1

1. I use rule #1

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

此规则支持命名位置location @maintenance，并且对于在root /home/shared/errors处常见的重定向到/maintenance.html的情况，一切正常.

this rule has a support of named location location @maintenance and for the common redirect to /maintenance.html at root /home/shared/errors everything works.

此页面包含图像some.jpg-要接收该图像，浏览器将启动新请求，并且此新请求再次达到规则#1

this page contains and image some.jpg - to receive this image browser starts new request and this new request again hits rule #1

所有这些都在最初的问题BUT中描述了

all of this was described in initial question BUT

如果我像Frank Farmer的答案中那样使用某些if魔法，则可以将服务器指向请求的文件，但HTTP答案将是503，浏览器(在我的测试中，除Safari以外的所有浏览器)都会在调试控制台中引发错误并显示图像但在相同情况下请勿处理CSS文件.

if I use some if magic like in Frank Farmer's answers I can point server to requested file BUT HTTP answer will be 503 and browsers (all, except Safari, in my test) throws errors in debug console and do show image but do not process CSS-files in the same situation.

这很关键.

我尝试使用位置魔术来解决我的新内容请求-这意味着我必须:

I tried to resolve this using location magic for my new content-requests - that means that I have to:

1. 请勿对内容请求进行return 503并完全跳过命名位置.

1. do NOT return 503 for content requests and skip named location at all.

进行更改root /home/shared/errors，因为维护内容仍然存在.

do change root /home/shared/errors because maintenance content is still there.

最后，我有了下一个解决方案:

Finally, I've got next solution:

1. 为所有静态内容创建maintenance-static文件夹，并更改我的maintenance.html文件和维护静态样式表中的路径

1. create maintenance-static folder for all static content and change paths in my maintenance.html file and maintenance-static stylesheets

接下来使用这些规则(我相信它们是自描述性的)替换初始问题中的单个if (-f /home/shared/system/maintenance.html):

next use these rules (I believe they are self-descriptive) which replace single if (-f /home/shared/system/maintenance.html) in initial question:

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;
}

例如，此解决方案在所有浏览器中以及shared/errors文件夹中的许多页面中均能正常运行. maintenance.html，error.html，overload.html等.

This solution works without any errors in all browsers and for numerous of pages in shared/errors folder, for ex. maintenance.html, error.html, overload.html, etc.

这个解决方案还不是很清楚-可能您可以提示我如何使其更整洁，但是请记住，我们正在处理单独的请求(在高负载的情况下，每个文件/请求都有单独的nginx进程，等等).初始html及其内容，我们不能对所有文件使用503重定向使用相同的规则.

This solution is not really clear - probably you can hint me how I can make it neater, but remembering we are dealing with separate requests (and separate nginx processes for each file/request in case of high load, etc.) for initial html and its content we cannot use same rule with 503 redirecting for all files.

这篇关于nginx维护页面出现内容问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！