오늘 새 VPS로 마이그레이션을 진행했는데, 최근 업데이트에서 구버전 운영체제 차단 문제에 부딪치는 분들이 꽤 있는 것 같아 경험을 공유해 보려 합니다 ![]()
저는 Digital Ocean을 사용하므로 새로운 드롭렛(droplet)을 생성했습니다.
구 VPS = Ubuntu Server 18.04.6 LTS
신규 VPS = Ubuntu Server 23.10
새 VPS에서 기본적인 정리를 수행했습니다 - 필요에 맞게 수정하세요:
Apt-get update
Apt-get upgrade
Apt-get install fail2ban
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow http
ufw allow https
ufw enable
이후 Discourse를 위한 새 빈 디렉터리를 생성했습니다:
sudo mkdir -p /var/discourse
그다음 Docker를 설치했습니다:
wget -qO- https://get.docker.com/ | sh
그리고 DNS의 TTL을 30분에서 10분으로 변경했습니다(GoDaddy가 허용하는 최소값).
구 서버에서는 지난밤의 Discourse 데이터베이스 백업의 로컬 사본을 다운로드했습니다(로컬 백업은 아무리 많아도 지나치지 않습니다). 또한 app.yml 사본도 로컬 PC로 다운로드했습니다.
위에서 몇몇 분들이 제안한 대로 “루트-투-루트(root-to-root)” rsync를 수행했습니다. DNS 혼란을 피하기 위해 호스트명 대신 IP 주소를 사용했습니다. 또한 위에서 제안된 대로 -avz 옵션을 사용했습니다:
rsync -avz root@old.ip.address.here:/var/discourse /var
참고로 제 discourse 폴더는 25GB입니다.
구 서버에서 새 서버로 rsync하는 데 약 25분이 걸렸습니다. 이는 동일한 LON1 리전에 있는 두 Digital Ocean 드롭렛 사이의 전송이므로, 환경에 따라 결과가 다를 수 있습니다.
rsync를 마치고 리빌드를 시도한 후, @piratdavid가 postgres database system is shut down 관련으로 겪었던 동일한 오류가 발생했습니다.
그래서 구 VPS에서 앱을 중지했습니다:
./launcher stop app
그리고 이번에는 변경 사항만 포함하도록 rsync를 다시 실행했습니다:
rsync -avz --delete root@old.ip.address.here:/var/discourse /var
이후 구 Discourse 앱을 다시 시작하고 즉시 유지보수 모드(Maintenance Mode)로 전환했습니다. 이렇게 하면 사용자가 여전히 사이트에 접근할 수 있으며 일반적인 유지보수 경고 메시지를 볼 수 있습니다.
이로써 새 VPS 작업을 위한 시간도 확보됩니다 ![]()
로컬 PC의 HOSTS 파일을 업데이트하여 브라우저 경고나 문제 없이 새 VPS의 discourse에 접근할 수 있도록 했습니다.
새 VPS에서 다음을 실행했습니다:
./discourse-setup
이것은 app.yml 파일의 RAM 및 CPU 설정을 자동으로 업데이트하기 위함입니다.
그다음 새 VPS에서 앱 리빌드를 수행했습니다:
./launcher rebuild app
간단한 스모크 테스트를 수행했고, 모두 정상적으로 작동했습니다.
DNS 업데이트 완료 - 작업 종료.
상세한 주제에 대해 감사드립니다, 여러분 ![]()