다시 discourse가 오프라인 상태: 「bootstrap failed with exit code 5」

커뮤니티 여러분, 안녕하세요! 이런 상황에서 만나게 되어 죄송합니다. 업그레이드 실패로 인해 Discourse가 오프라인 상태입니다.

다음과 동일한 문제입니다.

Discourse offline after failed upgrade "bootstrap failed with exit code 5"

v3.2.0.beta3 버전으로 업그레이드를 시도했습니다.

아직도 Ubuntu 16.04를 사용하고 있습니다.

다행히 이전 docker 이미지(라고 생각합니다)는 가지고 있지만, 서비스를 복구하려면 어떻게 해야 하는지 확실하지 않습니다. 또한 DigitalOcean을 사용 중입니다.

오류

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --retry 3 --jobs 4' failed with return #<Process::Status: pid 448 exit 5>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle config --local deployment true'", "su discourse -c 'bundle config --local without \"development test\"'", "su discourse -c 'bundle install --retry 3 --jobs 4'"]}
bootstrap failed with exit code 5
** 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.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261

도와주실 분 계신가요?

기존 이미지들은 가지고 있지만, 최신 이미지는 삭제했습니다…

docker rmi 51421f454322 -f

기존 컨테이너들은 가지고 있지만, ./launcher start app을 실행하려고 하면 삭제된 이미지를 우선적으로 사용하는 것 같습니다.

root@hostname:/var/discourse# ./launcher start app
WARNING: Docker version 17.05.0-ce deprecated, recommend upgrade to 17.06.2 or newer.
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml

starting up existing container
+ /usr/bin/docker start app
app

root@hostname:/var/discourse# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                      NAMES
afeec2777503        51421f454322        "/sbin/boot"        3 hours ago         Up 5 seconds        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
root@hostname:/var/discourse# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
discourse/base      2.0.20231218-0429   984f729957df        12 days ago         3.14GB

이미지 ID 984f729957df로 진행하는 방법이 있을까요?

더 쉬운 방법은 새로운 드롭레트를 생성하고 /var/discourse를 복사한 후 거기서 다시 빌드하는 것입니다. 이렇게 하면 문제를 완화하는 것이 아니라 근본적으로 해결할 수 있습니다.

도커 명령을 알려 주는 런처 명령이 있습니다. 이 명령이 도움이 될 수 있습니다. 런처 스크립트를 확인하면 명령 이름을 찾을 수 있지만(현재 모바일에서 작성 중입니다), 확인해 보시기 바랍니다.

다음과 같이 제안하고 있는 것 같습니다: ./launcher start-cmd app

출력이 꽤 많은데, + true run --shm-size=512m -d --restart=always...로 시작합니다.

대단한 추측이지만, 다음을 시도해 보았습니다:
docker + true run 984f729957df --shm-size=512m -d --restart=always ...
하지만 효과가 없었습니다.

container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH".

도움이 되실 수 있다면 환영합니다. 감사합니다.

그래요. 뭐, 그런 거죠. 어떻게 해야 할지 모르겠어요. 유일하게 쓸 수 있던 이미지를 삭제했을 수도 있겠네요.

제 권고는 그대로, 새 드롭렛을 만들고 파일을 복사해 오는 겁니다. 만약 저의 클라이언트였다면 그렇게 했을 거예요.

제안해 주셔서 감사합니다. 계획되지 않은 마이그레이션은 선호하지 않지만, 결국 그렇게 될 것 같습니다. 혹시 이 글을 말씀하시는 건가요? Move a Discourse site to another VPS with rsync

DO Spaces(S3 저장소)를 활성화한 경우, 추가로 알아야 할 지침이 있을까요?

이 시기에 다른 팀원들과 필요한 변경 사항을 적시에 조율하는 것은 정말 어려울 것 같습니다(읽어 주시는 분은: 아마 불가능할 것입니다).

마이그레이션을 계획할 수 있도록, 먼저 마지막으로 정상 작동하던 상태로 되돌리는 것이 훨씬 낫겠습니다.

도움 주실 수 있는 분 계신가요?

Configure an S3 compatible object storage provider for uploads을 따랐다면 그렇지 않습니다. 데이터베이스에 설정이 남아 있는 경우, rsync 대신 복원(restore)을 시도하면 상황이 더 복잡해질 수 있습니다.

새로운 드롭렛으로 이동하는 것은 위험이 낮습니다. 비활성화된 사이트로 DNS를 다시 변경할 수 있기 때문입니다. 하지만 DNS와 Digital Ocean에 접근할 수 없다면 꼼짝없이 막힙니다.

시작 명령어에서 무언가를 따옴표로 묶는 것을 놓친 것 같습니다. 그것이 당신이 하고 싶은 일이 아닐까 싶습니다.

행운을 빕니다.

업로드를 위한 S3 호환 객체 저장소 제공자 구성

이 서비스를 2016년에 구성했기 때문에, 불행히도 설정이 데이터베이스에 저장되어 있는 것으로 보입니다. app.yml에는 S3 매개변수가 없습니다.

알아두면 좋을 다른 함정은 없나요?

rsync로 전송하면 문제가 없습니다. 그런 다음 권장되는 설정으로 전환할 수 있습니다. 데이터베이스 복원을 시도하면 문제가 발생할 수 있습니다.

도움을 주셔서 다시 한번 감사합니다. rsync와 관련하여, 설명서가 이렇게 명시하고 있어 조금 걱정이 됩니다:

  1. 새 서버를 설정하고 동기화
  2. 기존 서버에서 서비스를 중지
  3. --delete 옵션을 추가하여 다시 동기화

이 방식은 불안정해 보일 뿐만 아니라, 제 상황에서는 적용이 불가능합니다. 이 부분이 문제가 될까요? 지난 rsync 이후 포럼에서 발생한 변경 사항이 동기화되는지만 확인하면 된다고 생각하지만, 제가 틀렸을 수도 있습니다.

업데이트:
새로운 Droplet로 다시 온라인에 복귀했습니다.

마이그레이션이 비교적 간단하다는 걸 이제 알게 되어 다행입니다. 업데이트가 기존 Droplet을 깨뜨리지 않았더라면 훨씬 좋았을 텐데요.

연휴인 걸 알지만, 개발팀에서 시간을 내서 이 문제를 살펴봐 주시면 좋겠습니다. 이건 단발성 문제가 아니라고 생각합니다. 다른 스레드에서 태그를 받았는데, 거기서 컬렉션이 계속 커지고 있는 걸 확인했습니다.