안녕하세요!
최근 업데이트 이후 왜 CDN에서 에셋을 서빙하지 않게 되었는지 이해가 되지 않습니다. 우리는 Cloudfront을 사용 중이며, 업로드된 파일과 에셋 모두를 서빙하는 데 잘 작동하고 있었습니다. 하지만 최신 업데이트 이후 에셋이 CDN 대신 서버에서 서빙되고 있는 것으로 보입니다.
또 다른 문제는 DISCOURSE_CDN_URL 변수를 전달하면, Discourse가 s3:upload_assets 작업에 의해 생성되거나 업로드되지 않은 에셋(예: 스타일시트)을 요청하기 시작한다는 점입니다. 이로 인해 사이트가 완전히 깨져 흰 화면만 표시됩니다. 이 게시물에서 비슷한 문제를 언급하고 있습니다.
도움을 주시면 감사하겠습니다.
감사합니다!
이거 새 버그인가요 @falco? 여기 뭔가 깨진 건가요?
@eatcodetravel 도움이 되려면 훨씬 더 자세한 정보가 필요합니다.
S3와 CDN에 관련된 설정 및 환경 변수의 정확한 값은 무엇인가요?
@Falco 네, 어떤 정보가 필요하신가요? 저희 세팅은 오픈소스이며, 현재 사용하고 있는 설정은 다음과 같습니다.
DISCOURSE_CDN_URL은 DISCOURSE_S3_CDN_URL과 동일한 값으로 설정되어 있었으나, 이 값이 사이트를 깨뜨렸기 때문에(S3에 존재하지 않는 에셋을 가져오려고 시도했기 때문) 제거했습니다.
문제가 발생했던 사이트를 다시 살펴보니, 사용하던 CDN URL에서 https://를 누락한 상태였습니다. 어떻게 작동했는지, 혹은 작동하지 않았다면 깨진 값을 추가했을 때 왜 눈치채지 못했는지는 정확히 알 수 없습니다.
@eatcodetravel, 물론 SMTP 비밀번호와 S3 키는 마스킹 처리해야 하지만, 문제가 무엇인지 추측해 볼 수 있도록 최소한 CDN 값은 공유해 주셔야 할 것 같습니다.
네, 여기에 적어볼게요. 다른 값들은 AWS SDK를 통해 검증되므로 CDN_URL만 적으면 될 것 같습니다.
DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org'
DISCOURSE_S3_REGION: 'us-west-1'
DISCOURSE_CDN_URL도 제거하기 전에 'https://community-cdn-prod.debtcollective.org’로 설정되어 있었습니다.
환경 설정에는 큰 변화가 없었고, 더 큰 용량의 EC2 인스턴스로 마이그레이션한 것뿐입니다.
@Falco, 추가 정보가 필요하시면 말씀해 주세요. 질문에 기꺼이 답변드리겠습니다.
현재 S3 CDN을 사용 중이지만 일반적인 CDN은 사용하지 않는 것으로 보입니다. 이것이 지원되는 설정인지 확신이 서지 않습니다…
다른 3가지 조합은 확실하게 정상 작동합니다:
DISCOURSE_CDN_URL만 사용DISCOURSE_CDN_URL과 DISCOURSE_S3_CDN_URL 모두 사용과거에 겪었던 다른 CDN 문제들의 원인일 수도 있겠네요.
네, DISCOURSE_CDN_URL을 제거해야 했습니다. rake s3:upload_assets 태스크로 S3에 업로드되지 않는 에셋을 요청하기 시작했고, 이로 인해 사이트가 완전히 깨져버렸거든요. 아마도 이 부분이 변경된 것 같고, 다시 올바르게 작동하도록 rake s3:upload_assets를 업데이트해야 할 것 같습니다.
네, DISCOURSE_CDN_URL과 DISCOURSE_S3_CDN_URL에 동일한 CDN URL을 사용하는 것은 가능하지만, URL에 따라 각 자산에 올바른 소스를 사용하려면 CDN에 많은 양의 로직이 필요합니다. 예를 들어, CSS는 앱에서, JS는 S3에서 제공되며, 이것은 하나의 경우일 뿐 수십 가지 경우가 있습니다.
따라서 DISCOURSE_CDN_URL은 웹 앱으로의 "프록시"이고, DISCOURSE_S3_CDN_URL은 오브젝트 스토리지 버킷으로의 프록시인 두 값을 모두 설정해야 한다는 것이 기대되는 동작입니다.
아, 알겠습니다. 이 부분이 최근에 변경된 건가요? Cloudfront가 S3 버킷 대신 우리 앱의 백업 프록시로 사용될 수 있는지 확실하지 않습니다.
메타에서 Cloudfront를 사용 중이신 것 같은데, 실행을 위해 특별히 설정하는 부분이 있나요, 아니면 Discourse가 모든 것을 알아서 처리하나요?
이 페이지를 검사해 보면 두 가지 다른 Cloudfront URL이 있는 것을 확인할 수 있습니다. 따라서 위에서 말씀드린 대로 두 개의 배포를 사용하며, 하나는 일반 CDN용이고 다른 하나는 S3용입니다.
OP 제목에서 언급된 문제는 다음과 같습니다. CSS는 앱에서, JS는 S3에서 제공됩니다. 모든 개별 자산이 어디에서 오는지 파악하고 필요한 위치로 접근할 수 있는 CDN이 필요하거나, 두 개의 CDN이 필요합니다. 그래서 결국 두 가지 다른 설정을 사용하게 된 것입니다.
이제 이해하니 완전히 말이 되긴 하지만, 이것이 문서화되어 있는지 확실하지 않습니다. 그리고 문제가 생길 가능성이 높습니다(적어도 저는 그랬습니다!). move-uploads-to-s3 rake 작업은 s3_cdn이 있어야 요구하기 때문입니다. 이것이 제가 여러 번 S3로 파일을 이동하려다 결국 포기하게 된 이유를 설명해 줍니다.
어딘가에 "에이, 에셋 CDN이 없으면 S3 CDN을 가질 수 없습니다"라는 경고가 있으면 좋았을 텐데 싶습니다.
아 이제 말씀하신 내용을 이해했습니다. 이게 필요하다는 걸 몰랐네요. CSS가 왜 앱에서 와야 하는지, rake s3:upload_assets 태스크를 통해 업로드할 수 없는 이유가 무엇인지 여쭤봐도 될까요?
Cloudfront에서 이를 어떻게 구현할 수 있는지 조사해서 결과를 여기에 올리겠습니다.
@Falco, 정말 도움이 많이 되었습니다. 감사합니다.
글쎄요, 제가 설명을 잘 못 하고 있는 것일 수도 있습니다. 사용은 가능합니다. 하지만 여러분의 주제와 이 글에서 보여지듯이 꽤나 번거롭습니다.
@eatcodetravel 님의 사이트는 현재 S3_CDN만 설정된 상태로 정상 작동 중입니다. 하지만 이렇게 하면 렌더링을 차단하는 CSS는 서버에서 제공되는 반면, 게시물 속 이미지는 그렇지 않아서 말이 안 되는 상황이 됩니다.
Admin > Customize 기능이 있기 때문입니다. 관리자가 관리 패널에서 CSS를 변경할 수 있습니다. 또한 테마에 포함된 사용자 정의 JS 스니펫도 앱에서 제공되는 것으로 알고 있습니다(AFAIK).
@falco 님, 이 부분을 더 잘 문서화할 수 있을까요? 혹시 "여기엔 
가 있다"는 식으로 표현하면 어떨까요?
웹 서버를 가리키는 두 번째 CloudFront 분배를 제공하여 이 문제를 해결했습니다. 기존 분배는 S3 전용으로 유지했습니다. 피드백을 주신 @Falco님께 감사드립니다. 다만, 이 부분이 조금 더 잘 문서화되어야 한다는 점에는 동의합니다.