"Down for Maintenance" page


(dougalcorn) #1

I like to keep up to date, but a couple times I’ve upgraded I’ve had users complain the site was down while I was doing it. I’ve had other rails apps have a maintenance page. Is there an easy way to put up a maintenance page while upgrading?


(Ben T) #2

Add a error_page handler to your nginx configuration for discourse. I’m not as familiar with Apache, so it may involve this page.

We can print a custom error assuming nginx is still running. It should be during updates, as it is just forwarding requests on our behalf to the rails application.

My additional settings are

server {
 error_page 502 /502.html;
 root   <document location>;
 **location / block from original config**
 location = /502.html {

 }
 }

The only oddity I encountered is the need for that second location block. Without it, nginx refuses to process the error_page from a different location. You can also use this method for other error codes, excluding 404.


(dougalcorn) #3

I see where you’re going with this, but I don’t know nginx config well enough. Can you explain it to me more specifically? Is this something we can add into the nginx.config.sample?

If this were setup, does it mean all 502s would go to that page? Should this be something that’s always running or only when doing an upgrade? Would it be fair enough to make a 502.html page that says “down for maintenance”?


(Ben T) #4

The 502 error implies that it tried to connect to one of the thin sockets, but failed to (Bad Gateway.) It’s safe to assume that either you are upgrading, or something is not working. If you’re using the sample config, it looks something like this. There’s an addition in near the top, and at the bottom.

Without this handling, you should see nginx make an error page called 502 bad gateway if you stop the thin sockets. This just replaces that page with a different one of your own design. It causes all 502s matching that server request to go to this html page instead.


(Brentley Jones) #5

@sam What is your thoughts on getting something as smooth as a 10-second zero-downtime deploy?

http://ariejan.net/2011/09/14/lighting-fast-zero-downtime-deployments-with-git-capistrano-nginx-and-unicorn/

I’m assuming that once there is proper Unicorn support that this would be possible? Since I’m a noob with Ruby though, what files/folders would I have to add to my git branch to capture the bundler install and assets:precompile stages (which take the longest)?


(Ben T) #6

If you switched the below with unicorn, it’d be almost identical.


(Sam Saffron) #7

admin/docker does zero downtime deploys, if you do a data/web container you can reduce downtime to about 5-10 secs on container rebuild. Chuck haproxy in front and you get zero downtime during container rebuild.

It would be really cool if docker allowed you to reassign ports while a container is running


How to get 5-10 second rebuilds?
(Sebastian) #8

Sorry to dig this up, but I am also wondering about this issue. I know tons of “coming soon” or “maintenance mode” Wordpress plugins.
Why not a modal dialog that shows a maintenance message (to be configured via admin), shown to any non-user or non-admin/owner user while active, the board meanwhile being locked down and more or less invisible to humans (still indexable, and maybe grayed out in the back).
This would be helpful for admins fooling around with design aspects, reordering categories or other things, without interference, and will give users something to look forward to…


(Dave Higgins) #9

Absence of this option presumes that Discourse site will always be working properly.
E.g. what if a private forum is somehow accessible by all (whether by bug, or by admin user error, whatever).
The safe thing to do is close all access and test.
At the moment there is no option for that.

Does anybody know of a non-DNS based workaround to shut the site if needed?


#10

I saw that are forum was down the new update it great!


(Jeff Atwood) #11

See