프로덕션 환경에 전체를 배포하기 전에 Discourse 포럼을 구축하고 테스트하며 의도적으로 갭을 찾아왔습니다. S3 업로드가 활성화된 테스트 포럼을 한 서버에서 다른 서버로 마이그레이션했는데, 복원 후 첨부된 모든 항목의 URL이 S3가 아닌 포럼 URL로 다시 작성(rewrite)되었습니다.
다행히 테스트 포럼이라 데이터에 대해 크게 신경 쓸 필요는 없지만, 다음 두 가지를 하고 싶습니다:
A. 이 문제를 여전히 수정하고 싶습니다.
B. 프로덕션 환경에서 이런 일이 일어나지 않도록 완화/방지할 방법을 찾고 싶습니다.
영향을 받은 것은 게시글만이 아니라 이미지/미디어/콘텐츠/아바타(이건 꽤 심각한 문제입니다)까지 전부였습니다…
어떤 아이디어가 있을까요?
복원하기 전에 대상 사이트에서 app.yml을(를) 통해 S3를 구성할 수 있습니다(관리자 대시보드를 통해서는 안 됩니다). 구성이 완료되었고 올바른 버킷에 접근할 수 있는지 확인한 후 복원을 진행하면 미디어가 올바르게 연결됩니다.
이 방식으로 S3를 구성하는 방법은 다음 가이드를 참고하세요: Configure an S3 compatible object storage provider for uploads
Kris님, 안녕하세요.
우리는 실제로 그렇게 했고, 그 결과 지금의 상황에 이르렀습니다.
app.yml 파일을 원본 그대로 대상 위치에 복사한 뒤, 원본에서 백업했습니다. 문제는 복원 과정에서 발생했는데, 아무것도 변경하지 않았고 S3 업로드가 여전히 활성화되어 있었음에도 불구하고 복원을 수행했을 때 URL이 다시 작성(rewrite)되었기 때문입니다.
결국 rebake를 통해 이 문제를 해결했습니다(우리는 그렇게 생각하고 있습니다. Discourse의 캐싱이 매우 강력하기 때문에, 우리가 시도한 여러 해결책 중 실제로 어떤 것이 문제를 해결했는지 정확히 알지 못합니다). 그러나 여전히 해결되지 않은 질문이 남아 있습니다. 즉, 최소한의 문제로 마이그레이션을 수행하는 방법, 또는 프로덕션 환경에서 백업에서 복원해야 할 경우 어떻게 해야 하는지에 대한 질문입니다.
사이트 설정을 통해 S3를 구성한 것으로 보이며, Kris가 제안한 환경 변수 방식은 아닌 것 같습니다. 복원 과정에서는 S3에 대한 정보가 필요합니다. 사이트 설정만으로는 이를 처리할 수 없습니다.
원한다면 콘솔에서 업로드를 제외한 백업을 생성할 수도 있습니다: discourse backup --sql_only
이러한 백업을 복원하면 업로드 URL이 다시 작성되지 않습니다. 따라서 새 서버가 동일한 S3 버킷에 접근할 수 있는 한 이 방법이 작동합니다.
S3 설정은 app.yml에 있습니다. 사이트 설정이 아닙니다.
수정:
제가 지나치게 설명을 생략하고 있다는 점, 그리고 세부 사항을 숨기려는 의도는 아니라는 걸 깨달았습니다.
우리는 OVH S3를 사용하며, 이는 app.yml에서 설정됩니다.
저는 업로드 없이 테스트 포럼을 백업했지만, 그 시점에도 S3는 활성화되어 있었습니다.
이후 동일한 app.yml을 사용하여 새 사이트에 복원했는데, 그때 문제가 시작되었습니다. 명확히 하자면, 지금은 문제가 해결되었지만, 여러 번 rebake를 반복한 것이 원인인지, 아니면 Discourse가 공격적으로 캐싱을 한 것인지 불분명합니다. 그래서 제가 제대로 된 방법을 알고 처음부터 올바르게 처리하는 법을 알아야 합니다. 제 걱정은, 만약 프로덕션 인스턴스에 백업을 복원해야 할 때 이 문제가 다시 발생하면, 사용자가 알아채기 전에 즉시 정확히 어떻게 수정해야 하는지 알아야 한다는 것입니다.
안녕하세요, 이 건에 대해 다시 한번 말씀드리고자 연락드립니다.
말씀드린 대로, 동일한 S3 버킷을 사용하는 서버에 복원하려면 app.yml에 S3가 설정되어 있는지 확인하고 업로드 없이 백업을 생성하세요(discourse backup --sql_only). 백업에 업로드가 포함되지 않으면 업로드 URL이 다시 작성되지 않습니다.
다른 S3 버킷을 사용하는 서버, 또는 S3 설정이 전혀 없는 서버에 복원하려는 경우 업로드가 포함된 전체 백업을 사용하세요. 복원 과정에서 업로드 URL이 다시 작성됩니다.
양쪽 서버 모두 app.yml의 환경 변수를 통해 OVH S3를 설정했고 업로드가 없는 백업(.sql.gz 파일 확장자)을 사용했다는 것에 100% 확신이 있으신가요?
네, 그렇게 했습니다.
처음에 업로드가 완료된 상태로 복원했을 때 실제로 문제가 발생해서, 이번에는 완전히 초기화하고 업로드를 제외한 백업으로 다시 시작해야 했습니다. 문제가 시작된 것이 바로 그 때였습니다. URL이 여전히 잘못 작성되어 있었습니다.
app.yml 파일에는 0개의 변경 사항이 있었습니다.
그 일이 어떻게 일어났는지는 잘 모르겠습니다. .sql.gz 파일을 복원할 때, 복원 프로세스는 업로드 관련 코드(업로드 URL 재작성 포함)를 모두 건너뜁니다.
혹시 서로 다른 것에 대해 이야기하고 있는 건 아닌지 모르겠습니다. 제가 말하는 것은 uploads 테이블의 url 컬럼인데, 보통 //your-s3-bucket/original/... 형태이거나 로컬에서는 /uploads/original 형태입니다.
.sql.gz 파일 복원의 한 가지 주의사항은 URL이 전혀 재작성되지 않는다는 점입니다. 이 과정은 서버가 백업이 생성된 서버와 동일한 호스트 이름으로 접근 가능하다고 가정합니다. 호스트 이름을 변경했다면 URL을 다시 매핑해야 합니다.
이 모든 질문에 대한 답변을 드리겠습니다.
따라서 위의 S3 업로드 URL이 https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized처럼 작성될 것으로 예상했지만, 실제로는 https://forum.somedomainhere.com/uploads/optimized로 작성되어 있었습니다. 당연히 이는 작동하지 않습니다.
원하시면 VM을 다시 시작하여 전체 복원(restore)을 수행하고, 제가 취한 모든 단계를 검증해 드릴 수 있습니다.
네, 그렇게 해 주세요. 그리고 복원 시 출력 내용을 확인해 주세요. .sql.gz 파일을 복원할 때 URL 재매핑에 대한 언급이 있어서는 안 됩니다.
S3에 저장되어 있던 sql.gz 파일로만 복원 작업을 진행했는데, 지금까지 깨진 부분은 일부 사용자 프로필 사진과 몇몇 게시글이었습니다. 아마도 해당 파일들이 생성될 당시 S3에 업로드되지 않았기 때문이겠죠.
프로덕션 환경에서, 런칭 후 모든 것이 순조롭게 진행되고 모든 데이터가 S3에 안전하게 저장되어 있다고 가정한다면, 백업에서 복원할 때 첫 번째 게시글에서 언급했던 것과 같은 이상한 문제가 발생하지 않을 것인가요?
