what’s the different between ./launcher rebuild app ./launcher bootstrap app they both tool slow , is where any command to modify config like UNICORN_WORKERS and then fast test it

bootstrap: Bootstrap a container for the config based on a template rebuild: Rebuild a container (destroy old, bootstrap, start new)

Like @vinothkannans said, they are basically the same. If you want to tweak memory settings, it’ll take 10 minutes to rebuild before you can see if there is a difference.

Well, more like four minutes on a fast machine :wink:

Rebuild is a shortcut for the sequence: stop, bootstrap, destroy and then start If you only need to amend env, do a destroy and then start

[image] sam: If you only need to amend env, do a destroy and then start Oh! That’s news to me. So when ./discourse-setup is re-run to change email and memory settings, it needs just ./launcher destroy app ./launcher start app And only if Let’s Encrypt changes does it need to ./launcher rebuild app? Is that right, @sam? If that’s so, @codinghorror, would you like a PR for that?

I think that only applies to the variables, not anything that happens to the config as a result of those variables?

There’s not, to my knowledge, any guaranteed delineation between “stuff that gets configured on rebuild” and “stuff that gets configured on container start”. That is, for example at the moment UNICORN_WORKERS only gets passed into the container via the environment on boot, however in the future we may need to mangle the container image at build time to apply the setting for some reason. Taking a quick rummage around, it looks like LETSENCRYPT_ACCOUNT_EMAIL does, indeed, get used in the image build process, so a destroy/start cycle after changing that setting in app.yml wouldn’t be effective.

[image] mpalmer: “stuff that gets configured on container start”. Just a minor point for other people reading, not for @mpalmer who knows all this stuff :slight_smile: . Nothing gets configured on container “start”, only on container “create”. So, for example, ./launcher stop app ./launcher start app Will not change anything in the environment. Stuff gets configured on container creation, which means that there needs to be no pre-existing container on the machine when you run start There are indeed ways of using ENV to bootstrap bits of hardcoded data in the container image. However we really should prefer params here. I always found this distinction to be just way to subtle for people to comprehend which is why I always ask people to do ./launcher rebuild and forget about all the nuance and edge caseyness here.

Destroy can come after bootstrap since the bootstrapped image hasn’t been started as a container yet. So the only container to be destroyed is the one that currently exists in the Stopped state. I think I explained this to you over the phone as well.

What's the different between rebuild and bootstrap

Product Support Self-hosting

BobbyZopfan (Bobby) September 28, 2019, 12:31pm 11

Did you mean: stop, destroy… bootstrap, start? (i.e. destroy would come before bootstrapping. Otherwise how would it know which one to delete from 2 stopped containers?)

Topic		Replies	Views
Bootstrap && destroy && start Self-hosting two-container	3	245	February 9, 2025
The launcher command in the /var/discourse folder are not self-explaining Self-hosting	9	3494	March 7, 2023
Faster rebuilds? Self-hosting	22	9331	October 28, 2019
Rebuild problem Product Support	11	1922	April 23, 2016
Question about rebuild app Self-hosting	5	1056	March 27, 2023

What's the different between rebuild and bootstrap

Related topics