Scaleway S3 호환 객체 스토리지 사용

제품 지원
1

안녕하세요,

Scaleway의 S3 호환 객체 저장소를 Discourse에서 사용하도록 설정하려고 시도하고 있지만, 작동하지 않는 것 같고 문제가 어디에 있는지 확실하지 않습니다.

aws-cli를 사용하여 두 버킷이 모두 정상적으로 작동하는지 확인했고, Scaleway의 공식 문서를 따라 CORS 설정이 올바르게 구성되어 있는지 확인했기 때문에 버킷 자체에 문제가 있다고 생각하지 않습니다.

제 Discourse S3 설정입니다(버킷 이름의 일부는 생략했습니다):

discourse-admin-s3
discourse-admin-s31355×1654 348 KB

백업 탭을 열면 'Failed to list backups from S3: Aws::S3::Errors::BadRequest’라는 오류가 표시됩니다.
그리고 이미지를 업로드하려고 하면 로그에 'Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known)'라는 메시지가 나옵니다.

최신 버전의 Discourse - 2.4.0.beta10 (14ae574bc5)을 실행 중입니다.

2

제 추측은 그들이 생각하는 것만큼 S3와 호환되지 않는다는 것입니다.

S3 리전 설정도 여기에서 영향을 미치는 것 같습니다.

3

가능하지만, 엔드포인트를 입력했다면 URL에 amazonaws.com이 포함되면 안 되는 것 아닌가요?

4

맞아요, 이건 좀 이상하네요. 히피스터 TLD 때문일 수도 있겠어요. 제가 한번 확인해 볼게요.

@dino s3 endpoint에서 https://를 제거해 보세요.

5

검증 때문에 그렇게 할 수 없습니다: ‘s3_endpoint: 필수 형식과 일치하지 않습니다.’

6

네, 그건 잘못된 추측이었네요.

해당 코드를 읽어도 당신처럼 URL로 끝나도록 하는 방법을 찾을 수 없어요:

이 문제가 백업에만 영향을 미치나요? 업로드는 정상적으로 작동하나요?

7

저는 GCP 버킷에서 다른 문제를 겪었지만, Trouble with Google Bucket for backup - #4 by pfaffman 링크를 참고해 보시는 것이 좋을 것 같습니다.

aws-sdk-s3 제이의 어떤 업그레이드가 GCP 버킷 사용이 작동하지 않는 원인이었는지 파악할 수는 있었지만, 저희 클라이언트가 선택한 해결책은 AWS 버킷으로 전환하는 것이었습니다.

8

@Falco 네, 저도 막혀 있습니다.
amazonaws가 포함된 URL과 관련된 오류는 백업이 아니라 파일 업로드에 특화되어 있습니다. 백업의 경우 일반 오류만 발생하므로, URL 문제로 인해 둘 다 깨진 것 같습니다.

다른 생각이 있으신가요?

@pfaffman 팁 감사합니다 - 제ems 버전 변경이 도움이 되는지 확인해 보겠습니다.

9

@dino님, 그 방법으로 해결이 되셨나요? 저도 같은 문제를 겪고 있어서 결국 포기하고 Amazon S3로 전환하려고 합니다.

10

안녕하세요, @FroggyC,

사실 디버깅할 시간이 부족해서 결국 gem 버전 변경에 대한 실험은 하지 못했습니다. 공식 문서를 참고하여 Amazon S3를 사용하도록 전환했는데, 바로 잘 작동했습니다.

더 좋은 소식이 아니라 죄송합니다…

11

감사합니다. 우리도 똑같이 해야 할 것 같아요. 감사합니다!

12

여기서도 같은 문제가 발생합니다. 디버깅을 위해 우리가 할 수 있는 일이 있을까요?

예를 들어 CLI를 통해 버킷에 액세스하고 로그 파일을 보내는 것처럼요.

s3_region은 무시되는 것이 맞나요? Scaleway는 AWS와 다른 값을 사용하니까요.

13

Scaleway에게 문의해 보는 것도 좋습니다. 호환성에 대한 책임은 그들에게 있습니다. AWS S3와 완전히 호환되지 않는다면, 그쪽에서 수정해야 합니다.

14

그것이 그들의 책임이라고 암시하고 있지만, 지금까지 @dino님의 코멘트를 무시해 왔습니다:

(변조되지 않은) s3_endpoint URL이 그대로 사용되지 않는 한, Scaleway에 오류가 그들의 측에 있다고 설득하기는 어려울 것입니다. 특히 다른 S3 클라이언트들은 연결할 수 있는 상황에서 더욱 그렇습니다.

15

좋습니다, 증명해 보세요. 이것이 사실임을 보여주는 문서와 로그 추적을 보여주세요. 만약 우리 쪽에 문제가 있다는 실제 증거를 제시할 수 있다면, 확인해 보겠습니다.

16

네, 제가 말한 게 바로 그거였죠.

그럼 discourse가 s3 연결 시도를 로그로 남기도록 어떻게 설정할 수 있을까요? 어떤 URL로 연결하려고 하는지 정확히 알면, 트래픽을 가로채서 결과를 공유할 수 있을 겁니다.

17

S3 업로드/백업이 작동하지 않는 이유는 fr-par(또는 nl-ams)로 설정해야 하는 리전 값을 Discourse의 SiteSetting 유효성 검사를 우회해야만 설정할 수 있기 때문입니다.

(./launcher enter app 실행 후 rails c 입력)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

이 변경 사항 이후 업로드와 백업이 Scaleway 오브젝트 스토리지에 정상적으로 작동합니다.

Scaleway Object Storage 문서

물론 이것은 임시 해결책일 뿐이며, 웹 관리자를 통해 이 사이트 설정을 초기화하거나 변경하면 다시 작동하는 상태로 되돌릴 수 없습니다(다시 rails 콘솔을 사용하는 경우를 제외하고).

웹 관리자의 현재 상태와 달리, AWS/S3 클라이언트는 모두 리전 문자열을 명시적으로 설정할 수 있다고 생각합니다.

또한 Discourse의 “EU (Paris)” 드롭다운 값의 경우에도 다소 혼란을 줄 수 있는데, 이는 Scaleway에서 기대하는 값이 아니라 AWS 네이밍 스키마 eu-west-3(또는 이와 유사한 것)를 가리키기 때문입니다.

18

아하. @falco님, 'S3 호환 리전’이라는 특별한 사이트 설정 필드가 필요합니까? 그러면 사람들이 완전히 임의의(즉, 아마존의 관점에서 ‘제작된’) 리전을 입력할 수 있게 되지 않을까요?

19

그건 필요 없습니다.

S3 클론을 사용하는 사용자는 S3 Region을 덮어쓰는 S3 Endpoint 환경 변수를 설정해야 합니다.

Digital Ocean S3 Clone에 대해 그 내용을 설명하는 가이드를 하나 작성해 두었지만, Digital Ocean의 S3 CDN 버그가 수정될 때까지 배포를 기다리고 있습니다.

Scaleway가 Digital Ocean보다 상황이 더 좋다면, 직접 시도해 보고 가이드를 Scaleway 기반으로 작성해 볼 생각입니다.

20

맞습니다. 그런데 그들이 그렇게 해야 한다는 걸 어떻게 알 수 있을까요? 기존 사이트 설정의 설명에 이것이 언급되어 있나요? 언급되어야 한다고 생각합니다. 그렇게 수정해 주실 수 있나요?