Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2개의 좋아요
Hi there,
Introduction
Thanks for that solution, @fefrei! We’ve implemented this on https://community.hiveeyes.org/ and it works like a charm.
Further thoughts
However, we would like to reference the related question by @mlinksva at Site maintenance mode during rebuilds? here, as this also resonates with us and does not get solved by the /errorpages solution yet. This is about improving the generic text “Sorry, we couldn’t load that topic, possibly due to a connection problem.”. We will try to outline this in more detail.
Serving discourse_offline.html
This is perfect when users come along fresh to the site.
Serving a different “Sorry for that” text
However, when navigating within Discourse, it will yell at you like
without reveilling anything about the reason.
As we know you already, there will probably be a customization feature for being able to change that text, right? We might just have missed that. We’ve also not investigated whether the Feature Admin » Backup » Enable read-only would solve that already as outlined in Maintenance Mode?.
Nevertheless, it made sense to us to bring up this topic here again and hope you don’t mind if that would have been silly.
With kind regards,
Andreas.
P.S.: @staff: As this discussion somehow spiraled out of control regarding appropriate Nginx or Web server configuration details, I would like to suggest a thorough refactoring by splitting these posts into an appropriately named topic like “Configuring web server for offline page”. I’m sure you will find a good title. Thanks already if you like that suggestion and find it worth to follow.
Now, we actually do feel silly after finding it right away as a customizable site text block:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
We’ve changed the standard text js.topic.server_error.description to read:
Thanks for listening ;].
3개의 좋아요
Hm. We are not sure if changing that text actually works for us. Do we have to consider something special here when amending this guy?
Also, we would like to mention that during specific time range while the site was down, it was yelling differently like
Do you have an idea how we would be able to change that also?
1개의 좋아요
I use that, but i want a custom offline webpage and im not able to do it
Wonderful guide.
But if only you had told some commands to auto-renew this certificate also. It’d be a complete guide.
Because I’ve seen the link mentioned here. But that link only tells to install the certificate fresh. Or to renew it.
But I couldn’t find the guidance to ‘Auto-renew’ the same.
Thanks.
1개의 좋아요
Good point! I updated this section above in the original post 
1개의 좋아요
업그레이드가 진행될 때 더 일반적인 500 에러가 표시되는 것을 다른 분들도 목격하셨나요? 제가 시기를 잘못 잡은 건가요?
1개의 좋아요
재빌드 중에 컨테이너가 중지되면, 500 에러를 반환할 프로세스가 실행되지 않습니다.
4개의 좋아요
처음에 제안된 대로 이러한 수동 단계를 피하기 위해 다른 Docker 컨테이너를 사용해 본 사람이 있습니까?
네, 이미 많은 분들이 그렇게 하셨습니다. Move from standalone container to separate web and data containers 를 참고해 주세요. 단, 컨테이너를 분리하는 방식은 설치 과정이 더 복잡하며, 메타 사이트의 많은 가이드는 단일 컨테이너(스탠드얼론) 설치를 전제로 하고 있습니다. 컨테이너를 분리하기 전에 두 컨테이너가 각각 어떤 역할을 하는지, 그리고 앞으로 어떻게 상호작용해야 하는지 충분히 이해하고 있는지 확인하시기 바랍니다. 특히 주목할 점은: ./launcher 명령어의 유효한 대상(target)으로 app을 더 이상 사용할 수 없다는 것입니다.
5개의 좋아요
음, 이 주제에서 왜인지 두 개의 게시물에 여전히 "앞단에 nginx"라고 언급되어 있네요…
그리고 실제로 제가 원하는 것은
- 여기서 오프라인 페이지를 논의하는 것
- 웹 서버에서 http → https 및 루트 도메인 → www로 리다이렉트하는 것입니다. 러시아에서 일부 IP가 차단되어 있어서 Cloudflare를 이를 위해 사용하길 원하지 않습니다.
제가 이해하기로는 웹 전용 컨테이너에서 어떻게 하면 되는지 알아내면 되는 것 같습니다 
이제 좀 혼란스럽네요.
위 두 가지 목표 모두 별도의 컨테이너 구성을 요구하지 않습니다. 위의 두 단계를 설정하되, 각각 독립적으로 별도의 컨테이너를 원하시나요? 아니면 위의 내용을 완료하기 위해 별도의 컨테이너가 필요하다고 생각하여 그렇게 보신 건가요?
제 이해로는 오프라인(재구축) 페이지 처리는 같은 컨테이너에 둘 수 없는데, 해당 컨테이너가 실행되지 않기 때문입니다. 따라서 현재 주제에서 제안된 해결책은 nginx를 앞에 배치하는 것입니다. 하지만 이 주제에서 논의되었듯이 수동 단계가 많고 OS에 종속적이어서, 이 프론트 nginx를 위해 별도의 Docker 컨테이너를 사용하는 것이 더 안정적이고 유지보수가 쉽다고 생각했습니다.
아, 이제 이해가 됩니다. 그렇다면 이전에 링크한 주제는 무시해 주세요. 그 주제는 Discourse 웹 서버와 데이터베이스를 분리하는 것에 대한 논의였는데, 여기서는 필요하지 않습니다.
Nginx를 운영체제에 직접 설치하는 대신 Docker 컨테이너에 설치하는 것은 분명히 가능하지만, 이를 위한 Discourse 전용 가이드는 제가 알고 있는 바가 없습니다. 이 경로를 선택하신다면, 이 주제의 원포스터(OP)가 설명한 내용(오프라인 페이지 생성 및 Nginx 프록시 설치를 위한 필수 변경 사항)을 충분히 이해하고 계신지, 그리고 특히 두 Docker 컨테이너 간의 네트워크 설정을 포함한 Docker 작동 방식을 잘 숙지하고 계신지 반드시 확인해 주세요. 또한, 이는 우리가 경험이 없는 분야이므로 도움을 드릴 수 있는 범위가 제한적일 수 있다는 점도 유의해 주세요.
이 문제가 더 이상 작동하지 않는다는 것도 깨달았습니다.
11월 초에 @fefrei님의 방식을 구현했는데, 그때는 확실히 잘 작동했습니다. 아마도 /admin/upgrade를 사용하는 대신 컨테이너를 수동으로 중지하고 git pull을 실행했기 때문일 수도 있습니다.
1개의 좋아요
4개의 게시물이 새 주제로 분리되었습니다: Add support for a native offline page when rebuilding
우리는 최근에 정확히 그렇게 했고, 오프라인 페이지가 성공적으로 표시되었습니다.
지금 우리는 /admin/upgrade를 통해 온라인 업그레이드를 진행했는데, Discourse가 아예 오프라인으로 전환되지 않았습니다! 이것이 최근에 개선되었든 아니든, 아니면 이번에는 운이 좋았던 것일지라도, 아무런 심각한 다운타임 없이 온라인 업그레이드가 진행되는 것을 보니 정말 좋습니다.
Docker Manager(/admin/upgrade)를 통해 업그레이드를 실행하는 동안 Discourse는 절대 오프라인이 되어서는 안 됩니다. 여러분은 보통 오프라인이 됩니까? 그렇다면 해당 문제에 대해 Support 토픽을 시작해야 합니다.