Bootstrap && destroy && start

제품 지원 자체 호스팅
1

이것은 아주 기초적인 질문입니다.

컨테이너 설정 두 개를 준비해 두었는데, 좀 조용한 순간이 오면 실행하려고 합니다.

하지만 왜 항상 이렇게 안내하죠:

./launcher bootstrap .. && ./launcher destroy .. && ./launcher start ..

처음 할 때는 이해가 가는 것 같습니다. 솔직히 말해서: bootstrap과 rebuild의 차이를 전혀 이해하지 못하지만, 전지전능한 AI가 처음에는 bootstrap을 하라고 했거든요. 뭔가 개발자용 특수 작업이래서요. 그 이후에는 매번 rebuild를 하면 된다고 했습니다.

그러면 왜 ./launcher rebuild web_only로 끝내는 게 아니죠? 만약 먼저 destroy를 하면 rebuild가 실패했을 때 재시작할 것이 아무것도 없잖아요, 맞죠?

모든 것을 업데이트할 때는 web_only를 먼저 중지하고, 그 다음 data를 처리하고, 마지막으로 web_only를 다시 시작해야 한다는 것은 이해합니다.

2

rebuild를 수행하면 컨테이너를 종료한 다음 bootstrap을 실행하고, 기존 컨테이너를 제거한 후 새 컨테이너를 시작합니다.

rebuild는 새 컨테이너를 시작할 준비가 될 때까지 기존 컨테이너를 제거하지 않습니다.

bootstrap이 실패하면 기존 컨테이너를 직접 다시 시작할 수 있습니다.

처음에는 rebuild를 수행하지 않을 이유가 없습니다.

이후 빌드에서는 기존 컨테이너가 새 컨테이너가 빌드되는 동안에도 계속 요청을 처리할 수 있도록 bootstrap을 수행하는 것이 좋습니다.

데이터 컨테이너의 경우, 두 개의 데이터베이스 인스턴스가 동일한 파일을 수정하는 것을 원치 않으므로 항상 rebuild를 수행해야 합니다.

PG 업그레이드의 경우, 데이터베이스 없이는 웹이 작동할 수 없으므로 데이터 컨테이너를 rebuild하기 전에 모든 것을 중지해야 합니다.

rebuild는 "git pull"도 실행하므로, 이 과정을 제어하려면 bootstrap을 대신 사용할 수 있습니다.

3

컨테이너 개념을 이해하는 데 여전히 어려움을 겪고 있지만, 내 머리 위로 스쳐 지나가는 것들이 꽤 많습니다.

하지만 이제 순서는 알게 되었습니다. 무엇을, 언제, 그리고 (거의) 왜 하는지 말이죠.

감사합니다.

4

전체 컴퓨터의 하드 드라이브와 같은 개념입니다. 컨테이너는 포트나 운영체제가 접근할 수 있는 파일 업데이트를 통해 연결할 수 있는 경로가 제한된 전체 컴퓨터라고 보면 됩니다.