[1,2,3]과 같은 문제에 몇 번이나 부딪힌 끝에, "컨테이너 중지, git pull, 런처 재빌드"라는 업그레이드 절차를 사용하기 시작했기 때문에 오프라인 페이지를 구현했을 수도 있습니다.
PostgreSQL이 제때 종료되지 않을 때 이를 강제 종료하는 과정의 견고성(robustness)이 업그레이드 프로세스가 원활하게 진행되도록 하기 위해 변했을 수도 있습니다.
어쨌든, 방금 다시 시도해 보니 온라인 업그레이드가(다시) 잘 작동했습니다. 그러니 신경 쓰지 마시고, 소란을 끼쳐서 죄송합니다.
[1] Discourse stuck on "Currently Upgrading" - #15 by amotl
[2] Upgrade failed due to unclean database shutdown
[3] https://meta.discourse.org/t/upgrade-failed-due-to-unclean-database-shutdown-ii/103268
이어서 컨테이너 외부에서 nginx를 설치하고 구성하는 방법이 설명되므로, 이 문장은 다소 혼란스러울 수 있습니다.
어쨌든, 오늘 저는 이 외부 nginx 구성 방식의 추가적인 이점을 깨달았습니다. 등록 또는 로그인 IP 주소로 127.0.0.1이나 도커 주소(대부분 172.로 시작합니다)를 확인해 본 적이 있다면, 이는 IPv6 트래픽이 컨테이너로 전달될 때 IPv4와 달리 IPv6 주소를 함께 전달하지 못했기 때문일 수 있습니다. 이 구성을 사용하면 이제 로컬 주소 대신 올바른 IPv6 주소를 확인할 수 있습니다.
즉, 이 구성은 점점 더 IPv6 중심으로 변화하고 있는 인터넷 환경에서 유용한 관리 도구가 올바르게 기능하는 데 사실상 _필수적_입니다. (미국에서는 많은 모바일 트래픽이 이에 해당합니다.)
매우 유용한 가이드를 올려주셔서 감사합니다! 몇 가지 코멘트가 있습니다:
sudo apt-get install letsencrypt 명령이 sudo apt-get install certbot으로 대체된 것 같습니다. 전자를 실행하면 Note, selecting 'certbot' instead of 'letsencrypt'라는 알림이 표시됩니다.
지인이 사이트의 Facebook 공유 시 미리보기에 "301 moved permanently"가 표시된다는 것을 알아냈습니다.
수정: 처음에는 포트 80 서버 블록의 location / 섹션을 포트 443 서버 블록의 location / 섹션으로 대체했습니다. 하지만 이는 중복된 것 같습니다. 대신 리다이렉트 블록 역할을 하던 포트 80 서버 블록을 삭제하고, 메인 서버 블록의 적절한 섹션에 다음을 추가했습니다:
listen [::]:80;
listen 80;
또한 Discourse 설정에서 HTTPS 리다이렉트를 활성화했습니다(이것이 필요한지 확실하지는 않습니다).
이렇게 하니까 FB 공유 문제가 해결되었고, 일반 HTTP 요청이 HTTPS로 리다이렉트되는 것으로 보입니다. 다른 방법이나 더 나은 방법이 있다면 알려주세요.
튜토리얼 감사합니다. 정말 좋습니다. 이제 제 502 페이지가 훨씬 더 좋아졌습니다.
실제 환경에서는 nginx 설정을 /etc/nginx/sites-enabled/discourse.conf 파일에 추가해야 합니다.
nginx가 실행 중인 상태에서 wordpress를 실행한 후 Discourse를 성공적으로 설치했습니다.
이 가이드를 따라 설치한 후 nginx가 재시작되지 않아 갱신된 인증서를 인식하지 못하는 문제에 부딪혔습니다. 제 경우 해결 방법은 다음과 같았습니다:
systemctl edit certbot
그 다음 두 줄을 추가했습니다:
[Service]
ExecStartPost=/bin/systemctl reload nginx
또는 시스템의 인증서를 공유하는 별도의 mail-receiver 컨테이너를 사용하는 시스템에서는 다음과 같이 설정했습니다:
[Service]
ExecStartPost=/bin/systemctl reload nginx
ExecStartPost=/bin/sh -c 'cd /var/discourse && ./launcher restart mail-receiver'
튜토리얼 감사합니다. 제 환경에서는 잘 작동합니다.
궁금한 점이 하나 있습니다. 예를 들어 구글봇이 해당 오류 페이지를 확인하면, 이것이 임시 페이지라는 것을 알 수 있을까요? 아니면 변경 사항의 임시적 특성을 알리기 위해某种 오류 코드를 보내야 하는 걸까요?
더 세련된 오류 페이지를 만들었다는 이유만으로 구글이 포럼에 대한 인덱싱을 모두 삭제하는 상황은 보고 싶지 않습니다…
Google은 500/502 오류를 '나중에 다시 확인하라’는 신호로 해석합니다. 웹사이트가 너무 자주 재구축되지 않는 한 문제는 없을 것입니다.
저는 오랫동안 포럼을 nginx 뒤에 두고 운영해 왔으며, 검색 랭킹에 부정적인 영향을 미친 적이 없습니다.
네, 502가 여전히 전송되고 있는지 확실하지 않았습니다.
여전히 전송되고 있습니다. 이렇게 확인할 수 있습니다:
nginx 문서에서:
문법:
error_page 코드… [=[응답]]uri;
설정에서 가져온 스니펫은 다음과 같습니다:
error_page 502 =502 /errorpages/discourse_offline.html;
이것은 "502 Bad Gateway 응답 코드를 만나거나(또는 생성할 때) /errorpages/discourse_offline.html 파일의 내용을 502 Bad Gateway 응답 코드와 함께 전송하라"는 의미입니다. =는 어떤 HTTP 응답 코드를 전송할지 지정하는 역할을 합니다.
모두 정상입니다!
그리고 @ashs의 의견에 동의합니다. 한 달에 한두 번 1분 이내의 502 에러는 검색에 해를 끼치지 않았습니다. 구글 검색 결과에서 최근 게시물을 자주 확인합니다.
이렇게 했는데도 여전히 Cloudflare에서 502 Bad Gateway 오류가 나네요…
502 오류는 Nginx가 시작되지 않고 있음을 나타내며, 이는 일반적으로 구성 오류로 인해 발생합니다. nginx -t를 실행하면 구성 파일에 문제가 없는지 확인할 수 있습니다. 오류가 없다면 systemctl status nginx.service를 실행하여 Nginx 서비스의 상태를 확인하세요.
nginx는 실행되게 만들었지만, 모든 파일을 올바른 위치에 배치했음에도 불구하고 404 오류만 계속 나타났습니다. 정상적으로 표시되어야 하는데 말이죠.
제 질문은 주제 제목과 직접적으로 관련은 있지만, 이 주제에서 사용된 방법과는 관련이 없으므로 이 토론에 남기는 것이 괜찮을지 모르겠습니다.
이 문제를 해결하기 위해 매우 간단한 설정을 해 보았고, 구체적인 질문이 있습니다.
DigitalOcean에서 별도의 드롭렛을 설정하고 마켓플레이스를 통해 LAMP 서버를 설치했습니다. 그런 다음 서버가 유지보수 중임을 나타내는 이미지 몇 개가 포함된 기본적인 HTML 페이지를 업로드했습니다. 필요에 따라 기존 Discourse 서버와 이 유지보수 서버 사이에 IP를 플로팅했습니다.
질문은 이렇습니다. ‘유지보수’ 서버가 올바르게 로드되려면, 결국 해당 서버에 대해 certbot으로 인증서를 발급받아야 했습니다(주 Discourse 인스턴스에 이미 가지고 있던 인증서 외에). 다시 말해, 동일한 도메인에 대해 서로 다른 서버에 인증서 2개를 사용하게 된 것입니다. 작동은 했지만, 이것이 미래에 문제를 일으킬 수 있다는 우려가 항상 있었습니다. 온라인에서 읽은 내용으로는 이것이 괜찮다고 하지만, 직접 경험을 해 보신 분이 있는지 확인하고 싶었습니다.
이것은 완전히 유효한 방법입니다. 그러나 인증을 수행한 방식에 따라 인증서 갱신이 제대로 작동하지 않을 수 있습니다. 예를 들어, ‘maintenance’ 서버가 HTTP 기반 인증을 사용하는 경우, 도메인이 해당 서버로 가리켜지지 않는 동안에는 인증이 실패하므로 의도와 정반대의 결과를 초래할 수 있습니다. Let’s Encrypt에서 새 인증서를 요청하는 대신, 유지보수 서버가 주기적으로 메인 서버에서 최신 인증서를 복사해 오는 방식이 더 합리적일 수 있습니다.
답변과 조언을 주셔서 감사합니다, Felix님.
제 서버가 HTTP 기반 검증(HTTP-based validation)을 사용 중인지에 대해서는 솔직히 전혀 알지 못합니다(모든 작업을 그 훌륭한 certbot을 통해 처리했기 때문이죠). 하지만 Felix님의 우려는 충분히 타당합니다. 주변을 좀 둘러봤지만, Felix님이 제안하신 것처럼 인증서를 복사하는 방법에 대한 자료를 찾지 못했습니다. 또한, 어떤 형태로든 cron job 설정이 필요할 것이라 짐작하고 있습니다. 혹시 추가로 제안해 주실 부분이 있다면 알려주시면 좋겠습니다. 그렇지 않다면, 다시 한번 도움 주셔서 감사합니다.
서버에서 서버로 파일을 직접 복사하려면 scp나 rsync가 좋은 도구입니다 – 이곳에서 시작해 볼 수 있습니다.
제 제안은 크론 작업(cron job)을 통해 주기적으로 메인 서버에서 유지보수 서버로 인증서를 복사하는 것입니다. 
그리고 HTTP 기반 검증의 배경을 설명드리자면, 도메인이 실제로 귀하에게 속하는지 확인하기 위해 Let’s Encrypt는 서버에서 특정 파일을 요청하고 특정 응답을 기대합니다. Certbot은 이를 자동으로 처리할 수 있습니다(검증 요청에 대해 이 파일을 반환하도록 서버를 일시적으로 설정하는 방식) 하지만 물론, 요청이 실제로 귀하의 서버에 도달할 때만 작동합니다. DNS가 귀하의 서버를 가리키지 않거나 IP를 다른 곳으로 옮겼다면, 요청은 잘못된 서버로 전달되고 Let’s Encrypt는 기대하는 응답을 받지 못해 인증서 서명을 거부합니다.
이 부분을 더 자세히 살펴보겠습니다. 링크와 도움 주셔서 다시 한번 감사합니다.
…이렇게 하면 수동 설정 없이도 해결되나요? 감사합니다.
사이트 재구축 중에 “공사 중” 페이지를 표시하려면 위에서 설명한 번거로운 단계를 수행해야 합니다. 2컨테이너 설치를 전환하는 것을 권장합니다. 이 방식은 유지보수가 다소 까다롭지만(데이터 컨테이너를 언제 재구축해야 하는지 알아야 하므로), 새 컨테이너가 부팅될 때 약 30초 정도의 다운타임만 발생하며, 현재는 상당한 양의 RAM이 필요합니다(2GB로는 부족할 수 있지만, 정확히 확신은 못 합니다).
letsencrypt 패키지는 이제 일반적으로 certbot이라고 불립니다.