What's the different between rebuild and bootstrap

(Gastrodia) #1

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

(Vinoth Kannan) #2

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

(Jay Pfaffman) #3

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.

(Jeff Atwood) #4

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

(Sam Saffron) #5

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

(Jay Pfaffman) #6

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?

(Jeff Atwood) #7

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

(Matt Palmer) #8

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.

(Sam Saffron) #9

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.