안녕하세요.
공식적으로 다루거나 지원하지 않더라도, Discourse/컨테이너가 더 빨리 시작/부팅되도록 조정하는 것이 가능한가요? (호스트 |& 컨테이너 자체의 리소스 조정을 제외하고)
단일 스탠드얼론 app.yml 파일 대신 여러 컨테이너 파일을 사용하는 방법을 시도해 볼 수 있습니다.
솔직히 말해, 거의 아무도 컨테이너를 자주 재빌드할 필요가 없지 않나요?
플러그인을 설치해야 하는 경우에도 컨테이너를 재빌드할 필요가 없습니다. 재빌드 없이 플러그인을 설치하는 비공식적인 방법을 알고 있습니다.
정말 컨테이너를 재시작한 후 페이지 서빙을 더 빨리 시작하는 것, 즉 부팅 속도를 높이는 것을 말씀하시는 건가요? 아니요. Rails와 모든 관련 구성 요소를 실행 상태까지 올리는 데 시간이 좀 걸립니다.
컨테이너 재빌드와 관련된 다운타임을 의미하신다면, 두 컨테이너 솔루션이 찾으시는 해결책입니다.
그것도 충분히 빠르지 않고 제로 다운타임이 필요하시다면, 로드 밸런서를 사용하여 새 컨테이너를 시작하는 동안 기존 컨테이너가 계속 페이지를 서빙하도록 하고, 새 컨테이너가 준비되면 기존 컨테이너를 종료하는 방식으로 처리할 수 있습니다.
제가 (반드시) 재구축을 의미하는 것은 아닙니다.
예를 들어, 제가 선호하는 방식대로 docker로 전체를 관리한다고 가정해 보겠습니다.
컨테이너의 docker 재시작만으로도 Discourse가 부팅 시 긴 작업 목록을 실행하는 것 같습니다 — 네, 제가 의도한 것이 바로 그거였습니다 — 이 Ruby/Rails 관련 설정을 조정하거나 줄일 수 있을까요? (왜 매번 시작할 때마다 모든 작업이 수행되는 걸까요? 이것이 영구적으로 유지될 수는 없나요?)
두 컨테이너 솔루션 — 그게 무엇인가요?
상호 충돌하지 않는 관련 구성 요소들을 두 개의 컨테이너에 나눠 두고, 동일한 호스트 위에서 (두 컨테이너 모두) 동일한 외부 pgSQL 및 Redis와 통신하는 것을 의미하나요?
아니면 무중단(zero-downtime) 설정을 의미하나요?
서빙을 준비하기 위해 대량의 코드를 로드해야 합니다. 스마트폰, 컴퓨터, 또는 최신 TV를 부팅해 본 적이 있나요? 시간이 좀 걸립니다. 정확히 그런 원리입니다. 컨테이너 안에는 전체 운영체제가 들어 있습니다.
네. rails와 nginx를 별도의 컨테이너로 분리하고, postgres와 redis를 다른 컨테이너에 두는 방식입니다 (또는 postgres와 redis를 제공하는 방식을 원하는 대로 구성할 수 있습니다).