이 업데이트가 실패하고 있으며, 현재 제 디스코urs 포럼 3개 모두 다운된 상태입니다.
업그레이드 화면의 콘솔 창에는 아무것도 표시되지 않지만, 나머지 UI는 업그레이드가 여전히 진행 중인 것처럼 보입니다(하지만 지금까지 제가 해본 어떤 업데이트보다 훨씬 오래 걸리고 있습니다).
이 문제를 겪고 계신 분이 더 계신가요? 업그레이드가 성공적으로 완료되도록 해결할 수 있는 아이디어가 있으신가요?
@pearsonified 이 릴리스에는 Rails 구성 요소 업데이트가 포함되어 있으므로, 커맨드 라인에서 업데이트가 필요한 릴리스 중 하나입니다.
아, 그래서 Ruby 3.0 오류와 web-push-3.0.0 문제의 원인이 그거였군요?
관리자 업그레이드 웹 UI는 "모두 업그레이드"를 클릭하게 해서 완전히 망가진 포럼을 만들게 하는 것보다는, 해당 문제를 사용자에게 알려주는 것이 좋습니다. 많은 사용자의 가슴 두근거림을 막아줄 수 있겠죠.
잘 모르겠어요. 개인적으로는 업데이트에 GUI를 절대 사용하지 않고, 항상 커맨드 라인에서만 수행합니다. 그런 것처럼 보이는 에러는 확인하지 못했어요. 하지만 제 경우에는 그런 에러가 나오지 않았을 수도 있겠죠.
보통 일반적인 에러 메시지가 표시될 때, 특정 시나리오에 대해 구체적인 에러 메시지를 표시할 수 있을 정도로 충분히 예측 가능했다면, 그 에러 메시지는 대신 방지되었을 것입니다.
"GUI 업데이트가 실패했는데 도와주세요"라는 문제가 매우 드물어서, 기본 배포 환경에서는 git pull; ./launcher rebuild app을 실행하는 것이 첫 번째 조치라는 사실을 많은 사람들이 인식하지 못하는 것 같습니다. 대부분의 경우 이것이 정답입니다.
하지만 GUI 업데이트가 실패할 때 일반적으로 취해야 할 조치이기도 합니다.
저는 discourse를 여러 해 동안 사용해 왔습니다. 대략 7년쯤? 어쨌든, 웹 업그레이드가 이전에 이렇게 심각하게 실패한 적은 없었습니다. 물론 실패한 적은 있었지만, 롤백을 통해 이전 컨테이너를 다시 시작하면서 포럼은 항상 복구되었습니다.
이것은 일반적인 오류가 아니며, ruby 관련 메시지는 꽤 명확합니다.
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
제가 유료 Discourse를 사용하고 있다면 이 문제로 꽤 크게 불만을 제기했을 것입니다. 포럼을 멈추게 한 큰 버그가 있어서가 아니라, 버그는 언제든 생길 수 있지만, 적어도 지난 3일 동안 수정되지 않았기 때문입니다. 현재 상황은 그저 하루의 끝에서 느끼는 작은 짜증 정도입니다.
Docker 매니저의 관점에서 보면, 이미 실행 중인 버전이 작성되었을 당시에는 앞으로 이런 문제가 발생할지 알 수 없었습니다. 답답하신 마음은 이해하지만, 요청하시는 것이 기술적으로 의미가 없을 수 있습니다.
Discourse를 유료로 이용하셨다면 이 과정을 그들이 관리해 드리고, 사용자는 이런 문제를 전혀 보지 못했을 것입니다. 
기술적으로 수정이 불가능하더라도, 사용자에게 CLI를 통해 업그레이드하라는 경고를 이메일로 보낼 수는 있습니다. 이 문제에 대해 목소리를 높여야 합니다. 롤백 없이 포럼을 깨뜨리는 것은 매우 나쁜 일입니다.
Discourse가 온프레미스 사용에 대한 지원도 판매하는 것 같던데, 어쨌든 저는 유료 고객이 아니므로 너무 크게 불평할 수는 없지만, 3일은 좀 너무 길죠.
7년 만에 이런 방식으로 되돌아가야 했다는 점이 처음이라는 것에 대해 다행스럽게 생각합니다. 하지만:
이것은 사실과 다르다고 지적하겠습니다. CDCK는 실제로 업데이트 전 백업을 최선의 관행으로 권장하고 있습니다. 메타 사이트에서 GUI 업데이트가 실패하면 커맨드 라인으로 다시 구축하는 방식으로 되돌아가라는 안내를 포럼 관리의 일반적인 기대 사항의 일부로 여러 번 확인해 왔습니다. 따라서 롤백 없이 포럼을 망가뜨린 것이 아니므로 당신의 암시는 거짓입니다.
여기서 몇 시간 동안 논쟁을 벌일 생각은 없습니다. 그저 당신이 여기에서 완전히 합리적이지 않다고 생각할 뿐입니다.
더욱이, 어떤 형태의 스테이징 환경 없이 프로덕션 서버를 업그레이드하는 것은 스스로 고통을 자초하는 것과 같습니다.
완전한 복제본일 필요는 없으며, 대부분의 경우 5달러짜리 VPS면 충분합니다. 다운타임을 피하고 백업에 의존해야 하는 상황을 원치 않는다면, 이는 얻을 수 있는 가장 저렴한 보험입니다.
오래전부터 업데이트하지 않은 테스트용 DO 인스턴스에서 이 문제를 직접 테스트해 보았습니다:
보고된 대로 오류가 발생했습니다:
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/rails/sprockets
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:93:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 3 Unicorn worker(s) that were stopped initially
그리고 이제 업그레이드 페이지에는 다음과 같이 표시됩니다:
또한 메인 사이트는 500 오류를 반환합니다. /logs에서 다음 오류를 확인했습니다:
NoMethodError (undefined method `navigation_menu' for #<Class:0x00007fdffcb1b2f8>)
lib/wizard/builder.rb:98:in `block in build'
lib/wizard.rb:25:in `append_step'
lib/wizard/builder.rb:61:in `build'
lib/wizard.rb:110:in `requires_completion?'
lib/wizard.rb:117:in `user_requires_completion?'
app/serializers/site_serializer.rb:171:in `include_wizard_required?'
…
@pearsonified @mcdanlj 여러분이 받은 오류 메시지를 붙여넣어 주시겠습니까?
향후 다른 사용자에게 이 문제가 발생하지 않도록 방지할 수 있는 방법이 있는지 확실하지 않지만, 조사해 보겠습니다.
그동안 다음 단계가 도움이 되었나요?
오늘 아침에 커맨드라인 업그레이드를 실행해 보고 결과를 확인해 볼 거야. 포럼이 벌써 18시간째 다운되어 있네 
내가 물어본 거라면, 네, CLI 재구축은 잘 작동했다. 나는 꽤 괜찮은 SA(시스템 관리자)라서 여기서 포럼에서 해결책을 찾았지만, @pearsonified 같은 다른 포럼 운영자들도 큰 불편을 겪었다. 18시간 동안 다운타임이라니, 끔찍하다.
스테이징 환경과 프로덕션 환경에 대해 말하는 사람들은 완전히 딴 세상에서 사는 사람들이다. 소규모 VM에서 Discourse 포럼을 호스팅하는 비기업체 사용자들도 많다. "스테이징 환경에서 테스트해야 한다"는 것은 그들의 설치를 망가뜨린 것을 전혀 정당화하지 못하는 모욕적이고 교조적인 답변이다. 아무것도 그걸 정당화할 수 없다.
나는 이 훌륭한 소프트웨어가 완전히 무료라는 점을 정말 감사하게 생각한다. 가끔씩 겪는 문제들로 인해 그 감정이 바뀌지는 않는다.
디스커스는 무료이지만, 서버, 도메인, 그리고 우리의 시간은 그렇지 않습니다.
이것은 기업 환경과 무관하며, 변수가 많을 때 그저 상식적인 문제입니다. 업그레이드가 원활하게 진행되도록 많은 노력이 기울여지고 있으며, 중요한 오류를 해결하기 위해 시간을 무료로 쓰고 싶다면 그것은 본인의 선택입니다. 하지만 개인적으로는 제가 호스팅하는 비영리 및 자원봉사 커뮤니티가 고통스러운 긴 기간 동안 중단되는 것보다는, 무난한 업그레이드를 위해 한 번만 중단되는 것을 선호합니다.
테스트가 대표성을 갖출 수만 있다면, DigitalOcean의 가장 작은 VPS만으로도 업그레이드 리스크를 줄이는 데 충분합니다. 괜찮은 시스템 관리자라면 그 5달러는 커피 한 잔 값일 뿐이며, 시간당 시급의 일부에 불과합니다.
stg VM에는 포럼 데이터도 저장되어야 했는데, 그렇게 되면 호스팅 비용이 두 배가 됩니다. 어쨌든 그럴 필요는 없습니다. 여기는 비디오 게임 포럼이고, 약간의 다운타임(18시간이 아니라!)은 괜찮으니까요. 최악의 경우를 대비해 업그레이드 전에 VM 스냅샷을 만들어 두었으니, 그냥 되돌리기만 하면 됩니다.
이 문제가 4일 동안이나 방치되고 있다는 점이 우려됩니다. 롤백 없이 업그레이드가 실패했다면, "이건 당장 해결해야 한다"는 경각심이 생겼어야 합니다. 이 말은 논쟁의 여지가 없는 명백한 사실입니다.
저도 web-push Ruby 오류를 겪었습니다. 일반 포럼이고 커스텀 플러그인은 없습니다.
web-push-3.0.0은 Ruby 버전 >= 3.0을 요구하며, 이는 현재 버전인 2.7.6과 호환되지 않습니다
이전에는 커맨드 라인을 통해 업그레이드해야 한다고 언급된 적이 있습니다. 지금 이 문제를 일으키는 버전에 대해 해당 옵션을 활성화할 수 있을까요?
수정: 아, 실제로 그렇게 나와 있네요!
문제는 docker_manager 업데이트를 실행한 후 페이지를 새로고침하는 대신 상단의 탭을 클릭할 때 발생합니다. 따라서 JS로 탭만 변경하는 대신 HTTP를 통해 새로고침되도록 변경할 수 있을까요?