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

[图片] 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.

[图片] 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.

[图片] sam: Rebuild is a shortcut for the sequence: stop, bootstrap, destroy and then start 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.

What's the different between rebuild and bootstrap

Product Support Self-hosting

BobbyZopfan (Bobby) 2019 年9 月 28 日 12:31 11

你的意思是：停止、销毁……引导、启动？（即销毁应在引导之前。否则，它如何知道要从两个已停止的容器中删除哪一个？）

话题		回复	浏览量
Bootstrap && destroy && start Self-hosting two-container	3	245	2025 年2 月 9 日
The launcher command in the /var/discourse folder are not self-explaining Self-hosting	9	3495	2023 年3 月 7 日
Faster rebuilds? Self-hosting	22	9332	2019 年10 月 28 日
Rebuild problem Product Support	11	1922	2016 年4 月 23 日
Question about rebuild app Self-hosting	5	1057	2023 年3 月 27 日

What's the different between rebuild and bootstrap

相关话题