수 시간 동안 고군분투한 끝에, 이제 도움을 요청할 때가 된 것 같습니다.
디버그 로그:
https://privatebin.net/?b56249efe41b5599#8nt7yMQU2Hft4HysXSoZkxXQTYdR9MFv91qC9sbBgen
Droplet(또는 Docker 컨테이너)에서 GitHub로 연결할 수 없는 문제가 발생했습니다.
fatal: unable to access ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub’: Could not resolve host: github.com
GitHub에 접근할 수 있는지 확인해 주시겠습니까?
아, 그러면 짧은 시간 내에 너무 많이 재구축을 시도해서 서버 IP가 일시적으로 차단된 건가요?
다른 오류들은 중요하지 않나요?
방금 다시 시도했는데 여전히 차단되어 있네요. 다른 방법을 시도해 볼 수 있나요, 아니면 24시간을 기다린 후 다시 시도하는 게 좋을까요?
github.com에 ping/curl을 시도해서 응답이 오는지 확인해 볼 수 있습니다. 속도 제한이 아니라 방화벽이나 연결 문제일 수도 있습니다.
"호스트를 확인할 수 없습니다"라는 메시지는 DNS 문제, 즉 서버가 github.com의 IP 주소를 찾을 수 없음을 나타냅니다.
==================== REBUILD LOG ====================
x86_64 arch detected.
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
이 로그는 discourse_docker 저장소를 다른 곳에서 클론한 경우가 아니라면, 호스트가 github.com을 해결하고 연결할 수 있음을 시사합니다. 저장소의 리모트를 나열하는 다음 명령을 사용하여 이를 확인할 수 있습니다:
cd /var/discourse
git remote -v
다음과 같은 출력이 표시됩니다:
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
이것이 사실이라면, 호스트는 github.com을 해결할 수 있음에도 불구하고 Docker 컨테이너는 해결하지 못한다는 점에서 github.com을 해결하지 못하는 후속 오류는 Docker 연결성에 문제가 있음을 시사합니다.
git remote -v 명령은 의도한 대로 출력이 확인되었습니다. Docker 문제를 어떻게 해결해야 할까요, 아니면 단순히 재설치하는 것이 좋을까요? 데이터가 손실되지 않는 한 재설치도 마다하지 않겠습니다. 다음 단계가 어떻게 진행되든, 수동으로 백업하고 싶은데 Discourse가 데이터베이스와 업로드된 파일을 어디에 저장하는지 정확히 알려 주실 수 있을까요?
/var/discourse/shared/standalone은 컨테이너의 볼륨에 매핑되어 있으며, 모든 영속 데이터는 해당 경로 아래에 저장됩니다.
docker network ls 명령을 실행하면 Docker 네트워크 목록이 표시됩니다. 제 환경에서는 기본 브리지 네트워크와 다른 두 개의 네트워크가 보입니다. 컨테이너는 명시적으로 다른 네트워크를 사용하도록 지정되지 않는 한 기본 브리지 네트워크를 사용합니다.
기본 브리지 네트워크가 더 이상 외부 세계와의 연결을 제공하지 않는다는 정보를 찾았습니다. 이는 추측이지만, Ubuntu 22.04에서는 이 사항이 적용되는 Docker 버전으로 이동했을 수 있으며, 이는 Discourse 컨테이너가 사용자 정의 브리지를 사용하도록 설정되어야 함을 의미합니다.
/var/discourse/containers/app.yml 파일을 편집하여 아래 내용을 하단에 추가한 후 다시 빌드하면 된다고 생각합니다. (다만, 저는 이를 테스트하지 않았습니다.)
networks:
default:
driver: bridge
/var/discourse/shared/standalone/backups/default에는 데이터베이스와 업로드 파일 등 중요한 부분들이 압축된 백업으로 포함된 것 같습니다.
좋은 아이디어를 주셔서 감사합니다만, 결국 실행할 수 없었습니다.
그냥 Docker를 재설치해 볼까요? 아니면 그렇게 할 거라면 아예 모든 것을 초기화하고 Discourse를 처음부터 완전히 새로 설치하는 것이 나을 것 같습니다 (Discourse | DigitalOcean Marketplace 1-Click App 를 통해 설치했었거든요).
백업 파일을 가져오는 작업은 Discourse 관리자 화면에서 간단히 수행할 수 있는 것 맞죠?
표준 설치는 공식적으로 지원되는 유일한 설치 방법이지만, 아래에서 백업 복원 관련 정보를 찾을 수 있습니다. DO 1-Click 설치에서도 동일한 과정이 적용됩니다.
1-Click 앱이 명시적으로 Ubuntu 20.04를 사용하는 것으로 보이므로, 이 설정이 변경될 때까지 20.04를 유지하는 것이 좋습니다. 20.04는 앞으로 3년간 버그 수정 및 보안 업데이트를 계속 제공하므로 22.04로 전환을 서두를 필요는 없습니다.
다만, 먼저 Docker를 재설치해 보는 것도 좋습니다. 문제가 업그레이드 과정에서 발생했을 수 있으며, 설치 과정에서 Docker 네트워킹이 제거되었다가 다시 추가되는 것이 문제를 해결할 수도 있습니다.
결국 Ubuntu 22.04의 깨끗한 복사본으로 드롭릿을 재구축하고, Discourse를 수동으로(표준 방식) 재설치한 뒤 백업을 가져왔습니다. 빠르고 쉬워서 처음부터 이렇게 했으면 좋았을 걸 후회합니다.
도움 주셔서 감사합니다!
22.04에서 설치할 때 발생하는 일반적인 문제가 아님을 알게 되어 유용합니다.
이번 주말에 20.04에서 22.04로 do-release-upgrade를 몇 번 수행해 봤는데, Docker를 다시 설치하지 않아도 모두 정상적으로 작동하는 것을 확인했습니다. 지난 몇 주 동안 Ubuntu 저장소에서 무언가가 수정되었을 것입니다.
이제 이런 방식으로 업그레이드를 진행해도 문제없이 잘 될 것입니다.