UI를 통해 업그레이드를 시도할 때 다음과 같은 메시지가 팝업으로 표시됩니다:
여러 번 git pull과 재빌드를 시도했지만 여전히 같은 메시지가 표시됩니다. 조언을 구합니다.
아래 작업을 수행해야 하는지 궁금합니다:
이것은 오래되고 잘 알려진 포럼에 관한 것입니다.
Cc @pacharanero
표준 설치였나요? 업그레이드를 잘못된 서버에서 실행한 것과 같은 문제일 수 있나요? 재구축이 실패하여 이전 컨테이너를 다시 시작했나요? 더 나은 추측은 없습니다.
링크한 주제에서 권장된 대로 운영 체제를 최신 상태로 유지해야 하지만, 이는 설명한 문제와는 무관합니다.
GUI 업데이트가 리셋되지 않은 것처럼 보일 때, 방금 SSH로 접속을 마쳤음에도 불구하고 다시 SSH 접속을 요구하는 경우가 있어 가끔 당혹스러웠습니다.
표준 설치 방식으로 진행했지만, 원래 설치는 2014년, Discourse가 공개 베타를 막 벗어난 초기 시절에 이루어진 것입니다.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
더 최신 버전의 Docker가 있지만, Ubuntu의 버전이 최신 버전보다 약간 뒤처지는 것은 흔한 일입니다.
OS는 완전히 그리고 정기적으로 업데이트되어 있습니다.
음. 업데이트 후 컨테이너가 재빌드되었는지 Discourse가 확인하기까지 약간의 지연이 있습니다. 다만 docker-manager에 영향을 미친 적은 본 적이 없습니다.
아래를 시도해 볼 수 있습니다:
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
다만, 이미 꽤 시간이 지났으므로 이것이 문제의 원인일 것 같지는 않습니다. 그래도 해보는 데는 무리가 없습니다.
지원되는 Docker의 최소 버전을 정확히 기억하진 못하지만, 적어도 Ubuntu 16.04를 사용하지 않는다면 그것도 문제가 아닐 것 같습니다.
지금 실행 중인 브랜치와 관련이 있을 수 있을까요?
containers/app.yml에서는 tests-passed를 명시적으로 선택하고 있습니다.
하지만 물론 컨테이너 내부에서 실행되는 것이 그 브랜치입니다. 컨테이너 외부의 기본 브랜치가 무엇인지가 영향을 줄 수 있을까요?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
예전에는 GitHub에서 기본 브랜치로 master를 사용했습니다. 지금은 main으로 바뀌었죠.
맞습니다. 다음을 시도해 볼 수 있겠네요.
cd /var/discourse
git checkout main
하지만 이를 명시적으로 수행할 필요가 있다고 생각하지는 않았습니다.
다음은 어떤가요?
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
이것은 물론 discourse_docker와 관련이 있습니다:
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
해당 브랜치는 2021년 8월에 전환되었으며, 작성 시점 기준으로 main 브랜치보다 49개의 커밋이 뒤처져 있습니다:
GitHub - discourse/discourse_docker at master · GitHub
따라서 main 브랜치로 전환하는 것이 확실히 필요할 것입니다.
그러나 저는 @pfaffman의 의견에 동의합니다. 저는 명시적으로 그렇게 한 적이 없으므로, 이를 수행한 스크립트가 있었을 것입니다. 아마도 다음 재빌드 시 발생할 수 있을까요?
다음과 같은 결과를 반환합니다.
user@inside-container-app:/var/www/discourse# git status
Refresh index: 100% (30949/30949), done.
On branch tests-passed
Your branch is up to date with 'origin/tests-passed'.
최신 상태인 것 같습니다. 그런데 여전히 업그레이드 비활성화 페이지가 표시되나요?
네. 제가 운영하는 다른 Discourse 사이트 중 좀 오래된 것을 확인해 봤는데, 이 사이트도 master를 사용 중이며 마찬가지로 Upgrades Disabled 페이지가 표시됩니다.
그럼에도 불구하고, 2022년 중반에 설정한 또 다른 Discourse 사이트도 master를 사용 중인데 업데이트 화면은 정상적으로 표시됩니다!
discourse_docker의 브랜치를 main을 추적하도록 변경하면 문제가 해결된다는 확인을 받을 수 있다면, 한 번 시도해 볼 의향이 있습니다. 아마도 저만 사용하는 사이트에서 테스트해 볼 수 있을 것 같습니다.
이 시점은 제가 일부 Discourse 사이트에서 업데이트 시간에奇怪的한 동작을 시작했던 때와 대략 일치합니다. (이 때문에 저는 매번 Ansible을 사용하여 SSH를 통해 모든 사이트를 업데이트하게 되었습니다).
저도 대개 그렇게 합니다. 다만 점점 더 https://www.pfaffmanager.com/ 를 통해 Ansible 업그레이드 스크립트를 실행하는 방식을 사용하고 있습니다.
네, 개인 노트나 저널 등으로만 사용하는 Discourse에서 트랙을 main으로 전환했습니다.
전환 전에는 master를 추적하고 있었고, 관리자 업그레이드 페이지가 실제로 비활성화되어 있었습니다.
main으로 전환하고 재빌드한 후, 관리자 업그레이드 UI가 정상적으로 작동하는 것을 확인할 수 있었습니다.
음. 그러면 그 오래된 설치 환경들이 모두 브랜치를 변경해야 한다는 뜻인 건가? @Falco, 이 부분을 한번 확인해 줄래?
런처가 브랜치를 master에서 main으로 자동으로 변경합니다. 대기 중인 스테시 변경 사항과 같은 요인이 자동 전환을 방해한 것으로 보입니다.
이렇게 많은 인스턴스에서 그런 일이 일어날 확률은 얼마나 될까요?
그리고 도대체 스테시 변경 사항이란 무엇인가요?
몇 개를 말씀하시는 건가요? Discourse 인스턴스는 수천 개가 있고, 이 문제에 대한 수십 건의 보고서는 보이지 않습니다. 적어도 아직까지는요 
현재 이 버그를 재현할 수 있는 서버를 보유하고 있고, 하루 정도 더 그 상태를 유지할 수 있다면, 추가 조사를 위해 여기에 답변해 주세요.
음. 이 문제는 우리의 인스턴스에서 @nathank 와 관련이 있을 지도 모릅니다. 저는 Discourse 코드베이스와 전혀 무관한 운영용 파일들을 Discourse Git 저장소와 동일한 디렉토리에 가지고 있습니다. ./launcher가 브랜치를 변경하려고 하면 Git이 반드시 오류를 발생시키며, 이 변경 사항을 stash하거나(또는 커밋하거나) 해야 합니다.
@Falco 감사합니다. 추가 조사를 해보겠습니다. Git이 브랜치 변경 시 어떤 이유에서든 오류를 일으키는 Discourse 인스턴스만 영향을 받을 수 있을 것 같습니다.
업데이트: 몇 가지 추적되지 않은 파일로 인해 발생한 문제가 *원인이었을 수 있습니다.
해당 파일을 삭제하고 git checkout main 명령이 성공적으로 실행되는지 확인했습니다.
그 후 ./launcher rebuild app을 실행했는데 정상적으로 작동하는 것 같습니다.
제가 파악한 바로는, 위에서 @Falco가 언급한 바와 같이 Discourse 저장소에서 main을 실제로 추적할 *필요는 없는 것 같습니다. ./launcher rebuild app을 실행하면 스크립트 자체가 올바른 브랜치를 체크아웃합니다.
기존의 Discourse 인스턴스 몇 개는 git checkout main, git pull, git checkout master 명령이 오류 없이 정상적으로 실행되었음에도 불구하고 여전히 “업그레이드 비활성화” 페이지가 표시되고 있었습니다.
이 인스턴스들은 단순히 main 브랜치를 추적하도록 두고 ./auncher rebuild app 명령을 실행했는데, 그렇게 하니 문제가 해결되었습니다.