백업 복원 중 오류 발생 – enable_s3_uploads가 데이터베이스에 설정되어 있어 SiteSetting::Upload.s3_base_url이 실패함

일반
1

멀티사이트 인스턴스의 기본 사이트에서 백업이 하나 있습니다. 업로드는 S3에 저장되어 있습니다. include_s3_uploads_in_backups를 true로 설정하여 백업을 성공적으로 생성했습니다.

다른 멀티사이트 인스턴스(s3 사용)나 새로운 표준 설치 환경에서 커맨드 라인을 통해 이 백업을 복원하려고 하면 Something went wrong while remapping uploads라는 오류가 발생합니다.

lib/backup_restore/uploads_restorer.rb에 여러 puts 문을 추가하여 디버깅한 결과, 아래 코드가 오류를 유발하는 것으로 확인되었습니다:

  puts "base url #{SiteSetting::Upload.s3_base_url}"

디버깅 전에 실패했던 것으로 보이는 다음 줄은 다음과 같습니다:

       current_s3_base_url = SiteSetting::Upload.enable_s3_uploads ? SiteSetting::Upload.s3_base_url : nil

discourse.conf에서 다양한 s3 변수를 주석 처리하여 데이터베이스에 문제 있는 값이 있는지 확인해 보았지만, 모두 비어 있었습니다.

음. 그리고 클린 설치 환경에서는 백업이 실패했고, 이제 사이트는 다음과 같이 반환합니다.

{
errors: [
"`s3_upload_bucket` site setting has to be set."
]
}

그래서 제가 놓친 다른 s3 설정이 데이터베이스에 설정되어 있는 것 같습니다. 네, enable_s3_uploads는 데이터베이스에 설정되어 있습니다. use_s3와 enable_s3_uploads의 관계가 무엇인지 혼란스럽습니다…

1개의 좋아요
Discourse Automated Weekly Backup and Update Script (Avoiding S3 Upload Issues)
2

결국 문제의 원인이 몇 년 전 S3를 처음 설정하려고 했을 때 데이터베이스에서 enable_s3_uploads를 설정한 것임이 확인되었습니다. 이 설정은 S3에 업로드를 시도하지만 충분한 정보가 없어 복원이 작동하지 않는 원인이 됩니다. (아쉬운 점은 멀티사이트/S3 인스턴스를 복원할 때 일부 파일이 "S3로 마이그레이션되지 않았다"는 이유로 실패한다는 것입니다.)

UX에서 S3 업로드 설정을 모두 숨기는 것이 합리적인지 궁금합니다. UX에서 이 설정을 변경하는 것에서 좋은 결과가 나올 것이라고는 생각하지 않습니다. 하지만 데이터베이스에서 S3 업로드를 설정하는 것은 유용할 수도 있겠네요. . . . 어쩌면.

표준 설치로 복원된 인스턴스는 업로드를 표시하지 못하는데, 그 이유는 다음과 같은 처리를 하고 있기 때문입니다:

      Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
  Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)

시스템이 찾고 있는 경로는 /var/www/discourse/public/uploads/default/original/1X/가 아니라 /var/www/discourse/public/default/original/1X/입니다.

… . .

그리고 이것은 S3 버킷 참조를 수정하려고 시도하면서 리맵을 수행한 결과, 로컬 URL의 경로가 깨져서 발생한 것입니다.

이것은 너무 세부적인 내용이라 다른 사람들에게 유용하지 않을 수도 있다고 생각합니다. 그래도 UX에서 S3 업로드 변수를 숨기는 것이 좋은 아이디어라고 여전히 생각합니다.

3개의 좋아요