Currently when we are doing any kind of maintenance (aside from simply updating) and want to take the site offline or set it to read-only there is no way of giving visitors a message about what is going on or how long of an estimate there may be for the system to be inaccessible.
It would be nice to have a comprehensive offline mode that would allow administration to give status updates and messages to the inbound visitors during this downtime so as to manage expectations and to make the visitors feel good about the situation vs wondering what might be going on.
For posterity here’s the original remark that spawned this split as per @jomaxro:
What really needs to be done here is an integrated offline / maintenance mode that incorporates this methodology and the ability to give customized messages to users while the system is in offline and/or maintenance mode.
It might be something that’s integrated into the upgrade manager (rename upgrade manager to “Discourse System Manager” and have upgrades, logs, processes, and backups all together in this area).
This would both make the system less fragile, more friendly and useful for both admins + users.
Docker Manager, the official plugin we support for upgrades, does not cause any downtime. There’s shouldn’t be a need for changes to the plugin, because it already supports downtime-free upgrades. The issue this howto addresses is upgrades (rebuilds) done from the command line. These are only required infrequently, a few times a year, when we need to upgrade an underlying dependency, like the Ruby version, or Postgres.
It is not possible to make Docker Manager handle such upgrades, as Docker Manager, like all of Discourse, is down during a rebuild. Any solution must be outside Discourse, like the Nginx proxy solution this topic supplies.
Hmm, I think there are other options here that would be more unified with the nature of Discourse… Instead of shooting this concept down, let’s talk about ways to improve the overall experience in this regard, especially if an admin needs to - for one reason or another - take the site down for maintenance.
One thought that comes to mind: why not incorporate the Nginx proxy solution as per OP into the Docker setup and thus it becomes both more predictable, manageable and consistent for both users/admins of Discourse + support (folks like yourself here on the forum) instead of dealing with uncoupled solutions such as the option presented herein?
If you wish to have minimized outages during ./launcher rebuild app you are going to need a multi container setup.
This is already documented. It is a more complex setup.
To have launcher rebuild in a single container mode have “offline” page we would have to swap the container out with a “site is offline” special dedicated container. This is not impossible but would require about 2 weeks of engineering to get it to work perfectly. I do not think we can afford to fund this at the moment given how rare rebuilding a container is and how we already have a documented way of doing disruption free rebuilds.
The two-container install makes for minimum downtime upgrades most of the time. Sometimes building the new container does a migration that crashes the running site. There’s a way around it, but it’s fairly complicated and those updates happen pretty rarely.
You could also re-point your DNS (or have an elastic IP or whatever Digital Ocean calls it) and spin up a droplet/whatever AWS calls it with a web server with your status message in it.
By the way @jomaxro how did you split off my post to this new topic here? What were the steps you followed, this would be rather handy and useful to know… I’m not seeing any methodology for this in stock Discourse.