안녕하세요, 테마와 플러그인을 설치하거나 업데이트할 때 사이트가 오프라인 상태가 되는 것이 정상인가요?
사이트를 재빌드할 때 사이트가 오프라인 상태가 되는 것은 정상적인 현상입니다.
해결 방법으로는 두 가지가 있습니다. 하나는 2개 컨테이너 설치를 사용하여 새로운 컨테이너를 빌드함으로써 다운타임을 1분 미만으로 줄이는 것이고, 다른 하나는 사이트가 중단된 동안 “조금만 기다려 주세요” 페이지를 표시하도록 하는 것입니다. 후자의 경우 다운타임 자체는 변하지 않지만, 사이트가 중단된 사실을 알고 있다는 것을 모든 사용자에게 알릴 수 있습니다.
모두는 이 두 가지 해결 방법 중 적어도 하나는 너무 어렵고 전혀 가치가 없다고 생각합니다.
추가로, 플러그인과 달리 테마 및 테마 컴포넌트를 설치하거나 업데이트할 때 오프라인 시간이 필요하지 않습니다. 
언급하신 방법에 대한 문서가 있나요? 또한, 담론 측면에서 SEO에 매우 적합하다고 보이지만, 로딩 중 중단이 발생하여 Google 봇이 사이트를 크롤링할 수 없다는 점은 아이러니합니다.
새 플러그인을 설치할 것으로 예상되는 횟수는 몇 번인가요? 이는 일반적으로 매우 드문 경우입니다.
컨테이너가 전환되는 동안 서비스 중단이 거의 없으므로, 플러그인을 온라인으로 업데이트할 수 있습니다.
답변 주셔서 감사합니다. 
용기가 나실 때 Add an offline page to display when Discourse is rebuilding or starting up 링크를 확인해 보세요.
안녕하세요 
확실하지 않고 제가 틀렸을 수도 있지만(아직 시도해 보지 않았습니다) 이게 이제 코어 기능이 된 건가요? 몇 달 전 discourse/templates에 offline-page.template.yml이라는 새로운 템플릿이 추가되었고, 그 안에서는 https://github.com/discourse/discourse-offline-page를 트리거합니다. 이 플러그인은 Discourse 로딩 중에 표시되는 정적 HTML 사이트입니다. discourse_docker에도 이에 대한 PR이 있습니다: FEATURE: add offline page template - Pull Request #752 - discourse/discourse_docker - GitHub
그렇게 하면 절반만 영향을 받을 것 같은데? 제가 리빌드를 제대로 이해하고 있다면, 시작할 때는 표시되지만 리빌드할 때는 표시되지 않을 겁니다:
nginx는 사용 가능하지만 rails는 사용 불가능할 때, https://github.com/discourse/discourse-offline-page에서 정적 HTML 파일을 가져와서 서빙하도록 템플릿을 추가합니다.
^ 그 GitHub PR입니다
하지만 올바른 방향으로의 한 걸음, @Don (그리고 @featheredtoast!) 감사합니다.
@Firepup650 저도 왜 못 봤는지 궁금했는데, 당신이 그 이유를 알려주신 것 같네요!
여기 좋은 
가 있네요! 
이것이 나중에 nginx 컨테이너를 별도로 빌드하는 영구적인 2컨테이너 표준 구성으로 가는 전단계가 될까 궁금하네요. 
붙잡혔네요. 오프라인 페이지 제공을 더 널리 가능하게 만들기 위한 움직임이 진행 중입니다. 언급된 커밋과 저장소는 이를 위한 기반 작업일 뿐, 아직 완전히 구현되지는 않았습니다.
아무 이유 없이 내 사용자들은 리빌딩 중이라는 알림을 전혀 보고 있지 않습니다. 적어도 채팅에서는 그렇고, 그래서 사용자가 방금 작성한 메시지를 잃어버리는 사고가 몇 번 있었습니다.
제 생각에는 이미 로그인된 사용자에게 다운타임을 전혀 알리지 않는 상황이 Discourse의 가장 큰 단일 UX 문제입니다. 이 앱의 본질적인 특성에서 비롯된 이유를 이해할 수는 있고, 개발자들도 처음부터 스스로를 궁지에 몰아넣은 상황(드래프트 등 몇 가지 다른 상황과 비슷합니다)이지만, 그로 인해 문제 자체가 사라지는 것은 아닙니다.
우리는 몇 가지 우회 방법을 가지고 있습니다. 그중 하나는 Discourse 앞에 Nginx를 리버스 프록시로 사용해서 조정된 오류 페이지를 표시하는 것입니다. 그리고 관리자가 문제를 겪으면 답변은 “우리는 표준적인 것만 지원합니다”가 됩니다. 그것이 제가 그 방법을 포기한 실제 이유였습니다.
서로 다른 두 개의 컨테이너를 사용하는 것이 하나의 해결책입니다. 아니면 적어도 다운타임을 매우 짧게 유지할 수 있습니다. 그 방법에 대한 경고가 너무 많아서 그런 길을 따르는 것이 조금 무섭습니다.
또는 가끔만 업그레이드하고, 발생 전에 사용자에게 알린 후 공개 액세스를 종료할 수도 있습니다. 네, 그건 하나의 해결책이지만… 지금은 2024년이고 제 환경에서는 은행 시스템만이 그렇게 하고 있습니다 
스테이징 서버를 사용하는 것은 해야 할 일입니다. 물론, 기업 수준의 해결책으로 비용이 많이 들고 제대로 하려면 꽤 어려운 방법이며, 자체 IT 팀이 필요합니다.
그래서 새롭고 유출된 계획들 
은 정말로 개선 사항입니다. 네, 별도 컨테이너가 필요하다면 심해로 뛰어드는 데 시간이 될 것 같습니다.
거의 정확히 같은 내용이지만, 드물게 데이터 컨테이너를 다시 빌드해야 하는 경우도 있습니다.
하지만 다운타임은 20분보다 훨씬 짧지 않나요?
채팅은 일반 사이트 뷰와 다른 점이 있을 수 있습니다. 페이지 캐싱이 가능한 일반 사이트와 달리, 채팅은 더 실시간적인 접근 방식이기 때문입니다.
동의합니다. 제 생각에 계획된 유지보수 공지는 옛날 DOS 기반 다이얼업 BBS 시절처럼 하는 것이 가장 좋습니다. 당시에는 계획된 유지보수 종료에 대한 시스템 메시지를 통해 경고하고, 지정된 시간에 사용자를 로그아웃시키는 옵션이 있었습니다. 그 시절에는 주로 네트워크로 연결된 BBS들 간의 메일 패킷 전송을 위해 이러한 유지보수가 이루어졌습니다.
네. 다운타임은 보통 1분 미만이지만, 한 컨테이너를 재구성하는 동안 다른 컨테이너가 빌드되도록 충분한 RAM 또는 스왑 공간이 필요합니다.