Improving pain points on bootstrap and rebuild

Dev
1

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
2

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
3

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.

4

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)
5

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.

4 Likes
6

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.