I’m looking at automating upgrades of discourse. This is for the most basic single container install. Trying to keep things simple. The most basic would be to setup up this to run via cron: cd /var/discourse git pull ./launcher rebuild app Problem is you take the service offline for the rebuild even if there are no updates. I’d preferebly like to do something like this: if ./update_available.sh; then cd /var/discourse git pull ./launcher rebuild app fi (assuming the script exits with true if updates are available) Anyone know of any easy methods to get this info on the host? Thanks!

I’d suggest looking into how GitHub - discourse/docker_manager: Plugin for use with discourse docker image · GitHub works. It compares the running version to GitHub, and updates with close to no downtime. Perhaps you can automate that instead of doing a full rebuild each time?

You might check out having separate data and web containers. That way you don’t need to take the site down to build a new image.

Thanks for the suggestion. Interesting path, definitely. I’ve found what looks to be the function that initiates the update: lib/docker_manager/git_repo.rb a7b256245 class DockerManager::GitRepo attr_reader :path, :name, :branch def initialize(path, name=nil) @path = path @name = name @memoize = {} @branch = tracking_branch end def start_upgrading $redis.setnx(upgrade_key, latest_local_commit) end def stop_upgrading $redis.del(upgrade_key) end def upgrade_version @upgrade_version ||= $redis.get(upgrade_key) end But that can only be kicked off when I have detected the local git version, the version available and compared the two. So I would need to take care of that to mimic the user interaction with the interface, which is starting to look a bit complex. It would, as you point out, be a faster upgrade compared to rebuild. But if I already have local and remote git commit, I would be okay with using that in bash and just having the upgrade take a bit longer over poking this deep into discourse.

Thanks for the suggestion. I may need to dive into the documentation a bit more to understand fully. Is my understanding right that you are suggesting that I just build a new web container and then switch traffic over to the new one and pull down the old when done? I.e. “containers/web1.yml” and “containers/web2.yml”. I would need a load balancer or traffic forwarder of sorts in front of the containers, right?

Thanks for the link. Reading that thread and this post made it clear. The new web container can be build behind the scenes and then switched over. So I would end up with: cd /var/discourse git pull ./launcher bootstrap web_only ./launcher destroy web_only ./launcher start web_only Over cd /var/discourse git pull ./launcher rebuild app

[image] simonclausen: ./launcher bootstrap web_only ./launcher destroy web_only ./launcher start web_only or ./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only That way, if the bootstrap fails, you won’t kill your working server.

Yes, very good point. Thank you!

Looking up available upgrades via CLI

Product Support Self-hosting

pfaffman (Jay Pfaffman) August 18, 2017, 9:27pm 6

See Move from standalone container to separate web and data containers

Topic		Replies	Views
Completely automatic updates Feature	13	4421	June 27, 2018
How Discourse deals with upgrades Product Support	3	1094	January 29, 2020
How to tell whether to upgrade via web or console? Self-hosting	9	1020	July 10, 2024
关于discourse部署后更新升级问题 Self-hosting	5	425	January 9, 2026
Automating upgrade of Discourse and plugins Product Support	3	1073	April 30, 2016

Looking up available upgrades via CLI

Related topics