안녕하세요, 방금 새로운 discourse 설치 환경을 설정했습니다. 이렇게 사용하기 쉽게 만들어 주셔서 정말 감사합니다!
이상적으로는 discourse 서버를 일회용(disposable)으로 만들고 싶습니다. 예를 들어 누군가 EC2 콘솔에서 실수로 인스턴스를 종료하더라도 데이터가 손실되지 않도록 하는 것이죠.
내장된 백업/복원 기능은 훌륭하며, 이미 몇 번의 테스트를 마쳤습니다. app.yml, 업로드 파일, 백업 파일을 S3에 저장하고 있습니다.
다음 단계는 데이터베이스를 Amazon RDS로 이전하는 것인데, 이를 위한 훌륭한 가이드가 여기에 있습니다.
질문이 있습니다. 이렇게 하면 이론적으로 인스턴스를 종료한 후, 새 서버에서 discourse를 클론하고 app.yml을 가져와 ./launcher rebuild app을 실행하는 것만으로 안전할까요? 아니면 postgres/uploads/app.yml 외에 Redis 같은 다른 상태 데이터가 있을까요?
대체로 맞습니다. 두 인스턴스가 동시에 실행되지 않도록 주의해야 합니다. 새로운 컨테이너를 빌드할 때 데이터베이스가 마이그레이션되어 다른 컨테이너에서 사용할 수 없게 될 수 있습니다(skip_post_deployment_migrations 옵션으로 이를 방지할 수 있습니다). Redis에 있는 데이터는 휘발성(ethereal)으로 간주되며 백업되지 않습니다.那里的 일부 데이터가 어떻게 또는 복원되는지 정확히 확신은 없지만, 아마도 크게 신경 쓸 부분은 아닐 것입니다.
@phil22 - 제안하신 것과 유사한 설정을 직접 구축해 본 경험이 있는데, 생각하시는 것보다 훨씬 더 섬세한 부분이 있습니다:
Discourse 팀은 매월 여러 번 릴리스를 진행하므로, 새로운 ec2로 클론할 때 원래의 버전을 유지해야 합니다. 보통은 앱을 무심코 업그레이드해도 괜찮지만, 일부 릴리스에는 주요 데이터베이스 업그레이드(PG 12 → PG 13)가 포함되어 있습니다. 이를 추적하지 않고 외부 RDS 업그레이드를 소홀히 하면 문제가 생길 수 있습니다.
ec2에 EBS 볼륨을 사용하고, 이를 앱 컨테이너 내부에도 마운트하도록 구성하는 것이 성공적인 방법임을 확인했습니다. 이렇게 하면 /shared 폴더의 모든 내용을 저장할 수 있습니다. 그러면 ec2 인스턴스가 생성되고 삭제되는 과정에서 이 공유 폴더 내용이 EBS에 영구적으로 유지됩니다. 또한, 나중에 파일을 s3에 저장하기로 한 결정을 번복할 수도 있습니다. 그런 경우를 대비해 업로드된 파일을 저장할 대안적인 위치(/shared 폴더 등)가 있는 것이 좋습니다.
여러분의 조언을 따르기로 했는데, RDS를 사용하되 discourse_docker 저장소의 특정 커밋에 고정하는 방향으로 가려고 합니다. 업그레이드가 더 복잡해질 것 같긴 하지만, 서버에 문제가 발생했을 때 모든 데이터가 RDS에 안전하게 저장되어 있어 수동 복원 없이도 신속하게 동일한 작동 상태로 복귀할 수 있기를 희망합니다.
(EBS로도 같은 효과를 낼 수 있을 것 같지만, 볼륨 암호화와 인스턴스 간 볼륨 마운트/디마운트를 위한 유닉스 마법 같은 설정을 자동화하는 과정이 좀 두렵습니다.)