Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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
add comment

2 Answers

up vote 2 down vote accepted

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;
}
share|improve this answer
add comment

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;
    }
    ...
    
share|improve this answer
    
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 8 '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 8 '12 at 16:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.