Improving pain points on bootstrap and rebuild

Continuing the discussion from Can Discourse ship frequent Docker images that do not need to be bootstrapped?:

Well, it took me two years, but I finally bothered to learn how to create a separate data container and rebuild/upgrade the site with a minute rather than a quarter hour of downtime. Just yesterday I started thinking about creating a ./discourse-setup that would create two containers (based on data.yml and web_only.yml) rather than one.

I hadn’t started looking at launcher’s exit codes to see if I could safely script

./launcher bootstrap web
./launcher destroy web
./launcher start web

to avoid destroying the container if the new one didn’t get created.

Since the site isn’t down during a rebuild, reducing the build time is less critical.

1 Like

If the server is fast enough, the rebuild is more like 3 minutes. So there’s another way to solve rebuild times :wink:

1 Like

Yes, well. Moving off digital ocean isn’t an option for lots of people. Heck. Once someone offered to subsidize my getting such a server, but couldn’t justify it with my current business model. :joy: I’m getting closer now, but I’m still a ways off from that making fiscal sense.

Even with a fast Server, though the two container model reduces downtime dramatically.

So been trying to find an answer to this question which led me here.

  1. What’s the difference between doing site/admin/upgrade via the button and doing a stop/rebuild from the CLI?
  2. If I can do the former (which is practically no down time), why would I want to do the latter?
  3. Can I automate the former? (I guess the latter can be automated using a bash script with some delays in between the commands and cron scheduler)

One click updates Discourse, the software, but not the underlying docker image and all it’s software, like PostgreSQL, Ruby, etc.

Sometimes a rebuild is needed, when we update minimum requirements, like a new Ruby version.

That’s something that could probably already work, but not on the current backlog.

3 Likes

So I’m assuming that the one click upgrade will not work when an underlying component needs an upgrade right?

I’m trying to figure out if I can’t automate the upgrades and “forget” to upgrade for a few months or year or more and suddenly decide to upgrade - will I be able to?

It would be really cool if during setup discourse could setup an automatic upgrade script to run every X days or weeks or months. Maybe pick a day and time of a week or month to run the upgrade in the background essentially making it even (awesome) hands free to maintain.