URL //s3-bucket/prefix/file.jpeg 위치에 있는 스토어에서 파일을 찾을 수 없음

제품 지원 자체 호스팅
1

현재 AWS ECS에서 공식 Docker 이미지를 설정하는 중입니다.
EC2에서 실행할 때는 Docker 이미지가 완벽하게 작동합니다.

그러나 ECS에서 동일한 구성으로 시작하면 아바타 이미지가 깨져 나타납니다.

관련된 오류:

Could not find file in the store located at url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

그리고

Failed to process hijacked response correctly : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination: lookup failed

해당 파일은 버킷에 존재하며, EC2 인스턴스와 동일한 접근 권한을 가지고 있습니다.

어디를 더 깊이 파고들어 근본 원인을 찾을 수 있는지 알려주시는 분 없을까요?

감사합니다

2

런처를 포함해 이미지를 빌드하고 리포지토리에 푸시했나요? 그리고 런처가 사용하는 것과 동일한 환경 변수로 실행하고 있나요?

3

네. run-cmd 명령이 생성하는 환경 변수를 사용하고 있습니다. 아직까지 오류를 발견하지 못했습니다.
불행히도 아직까지 Discourse를 위한 ECS 예시를 찾지 못했습니다.

4

방향이 맞긴 하지만, 스탠디를 마이그레이션하고 자산을 업로드하는 과정이 까다로워요. 문제가 뭔지 정확히 모르겠네요.

5

근본 원인을 찾았습니다. Discourse AI 플러그인 설정 과정에서 다양한 서비스를 VPC 내부에서 사용할 수 있도록 VPC에 프라이빗 존을 추가했기 때문입니다.

EC2 인스턴스에서 Docker 컨테이너로 Discourse를 실행할 경우, 컨테이너에는 12-34-56-78-app과 같은 호스트 이름이 부여됩니다. 그러나 ECS 태스크로 실행할 때는 awsvpc 모드에서는 호스트 이름을 설정할 수 없으며, DNS 검색 도메인도 구성할 수 없습니다. 이로 인해 ECS에서는 DNS 해석이 달라지며, 제 경우에는 xxxx.internal과 같은 검색 도메인이 추가되었습니다.

여러 방법을 시도한 끝에 tcpdump를 사용하여 확인해 본 결과, Discourse가 SSRF 검사 과정에서 자신의 FQDN을 해석하려고 시도하고 있음을 발견했습니다. 이 해석에 실패하면 검사도 실패합니다. 그 결과, S3 호출이 위에서 언급된 잘못된 오류 메시지와 함께 실패하게 됩니다.

제 경우의 해결 방법은 CloudFront 배포에 대한 별칭인 FQDN 레코드를 프라이빗 DNS 존에 추가하는 것이었습니다.

6

와. 정말 훌륭한 디버깅이네요! 그래서 이것이 비공식 설치인 거예요! 그 정도 내용을 추측할 방법은 거의 없으니까요!

7

결국 늘 그렇듯, 안 되면 다 DNS 탓이죠 :joy:

8

안녕하세요 @nodomain,

아래 게시글과 동일한 오류를 경험했습니다. 예를 들어 사용자 아바타 요청인 https://example.com/user_avatar/example.com/myself/96/215_2.png 이 500 응답을 반환합니다. 제 경우 example.com 도메인 이름이 공개 DNS에 설정되어 있지 않으며, 테스트 단계에서 로컬의 hosts 파일에 example.com을 스푸핑(spoof)했습니다. example.com 도메인 이름이 공개 DNS에 설정되면 이 문제가 발생하지 않을까요?