동의합니다. 설명서에는 조정이 필요해 보입니다. 데이터 부분이 더 이상 작동하지 않는다는 것이 이상하게 느껴지네요.
1년에 한 번 정도 더 긴 다운타임이 발생해도 큰 문제는 아닙니다…
아니요, 기존 app.yml 설정과 함께 web_only.yml을 잘못 편집해서 제가 만든 문제들만 있었을 뿐입니다. 
1개의 좋아요
이 두 컨테이너 설정에서 이제 잘 작동하는 것 같아 기쁘게 보고합니다!
남은 문제는 CLI에서 다시 빌드하는 방법을 알려주는 사이트 텍스트(“app”)인데, 아주 사소한 문제입니다.
cc: @pfaffman
네. 하드코딩되어 있거든요. 기억이 안 나시면 텍스트를 커스터마이즈해야 합니다. 
1개의 좋아요
5개의 게시물이 새 주제로 분리되었습니다: Build fails due to ruby version mismatch
이건 절대 작동하지 않습니다. 전에 그걸 놓친 점 죄송합니다. OP(원문)를 업데이트했습니다. 데이터를 다시 구축해야 한다면, 다음 명령을 실행해야 합니다.
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
아니요. 바로 그 점이 예상되는 동작입니다. 다른 postgres가 파일에 접근하고 있는 동안 postgres를 다시 구축할 수 없습니다. 새로운 data 컨테이너가 생성되면, docker가 data라는 이름의 참조가 아닌 정확한 컨테이너에 연결되도록 되어 있으므로, web_only 컨테이너도 파괴하고 새로 시작해야 합니다.
1개의 좋아요
OP 수정 
과 Build fails due to ruby version mismatch 에 대한 도움을 주셔서 감사합니다.
1개의 좋아요
내가 미친 건지, 아니면 discourse-install 스크립트에 더 이상 –two-container 인수가 없는 건지 궁금합니다. 권장 위치(https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse)에서 바로 실행했는데, Hetzner의 새 Ubuntu 24.04 VPS에서 app.yml이 포함된 일반 1컨테이너 설정만 설치되었습니다. 아마도 그 과정에서 생성되는 discourse-setup을 실행해야 하는 건가 생각했지만, 그것도 똑같은 작업을 반복할 뿐이었습니다.
수동 설치 방법을 사용하고 ./discourse-setup --two-container를 실행하세요. 제가 마지막으로 이 방법을 사용했을 때 잘 작동했습니다.
또는 멋진 설치 스크립트를 사용하여 설치한 후, OP에서 언급된 대로 두 개의 컨테이너로 전환할 수도 있습니다.
@Falco와 @pmusaraj, 현재 INSTALL-cloud.md에서 참조할 수 있도록 구 INSTALL-cloud.md의 일부 내용을 어딘가에 보관해 두는 것이 유용할 것 같다고 생각하시나요?
1개의 좋아요
실제로 제거되었습니다. 위 위키에서 해당 참조를 삭제했습니다.
정보 주셔서 감사합니다. 왜 제거되었나요? 정말 유용한 방법이었는데.
Docker에 대해 충분히 숙지하지 않은 사용자들에 의해 수행된 두 건의 컨테이너 설치로 인해 지원 요청이 과도하게 증가했습니다. 이는 고급 설치 구성으로, Docker를 잘 다루는 사용자에게만 권장됩니다.
1개의 좋아요
결국 그 기능을 사용 중인 우리에게는 불편을 초래하는 셈이네요. 변경 사항에 대해 사전에 누구에게든 의견을 물었나요? OP 방식은 잘못 사용해도 스스로 문제를 만들 수 있으니, 그냥 그대로 두는 것도 방법이었을 것 같습니다.
누구의 부담이라는 말씀인가요? 이 스레드에서요? 지원은 팀보다는 자원봉사자/사용자들이 제공해 왔습니다.
1개의 좋아요
결국 samples 폴더에 web_only와 data를 그대로 두는 건가요? 두 개의 컨테이너를 사용하려는 사람들은 직접 복사하고 설정을 해야 하는 거죠? 이전에는 data 컨테이너를 업데이트하는 데 관심이 없었던 사용자에게 도움을 주는 것이 유일한 추가 지원이었습니다.
이제 우리는 많은 사람들에게 cp와 nano를 어떻게 사용하는지 알려줘야 합니다. 솔직히 cp와 nano를 모르면 두 컨테이너 구성을 실행하지 않는 것이 맞다고도 할 수 있습니다. Jeff는 cp와 nano를 모르면 Discourse를 설치하지 말아야 한다고 주장했지만, 저는 discourse-setup을 만들면서 그의 생각을 바꿨습니다.
앞으로 저는 dashboard.literatecomputing.com을 다시 작성하여 표준 설치를 중단할 것입니다(이제는 discourse-setup에 답변을 파이프할 수 없기 때문입니다). 그리고 그곳에서 2-컨테이너 설치를 옵션으로 유지할 것입니다.
4개의 좋아요
@Falco @pfaffman의 의견을 참고하여 다시 한번 검토해 주세요
나이는 아니다. 전체적으로 두 컨테이너에 대한 지원을 중단하는 방향으로 한 발짝 더 다가가는 것 같아서, 그렇게 되면 정말 큰일이 될 것 같다.
5개의 좋아요
오픈 소스의 장점이 바로 이것입니다. 각자 원하는 방식을 선택할 수 있으니까요!
수많은 사람들이 구형 컨테이너를 실행하는 것을 완전히 방치하는 것은 좋지 않으며, PostgreSQL의 주요 업데이트가 필요할 때마다 많은 혼란을 초래했습니다. 이로 인해 PostgreSQL 업데이트가 덜 자주 이루어졌고, 결과적으로 전체 제품의 품질이 저하되었습니다.
동의합니다 
2개(또는 N개) 컨테이너 설치에 대한 지원을 실제로 중단하는 것은 불가능합니다. Discourse를 별도의 PostgreSQL 서버를 사용하도록 설정에 문서화된 바와 같이, Discourse는 외부 데이터베이스에 기본적으로 연결할 수 있습니다.
유연성이 제거된 것은 아닙니다. 그러나 The Power of Defaults 와 유사하게, 우리가 만드는 도구에서 제공하는 모든 옵션은 고려해야 할 사항이 됩니다.
수천 줄의 스크립트를 제거하고 설치자를 단순화하여 훨씬 더 일반적인 사용 사례를 커버하는 것은 의도적인 선택이었습니다. 그러나 Discourse는 여전히 동일한 모든 사용 사례를 지원하며, 사람들이 원한다면 자신만의 길을 개척하는 것도 자유롭습니다.
2개의 좋아요
이 생산 방식이 큰 커스터마이징 없이도 계속 작동할 것이라는 안심의 말씀에 감사드립니다 
1개의 좋아요
제거된 메서드를 사용하던 사용자들의 편의성은 모든 사람에게 하나의 경로를 강제하는 것보다 희생되었습니다. 이것이 한 사람의 결정이었나요, 아니면 다른 사람들도 관여했나요?
codinghorror에서
"기본값은 소프트웨어 개발자로 살면서 내릴 수 있는 가장 중요한 설계 결정 중 하나라고 할 수 있습니다. 좋은 기본값을 선택하면 사용자는 소프트웨어의 유용함과 사용의 간편함을 칭찬할 것입니다. 반면, 나쁜 기본값을 선택하면 설정에 대한 사용자의 고통과 아마도 수많은 기술 지원 요청을 마주하게 될 것입니다."
제 생각에는 나쁜 기본값이 선택되었고, 이 선택/변경은 해당 변경 사항을 아쉬워하는 사용자 계층과의 관여, 토론, 또는 고려 없이 이루어졌습니다.
다시 묻지만, 누가 의도적으로 선택한 것인가요?
이 사용자는 그 발언을 오만함과 무례함으로 느낍니다. 마치 무시당하고 무시당하는 것처럼 느껴집니다. 그런 반응을 의도한 것은 아니었을 것이라 생각하지만, 여기까지 온 상황이 되었습니다.
전체적으로, 이 에피소드는 몇 주 전 @nat에게 보낸 개인 메시지에서 불평했던 내용과 일치합니다. CDCK/Meta에는 두 가지 불평등한 고객 계층이 있습니다. 호스팅을 위해 돈을 지불하는 사람들과 자체 호스팅을 하는 사람들입니다. 이 에피소드에서의 접근 방식은 이 두 계층 시스템의 최신이자 아마도 가장 심각한 예시입니다.
그럼에도 불구하고…
새로운 설치 프로그램을 칭찬합니다. 설치 문제와 1일차부터 이어져 온 결과적인 지원 요구를 잘 처리하고 있습니다.
변경 사항에 대해서는, CDCK는 원하는 대로 구축/변경할 권리가 있습니다. 이 점에 대해서는 이의가 없습니다. 제 희망은 그들이 사람들을 소외시키지 않는 방식으로 그렇게 해 주기를 바라는 것입니다.
마지막으로, codinghorror의 글을 다시 읽으면서 Jeff가 게시물에 개입했을 때의 상황들이 어떻게였는지 생각하게 되었습니다. 그의 게시물들은 종종 무시, 무례, 그리고 약간의 오만함이 느껴졌습니다. 다행히 저는 직접적인 대상이 된 적은 없었지만, 그 게시물 중 일부는 읽기 고통스러웠습니다. 최근 스태프와 게시물 처리 방식에 대한 제 경험과 이 에피소드는 매우 유사하게 느껴집니다. 아마도 제 생각이 너무 과장된 것일지도 모릅니다.
조금 가혹한 표현인 것 같습니다. 팀은 이 포럼에서 매일 직접 호스팅하는 사용자들을 도와주고 있으며, #unsupported-install에 해당하는 사용자들도 포함됩니다. 
4개의 좋아요
드디어 해결했습니다! 
@pfaffman
bootstrap은 launcher를 업데이트하지 않으며, launcher는 오래된 base image를 고정(pin)할 수 있습니다.
git pull은 이 고정을 업데이트하여 다음 bootstrap에서 더 새로운 이미지가 사용되도록 합니다. (rebuild는 일반적으로 자동으로 이미지를 가져옵니다.)
결국 이것이 git pull이 때때로 필요한 이유입니다 - bootstrap 프로세스가 launcher를 업데이트하지 않기 때문이죠!
bootstrap과 recreate만 수행한다면 이 루프에서 벗어나지 못할 것입니다.
이 부분이 rebuild와 일치하도록 수정되어야 하는지 궁금합니다.
1개의 좋아요