기존 Discourse에서 백업 내보내기 (현재 백업은 S3에 저장되도록 설정되어 있지만, 이는 수동 파일 백업이 될 것이라 이해합니다)
새로운 Discourse에 백업 가져오기 (S3에서 자동으로 가져올 수 없으므로 수동으로 수행해야 한다고 이해합니다)
여기서 1단계 수행 시 몇 가지 제약 사항으로 인해 막혀 있습니다. 단일 도메인 이름을 가지고 있으며, 새로운 서버에도 동일한 도메인 이름을 유지하고 싶고, 다운타임이 없기를 원합니다 (새 서버 설정을 완료하고 백업을 복원한 후, 마지막으로 DNS 항목을 새 서버를 가리키도록 변경하여 두 서버가 동시에 실행되는 동안 다운타임을 피하려는 것이 목표입니다).
제가 이해하기로는, 새로운 Discourse 서버를 설정할 때 기존 서버의 app.yml을 새 서버로 복사한 후 discourse-setup을 실행할 수 있습니다. 여기서 제가 발견한 문제는, 이렇게 하면 기존 서버와 동일한 DNS 이름을 사용하게 된다는 점입니다(이것은 제가 원하는 것입니다). 하지만 두 가지 문제를 예상하고 있으며, 해결 방법을 찾고 있습니다.
도메인 이름이 여전히 구 서버를 가리키고 있으므로, Let’s Encrypt 인증서가 새 서버에 대해 SSL 인증서를 생성하지 못합니다.
SSL 인증서가 없으면(구 서버 설정은 SSL만 사용하도록 되어 있으며 이는 app.yml에 그대로 유지됩니다) 서버가 시작되지 않습니다.
DNS 이름 리다이렉션을 사용하여 Discourse 서버에 연결해 보았지만, 입력한 URL이 app.yml 설정과 일치하지 않으면 NGINX 또는 Discourse가 작동하지 않고 브라우저에서 연결 시 오류가 발생합니다. 따라서 웹 인터페이스 없이 백업 복원 프로세스를 시작할 수 없습니다.
그러면 기존 서버의 app.yml을 사용하여 새로운 Discourse 서버 설정을 완료하고, 백업을 복원한 후 DNS를 전환하는 방법은 무엇인가요? 아니면 이를 수행하는 더 쉬운 다른 방법이 있나요?
같은 S3 버킷을 사용하지 않을 경우, 백업이 S3 파일을 다운로드하도록 강제하는 숨겨된 설정이 있습니다. 설정 파일에서 해당 설정의 이름을 확인한 후 rails 콘솔에서 값을 설정할 수 있습니다. 이 주제를 다루는 게시물이 있지만, settings.yml 파일을 직접 확인하는 것이 가장 쉽습니다.
discourse-setup을 실행할 필요는 없으며, app.yml 파일을 복사하고 다시 빌드하기만 하면 됩니다.
Let’s Encrypt 인증서는 rsync로 복사할 수 있습니다. 실제로 /var/discourse 디렉터리 전체(일부 로그 등은 제외하고)를 복사해도 됩니다.
이상적으로는 “lift and shift”(원격 이전)을 하는 것이 목표이지만, Amazon Lightsail의 경우 기존 이미지를 가져올 수 없기 때문에 이것이 불가능합니다. 따라서 네, 동일한 S3를 그대로 사용하게 됩니다.
당신의 접근 방식이 lift and shift에 가장 가까운 것 같습니다. 제가 이해한 바로는, 원래 서버의 /var/discourse 폴더 전체를 tar/gz로 압축한 후 새 서버에 압축을 풀고 discourse start를 실행한 뒤, DNS를 bee 서버로만 다시 지정하면 되는 것이 맞나요? 새 서버에서 Discourse를 다시 빌드해야 하나요? 폴더 외부의 Nginx, Docker 및 기타 의존성은 어떻게 처리해야 하나요?
고맙습니다. 분명히 리프트 앤 쉬프트(Lift and Shift)가 내가 생각했던 것만큼 깔끔하지는 않더군요. 원활한 리프트 앤 쉬프트 작업을 위해 이전과 이후에 몇 가지 점검을 수행해야 합니다. (Postgres를 12.0에서 13.0으로 업그레이드하는 과정에서 리프트 앤 쉬프트 절차에 대해 몇 가지 교훈을 얻었습니다.) Amazon LightSail 서버(1GB RAM)로 이전하려는 분들을 위해 향후 참고용으로 단계별 가이드를 공유합니다:
기존 서버
S3에 백업 생성
cd /var/discourse
./launcher rebuild # 원활한 전환을 위해 최신 빌드 가져오기
./launcher cleanup # 오래된 데이터를 제거하고 패키지 크기를 줄이기 위해 정리
./launcher stop app # 이 단계를 건너뛰면 나중에 Postgres로 재빌드할 때 실패할 수 있습니다
discourse-setup을 실행하지 않는다는 의미인가요, 아니면 Discourse 실행에 필요한 컨테이너를 빌드하지 않는다는 의미인가요? 후자를 의미하신다면, 기존 이미지를 새 서버에서 사용할 수 있는 레포지토리에 푸시하는 방식으로 가능하지만, 초보자가 쉽게 처리할 수 있는 일은 아닙니다.
PG13 업그레이드로 인해 프로세스가 복잡해졌습니다. 새 서버에서 새 이미지를 처음부터 빌드하고 기존 서버의 백업/복원을 수행하는 것이 조금 더 쉬웠을 수 있지만, 새 서버에서 Let’s Encrypt 인증서를 설정하는 부분은 여전히 다소 까다로운 작업이 될 것입니다.
네, 그게 바로 새 서버에서 ./discourse-setup을 실행한 후 S3 이미지에서 복원하는 것을 막았던 유일한 이유였습니다. (DNS가 여전히 구 서버를 가리키고 있고, 브라우저에서 IP 주소로는 Discourse가 응답하지 않으므로 웹 관리자 콘솔에 접근하지 않고 어떻게 이 작업을 수행할지도 문제입니다.) 저는 라이브 시스템이 있었고 구 시스템에서 새 시스템으로 DNS를 즉시 전환해야 했기 때문에, Let’s Encrypt 인증서가 없는 것이 저에게 유일한 장애물이었습니다.
만약 구 시스템에서 새 시스템으로 인증서를 이전하는 방법, Let’s Encrypt 오류 없이 ./discourse-setup을 완료하는 방법, 그리고 웹 콘솔 없이 S3 백업에서 복원하는 방법이 있다면, 이것이 더 간단한 방식이 될 것입니다.
네, 말씀하신 내용을 어느 정도 이해한 것 같은데, 확실하지 않아서 제 이해를 다시 정리해 보겠습니다.
원래 서버에서는 Discourse를 S3에 백업하도록 설정되어 있었습니다(설정 및 사이트 콘텐츠).
containers에서 yml 파일을 복사하면 원래 서버의 모든 구성이 새 서버로 복사되므로, 이제 새 서버에서는 discourse-setup을 실행할 필요가 없고, 대신 ./launcher rebuild app을 실행하면 원래 서버의 구성을 사용하여 최신 이미지를 다운로드하고 Discourse를 설정하게 됩니다.
이제 해결해야 할 두 가지 문제가 있습니다:
Let’s Encrypt 인증서를 어떻게 이전하나요? (DNS가 여전히 원래 서버를 가리키고 있어 인증서를 재생성할 수 없으며, ./launcher rebuild app을 실행하기 전에 이 작업을 수행해야 한다고 추측합니다.)
재빌드(rebuild) 후 S3 백업에서 Discourse(설정 + 콘텐츠)를 어떻게 복원하나요? DNS가 여전히 원래 서버를 가리키고 있는 상황에서 IP 주소나 localhost를 사용하여 Discourse 관리자 웹 인터페이스에 접근할 수 있는 방법이 있나요, 아니면 S3 백업을 콘솔을 통해 복원할 수 있나요?
이 게시물에서 설명하는 시나리오에 대해 한 가지 추가적인 세부 사항이 있습니다. 컨테이너가 아직 빌드되지 않았기 때문에 이 단계에서는 ./launcher enter app 명령이 작동하지 않는다는 점입니다. 재빌드에는 상당한 시간이 소요되므로, 빌드를 수행 중인 컨테이너의 이름을 docker ps 명령으로 확인한 뒤 컨테이너에 진입할 수 있었습니다:
.