음… 이것은 제가 생각하기에 결정적인 차이점이며, 이 "관리자 인터페이스에서 업데이트"라는 개념은 과거 PHP 인터프리터만 있는 “웹 호스팅” 시절, 모든 것이 그 개념을 중심으로 구축되던 때를 상기시킵니다. 그리고 이것이 Discourse의 작동 방식과 관리 기대치에도 그대로 이어졌다고 생각합니다.
글쎄요, 제가 또 알아차린 점은 discourse가 상당히 무겁다는 것입니다(컨테이너가 시작될 때 무서운 수준으로 리소스를 소비하기 시작했거든요). 그러니까 네 - 이것이 문제가 될 수 있습니다.
Ruby 컨텍스트에서(대부분 컴파일되는 언어가 아닌 인터프리터 언어이므로) 그것들이 어떻게 "빌드"되는 건가요?
오프더셸프(시중 제품) 솔루션을 사용해보는 것이 더 나은 것은 아닌가요? postgres 설정도 단순히 커스텀 postgresql.conf 파일을 제공/마운트함으로써 쉽게 변경할 수 있으므로, 설정이 내장된 완전히 커스텀한 이미지가 필요하지는 않지 않나요… 그리고 설령 그것이 필요하다면, discourse는 매번 다시 빌드하는 대신 가져오기(pull)만 하면 되는 그런 사전 빌드된 이미지를 제공할 수 있을 것입니다…