Improving pain points on bootstrap and rebuild

[pfaffman (Jay Pfaffman)]

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

@sam

Pain points I am interested in solving long term are

• Faster bootstrap
• Easier and more frequent base image updates
• More consistent update process from web upgrader vs a full rebuild
• Probably move default setup to 2 containers vs 1 container

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.

[codinghorror (Jeff Atwood)]

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

[pfaffman (Jay Pfaffman)]

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. 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.

[RBoy]

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)

[Falco]

@RBoy

What’s the difference between doing site/admin/upgrade via the button and doing a stop/rebuild from the CLI?

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

@RBoy

If I can do the former (which is practically no down time), why would I want to do the latter?

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

@RBoy

Can I automate the former?

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

[RBoy]

@Falco

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

RBoy:

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.