검색을 통해 다음 지침을 찾았습니다.
해당 글에는 몇 주에 한 번씩 업데이트하고, 몇 달에 한 번은 다음 방법으로 업데이트해야 한다고 나와 있습니다.
Discourse를 셀프호스팅하는 경우, 최신 보안 패치 및 최신 라이브러리를 적용하기 위해 가끔 명령줄을 통해 수동 업데이트를 실행해야 합니다. 이러한 업데이트는 admin/update에서 반영되지 않으므로 가끔 이 추가 단계가 필요합니다.
admin->update와 ssh/콘솔 업데이트에 대해 논의하는 다른 주제들도 몇 개 있지만, 어떤 업데이트가 브라우저에서 수행될 수 없는지 명확하게 설명해 주는 곳은 없습니다.
제 경험상, Discourse를 9개월간 운영하면서 웹/관리자 업데이트가 실패한 경우는 단 한 번뿐이었습니다. 그때 위 글을 찾아 ssh 세션에서 지정된 명령어를 실행했습니다.
"더 쉬운 방법이 실패하면"이라는 기준 외에, 어떤 방법을 사용해야 하는지 알 수 있는 더 나은 방법이 있을까요?
미리 감사드립니다.
지금은 항상 명령줄을 사용한다. 예전에는 웹 인터페이스를 사용했지만, 제대로 작동하지 않을 수도 있고, 제어와 가시성이 떨어지기 때문에 더 이상 신경 쓰지 않는다.
하지만 내 포럼의 트래픽은 비교적 적어서, 잠시 서비스 중단이 일어나도 큰 문제가 되지 않는다.
또한, 나는 명령줄에 익숙하다. 하지만 결국 모든 디스코urses 관리자는 언젠가 명령줄을 사용해야 한다.
감사합니다, 도움이 많이 됩니다. 저는 명령줄이 더 빠를 것 같다고 상상하고 있었습니다 (다운타임 감소/프로세스 시간 모니터링).
업데이트를 위한 웹/GUI 인터페이스를 꽤 큰 장점으로 여겼습니다. 수십 년간의 유닉스/리눅스 코딩 및 관리 경험을 가지고 있지만, 조직 내에서 저는 단일 장애점(SPOF)이기도 하기 때문에, 일부 업데이트가 명령줄을 필요로 한다는 사실을 알게 된 것은 실망스러웠습니다.
그래도 괜찮습니다. 정말 훌륭한 플랫폼이며, 그 가격에 비해 충분히 가치가 있습니다 
웹 업그레이드를 시도하더라도, 커맨드라인 업그레이드에 대비해 두는 것이 좋은 생각처럼 느껴집니다. 개인적으로는 현재 누군가 어려움을 겪고 있는지 확인하기 위해 사전에 이 포럼을 살펴봅니다. 코드베이스가 일시적으로 깨져 있을 수도 있기 때문입니다. 또한, 시작하기 전에 항상 백업을 받아서 다운로드해 둡니다.
최소 다운타임이 중요한 경우, 가장 좋은 관행은 두 개의 컨테이너를 설치하는 방법인 것 같습니다.
저는 도커(Docker)를 완전히 이해하지는 못하지만(이건 과장이 아닙니다), 업그레이드 중간에 제대로 작동하지 않는 포럼에 놓이게 되면, 도움을 기다리는 동안 업그레이드 전 버전을 어떤 식으로든 실행할 수 있다고 이해하고 있습니다. (이 부분에 대해 "구 컨테이너 재시작"으로 검색해 보았지만, 정확한 정보를 찾지는 못했습니다.)
./launcher start app을 실행하면 중간에 실패한 경우 재빌드 이전 버전으로 복원됩니다.
다만 저는 대개 UI를 통해 업데이트를 진행합니다. 이렇게 하면 오프라인 시간이 발생하지 않습니다. 간혹 커맨드 라인을 통해 업데이트해야 하는 경우가 있지만, 일반적으로 docker manager를 업데이트한 후 Discourse 자체를 업데이트하려고 시도하기 전에 그렇게 하라는 프롬프트가 표시됩니다.
보통 커맨드라인 재빌드가 필요할 경우 UX가 이를 경고하고 업그레이드를 자체적으로 수행하지 않습니다. 하지만 항상 그런 것은 아닙니다.
저는 dashboard.literatecomputing.com을 운영하고 있으며, 이 대시보드를 사용하면 클릭 한 번으로 커맨드라인 재빌드를 수행할 수 있습니다. 물론 사람들이 이 도구를 사용(그리고 제 지원을 받기) 위해 비용을 지불해 주기를 희망하지만, “한정된 기간” 동안 무료 체험 그룹에 가입하여 무료로 사용할 수 있습니다. 이 도구는 코어로 이동된 플러그인 제거, Postgres 업그레이드, 재빌드가 실패할 경우 기존 컨테이너 재시작, 2컨테이너 설치인 경우 웹 컨테이너만 업그레이드하는 등 상당수의 문제를 처리해 줍니다.
좋은 지적입니다. 저는 좀 더 신중해서 업그레이드 전후로 시스템 스냅샷을 실행하고, Discourse 애플리케이션 백업도 추가로 진행합니다. … 아마도 백업에서 복원하는 법에 대해 더 배워야 할 것 같습니다.
아직 스냅샷을 사용해 본 적이 없습니다… 추가 비용이 드는 옵션인 것 같습니다.
하지만 그 백업을 다운로드하는 것이 중요하다고 생각합니다. 인스턴스가 완전히 손상되거나, 제 계정이 취소되어 호스트 측에서 제가 사용하던 모든 것이 삭제된 경우에도, 제가 원하는 어떤 호스트에서도 복원할 수 있는 형식으로 포럼을 그대로 유지할 수 있기 때문입니다.
시스템 스냅샷(으로 생각되는데)은 생성 중에 다운타임이 필요하며, 사실상 과한 조치입니다. app.yml 파일의 사본과 백업 파일만 있으면 충분합니다. 백업이 S3에 저장되어 있다면, app.yml만 있으면 완전히 새로운 서버를 시작하고 데이터를 복원할 수 있습니다.
스냅샷은 확실히 다운타임을 필요로 하며, 백업을 유지하기 위해 월 몇 달러를 지출하고 있습니다.
저도 백업을 수행하고 있지만, 한때 알려진 정상 시점에 만든 백업으로 손상된 Discourse를 복구해 본 경험이 있어서, 이제는 이중 안전장치(백업 + 스냅샷)를 사용하겠습니다.