8

I am looking for a solution to automate one of our application's deployment process. In the beginning of deployment, I would like to programmatically set the specified server into maintenance mode and finally after the deployment has been completed, remove the maintenance mode flag from the nginx server.

By maintenance mode, I mean that nginx should response with HTTP Response Code 503 to all the requests (with possible custom page).

I know how to set the server block to respond with 503 code (see http://www.cyberciti.biz/faq/custom-nginx-maintenance-page-with-http503/) but the question is about how to do this programmatically and most efficiently.

Two options have came to my mind:

Option 1: At the beginning of the deployment process, write a maintenance file into document root and conditionally check an existence of the maintenance file in nginx server config:

server {
    if (-f $document_root/in_maintenance_mode) {
        return 503;
    }
}

This method contains certain overhead as the file existence is checked for each request. Is it possible to check the file existence only when loading the nginx config?

Option 2: Deployment script replaces the whole nginx server configuration file with a maintenance version and swaps it back in the end of the deployment. If this method is used, I am concerned about possible other automation processes like puppet that may be override the maintenance configuration file.

Ville Mattila
  • 459
  • 7
  • 12
  • I believe Option 1 is the standard way of doing this. Yes, there will be overhead with each request. On the other hand, is the overhead killing you? Option 2 requires that the deployment script has sysadmin privs over the web server part of the stack. That may be true in your case, but it's not universally true. – cjc Nov 16 '12 at 13:26
  • @cjc thanks for your comment. No, not in fact, that overhead is not killing - I just would like to avoid any unnecessary overhead. In this case, we can even use our server's `/run/shm` so checking the file existence does not hit the disk. All other comments are welcome too. – Ville Mattila Nov 17 '12 at 17:57

2 Answers2

5

Option 1 is the best choice. If additional file request bothers you (although there are almost no overhead in it) you can replace it to variable check:

set $maintenance "on";
if ($maintenance = "on") {
    return 503;
}
Andrei Mikhaltsov
  • 2,987
  • 1
  • 22
  • 31
0

Something I do is this:

  • not use an explicit switch but have haproxy (or varnish) be the next component upstream
  • disable the next component or move it to a separate port

  • use the following snippet:

    ...
error_page 502 503 /_maintenance/index.html;
location ^~ /_maintenance {
    alias some/place/on/your/disk/static/_maintenance;
}
...
Theuni
  • 938
  • 5
  • 14
  • Thanks for your comment. I believe that adding one more component to the stack only for the maintenance mode is very much overhead. Altough, Varnish may help for other issues. – Ville Mattila Dec 08 '12 at 13:28
  • Right. My setup generally involves nginx/varnish/haproxy. I leave out varnish if I really don't need it. But haproxy is really valuable for it's "live monitoring" and very useful logging of timings, queue lengths etc. – Theuni Dec 08 '12 at 16:57