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 
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
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.
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.
你的意思是：停止、销毁……引导、启动？（即销毁应在引导之前。否则，它如何知道要从两个已停止的容器中删除哪一个？）
销毁操作可以在引导之后执行，因为引导后的镜像尚未作为容器启动。因此，唯一需要销毁的容器是当前处于“已停止”状态的容器。
我想我在电话里也向你解释过这一点。