Adding an offline page when rebuilding

Hm. We are not sure if changing that text actually works for us. Do we have to consider something special here when amending this guy?


Also, we would like to mention that during specific time range while the site was down, it was yelling differently like

image

Do you have an idea how we would be able to change that also?

I use that, but i want a custom offline webpage and im not able to do it

Wonderful guide.
But if only you had told some commands to auto-renew this certificate also. It’d be a complete guide.
Because I’ve seen the link mentioned here. But that link only tells to install the certificate fresh. Or to renew it.
But I couldn’t find the guidance to ‘Auto-renew’ the same.

Thanks.

1 Like

Good point! I updated this section above in the original post :arrow_double_up:

1 Like

Has anyone else noticed that they are seeing a more generic 500 error when the upgrade occurs? I might have caught it at a bad time maybe?

1 Like

When the container is stopped during a rebuild there’s nothing running to provide an error 500.

4 Likes

Has anyone tried to use another Docker container for that to avoid all these manual steps, as suggested in the beginning?

Yes, many have. See How to move from standalone container to separate web and data containers. Do note that separate containers is a more complex install, and many of the guides here on Meta assume a single container (standalone) install. Before you more to separate containers, be sure you understand what the two containers do, and how you’d interact with them going forward. Biggest item to note: app will no longer be a valid target for the ./launcher command.

5 Likes

hm, this topic still mentions “nginx in front” for some reason in two posts…

btw what I actually want is

  • to have the offline page discussed here
  • redirect http --> https and root domain --> www on my web server. I don’t want to use Cloudflare for that because some of its IPs are banned in Russia.

So as I understand I just need to figure out how to do that in the web only container :grinning:

Now I’m confused.

Neither of these goals require a separate container setup. Are you looking to configure both of the above steps and independently are looking for separate containers? Or were you looking at separate containers thinking that they’re needed to complete the above?

As I understand the offline (rebuilding) page handling cannot be in the same container, since it will not be running. So the proposed solution in the current topic is to add nginx in front. But as was discussed in this topic, it requires lots of manual steps and OS-specific, so I thought that using another Docker container for this front nginx would be more reliable and easier to maintain.

Ah, now I’m following. In that case, ignore the topic I linked to previously. That discussing separating the Discourse web server from the database. That isn’t needed here.

Installing Nginx in a docker container, rather than directly onto the OS is definitely possible, but I’m not aware of any Discourse-specific guides to do so. If you go this route, please be sure you understand the OP of this topic (the necessary changes to create the offline page and install an nginx proxy in front), and that you are well versed in how docker works, especially configuring networking between two docker containers. Also note that we’re likely to be limited in the help we can provide, as this is not something we have experience doing.

I’ve also realized this is no longer working.

I had implemented @fefrei’s approach back in early november and it was definitely working then. Maybe it’s because I was stopping the container manually and doing a git pull instead of using /admin/upgrade.

1 Like

4 posts were split to a new topic: Add support for a native offline page when rebuilding

We did exactly that recently and the offline page successfully kicked in.

Right now, we just went for the online upgrade through /admin/upgrade and found Discourse did not go offline at all! Regardless whether this has been improved recently or not or if we just have been lucky this time, it is great to see an online upgrade happening without experiencing any significant downtime behavior at all.

Discourse should never go offline when running upgrades through Docker Manager (/admin/upgrade). Does it usually go offline for you? If so, we should start a #support topic about that.

Maybe we just implemented the offline page because we started using the upgrade procedure »stop container, git pull, launcher rebuild« after being hit by things like [1,2,3] for a few times actually.

Maybe something changed on the robustness of killing PostgreSQL if it wouldn’t shutdown in time to run through the upgrade process smoothly.

Either way, the online upgrade (again) worked well for us when giving it another shot right now. So, nevermind and sorry for the noise.

[1] Discourse stuck on "Currently Upgrading"
[2] Upgrade failed due to unclean database shutdown
[3] Upgrade failed due to unclean database shutdown II

3 Likes

That’s a bit confusing, since what follows is a guide for installing and configuring nginx outside the container.

In any case, today I realized an additional benefit of this external nginx configuration: If you are used to seeing IP addresses 127.0.0.1 or your docker address (probably starting with 172.) as a registration or login IP address, it may have been because IPv6 traffic being forwarded into the container did not carry its IPv6 address along with it, unlike IPv4. With this configuration, you will now see correct IPv6 addresses instead of local addresses.

In other words, this configuration is essentially required for correct function of a useful administrative tool on the increasingly-IPv6 internet. (In the US, this includes lots of mobile traffic.)

4 Likes

Thanks for this very helpful guide! A couple of comments:

I think sudo apt-get install letsencrypt has been replaced with sudo apt-get install certbot. Running the former, I get the notice Note, selecting 'certbot' instead of 'letsencrypt'

A friend noticed that Facebook sharing of the site showed a preview of “301 moved permanently”.

Edit: I had originally replaced the location / section of the port 80 server block with the location / section of the port 443 server block. But I think that’s redundant. Instead I just deleted the port 80 server block, which served as a redirect block, and added:

    listen [::]:80;
    listen 80;

in the appropriate section of the main server block.

I also enabled https redirect (not sure if that’s necessary) from within Discourse settings.

That fixed the issue with FB sharing, and it does seem as though regular HTTP requests are being redirected to HTTPS. If there is another or better method, please let me know.

2 Likes

Thanks for the tutorial, it’s great. Now my 502 page looks much better.
In my practical case I have to add the nginx configuration to the /etc/nginx/sites-enabled/discourse.conf file.
I have successfully installed Discouse after nginx is running wordpress.

2 Likes