이 이미지는 작동할 가능성이 높습니다. 예를 들어 docker start b5f2a8a39709 명령으로 해당 이미지를 시작할 수 있습니다.
(또한 오래된 이미지들을 정리해 보시는 것도 좋습니다 - 상당한 양의 디스크 공간을 확보할 수 있을 것입니다!)
오류 응답: 컨테이너를 찾을 수 없음: b5f2a8a39709
감사합니다. 또한, 제 백업 절차는 시스템의 모든 파일을 복사합니다. 어디를 봐야 하고, 어디서 복사해야 하는지 알 수 있다면 더 최신 이미지가 그곳에 있을 가능성이 높습니다.
우회 조치를 진행하던 중 끼어들어서 죄송합니다. 하지만 우리는 다른 서버로 마이그레이션을 진행할 계획입니다. 이는 그 자체로 큰 도전이었는데요, 해당 서버가 전용 서버였기 때문이고, 지난 6월에 1년치 계약을 갱신한 상태였기 때문입니다.
Discourse 팀이 더 이상 지원되지 않는 서버에서 서비스를 실행하는 사용자에게 경고를 보내주면 좋겠습니다. 우리가 그랬던 것처럼 그 사실을 알아내는 과정은 매우 불쾌했습니다. (같은 문제를 겪는 사용자가 세 명이나 있습니다. 우리가 이야기하는 것은 서버입니다. 노트북처럼 빠르게 갱신되지 않거든요.)
이것이 의도적인 변경이 아니었음을 분명히 하고 싶습니다.
또한, 우리는 이 정도로 오래된 하드웨어에 직접 접근할 수 없으며, 정확히 어떤 문제가 발생하고 있는지 파악하는 데 커뮤니티의 도움을 받아야 합니다.
이것이 해당 gem 자체의 컴파일 문제임이 확실해지면, 우리는 조치를 취할 수 있습니다.
@here
app.yml 파일에 최상위 키를 추가하는 방법입니다.
base_image: discourse/base:2.0.20220621-0049-slim
이렇게 하면 문제를 우회할 수 있지만, 재빌드 속도가 약간 느려질 수 있습니다.
공감은 하지만, 여전히 전 세계 많은 프로바이더들이 이러한 서버를 낮은 진입 장벽의 서버로 제공하고 있습니다.
많은 소규모 오픈소스 프로젝트에는 이러한 서버가 가격 면에서 이상적이며, 32GB RAM을 갖춘 Intel Xeon이나 AMD Ryzen을 구매할 여유가 없는 경우가 많습니다.
해당 소프트웨어를 테스트할 하드웨어가 없다는 점은 충분히 이해합니다. 하지만 이 스레드에서의 소통을 보면, 우리 측에서 먼저 확인을 요청한 뒤 그 어떤 반응도 없었습니다.
이런 경우에는 대신 "죄송합니다, 확인해 보겠습니다"라는 간단한 한마디면 충분했을 텐데, 그렇게 하지 않고 우리를 방치해 두셨습니다.
해당 변경 사항으로 테스트 중입니다.
빌드가 동일한 방식으로 실패하는 것으로 보입니다.
containers/app.yml 파일에 다음을 추가한 상태입니다:
base_image: discourse/base:2.0.20220621-0049-slim
위 내용을 파일 상단에 추가했습니다.
즉, 문제는 미리 컴파일된 버전의 gem을 배포하는 것이 아니라, 해당 gem이 오래된 CPU에서 컴파일을 할 수 없다는 것입니다.
oj gem에 대해 issue #789를 제기했습니다.
이해했습니다. 최근의 docker 이미지 중 하나를 복원하고 싶습니다. rsync 백업에서 말이죠. 이 이미지들을 찾아서 복원하고 시작할 수 있는 절차를 알려주실 수 있을까요? 감사합니다!
./launcher start app을 시도해 보셨나요?
이 방법으로 해결되지 않으면, 마지막으로 정상 작동했던 커밋에서 다시 빌드하는 방법을 자세히 설명해 드린 다른 방법을 시도해 보세요.
네. 그렇게 하면 웹 서버는 실행되긴 하지만, 실제로 스레드에 접근할 수는 없고 그냥 회전만 할 뿐이에요.
이것은 도움이 되지 않습니다.
문제는 업데이트된 gem이 해당 명령어가 CPU에서 지원되는지 확인하지 않고 바로 사용한다는 점입니다.
이전(정상 작동하던) gem 버전을 설치하기 때문에(Bryan의 인스턴스를 복구하기 위해 제가 했던 조치로 증명됩니다) Discourse 인스턴스를 다시 가동하는 데는 도움이 되지만, 네 - 추가 업데이트(admin/upgrade를 통해)를 수행하면 동일한 문제가 다시 발생하게 됩니다.
새 빌드를 시도하거나 이전 인스턴스를 실행하는 데 아직 성공하지 못했기 때문에, 주말이 다가오고 있어 다음 주까지 기다려 보려고 합니다. 혹시 gem 쪽에서 상황을 수정해 줄 수 있을지 기대해 봅니다…
어떤 절차였나요? 솔직히 이 스레드의 여러 아이디어를 따라가다 보니 조금 혼란스럽습니다. 감사합니다!
이 게시물의 두 번째 부분:
한 번 해볼게요. 감사합니다.
다른 가능한 우회 방법은 app.yml에 다음 내용을 추가하는 것입니다.
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
이후에도 업데이트가 여전히 안전하지 않을 것이라고 가정해도 되는 것이 맞나요? 현재는 이전 커밋에서 빌드를 진행 중입니다.