맞아요. 우리 같은 페이지에 있는 거죠? 좀 더 명확히 하자면, 제 이해로는 Discourse와 S3를 연결하는 방식이 3가지 유형이 있습니다:
Discourse가 S3 클라우드를 직접 사용하게 하는 것. 장점: 설정이 매우 쉽습니다. 단점: 금방 비용이 비싸집니다.
Discourse가 커스텀 도메인(예: forum-storage.com)을 통해 S3 클라우드를 사용하게 하여 CDN을 사용할 수 있게 하는 것. 장점:버킷 이름이 커스텀 도메인과 정확히 일치할 경우 (예: forum-storage.com.s3-amazon-aws.com) S3 설정이 매우 쉽습니다. 단점: SSL이 문제가 됩니다.
Discourse가 커스텀 도메인을 통해 S3 클라우드를 사용하게 하는 것(다시 한번, CDN을 사용하려는 목적입니다)만, S3 버킷 이름을 설정할 때 이름 안에 추가적인 마침표가 없도록 하는 것(예: forum-storage-com.s3-amazon-aws.com). 장점: SSL이 정상적으로 작동합니다. 단점: Amazon S3에서 설정하는 것이 그렇게 쉽지 않습니다.
그래서… 저는 청구서가 도착할 때까지 #1 방식을 사용하다가 #2 방식이 가능하다는 것을 알고 설정을 마쳤습니다. 그러고 나서 이 주제를 시작했고, 곧바로 #2 방식은 실제로는 옵션이 아니라는 것을 깨달았습니다.
지금은 #3 방식을 진행 중입니다. 아마도 Amazon의 “Route 53” DNS 서비스나 비슷한 것을 사용해야 할 것 같습니다. 아직 헤매고 있습니다. 제가 구글링을 아무리 해봐도 #2 방식을 하는 방법에 대한 정보만 나올 뿐, #3 방식에 대한 명확한 설명을 쓴 사람은 없는 것 같습니다.
이건 정말로, 의심의 여지 없이 가장 짜증나는 일이다. Amazon S3 버킷(버킷 이름에 마침표가 없는 경우!), 내 커스텀 도메인, 그리고 CloudFlare를 어떻게 조합해야 실제로 모두 정상적으로 작동하는지 도무지 모르겠다. 버킷 이름에 마침표를 넣을 수 있다면 문제가 없겠지만, 지금은 너무 복잡해서 혼란스럽기만 하다. 아아, 누가 도와주거나 도메인 이름과 다름 S3 버킷에 CloudFlare를 설정하는 간단한 방법을 알려줄 수 없을까?
위에 언급된 StackPath 정보를 시도해 보았다. CloudFlare에서도 비슷한 작업을 한 것 같은데 확실하지 않다. 작동하지 않았다. CloudFlare의 Amazon 버킷에 CDN을 추가하는 방법에 대한 정보도 읽어 보았지만, 물론 그들은 버킷 이름이 도메인 이름과 같기를 원하는데, 그렇게 하는 것은 매우 나쁜 아이디어라고 들었고 나도 그렇게 할 수 없다.
결국 문제는 다음과 같다:
버킷 이름이 도메인 이름(마침표 포함)과 같으면 Amazon S3가 모든 것을 처리해 주니 훌륭하고 멋진데, SSL을 깨뜨리기 때문에 그렇게 하면 안 된다.
버킷 이름이 도메인 이름과 다르면, 모든 것이 훨씬 더 복잡해지고 나는 어떻게 해야 할지 모르겠다.
누가 도와주거나 조언해 줄 수 있을까? 그리고 그 사이 내 S3 저장소로 매월 100달러 이상의 청구서가 나오고 있다. 정말 끔찍하다. 지금 바로 200달러를 주고 이 모든 문제를 해결해 줄 사람을 구할 수 없을까? 끔찍하다.
이 글 읽어보셨나요? 저도 S3와 Cloudflare 설정에 애를 먹었지만 결국 방법을 찾았습니다. Cloudflare는 보안 이점을 위해 계속 사용할 수 있지만, 별도의 CDN 서비스도 함께 사용해야 한다고 확신합니다. Cloudflare는 일반적인 CDN과는 작동 방식이 다릅니다. Amazon은 비용이 비싸므로 더 저렴한 S3 서비스로 전환하시는 것이 좋습니다.
CDN을 통해 이미지를 캐시할 계획이라면 버킷 이름에 마침표가 있는지 여부는 중요하지 않지 않을까요? 중요한 것은 Cloudflare에서 서빙되는 이미지를 커버하는 좋은 인증서를 가지고 있는 것입니다.
Cloudflare 서버, DNS, 그리고 해당 내용을 커버할 수 있는 인증서에 집중해야 한다고 생각합니다. 사용자나 브라우저가 이 이미지들의 소스가 S3 버킷이라는 사실을 알 가능성은 거의 없을 것입니다. Cloudflare가 이미지 자체를 캐시/프록시할 것이므로, 맞죠?
@riking 디스코urses(Discourse)가 요구하는 것은 버킷 이름뿐인 것 맞죠? HTTPS가 실제로 요구된다면, 업로드와 관리는 AWS URL과 해당 인증서를 통해 수행할 수 있습니다. 지금까지 보안 인증서에 대해 이야기하는 이유가 있나요?
OP(질문자)는 자신의 CDN 또는 캐싱 솔루션이 S3에서 이미지를 가져오도록 허용하기 위해 별도로 어떤 조치가 필요한지 살펴보면 됩니다. 보안이 있든 없든, OP나 CDN에 특별한 요구 사항이 없다면 상관없지 않나요? 디스코urses가 S3와 CDN 사이의 OP의 설정에 신경 쓸까요?
마지막으로, OP는 이미지가 CDN에서 유효한 인증서와 함께 서빙되도록 확인해야 합니다. 이는 OP가 이미지가 최종적으로 reside할 기본 URL을 제공한다는 점을 제외하고는 디스코urses와 관련이 있나요? 일단 CDN이나 캐시가 S3에서 이미지를 가져오면, AWS, 버킷 같은 것들은 완전히 무관해집니다.
S3 버킷 이름에 마침표가 있으면 이미지를 거기서 서빙할 경우 문제가 발생한다는 점은 이해하지만, OP는 그렇게 하지 않습니다. 따라서 OP가 CDN 설정과 충돌하지 않는 한, 디스코urses가 수락하는 임의의 버킷 이름을 선택하는 것으로 충분합니다.
버킷 이름에 도메인이 포함된 URL을 피하는 것이 가능하지만, aws s3 sdk의 사용 방식과 설정의 어려움(?)으로 인해 실제로는 이를 피하지 못하고 있습니다.
다시 말하지만, 이러한 작업들은 CDN을 우회하며, 이를 수정하는 유일한 방법은 Discourse 소스에서 처리하는 것입니다. 수정은 가능하지만, 현재는 아직 이루어지지 않았습니다. 또한 많은 문제가 핵심 경로에서 발생하지 않고 나중에야 드러납니다. 따라서 이 상황이 바뀌기까지는 버킷 이름에 점을 사용하지 마세요.
(1) BUCKET NAME(버킷 이름) – 마침표가 권장되지 않는다는 말도 있고, 허용되지 않는다는 말도 있습니다. 제 생각에는 OP에게는 큰 문제가 아닐 수 있습니다. (그는 CDN이 이미지를 캐시하고 서빙하도록 하는 방법을 별도로 찾아내면 됩니다.) 여기까지 이해가 일치하는 거죠?
(2) S3 ENDPOINT(S3 엔드포인트) – AWS를 사용하는 경우 비워 두면 됩니다. 다른 제공업체를 사용하는 경우 해당 정보를 입력할 수 있습니다?
(3) S3 CDN URL(S3 CDN URL) – 이건 단순히 Discourse가 이미지 경로 앞에 붙일 기본 URL인가요? 그렇다면 아주 단순하고 명확한 문제이며, OP는 자신의 CDN을 설정한 뒤 해당 기본 URL을 여기에 입력하면 됩니다.
SSL 와일드카드 인증서가 이 문제에 어떻게 관여하는지 보이지 않습니다. OP에게는 Discourse 설정에 마침표가 들어가면 인증서가 깨진다고 했었죠. 하지만 CDN이나 캐시를 사용하는 경우, 버킷 이름은 인증서와 무관할 수 있는 거 아닌가요? 만약 다른 방식으로 Discourse가 깨진다면 그 점도 알아두면 유용할 것입니다.
이 모든 것을 자세히 따라가지는 못했지만, 좀 더 큰 그림으로 보면 이 간단한 요구 사항 목록이 도움이 될 수도 있습니다:
목표:
내 Discourse 이미지를 Discourse 서버에 저장하지 않기
이미지를 저장할 S3 버킷 보유 (Discourse가 S3를 지원하므로 S3여야 함)
비싼 S3 요금 발생 방지
CDN은 필수 사항은 아니지만, 비싼 S3 요금을 줄이거나(또는 제거하는 유일한 방법일 수 있으므로) 좋은 보너스입니다. 또한 전 세계적으로 가용성을 높이고, 메인 서버가 오프라인이 될 경우를 대비한 백업 역할도 합니다.
이 중 틀린 부분이 있다면 알려주세요
제한 사항/요구 사항:
외부 이미지 저장소는 S3 프로토콜을 지원해야 합니다 (Discourse가 S3로 작동하기 때문) 하지만, 엄밀히 말해 Amazon의 S3일 필요는 없습니다.
Discourse는 S3 버킷 이름에 마침표가 없어야 합니다.
이미지 소스(S3 또는 CDN)는 https://로 서빙해야 합니다. 페이지가 https인데 이미지가 https가 아니면 브라우저에서 경고가 나오기 때문입니다.
이 중 틀린 부분이 있다면 알려주세요
해결책:
이전에는 Amazon S3에서 직접 서빙했습니다. 잘 작동했지만, Amazon의 DataTransfer-Out-Bytes 요금이 매우 비쌌습니다. 이로 인해 Amazon에서 매월 높은 청구서가 나왔습니다! 그래서 다시 메인 서버로 옮겼습니다. 이를 해결할 두 가지 가능한 방법이 있습니다: Amazon S3 버킷 앞에 CDN을 배치하여 모든 데이터 전송을 CDN이 처리하도록 하거나, 다른 S3 제공업체로 전환하는 것입니다.
Amazon S3 버킷 위에 CloudFlare CDN을 올려보려 했으나, 해결할 수 없는 많은 문제에 빠르게 직면했습니다.
참고로, 지난 30일 동안 S3에서 약 300GB를 서빙했습니다. 그 중 일부는 사이트 백업이고, 상당 부분은 정적 이미지입니다. Amazon에서 이러한 항목을 어떻게 측정해야 하는지 정리하는 것은 매우 어렵습니다… Amazon의 청구 보고 인터페이스는 Amazon AWS의 모든 것처럼 관리하기가 정말 복잡합니다.
버킷 이름에 있는 마침표와 브라우저 인증서에 대해 상당히 많이 논쟁했지만, 저는 그 모든 논의가 완전히 무관하다고 생각합니다. 어떤 CDN이든 HTTPS 구성을 허용하므로, “와일드카드 인증서” 문제나 버킷 이름에 마침표가 있든 없든 최종 사용자의 브라우저 인증서와 관련하여는 아무런 문제가 없습니다. 다시 말하지만, 어떤 CDN이든 이를 허용할 것입니다.
따라서 OP는 단순히 다음을 수행하면 됩니다.
(1) S3 및 CDN과 호환되는 스토리지 솔루션을 선택하고, Discourse 설정에서 엔드포인트와 버킷 이름을 구성합니다.
(2) CDN이 S3에서 이미지를 가져오도록 구성합니다. 보안이 적용되었든 적용되지 않았든 상관없습니다. CDN이 사용자에게 HTTPS를 통해 이미지를 서빙하기만 하면 OP가 신경 쓸 일은 없다고 생각합니다.
제가 무언가를 놓치고 있다면 지적해 주세요. 저는 최종 사용자의 브라우저 인증서 + 버킷 이름의 마침표 문제가 버킷에서 직접 이미지를 서빙하는 경우에만 문제가 된다고 생각합니다. CDN을 통해 서빙하는 경우에는 무관합니다.
지금 즉시 멈추세요 
알려주셔서 감사합니다 
버킷 이름에 마침표(.)를 넣지 마세요