네, 단계별로 진행하는 것이 좋습니다:
- 조금 더 강력한 서버를 구합니다.
- 두 컨테이너 설치를 작동하게 합니다.
이 시점에서 만족스러우면 여기서 멈추거나:
- 위에서 @Lilly 님이 작성한 훌륭한 가이드를 사용하여 유지보수 페이지를 구현합니다.
하하, 물어봐서 기쁩니다. 이 부분을 설명할 시간을 내지 못했거든요 (설명해야 할 것이 많고 Cloudflare가 복잡해서 그래요!)
워커 라우트 페이지가 설정되면 포럼의 모든 이미지 로딩과 페이지 뷰가 해당 워커를 통해 라우팅됩니다.
Cloudflare의 무료 CDN 플랜에는 워커 라우트에 대해 하루 100,000회 요청 제한이 포함된 무료 티어가 있습니다.
따라서 비교적 트래픽이 많은 포럼을 운영 중이라면, 하루 안에 무료 티어 한도에 도달하는 것을 방지하기 위해 항상 켜 두지 않는 것이 좋습니다.
즉, 이것은 워커 라우트이지 유지보수 페이지가 아닙니다 - 유지보수 페이지는 항상 켜 두어도 됩니다. 워커 라우트가 켜져 있지 않는 한 해당 페이지에 요청이 들어오지 않으니까요. 이것은 단지 라우트를 할당했던 2단계 부분입니다 (설정과 삭제가 쉬운 부분). Cloudflare 유료 플랜을 사용하지 않는 한, 자신이 직접 유지보수를 수행할 때만 켜 두는 것이 좋은 관행입니다.
- 도메인의 Cloudflare 워커 라우트 페이지로 가서 라우트 오른쪽에 있는 버튼을 클릭하세요.
- 편집 화면 하단에서
remove버튼을 클릭하여 워커 페이지를 라우트에서 분리하세요.
- 걱정하지 마세요, 워커 코드 자체는 삭제되지 않고 라우팅 규칙만 삭제됩니다. 다음에 재빌드/업데이트를 수행할 때 위 2단계처럼 다시 추가하면 됩니다.
Cloudflare 유료 플랜을 사용 중이라면 걱정할 필요가 없습니다. 하지만 그렇다면 워커 페이지 대신 Cloudflare 오류 페이지를 사용할 수 있습니다… (Cloudflare가 꽤 복잡하다는 말을 했었나요? LOL)
제 일반적인 절차는 다음과 같습니다:
- Cloudflare에서 워커 라우트를 추가
- Hetzner에 SSH 접속
- 시스템 업데이트 수행 (예:
sudo apt update && sudo apt upgrade -y), 필요 시 서버 재부팅 (전체 종료 및 재시작을 위해shutdown -r now을 사용) - 서버 재시작이 필요했다면 다시 SSH 접속
./update-web.sh실행- 셸 스크립트가 완료되고 포럼이 다시 로드되면 Cloudflare에서 워커 라우트를 제거
코딩이나 개발 분야에 대해 잘 모릅니다. 아주 오래전에 Visual Basic으로 hello world를 한 번 만들어본 것 빼고는요. 하지만 WordPress와 Mastodon/Pixelfed 서버, 그리고 어찌어찌 Discourse를 관리하는 법은 더 잘 알게 되었으니 몇 가지 해볼 수 있습니다. 게다가 AI라는 것도 있긴 한데(광고만큼 초보자에게 쉽지는 않아요).
Docker 때문에 Discourse에서는 이게 가능할지 잘 모르겠습니다. 하지만 일반적인 Nginx-Varnish-WordPress 환경에서는 Plesk 서버가 50x 오류 정보를 받아 오류 페이지를 표시하도록 시스템을 구축해본 적이 있습니다. 실제로 세 가지 설정을 사용하는데, 프론트엔드 Nginx가 Varnish가 다운되면 생성된 스냅샷 콘텐츠를 표시하고, Varnish는 WordPress 관련 백엔드가 다운되면 캐시되지 않은 콘텐츠에 대해 스냅샷을 사용하며, 세 번째는 프론트엔드 Nginx가 응답하지 않을 때 오류 페이지를 표시하는 것입니다.
Varnish 관련 설정은 Discourse에서는 불가능하지만, Docker 환경에서도 50x 오류가 발생하면 오류 페이지를 표시하도록 비슷한 거미줄 같은 구조를 만들 수 없는 이유는 보이지 않습니다.
다만 그런 시스템은 오류가 발생하기 쉬울 수 있습니다. 그리고 사용자가 몇 명을 넘으면 무슨 일이 벌어질지 전혀 모르겠습니다.
물론 가장 명백한 답도 있습니다. 바로 Discourse 앞에 Nginx를 두는 것입니다. 2개 컨테이너 구성으로 전환하기 전에 그렇게 사용했었습니다.
드디어 시간을 내서 다시 Discourse를 설치했습니다. 현재 제 상황과 컨테이너 두 개를 유지보수하는 데 필요한 노력이 얼마나 되는지 평가해 본 결과, 당분간은 컨테이너 하나를 유지하는 쪽으로 가닥을 잡았습니다. 만약将来에 컨테이너 두 개가 필요하게 된다면, 여기서 언급한 모든 내용을 다시 검토하겠습니다. 플러그인 설치(컴포넌트 관리만큼 자주 해야 할 일은 아닌 것 같습니다)를 제외하면, 온라인 사용자가 적은 시간대에 커뮤니티가 20분 정도 중단되는 것과, 특정 날짜와 시간에 커뮤니티가 중단될 것이라는 배너를 통해 사용자에게 공지하는 것은 당분간 꽤 합리적인 방안이라고 생각합니다.
어떻게 될지 지켜보겠습니다.
싱글 컨테이너와 비슷하게 유지보수가 필요합니다 
그리고 덜 슬플 거야 
그 과정이 어떻게 진행되는지 구체적으로 설명해 주실 수 있나요?
저한테 답장하신 건지 @Jagster 님한테 답장하신 건지 확실하지 않네요. 무슨 뜻이에요?
사이트가 온라인 상태인 동안 새 컨테이너를 부트스트랩하는 과정은 훨씬 스트레스가 적습니다. 빌드가 실패하더라도 패닉할 필요가 없으며, 오프라인 상태가 되지 않고도 수정에 필요한 모든 시간을 확보할 수 있기 때문입니다.
음, 그러니까 둘 다 갖는 걸 권장하는 거군요. 그래서 "고민이 적다"고 한 거겠죠.
그래서, 이 분야에 경험이 없는 사람으로서, 컨테이너를 2개 만든다고 해서 Discourse 인스턴스가 2개가 되는 건 아니라고 생각하는데 맞나요?
다음 주제를 읽고 있어
그리고
얼마나 많은 작업이 필요하고, 얼마나 주의를 기울여야 하는지 이해하려고 합니다. 그래야 내가 관리하지 못할 상황을 만들지 않고, 단일 컨테이너 설치에서 발생할 수 있는 모든 다른 문제들보다 더 복잡해지는 상황을 피할 수 있을 것 같아서요.
두 컨테이너 설정에 대해 공유해 주셔서 감사합니다. 저는 하나만 사용했는데, 전용 서버(64GB RAM)에서도 보통 3~5분 정도 걸립니다.
이중 설치 환경에서 두 컨테이너를 모두 업데이트해야 하는 시점을 명확하고 간단한 예시로 알려 주실 수 있을까요? 즉, 어떤 Discourse 업그레이드는 두 컨테이너 모두를 재시작해야 하고, 어떤 업그레이드는 새로 생성된 web_container만 재시작하면 되는지 궁금합니다.
먼저 2-container를 시작하는 매우 간단한 지침을 따르세요. 그 후에는 주로 다음만 필요할 것입니다.
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only ) 2>&1 | tee ~/$(date +%Y-%m-%d_%H-%M-%S)-upgrade.log'
tee 부분은 로깅을 위한 것인데, 제가 사용하는 tmux 피드보다 이를 살펴보는 것이(제 입장에서는) 더 쉽기 때문입니다.
하지만 기본적으로는 app.yml을 사용하여 재빌드하는 것과 완전히 동일하며, 다만 사용자가 겪는 불편함이 훨씬 적습니다. 물론 data-container가 있지만, 이는 매우 드물게만 관심과 관리가 필요합니다. 그리고 컨테이너로 더 복잡한 트릭을 수행할 계획이라면, 컨테이너를 언제 어떻게 다뤄야 하는지 이미 알고 계실 것입니다.
2-container 환경에서 업그레이드가 실패하더라도 포럼은 여전히 가동된 상태로 유지되지만, 단일 컨테이너의 경우 크래시가 발생합니다.
따라서 시작하는 것만 약간 더 까다롭지만, 지침은 꽤 명확합니다. Amazon SES를 사용하는 경우, mail-reveiver를 설정하는 것이 더 어려운 작업이라고 말할 수 있습니다.
예를 들어, 이것은 단순히 무시할 수 없는 종류의 댓글입니다. 업데이트/업그레이드가 더 이상 버튼을 클릭하는 것만큼 단순하지 않고, 더 많은 집중과 주의가 필요한 것처럼 보이기 때문입니다. 경험 있는 사람에게는 쉽고 당연해 보일 수 있지만, 그렇지 않은 사람들에게는 그렇지 않을 수 있습니다:
2015년에 작성된 이 토픽의 설명이 2026년에도 여전히 유효하다고 보시나요?
오늘 Discourse를 다시 설치했으니 시도해 볼 의향은 있습니다. 문제가 생기면 다시 단일 컨테이너로 돌아가면 되니까요. 다만, 진행하다가 2026년에는 더 이상 유효하지 않은 내용을 따라하게 될까 봐 확인하고 싶었습니다…
제 경우 몇 분의 절약은 20분 이상에 해당합니다. 월 1회 업그레이드를 전제로 한다면 월 1회라는 말은 맞지만, 저는 주 2회 이상 업그레이드를 수행하고 있습니다. 그리고 어떤 플러그인이 실패하여 여러 번 시도를 해야 하는 경우(물론 우리는 라이브 인스턴스에서 작업하고 있으니까요 
) 그 긴 다운타임은 그저 고통일 뿐입니다.
따라야 할 새로운 릴리스마다 공지사항의 세부 사항은 존재하지 않습니다. mcdanlj에게는 그런 것이 있을 수 있지만, 그는 일반 시스템 관리자가 아니라 훨씬 더 높은 수준에서 업무를 수행하고 있습니다.
좀 혼란스럽네요…
여러분이 이렇게 말씀하셨는데:
그런데 이 글 바로 위쪽의 답변에서는 이렇게 말씀하시니:
이것만 봐도 두 개의 컨테이너는 하나인 경우와 동일하지 않고, 유지보수가 더 복잡해 보이는 것 같습니다. 물론 다운타임 같은 부분은 이해합니다만, 컨테이너 자체의 유지보수는 단일 컨테이너로 간단히 업그레이드하는 것보다 더 복잡하고 오류가 발생하기 쉬워 보입니다. 제가 뭘 놓치고 있는 건가요?
그렇습니다:
컨테이너 1 = 웹사이트 & nginx
컨테이너 2 = 데이터베이스 및 redis
(제가 맞다고 생각합니다)
컨테이너 1의 구성 요소는 매우 자주 변경됩니다.
컨테이너 2의 구성 요소는 거의 변경되지 않습니다.
그리고 컨테이너 2를 업데이트하지 않고 컨테이너 1만 업데이트할 수 있습니다.
더욱 좋은 점은, 컨테이너 1의 대체품을 준비한 후 몇 초 만에 교체할 수 있다는 것입니다(이 준비 과정을 "부트스트래핑"이라고 합니다).
단일 컨테이너에서 ./launcher rebuild app를 실행하면 웹과 데이터가 모두 정지되고, 두 개가 모두 업그레이드됩니다. 하지만 데이터 측에서는 업그레이드가 매우 드물게 필요하며, 작업이 완료된 후 문제가 없다면 모든 것이 다시 시작됩니다.
2개 컨테이너 방식에서는 'web’만 재구축하고 데이터 컨테이너는 건드리지 않습니다. 모든 것이 순조롭게 진행되면 이전 컨테이너를 제거하고 새 컨테이너를 시작합니다. 만약 문제가 발생하면, 기존에 정상 작동하던 'web’이 계속 사용될 수 있습니다.
따라서 실질적인 차이는 소프트웨어와 데이터베이스의 몇 가지 다른 항목을 어떻게 처리하느냐에 있습니다.
물론, 컨테이너 1개 구성도 하나의 옵션이죠. 하지만 핵심은 컨테이너 2개를 생성할 때, 난이도 이름의 유일한 실질적인 차이는 업그레이드 시 사용되는 명령어라는 점입니다. 그리고 그 부분은 alias로 해결할 수 있죠
그것은 데이터베이스를 업데이트할 때가 되었다는 내용을 언급하던, 손으로 작성되던 옛날 공지사항 시절에 쓰인 것이었습니다. 새로운 자동화된 사이트는 더 화려하지만, 예전처럼 실제로 가장 중요한 내용이 무엇인지에 대한 사람의 주석이 없습니다.
요즘은 데이터베이스 업데이트가 이루어진다는 게시물을 알아채야 하는 것 같습니다. 저는 그런 게시물을 몇 달 동안 놓친 것 같습니다.
그러나 이것은 몇 년에 한 번씩 발생하며, DB를 명시적으로 재구축할 때 재구축되고, CDCK는 pgsql의 이전 버전과의 호환성을 한동안 유지해 온 것으로 보입니다. 그래서 실제로는 문제를 겪은 적이 없습니다. 지금까지는요.
저는 두 컨테이너(또는 그 이상!) 구성을 제 자신에게 정말 좋아하지만, 모든 사람에게 가장 쉽지는 않기 때문에 여전히 주의 사항을 덧붙입니다. 두 컨테이너 배포가 "물론, 그게 간단하잖아"라고 느끼는 사람이 누구인지, "아, 그냥 버튼을 누르고 싶은데"라고 느끼는 사람이 누구인지는 저로서는 판단하기 어렵습니다.