# Discourse 업데이트/업그레이드 의존성 확인
**URL:** https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142
**Category:** Feature
**Created:** [5월 29, 2025, 7:53오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142 "2025-05-29T19:53:13Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [5월 29, 2025, 7:53오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/1 "2025-05-29T19:53:14Z")
수년간의 관찰 결과, 의존성 문제(예: Docker 버전/OS)로 인해 업데이트/업그레이드가 실패하는 경우가 있음을 확인했습니다.
제 아이디어는 Discourse가 기본 요구 사항이 충족되는지 확인하기 위해 일종의 의존성 검사를 수행하는 것입니다. 검사에 실패할 경우, 필요한 사항에 대한 세부 정보를 제공한 후 업데이트/업그레이드 프로세스를 중단합니다.
이는 실패할 프로세스를 중단함으로써 Core Discourse의 업데이트/업그레이드를 중단시켜 포럼의 다운타임을 줄이는 데 도움이 될 것입니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 29, 2025, 10:06오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/2 "2025-05-29T22:06:44Z")
그들은 그 일을 위해 꽤 열심히 노력하고 있습니다. 잘못될 수 있는 것들의 수가 꽤 많습니다. 대부분 운영체제(OS)(그리고 아마도 Docker)를 최신 상태로 유지하지 않으면 사용자 본인의 책임입니다.
그들은 Docker 버전을 확인하려고 하고, 제가 사용하는 스크립트는 Docker가 알려진 문제가 있는 경우 업그레이드를 수행합니다(아마도 Docker를 항상 업그레이드하는 것이 더 나을 것입니다).
기본 이미지(base image)가 조금이라도 변경되면 항상 커맨드라인 업그레이드를 강제하는 것이 더 나을 것이라고 생각합니다. 대시보드가 클릭 한 번으로 커맨드라인 업데이트를 수행하기 때문에 저는 거의 사용하지 않습니다.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [5월 29, 2025, 10:40오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/3 "2025-05-29T22:40:24Z")
deos 업데이트가 `docker_manager`의 docker를 업데이트하나요?
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [5월 29, 2025, 10:49오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/4 "2025-05-29T22:49:06Z")
저는 분명히 책임을 전가하려는 시도를 하고 있는 것입니다. 셀프 호스팅, 특히 더 구체적으로 말하자면, 서버 운영체제(OS)를 반드시 이해해야 하는 것이 아닙니다. 대부분의 사용자는 OS를 설치하고 일반적으로 최신 상태로 유지합니다. 하지만 LTS(장기 지원) 버전을 사용하는 경우, OS를 업그레이드하는 것에 대해 알지 못하거나 이해하지 못하는 경우가 많습니다. 특히 롤링 릴리스에 익숙한 사용자라면 더욱 그렇습니다.
예를 들어, 제가 도움을 주고 있는 한 회사는 한동안 업데이트를 하지 않다가 업데이트가 사용 가능하다는 것을 알게 되었습니다. 그래서 웹 UI를 통해 Docker를 업데이트했습니다. 그 결과 Discourse도 업데이트할 수 있게 되었습니다.
하지만 Ubuntu LTS가 최신 버전이 아니어서 Docker 업데이트가 최소 요건을 충족하지 못했습니다. 그럼에도 웹 UI는 업데이트 시도를 허용했습니다. 당연히 업데이트가 실패했고 사이트가 다운되었습니다.
그들은 명령줄을 통해 재구축을 시도했지만, 최소 요건이 충족되지 않아 당연히 실패했습니다.
웹에서 업데이트할 때 Docker 버전이 최소 요건을 충족하지 못하는 것을 식별할 수 있었다면, 사이트가 다운되지 않고 미충족 의존성을 알리면서 업데이트 프로세스를 중단할 수 있었을 것입니다.
저는 그들을 위해 일반적인 점검을 해 보았습니다. 서버에서 다른 것들도 실행하고 있는 것으로 보였습니다. 그래서 저는 기술 담당자에게 LTS를 더 새로운 버전으로 업그레이드하도록 살펴봐 달라고 지시했습니다. 제가 직접 OS를 업그레이드하면 그들이 실행 중인 다른 것들이 깨질까 봐 원치 않았기 때문입니다.
웹 및 명령줄 재구축 시도를 하기 전에 컨테이너를 재시작하는 쉬운 방법이 있을까요?
저는 ./launcher start app을 시도해 보았지만 실패했습니다.
또 다른 문제입니다. Discourse 사이트가 다운된 상황 때문에 rsync를 사용하여 새 서버를 설정하는 방식이 작동할까요? 그들은 권장되는 ‘테스트 통과’ 버전 대신 ‘안정’ 버전을 실행하고 있습니다.
만약 'do-release-upgrade’를 실행하고 수동으로 Docker를 업그레이드하면 PostgreSQL을 업그레이드하는 데 효과적인가요?
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [5월 29, 2025, 10:51오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/5 "2025-05-29T22:51:03Z")
이는 Ubuntu LTS 지원 버전 내에서 이루어집니다. 단, LTS에서 지원하는 버전만 해당됩니다. 이 경우 해당 LTS는 수명 종료 상태이므로 최소 Docker 버전을 지원하지 않습니다.
기억이 맞다면 Ubuntu LTS 버전은 4년 동안 업데이트를 제공합니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 29, 2025, 11:29오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/6 "2025-05-29T23:29:23Z")
> [@Heliosurge](#):
>
> 대부분의 사람들은 OS를 설치하고 일반적으로 최신 상태로 유지합니다
제가 함께 일하는 사람들은 그렇지 않습니다. EOL(지원 종료)이 지났다고 해도 업데이트를 하지 않습니다.
> [@Heliosurge](#):
>
> 웹에서 업데이트 시 Docker 버전이 최소 요건을 충족하지 못한다고 식별된다면
컨테이너 내부에서 실행 중인 프로세스가 어떤 버전의 Docker 위에서 실행되고 있는지 알 수 없다고 생각합니다.
아마도 가능할 수도 있겠네요. 컨테이너 내부에서 실행 중인 버전을 확인할 수 있는 것 같습니다.
`https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion`
그래서 더 잘 할 수도 있겠네요. 실제로 작동한다면 대시보드에 추가할 수 있는 멋진 기능이 될 것입니다.
> [@Heliosurge](#):
>
> ./launcher start app을 시도했습니다.
>
> 실패했습니다.
보통은 잘 작동합니다. 예외적인 경우는 데이터베이스가 마이그레이션된 경우입니다.
OS가 구버전이라면, 새 VM으로 이전하는 것이 더 쉽고 안전하다고 생각합니다. 이상적으로는 기존 서버가 여전히 작동하는 동안 이 작업을 수행해야 합니다. [rsync를 사용하여 Discourse 사이트를 다른 VPS로 이동하기](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812)를 참조하세요.
백업이 있다면 데이터베이스 복사 및 데이터베이스 업그레이드를 건너뛰고 새 데이터베이스에 복원하면 됩니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [5월 29, 2025, 11:54오후 UTC](https://meta.discourse.org/t/discourse-update-upgrade-dependency-check/368142/7 "2025-05-29T23:54:28Z")
> [@pfaffman](#):
>
> > [@Heliosurge](#):
> >
> > 대부분의 사람은 OS를 설치하고 일반적으로 최신 상태로 유지합니다.
>
> 제가 일하는 사람들은 그렇지 않아요. EOL(지원 종료) 상태라고 알려줘도 업데이트를 하지 않거든요.
그래서 제가 업데이트라고 말한 거예요. EOL인 경우에는 OS 업그레이드가 필요합니다. 하지만 지시를 잘 따르지 않는 다양한 사람들이 있다는 점에는 동의합니다. 😉
제가 무료로 도움을 주는 회사에서 관리자로 승진했을 때 🤦♀️
포럼이 언젠가 충돌할 것이라고 한 달 넘게 경고했었어요. 재빌드 앱을 실행하는 데 필요한 공간이 부족했거든요. 7년 전의 최소 사양 서버였어요. 기억이 정확하지는 않지만 총 용량이 25GB 정도였던 것 같아요. 당연히 그들은 듣지 않았고, 결국 여기 있는 누군가에게 돈을 지불해서 포럼을 새 서버로 옮겼습니다. 전체 다운타임은 약 2주, 혹은 그 이상이었어요.
> [@pfaffman](#):
>
> 아마도 가능할 수 있어요. 컨테이너 내부에서 실행 중인 버전을 확인할 수 있는 것으로 보입니다.
>
> `https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion`
>
> 그래서 그들은 더 잘할 수 있을지도 몰라요. 정말로 작동한다면 대시보드에 추가할 수 있는 멋진 기능이 될 수 있겠죠.
그것이 작동할 수 있다면 정말 멋질 거예요. 저나 당신처럼 여기에서 상당한 시간을 보내는 사람들은 비교적 최신 상태를 유지하지만, 문제 발생 후에나 방문하거나 추가 기능이나 기타 사소한 지원 문제를 위해 방문하는 다른 많은 사람들과 비교하면 그렇다는 거죠.
> [@pfaffman](#):
>
> 보통은 잘 작동해요. 예외는 데이터베이스가 마이그레이션된 경우입니다.
>
> OS가 구버전인 경우, 일반적으로 새 VM으로 이동하는 것이 더 쉽고 안전하다고 생각해요. 이상적으로는 구 서버가 여전히 작동하는 동안 수행해야 합니다. [rsync를 사용하여 Discourse 사이트를 다른 VPS로 이동하기](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812)를 참조하세요.
알겠습니다. 그들에게 조언해 주겠어요. 하지만 백업이 얼마나 오래된지 확실하지 않아요. 그래서 그들의 경우 rsync나 OS 업그레이드를 검토해야 할 것 같아요.
개인 서버가 구버전이 되어가던 때, 저는 웹/명령줄 업데이트를 하지 않도록 주의하며 많은 자료를 읽었어요. rsync 절차를 사용할 수 있을 때까지요. 그리고 여전히 몇 가지 작은 문제가 발생했는데, 당신과 커뮤니티가 디버깅을 도와주셨어요.
🍻😎👍✨