그 점은 감사하지만, 앱을 다시 빌드하는 데 약 3시간이나 걸립니다!
그것도 대규모 VPS 환경에서 말이죠.
테마를 추가하고 제거하듯 플러그인도 쉽게 제거할 수 있다면 좋겠다는 생각이 듭니다.
향후 기능으로 고려해 볼 만한 것일까요?
감사합니다!!
죄송?! 약 20분이면 충분해야 하는데요?!
여기 없어요
최초 설치에 2시간이 걸렸어요.
지금, ./launcher rebuild app가 여기까지 진행됐어요:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
그리고 마지막 줄 이후로 커서가 계속 깜빡이고 있어요(프로세스는 진행 중임)
이렇게 된 지 30분 정도 됐어요.
마지막에 이렇게 했을 때는 딱 160분이 걸렸어요.
서버 총 메모리: 4.657GiB, 커널 버전: 5.15.0-43-generic, 운영체제: Ubuntu 22.04 LTS, 50GB SSD 드라이브, 2.5 코어, 5 스레드 Intel® Xeon® CPU
…
왜 이렇게 매우 오래 걸리는 건지, 그게 아니면 뭐가 문제인지 모르겠어요 
3시간은 확실히 매우 이상해 보입니다. 이 문제를 조사하여 최우선 순위로 해결해야 합니다.
빌드 로그에 '시각적 멈춤’이 있는 경우가 있는데, 이는 정상적인 현상이지만 그 지연은 그렇지 않습니다.
직감으로는 빌드 중 스왑을 사용하기 시작한 것 같지만, 저는 시스템 관리자(SA)가 아닙니다. 해당 머신에서 다른 작업을 실행하고 있나요?
다운로드에는 압축 해제 과정이 필요하며, 이는 계산적으로 비용이 많이 듭니다. 하지만 모든 사용자에게 동일한 이미지들이 적용됩니다.
참고로, 방금 https://scaleway.com 의 2GB 2vCPU 머신에서 사이트를 재빌드했는데, 13분 46초가 걸렸습니다.
아니요, 이 VPS는 이 Discourse 인스턴스 전용입니다. 같은 회사에서 다른 VPS도 여러 대 운영하고 있는데, 모두 매우 원활하게 작동합니다(다만 Discourse 인스턴스가 아니라 커스텀 PHP나 WP/CP CMS 인스턴스 등 다른 앱들이에요).
스왑 사용량은 인지하고 있지 않으며, 자원을 정당화할 만한 스파이크도 확인되지 않습니다.
지금 building.... 단계에 있는데, 지난번보다는 조금 빠른 것 같지만 여전히 20분 이상 걸리고 있습니다.
서버 제공업체에 저희 쪽에서 특이한 점을 발견할 수 있는지 문의해 보겠습니다. 다만, 이전에 그들이 직접 운영 중인 Discourse 인스턴스도 빌드에 약 2시간이 걸렸다고 말한 기억이 나네요. (참고: 이 VPS들은 제3자를 통해 임대된 Hetzner 머신입니다. 더 나은 환경을 구하기는 어려울 것 같습니다.)
어쨌든, 제 제안은 여전히 유효합니다. 테마처럼 플러그인을 자유롭게 추가하고 제거할 수 있으면 좋겠습니다. 한번 고려해 보실 수 있지 않을까요?
저는 사실 잘 모르지만, AFAIK(제가 아는 한) Discourse는 컴파일된 JavaScript가 많이 포함되어 있어 불가능한 것 같습니다. 코어의 작동 방식에 영향을 주는 요소를 추가하거나 제거해야 할 경우 재빌드가 필수적이기 때문입니다.
Varnish의 경우와 매우 비슷한 상황이라고 할 수 있습니다.
음…
참고로 서버 담당 팀에 확인해 보니 실제로 메모리가 100%까지 차 있었네요.
5GB??? 어떤 작업이든 5GB의 RAM을 소비하는 건 좀 과한 것 같습니다.
Discourse의 요구 사항에는 1GB의 RAM만 필요하다고 되어 있거든요!
그리고 지금은 아래 단계에서 멈춰 있습니다:
104:M 04 Oct 2022 07:19:27.251 # Redis is now ready to exit, bye bye...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Removing old container
+ /usr/bin/docker rm app
app
이 때문에 프로세스가 중단되어 서버를 업그레이드조차 할 수 없습니다.
솔직히, 이건 서버 문제라고 전혀 생각되지 않습니다. 1GB가 필요하다고 하면, 5GB는 넉넉할 정도여야 합니다.
어딘가에서 뭔가 크게 잘못되고 있습니다.
다른 사람들은 더 좋은 경험을 하고 있을 거라 이해합니다 (@merefield 님은 2GB에서 업그레이드하라고 하셨던 걸 보면요) 하지만 우리 환경에서는 제대로 작동하지 않고 있습니다.
어쨌든, 이 스레드의 주제에서 벗어난 이야기인 것 같습니다.
또 다른 사이트를 재구축했는데, 4GB, 3vCPU 환경에서 다시 15분 미만에 완료되었습니다(즉, 제 경우 추가 메모리/CPU가 실제로 그렇게 큰 도움이 되지는 않았지만, 그래도 몇 시간 단위는 아니었죠!).
제가 방금 알아차린 유일한 점은 내 VPS가 권장되는 aufs나 overlay 대신 vfs를 사용한다는 것입니다.
하지만 이 링크(Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david)에 따르면 이는 중요하지 않은 문제라고 하므로, 그렇지 않으면 Discourse조차 실행할 수 없기 때문에 --skip-prereqs 옵션을 지정하여 런처를 실행하고 있습니다.
이 저장소 드라이버 요구 사항에 대해 더 깊은 의미가 있을지 궁금합니다.
그건 좀… 지나치게 낙관적인 표현이네요. 테스트 용도로는 충분할 수 있지만, 그래도 다소 빠듯할 수 있습니다. 현실적으로는 2GB가 훨씬 더 적합합니다.
다만 더 큰 인스턴스에는 4GB면 충분합니다. 하지만 코어의 수와 성능도 중요한 역할을 합니다.
그리고 여전히… 5GB를 가지고 있으면서도 재빌드(Rebuild)에 그렇게 오랜 시간이 걸린다면 뭔가 문제가 있는 것입니다.
저는 DigitalOcean/4 GB/2 인텔 vCPU를 사용하는데, 재빌드에는 약 25분 정도 걸립니다.
여러분의 시스템은 정확히 어떤 구성이며, app.yml 파일에는 커스텀 설정이 있나요?
안녕하세요, 커스텀 설정은 이전에 언급한 것(VFS를 aufs/overlay 대신 사용)뿐입니다.
나머지는 전부 기본 상태(vanilla)입니다.
서버:
서버 총 메모리: 4.657GiB, 커널 버전: 5.15.0-43-generic, 운영 체제: Ubuntu 22.04 LTS, 50GB SSD 드라이브, 2.5 코어, 5 스레드 Intel® Xeon® CPU
yaml은 다음 추가 플러그인 외에는 원본 그대로입니다:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
해당 데이터만으로는 재구축에 그렇게 오랜 시간이 걸리는 이유가 잘 보이지 않습니다.
호스팅 회사의 문제인지 확인하기 위해 다른 곳에 비슷한 크기의 Ubuntu VPS를 하나 더 띄워보겠습니다. 비용은 몇 달러 정도이고, 걸리는 시간도 1~2시간이면 충분합니다.
자바스크립트를 사전 컴파일하려면 많은 메모리가 필요합니다. 스왑(swap)을 추가해 보세요.
오버레이
그 테스트가 존재하는 데는 이유가 있을 것입니다. 이것이 문제의 원인일 수 있습니다.
더 작은 RAM 용량의 서버들은 자동으로 할당된 스왑 용도로 충분해하는데, 왜 5GB RAM의 바닐라 Discourse는 더 많은 스왑이 필요할까요?
진정으로 해야 할 일을 하는 것보다 더 쉽기 때문입니다.
스왑 공간을 추가하는 것이 도움이 될 수 있지만, 그것이 가장 큰 문제는 아닙니다.
discourse 컨테이너를 배포하기 전에 이걸 시도해 봤어야 했을 것 같습니다: How to change the Docker storage driver – Webdock
어쨌든 스토리지 드라이버를 변경하는 것이 가능하다고 합니다. 컨테이너를 배포할 당시 호스트가 제게 알려준 내용(로더 파일을 편집하거나 검사를 무시하라는 것)과는 정반대입니다.
아, 이제 늦었겠죠.
어쨌든 감사합니다. 만약 이것이 문제의 원인이라면, 제 실수인 것 같습니다. 제 잘못입니다 
그렇지 않을 것 같습니다.
또한 컨테이너 2개 구성은 기존 컨테이너가 계속 실행되는 동안 새 웹 컨테이너를 CSV로 재구성할 수 있어 다운타임을 줄였습니다.
당신의 사이트 규모는 어느 정도인가요? 메모리 문제를 해결하기 위해 어쨌든 스왑을 추가하는 것을 권장합니다.
빈 1GB 인스턴스에 1GB의 스왑을 추가하면 작은 테스트 커뮤니티에서는 잘 작동하지만, 규모가 커지면 그 정도로는 부족합니다. 스왑은 확실히 큰 차이를 만듭니다.
“방대한” VPS를 데이터센터에 위치시켜 인터넷과 두꺼운 파이프(fat pipe)로 연결해 놓고 재구축에 3시간이 걸린다면, 제 책상 위에 신용카드 크기의 보드로 구동되며 제3세계의 일반 가정용 인터넷 요금제로 연결된 https://discourse-on-a-pi.falco.dev 의 제 설치 환경은 재구축에 단 14분 (+ 새 컨테이너 이미지가 있을 경우 4분)밖에 걸리지 않는다는 사실은, 여러분에게 판매되는 제품에서 뭔가 잘못되어 있다는 것을 의미합니다…
서버의 메모리 사용량은 어떻게 되나요? 재빌드 시작 전에 용량이 가득 차 있거나 거의 가득 찬 상태라면, 스와핑이 많이 발생하여 모든 작업이 지나치게 오래 걸릴 것입니다.
그런 경우라면, 가능하면 서버에서 실행 중인 다른 작업들을 일시적으로 비활성화하는 것을 권장합니다.