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
1 Like
bootstrap: Bootstrap a container for the config based on a template
rebuild: Rebuild a container (destroy old, bootstrap, start new)
6 Likes
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.
3 Likes
Well, more like four minutes on a fast machine 
3 Likes
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
8 Likes
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.
5 Likes
Just a minor point for other people reading, not for @mpalmer who knows all this stuff 
. 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.
10 Likes
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?)
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.
4 Likes