현재 기존 Bitnami 기반 배포 환경(비교적 오래된 버전)에서 AWS에서 공식적으로 지원하는 설치 방식으로 서버를 마이그레이션하는 과정에 있습니다. 최신 Discourse 릴리스를 사용하고 있으며, 이 새 설치 환경에는 외부 Elasticache와 RDS 인스턴스가 포함되어 있고, 백업 및 업로드에는 S3를 사용할 예정입니다.
두 가지 질문이 있습니다:
기존 Discourse 서버는 상당히 오래된 버전입니다. 새 Discourse 서버에서 백업/복원 작업을 수행하면 관련 업그레이드 명령어가 모두 실행되는 것일까요?
새 서버의 새 Discourse Docker 컨테이너에 백업 파일을 복사하고 명령줄에서 복원을 시작하면, 설정에서 지정한 새 버킷 값이 복원 과정 중 덮어쓰기되는지, 아니면 제 새 값이 사용될지 궁금합니다. 제 추측으로는 새 DB가 백업으로 채워진 후, 컨테이너를 종료하고 ./launcher rebuild app를 실행하면 제 새 S3 값이 사용될 것 같습니다.
제 추측이 맞다면, 복원을 수행하기 전에 기존 S3 버킷의 내용을 새 버킷으로 복사해야 할까요?
Bitnami에서 마이그레이션이 문제없이 성공할지 100% 확신이 서지 않아, 마이그레이션을 중단해야 하는 경우 기존 데이터에 영향을 주지 않도록 하기 위함입니다.
버킷 네이밍 방식을 변경했기 때문에, 이를 위해 완전히 새로운 버킷 두 개를 사용하는 것이 더 쉬울 것이라 판단했습니다.
특히 1번이 걱정되므로 더 신중하게 접근하고 있습니다.
새로운 업로드 버킷에 대해 예상되는 문제가 있을까요? 기존 Discourse 서버는 읽기 전용 모드로 전환됩니다. 새 서버가 구동되고 검증되면, 기존 서버를 중지하고 DNS를 새 서버로 변경한 후 CDN(Cloudfront)의 캐시를 정리하고, 마지막으로 대외 공개를 할 계획입니다.
@RGJ 님이 언급했듯이, 저희 엔터프라이즈 인프라는 캐시, 데이터베이스 등을 위해 Elasticache와 RDS와 같은 외부 서비스를 사용하고 있습니다. 이를 통해 해당 서비스에 대한 완전한 백업과 중복성을 확보할 수 있을 뿐만 아니라 보안 관리에도 도움이 됩니다. Discourse의 관점에서 이것은 공식적으로 지원되는 설치 방식이며, 단지 다른 템플릿 세트를 사용하고 있을 뿐입니다. 저희는 discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub 파일을 사용하고 있습니다(‘표준’이라는 표현이 다소 오해를 불러일으킬 수 있었네요, 죄송합니다).
따라서 기존 설치 환경의 버킷 이름을 먼저 업데이트한 후 새 서버로 이전을 진행하는 것이 적절해 보입니다. 기존 설치를 최신 버전으로 업데이트하는 것은 불가합니다. 이전에 Bitnami 업그레이드 시 문제가 발생했던 경험이 있어, 공식 설치 방식으로 전환하게 되었습니다.
혹시 기존 버킷을 그대로 사용하여 복원을 수행한 후 app.yml 파일을 수정해 새 버킷을 참조하도록 변경할 경우 어떤 문제가 발생할 가능성이 있는지 여쭤봐도 될까요? DISCOURSE_ 환경 변수들은 모두 데이터베이스 내 설정(해당하는 경우)보다 우선순위가 높지 않나요? 아니면 다른 요인이 문제를 일으킬 수 있는 건가요?
한 가지만 더 여쭤볼게요 - Discourse 컨테이너 내에서 커맨드 라인을 통해 복원을 실행할 때, 데이터베이스 연결, Redis 연결 등의 세부 정보는 기존 /var/www/discourse/config/discourse.conf 설정 파일을 사용하는 건지, 아니면 백업 파일에 있는 내용으로 해당 설정을 덮어쓰는 건가요?
@RGJ님이 제안하신 대로, 버킷 이름을 변경하지 않고 백업/복원을 수행하겠습니다. 말씀드렸듯이 기존 서버 데이터에 영향을 주지 않는 것이 제 우려 사항이었지만, 먼저 기존 버킷을 백업하고 마이그레이션 동안 기존 서버를 읽기 전용(Read Only) 모드로 설정하면 버킷에 업로드된 데이터의 무결성이 상당히 잘 보호될 것 같습니다.
