Upgrade failed spectacularily에서 이어지는 토론입니다:
Discourse 업데이트를 수행하기 전에 VPS에 업그레이드가 필요한지 확인하는 가장 좋은 방법은 무엇인가요? 감사합니다.
생각나는 바로는, 운영체제(OS) 버전이 오래되었거나 Docker가 오래되었을 때 업그레이드할 수 있다고 생각합니다.
Ubuntu LTS(일반적으로 Discourse에 권장되는 배포판)를 사용 중이라면, 제 이해에 따르면 각 무료 버전 에디션은 5년 지원 주기를 가집니다.
따라서 제 이해에 따르면 목록에 따르면 18.04 또는 20.04를 사용 중이라면 운영체제 업그레이드를 고려해야 합니다. 18.04는 확실하고, 20.04의 지원이 4월에 종료되므로 이 경우에도 업그레이드를 고려해야 합니다.
다른 구성 요소는 Docker 버전 호환성을 확인하는 것입니다. 이 부분은 솔직히 확신이 서지 않습니다. 다만 추측컨대 Ubuntu 22.04 LTS가 Discourse가 요구하는 최신 Docker를 지원할 수 있을 것 같지만, 더 강한 지식을 가진 사람의 의견이 필요합니다. 하지만 여기 Meta에서 검색을 해보면 이 정보를 찾을 수도 있을 것입니다.
Discourse 3.4는 Docker 24.0.7 이상을 요구합니다.
구글 검색 결과에 따르면 Ubuntu 22.04 LTS가 이를 지원하는 것으로 보입니다.
물론 최신 Ubuntu 24 LTS에서도 지원됩니다. Ubuntu 20.04 LTS에서도 지원되는 것으로 보이지만, 제 생각에는 이 LTS 버전의 지원이 2025년 4월에 종료되므로 업그레이드를 고려하는 것이 좋습니다. 다만 이론적으로는 안전할 수 있으며, 운영 체제 업그레이드 전에 더 많은 시간이 필요하시다면 사용할 수 있습니다.
현재 사용 중인 운영 체제 버전을 알고 계신가요? Ubuntu LTS를 실행 중이라고 가정하고 있습니다.
저의 Docker 버전(20.10.21)은 해당 버전보다 이전 버전이고, Discourse 버전은 3.4.0.beta4-dev입니다. Discourse가 이제 3.4.0.beta4로 업그레이드하라고 알려주고 있습니다 – “중요한 업데이트가 있습니다. 업데이트해 주세요!”
두 가지 질문이 있습니다:
-
릴리스 노트 어디에 요구 사항이 명시되어 있나요? 저는 항상 공지 게시글을 대충 읽어봤지만, Docker나 Ubuntu 요구 사항을 본 적이 없습니다.
-
다시 Discourse를 업그레이드하기 전에 Ubuntu 24.04로 업데이트하고, 그에 포함된 Docker 버전으로 업그레이드하는 것이 맞을 것 같습니다. 맞나요?
감사합니다.
혹시 "업그레이드할 수 없다"는 뜻인가요? 아마도 그렇겠죠.
요건이 충족되지 않으면 업그레이드 스크립트가 내 포럼을 망치지 않고 정상적으로 종료된다는 말씀인가요?
방금 discourse_docker/launcher at main · discourse/discourse_docker · GitHub 확인했습니다:
docker_min_version='20.10.0'
docker_rec_version='24.0.7'
그러니 지금은 문제가 없을 수도 있겠네요. 24.0.7에 대한 말씀이 틀렸기를 바랍니다 – 하지만 제가 잘못된 곳을 보고 있는 것일 수도 있겠지요. 확인해 주시고 알려 주실 수 있을까요? 감사하겠습니다. 감사합니다.
Discourse 3.4의 Docker 요구 사항은 제가 실패한 명령줄 업그레이드 관련 토픽에서 가져온 것입니다. 인용하신 토픽에서 또는 다른 토픽에서 Jay라고 하는 분이 로그를 바탕으로 Docker 업그레이드가 필요하다고 언급한 것으로 기억합니다. 해당 로그에는 제가 언급한 최소 버전 이상의 Docker가 필요하다고 명시되어 있습니다.
아마 명시되어 있을 가능성이 높지만, 솔직히 말씀드리면 저는 그것들을 완전히 꼼꼼히 읽는 데 항상 능숙하지는 않습니다. 여기서 검색을 해보고 확인해 보겠습니다.
Ubuntu LTS 버전이 18.04라면 확실히 그렇습니다. 언급된 대로 Ubuntu 20.04 LTS라면 명령줄을 통해 수동으로 업그레이드할 수 있다고 생각합니다. 기억이 정확하다면 Docker 업그레이드에 관한 토픽이 있습니다. 제가 링크한 Docker 문서에는 업그레이드 방법에 대한 지침이 포함되어 있을 것으로 생각됩니다. 하지만 먼저 따라야 할 권장 단계가 있을 수 있으므로 해당 토픽이 있는지 확인하는 것이 좋습니다.
Discourse에 대해 저도 여전히 많은 것을 배우고 있다는 점을 염두에 두시기 바랍니다. Jay, Robert(Merrifield) 같은 분들은 이 유형의 주제에 대해 훨씬 더 많은 경험과 이해를 가진 분들 중 일부입니다.
그러나 가장 중요한 단계는 백업을 반드시 만들어 두는 것입니다. 제 생각에는 서버 스냅샷과 Discourse 백업을 모두 만드는 것이 좋습니다. 예정된 다운타임을 공지하고 서버 백업을 만드는 것도 좋으며, 이렇게 하면 업그레이드 이전 상태로 스냅샷을 로드할 수 있습니다. Discourse 백업만으로도 잘 작동할 것이라고 생각합니다.
확신할 수 없습니다. 공유된 로그가 있는 게시물들만 참고하고 있었거든요.
하지만 #documentation에서 가져온 가이드가 도움이 될 수도 있으니 참고해 보세요.
답변을 위해 플로우차트를 그린다면, 첫 번째 질문은 다음과 같은 형태가 될 것입니다.
다음 항목들이 모두 해당됩니까? 그렇다면 경험에 따라 진행하십시오. 해당되지 않는다면, 해당 버전이 최소 1개월 이상 경과한 최신 LTS인지 반드시 확인하십시오.
- 경험이 많은 시스템 관리자입니다.
- 안전한 위치에 최신 백업이 있으며, 이를 복원할 수 있다는 데 매우 확신이 있습니다.
- 명령줄을 통한 업그레이드 방법을 알고 있습니다.
- 여기 meta에서 문제를 보고할 때 로그의 관련 부분을 찾아 인용하는 방법을 알고 있습니다.
/etc/lsb-release 파일을 읽어서 현재 OS 버전을 확인하십시오.
root# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"
최근에 업데이트되었어야 하며, LTS 버전이어야 하고, 2년 이상 오래되었으면 안 됩니다. 숫자의 앞 두 자리는 연도를 나타냅니다. 하지만 1개월 미만인 LTS 버전은 신뢰하지 마십시오.
Move a Discourse site to another VPS with rsync에 설명된 대로 새로운 VM을 생성하고 그곳으로 이전하는 것을 권장합니다. 상당한 다운타임과 시스템이 손상될 가능성을 감수할 수 있다면 여러 번의 dist-upgrade를 시도해 볼 수 있습니다. 그렇게 할 경우, 복구가 가능하도록 스냅샷을 만들어 두는 것이 좋습니다(이 과정에도 다운타임이 발생합니다).
18.04에서 20.04로 업그레이드하는 과정은 같은 서버에서 수행했습니다. 아마도 How to upgrade your Ubuntu release - Ubuntu Server documentation 와 같은 가이드를 따랐을 겁니다. 100% 확신은 없지만, 이에 대해 어떻게 생각하시나요?
그 자리에서 업그레이드하는 것보다 마이그레이션을 선택하는 데에는 부수적인 이점이 있을 수 있습니다. 더 좋은 조건으로 서비스를 받을 수 있기 때문입니다. 제 경우를 들어보면, x86에서 ARM으로 전환하면서 동일한 호스팅 서비스에서 동일한 가격으로 더 많은 저장 용량을 제공하는 구성을 확보할 수 있었습니다. 또한 다른 호스팅 서비스로 전환하는 것도 가능하며, 저는 다른 사례에서 이 방법을 통해 다시 한번 더 좋은 조건을 얻었습니다.
Hetzner의 경우, 동일한 사양(vCPU, RAM, 저장 공간)에서 ARM 서버가 x86보다 약간 저렴합니다.
특히, 더 빠른 것 같습니다(Discourse 재빌드 속도와 페이지 로딩 시간 기준).
아쉽게도 Discourse에 대한 공식 벤치마크는 없지만, 최근 빌드 시간 비교를 수행한 적이 있습니다:
| Provider | Price | Disk | CPU | GB RAM | Build time | Data Centers |
|---|---|---|---|---|---|---|
| Hetzner CX22 (x86) | €3.95 | 40GB | 2 | 4 | 9m56s | DE, FI, SG, US (2) |
| Hetzner CAX11 (arm64) | €3.95 | 40GB | 2 | 4 | 5m45s | DE, FI |
공식적으로 ARM 호환 mail-receiver 이미지가 없다는 점에 유의하세요.
참고:
재빌드에 5분? 와, 제겐 약 2~3시간이 걸리는데.
저는 Digital Ocean에서 2GB 메모리를 가진 가장 작은 드롭렛을 사용하는데, 대략 10분 정도 걸리는 것 같습니다.
좋은 지적 감사합니다. 다만 제가 올린 Docker 문서 링크에서도 Gemini의 출력이 정확했던 것으로 확인되었습니다. 그래도 팁을 알려주셔서 감사합니다. 앞으로는 AI 출력에 대해 확실히 주의하겠습니다.
rsync 관련 토론은 질문과 제안된 변형이 너무 많아 따라가기 어렵다고 생각했습니다. 그래서 대신 이렇게 해 보았는데, 모두 정상적으로 작동하는 것 같습니다!