브라우저를 통해 Discourse를 업데이트하는 것과 터미널에서 ./launcher rebuild app를 실행하는 것은 동일한 과정인가요?
만약 그렇다면, 플러그인을 개별적으로 업데이트할 수 있다는 점을 제외하고 어느 쪽이 더 유리한 점이 있나요?
저는 이 분야에 전문가가 아니므로, 말이 안 되는 내용을 말하고 있다면 죄송합니다.
이렇게 묻는 이유는, 브라우저를 통해 업데이트를 시도한 것이 두 번째인데 두 번 다 멈추기 때문입니다. 처음에는 업데이트가 시작되어 중간에 멈췄고, 지난밤(두 번째 시도)에는 업데이트 버튼을 눌렀다가 잠자리에 들었는데, 아침에 보니 업데이트가 시작조차 하지 않은 상태였습니다. 취소하고 다시 시작해야 했습니다.
가능한 한 UI를 사용하여 다운타임(몇 초)을 최소화하세요
가끔 업데이트 유형(예: postgres 버전 업데이트)에 따라 커맨드라인 업데이트가 필요합니다. 이러한 경우에는 표준 설치에서 일부 다운타임(보통 20분 정도)이 발생하지만, 필요한 경우입니다. 비성수기 시간을 선택하세요.
이러한 상황은 UI에서 명확하게 확인됩니다.
플러그인을 추가하거나 제거하려면 콘솔 재빌드(rebuild)를 사용해야 합니다.
지금 업데이트를 진행하면서 포럼이 여전히 작동하지만, 가끔은 약간 느려지는 것을 확인했습니다. 포럼이 완전히 작동하지 않는 터미널 사용 방식에 비하면 좋은 점입니다. 이 부분을 명확히 설명해 주셔서 감사합니다.
제처럼 비전문가에게도 그렇습니까? 즉, 터미널을 사용해야 한다는 것을 알려주는 메시지가 표시됩니까?
기술적인 관점에서 볼 때, 언젠가 모든 작업을 브라우저에서 수행할 수 있게 될까요? 이 과정의 기술적 세부 사항은 잘 모르기 때문에 질문합니다.
다시 크래시 발생…
Spinning up 1 Unicorn worker(s) that were stopped initially
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod Docker Manager: FAILED TO UPGRADE
이런 문제가 자주 발생할까요? 원인은 무엇이며 어떻게 수정할 수 있을까요?
표준 설치 환경에서는 항상 이럴 것 같습니다.
그 20분간의 시간을 줄이기 위해 “오프라인 상태입니다. 나중에 다시 방문해 주세요” 화면을 설정하는 자원을 이곳에서 찾을 수 있지만, 이는 표준 설치에 해당하지 않으며, 저는 간단하고 지원이 쉬운 상태를 유지하는 것을 권장합니다.
몇日前에 그걸 봤는데, 제게는 정말로 복잡했습니다.
방금 업데이트를 시도할 때 보이는 오류를 게시했습니다. 다시 충돌이 발생했습니다. 이전 답변에 있습니다.
그래서 크래시가 난 후, 업데이트 재시작 버튼을 눌렀는데 다시 이 상태로 멈춰 있습니다. 지난밤에도 이런 일이 있었죠:
제가 알아낸 점은 다음과 같지만, 우연인지는 모르겠습니다: 아무 일도 일어나지 않는 상태로 멈췄을 때, '업데이트 초기화(Reset Update)'를 클릭합니다. 재시작을 시도해도 아무 반응이 없습니다. 그러다 업데이트가 모두 표시된 페이지로 돌아가 ‘업데이트’ 버튼을 클릭하면, 이번에는 업데이트가 시작됩니다. 초기화 후 재시작 버튼이 실제로 아무 동작도 하지 않도록 코드가 손상된 건지 확실하지 않습니다. 제 추측일 뿐이지만, 제 경험을 공유해 보려고 합니다.
지금 방금 제가 설명한 대로 한 후 다시 업데이트가 진행되고 있습니다.
이제 좀 혼란스럽네요… 또 크래시가 났는데, 브라우저를 새로고침하니 Discourse가 최신 버전이라고 표시됐어요…
플러그인이 있는 메인 업데이트 페이지로 갔더니, 실제로 Discourse가 업데이트 중이라고 나와 있더라고요 
스와프를 생성해 보세요:
이 에러 메시지는 최근 매우 흔했으며, 항상 스와프를 생성함으로써 해결되었습니다. Discourse의 공식 요구 사항이 변경되지 않았기 때문에 그 이유는 알 수 없습니다.
이 단어는 전에 본 적이 있지만, 이것이 무엇인지 그리고 어떤 용도로 사용되는지 전혀 모르겠습니다.
링크를 공유해 주셔서 감사합니다. definitely 그렇게 해보겠습니다. 만약 문제가 발생하면 공유하겠습니다.
DigitalOcean에 접속하면 제 드롭릿에 대해 다음과 같은 것이 표시됩니다:
그러니까 제가 공유해 주신 그 스왑 파일 생성 과정에 해당되는 조건에 부합하는 것이 맞나요? 제 서버의 RAM이 2GB 이하이기 때문에요.
2GB 미만이라면 스왑파일을 만드는 것을 권장합니다. 제 스왑파일이 1GB라 꼭 필요했습니다.
제 이해에 따르면, 스왑은 기본적으로 저장 공간을 일부 할당하여 이를 추가 메모리로 사용하는 것입니다.
그렇다면 ./discourse-setup가 자동으로 스왑을 생성했을 것입니다. 시스템 관리의 미묘한 부분에는 잘 정통하지 않아서, 이 부분에 대해서는 다른 분들이 더 자세히 말씀해 주실 것 같습니다.
그럼에도 불구하고, 요구 사항을 충족하는 환경에서도 이 문제를 겪는 사용자가 있으므로, 뭔가 이상한 점이 있는 것 같습니다.
인터페이스를 통한 업데이트에 대해서는, 지난 몇 년간 다소 불안정하다고 느꼈습니다. 왜 그런지는 모르겠지만, 재빌드(rebuild)는 잘 되는데도 아무런 이유 없이 실패하는 경우가 있는 것 같습니다.
이미 스왑이 있는지 확인하는 터미널 명령이 있을까요? (아마도 이것이 제 질문에 답이 될 것 같습니다: 저는 시스템 관리의 미묘한 부분에는 잘 정통하지 않습니다)
아, 그러면 제가 혼자가 아니군요.
조금 혼란스럽습니다… 터미널에서 말하는 그 두 가지는 서로 다른 것인가요? 업데이트와 리빌드(rebuild)라고요? 저는 ./launcher rebuild app만 사용해 왔는데, 항상 잘 작동하거든요.
네, 감사합니다. 도움이 됩니다!
죄송합니다, 인터페이스에서라는 뜻이었습니다. 제 게시물을 수정했습니다. 
아, 이제 이해가 가네요
네, 제 경험도 비슷합니다.
단점으로는 재빌드 시 포럼이 완전히 중단된다는 점이 있지만, 이상적이지는 않아도 어쩔 수 없는 일이죠… 해야 할 일은 해야 하니까요.
업데이트
이 분야에 전문 지식이 없어서 Claude와 ChatGPT를 활용해 상황을 파악했습니다. 조언대로 스왑파일을 사용하는 방향으로 진행했지만, Discourse 설치 방식에 따라 이미 스왑파일이 존재했을 수도 있다는 지적을 받았습니다. 확인하기 위해 터미널에서 다음 명령어를 실행했습니다.
sudo swapon --show
그리고 다음과 같은 결과가 나왔습니다:
그런 다음 “USED”(사용량) 열을 보고 이렇게 생각했습니다. “RAM이 부족할 때 시스템이 더 부드럽게 작동하도록 돕기 위해 스왑파일을 사용하는 건데, 스왑파일이 2GB 중 1.9GB를 사용 중이라고 하면 도움이 안 되겠구나”
그래서 ChatGPT에게 스왑파일을 비우거나 비울 수 있는지 물어보았고, 다음과 같은 명령어를 받았습니다:
sudo swapoff -a && sudo swapon -a
이 명령어를 실행하고 처리가 끝나기를 기다린 뒤, 다시 이전 명령어를 실행했습니다:
sudo swapon --show
이제 다음과 같은 화면을 볼 수 있습니다:
그러니까 가끔 이렇게 스왑파일을 정리/비우는 과정을 거두는 것이 좋은 것 같네요?
스왑을 늘려 보는 것도 좋습니다:
명령줄에서 재빌드하면 RAM 사용량이 적습니다.
두 개의 컨테이너로 설치한 경우, 기존 컨테이너가 계속 작동하는 동안(충분한 RAM이 있는 경우) 새 컨테이너를 빌드할 수 있습니다. 이를 통해 다운타임을 최소화할 수 있습니다.
기저 라이브러리가 업데이트되어야 하는 경우가 있으므로, 이는 UX에서 수행할 수 없기 때문에 때로는 명령줄 재빌드가 필요합니다.
cd /var/discourse
grep swap discourse-setup
을 실행하면 스왑을 생성하기 위해 실행되는 명령어를 확인할 수 있습니다. swapoff를 실행하여 파일이 더 이상 사용되지 않도록 한 후, 필요에 따라 파일을 더 크게 만드는 (fsallocate) 명령을 실행하고, 스왑으로 포맷팅(mkswap)한 다음 swapon -a를 실행하여 다시 활성화할 수 있습니다.
많은 플러그인을 설치한 경우 총 5GB 또는 6GB의 RAM이 필요할 수 있습니다.