The discussion revolves around whether web-based updates in Discourse replace container rebuilds and how to manage updates with minimal downtime. vitorl asks if web upgrades suffice or if rebuilding the container with ./launcher rebuild is still necessary, especially given downtime concerns. sam clarifies that most updates can be done via the web, but occasional rebuilds are needed for base image updates, and critical updates may be forced. vitorl encounters a Ruby version error during a web upgrade, prompting him to consider weekly rebuilds. sam notes the issue was fixed. vitorl faces a Git conflict during rebuilds, which sam resolves by advising a git reset --hard before rebuilding. vitorl attempts to automate rebuilds via cron but experiences log truncation. pfaffman suggests a two-container setup for better uptime, with a link to the guide here. vitorl finds the setup complex for his needs. dfriestedt asks about data container updates, and pfaffman confirms that web container upgrades handle database changes, while data container updates are only needed for PostgreSQL or Redis version changes, which occur infrequently.
I have been doing web based upgrades at admin/upgrade and since I tend to have very high up times, does this replace replace the updates that are done when rebuilding the container with ./launcher rebuild?
Also, when I reboot does the container auto-update itself?
Thanks!
Majority of your updates can be done via the web, once in a few months you need to rebuild to get updates to the base image. If we deem it critical we will force it upon you.
I was just upgrading stuff, and what a timing! I got a error
Discourse requires Ruby 2.5.2 or up
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
So I guess I’ll stick to rebuilding every week or so. The downtime is bad, but I don’t need to be up 99,9% of the time.
Oh … we got to force a rebuild here I just fixed that so others do not see this issue.
I don’t know if I’m doing something wrong, but I tried to do a rebuild via terminal and I’m getting this:
error: Your local changes to the following files would be overwritten by merge:
templates/import/mbox.template.yml
templates/web.ssl.template.yml
But I don’t use those templates, and I do not interact with templates files. I delete them and can proceed, but any idea why this could be happening?
And I’m not sure if you were being sarcastic, I have no reason to lie or anything…
cd /var/discourse
git reset --hard
git pull
./launcher rebuild app
Ok I’m trying to automate this, with a cronjob to rebuild the container after every reboot.
@reboot sleep 300 && /opt/discourse/launcher rebuild app > /root/discord-update.log
It seems to be working, but for some reason the log file get cut after Removing old container.
Is there some kind of recommended way to get automatic updates working?
I had to wait 300 seconds for the docker daemon to start. With this settings it should take 10 min after reboot to be back on air. Rebuilding takes 5 min with a SSD and 2 vCPU.
If you’re concerned about uptime, you should switch to a two container install.
For some reason the output of my script stops redirecting to the file… is there a guide on this two container install?
5 min of downtime every month is still like 99,5% uptime so unless the two container install is easy to do/manage it doesn’t worth it…
For a description see: Move from standalone container to separate web and data containers.
For a normal rebuild/upgrade It’s pretty much the same as a single container install. Rather than
./launcher rebuild app
you do
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only
I’m getting ready to migrate to separate data containers as described above.
When upgrading, do I ever need to update the data container? If so, when?
Also, can I assume the web container upgrade process will make necessary changes to the data tables, etc?
When there is a change to postgres or redis. Knowing when this has happened is a matter of keeping track of things and is the reason that many people think that the two container setup is too hard. I have scripts that check postgres and redis versions and upgrade the data container if a change has been made. Those changed happen every year or two, though sub-base upgrades happen a bit more often. Generally if you don’t upgrade from 13.1 to 13.5 it won’t matter much.
Yes.