./launcher rebuild app 실패: 'bundle exec rake db:migrate' 오류, github/master 저장소에서 auth/oath2_authenticator 제거로 인한 문제 가능성

안녕하세요, 도움을 요청드립니다…

장기간 운영 중인 Ubuntu 20.x 기반 EC2 인스턴스에서 Discourse를 사용 중인데, 문제의 근본 원인을 찾아보려 노력했습니다. 이 인스턴스들은 모두 AWS에서 구동 중이며, 거의 3년 동안 완벽하게 작동해 왔습니다. 그런데 갑자기 어떤 인스턴스도 재빌드(rebuild)가 되지 않습니다. app.yml 파일을 최소한의 설정으로 줄여 보았고, 끝없이 검색을 해 보았습니다. 현재 설치 환경은 Postgres 13, Discourse 2.9.0 Beta 4(항상 최신 버전을 유지하고 있습니다)이며, 특별한 설정 없이 매우 기본적인 컨테이너/도커 기반 설치를 사용하고 있습니다(별도의 컨테이너나 다른 소프트웨어의 독립 설치 등은 없습니다). 이는 수많은 추측 중 하나일 뿐이지만, 최근 Discourse 코드베이스에서 auth/oauth2_authenticator가 제거/이름이 변경되어 "ManagedAuthenticator"와 "UserAssociatedAccount"로 바뀌었다는 점을 알게 되었습니다.

다음 커밋에서 확인할 수 있습니다: DEV: Deprecate OAuth2Authenticator and OAuth2UserInfo (#15427) · discourse/discourse@78d0ec3 · GitHub
해당 커밋에 대한 저장소 내 코멘트:
DEV: Deprecate OAuth2Authenticator and OAuth2UserInfo (#15427)

이것들은 ManagedAuthenticator와 UserAssociatedAccount로 대체되었습니다. 자세한 내용은 Adding a new 'managed' authentication method to Discourse 를 참고하세요.

실패 직전 로그입니다 (네, discourse-doctor를 실행해 보았는데 거의 동일한 결과를 주었습니다… 또한 NGINX를 사용하지 않고 있는데, 이것이 일반적인 문제임을 확인했습니다):

I, [2022-05-17T21:26:52.663629 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all'
I, [2022-05-17T21:26:54.697333 #1]  INFO -- : discourse-chat-integration is already at latest compatible version
discourse-rss-polling is already at latest compatible version
discourse-assign is already at latest compatible version
discourse-azure-ad is already at latest compatible version
discourse-solved is already at latest compatible version
discourse-knowledge-explorer is already at latest compatible version
docker_manager is already at latest compatible version

I, [2022-05-17T21:26:54.697677 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
LoadError: cannot load such file -- auth/oauth2_authenticator
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:15:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:15:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.4/lib/zeitwerk/kernel.rb:35:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/dependencies/require_dependency.rb:21:in `require_dependency'
/var/www/discourse/lib/require_dependency_backward_compatibility.rb:18:in `require_dependency'
/var/www/discourse/plugins/discourse-azure-ad/plugin.rb:7:in `activate!'
/var/www/discourse/lib/plugin/instance.rb:679:in `instance_eval'
/var/www/discourse/lib/plugin/instance.rb:679:in `activate!'
/var/www/discourse/lib/discourse.rb:279:in `block in activate_plugins!'
/var/www/discourse/lib/discourse.rb:276:in `each'
/var/www/discourse/lib/discourse.rb:276:in `activate_plugins!'
/var/www/discourse/config/application.rb:222:in `block in <class:Application>'
/var/www/discourse/lib/plugin.rb:6:in `initialization_guard'
/var/www/discourse/config/application.rb:221:in `<class:Application>'
/var/www/discourse/config/application.rb:81:in `<module:Discourse>'
/var/www/discourse/config/application.rb:80:in `<top (required)>'
/var/www/discourse/Rakefile:7:in `require'
/var/www/discourse/Rakefile:7:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
(See full trace by running task with --trace)
I, [2022-05-17T21:26:55.807801 #1]  INFO -- :
I, [2022-05-17T21:26:55.808466 #1]  INFO -- : Terminating async processes
I, [2022-05-17T21:26:55.808709 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 44
I, [2022-05-17T21:26:55.808935 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 105
2022-05-17 21:26:55.808 UTC [44] LOG:  received fast shutdown request
105:signal-handler (1652822815) Received SIGTERM scheduling shutdown...
2022-05-17 21:26:55.810 UTC [44] LOG:  aborting any active transactions
2022-05-17 21:26:55.815 UTC [44] LOG:  background worker "logical replication launcher" (PID 53) exited with exit code 1
2022-05-17 21:26:55.816 UTC [48] LOG:  shutting down
2022-05-17 21:26:55.851 UTC [44] LOG:  database system is shut down
105:M 17 May 2022 21:26:55.894 # User requested shutdown...
105:M 17 May 2022 21:26:55.894 * Saving the final RDB snapshot before exiting.
105:M 17 May 2022 21:26:55.940 * DB saved on disk
105:M 17 May 2022 21:26:55.941 # Redis is now ready to exit, bye bye...


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 654 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c961e72970eba95a26f294e0f123987c40da1c350a4b1fe9621edf0bd665720c

하지만 2년 동안 업데이트가 되지 않은 것 같네요? (아니면 제가 잘못 본 건가요?) 그래서 이것이 문제가 될 가능성이 높습니다. 지금은 다른 해결책이 있을 것 같습니다.

네, azure-ad 플러그인은 더 이상 유지보수되지 않으며 GitHub에서 아카이브되었습니다. 가장 좋은 대안은 아마도

입니다 (Azure AD 사용 방법은 해당 게시글 하단에 있습니다)

정말 유용한 답변이라 감사하지만, 동시에 매우 실망스럽습니다. 이 플러그인은 이미 수많은 사용자에게 배포되어 사용되고 있었기 때문입니다. 이 플러그인은 사용법이 간단했고, 제3자 플러그인이 아니었기 때문에 향후 최소한 반(半) 공식 지원이 이루어지는 솔루션이 될 것이라고 꽤나 확신을 갖고 있었습니다. 만약 저장소에서 auth/oauth2_authenticator를 단순히 삭제하거나 이름만 변경하는 대신, 새 파일 하나둘을 추가하는 식으로 진행했다면 이런 문제가 발생하지 않았을 것입니다.

물론 OpenID Connect 인증 플러그인을 사용해보려고 하겠지만, 이를 구현하는 데는 상당한 노력이 필요할 것입니다.

공식 코드도 폐기될 수 있습니다. 이는 Discourse 자체의 문제라기보다는 릴리스 프로세스와 관련된 문제로 보입니다.

'매우 많은 사용자’를 보유하고 있다면, 모든 업데이트를 먼저 사이트의 스테이징(Staging) 복사본을 통해 진행하는 것을 고려해야 합니다. 프로세스를 먼저 검증하지 않고 프로덕션 서버를 무작정 업그레이드하는 것은 극도로 위험합니다.

고맙습니다. 프로덕션 서버를 무턱대고 업그레이드할 생각은 없었거든요 ;). 먼저 철저하게 테스트해야 할 환경이 꽤 많습니다.

테스트 후 변경 사항을 전달하고, 새로운 설정에서 차이를 찾아내는 데 매우 세심하게 접근하는 것이 더 중요합니다.