CDN 기술에 대해 질문이 있습니다.
CDN은 내 사이트의 파일만 캐시할 수 있고, 다른 사이트에서 핫링크된 파일은 캐시할 수 없다는 것이 맞나요?
저는 카탈로그 파일(mps와 이미지)을 다른 서버에 저장해 두고, 제 Discourse 사이트에서 핫링크로 사용하고 있습니다. 이러한 파일들은 CDN에 의해 캐시되지 않는다는 것이 맞나요? 핫링크된 파일도 캐시할 수 있는 방법이 있을까요?
Discourse가 원격 이미지를 자체 이미지 스토어로 가져오지 않도록 설정하지 않는 한, 기본적으로 그렇게 처리합니다. 아래 내용은 이 기능을 비활성화했다고 가정하고 설명합니다.
해당 사이트를 CDN 뒤에 배치한 후, CDN URL을 Discourse에 공유해야 합니다.
이미지 사이트에 CDN을 앞에 배치했지만 Discourse에 원본(origin) URL을 공유하는 경우, 내장된 기능을 사용하여 원본 URL을 CDN URL로 교체할 수 있습니다.
2개의 좋아요
Discourse에서 CDN 기능을 활성화하고 원본을 Discourse에 저장하는 기능을 끄면, CDN 서비스가 이러한 외부 파일을 캐시하고 Discourse가 다른 사이트에서 핫링크된 파일에 대한 모든 링크를 대체하게 되는 것이 맞나요?
다른 사이트에서 핫링크된 외부 파일을 캐시할 수 있을지 의문입니다. 확인해 주실 수 있는 분 계신가요?
참고로, AWS CloudFront를 사용하여 전체 사이트 CDN 가속(및 SSL 종료)을 설정하는 방법에 대한 새 스레드를 여기에 게시했습니다(아래 링크). 이 부분은 주의가 필요합니다 — 신중하게 접근하세요.
1개의 좋아요
Reason: CORS header ‘Access-Control-Allow-Origin’ missing 오류가 발생했을 때에도 여전히 이것이 필요한가요?
Github에서 해당 변수를 사용하는 것을 찾을 수 없습니다:
수정: 설정 주석에는 여전히 필요하다고 되어 있고, 실제로 그렇게 설정한 후에는 작동합니다. 그냥 받아들여야겠네요 
1개의 좋아요
현재 2023년 기준으로, 아래 네 가지 규칙을 여전히 엄격히 준수해야 하나요? 예를 들어, Akamai와 같은 CDN을 사용하여 메인 도메인 이름을 가속하도록 설계된 경우를 생각해 봅시다. 아래 규칙들의 정제된 구성 예가 있을까요? 예를 들어 **메시지 버스(message bus)**와 **롱 폴링(long polling)**은 여전히 오리진 서버로 요청을 보내야 하는가요? 이러한 설정은 어디에 적용해야 하나요? 롱 폴링 기본 URL(long polling base url)이 관리자 대시보드에서 제거된 것 같습니다.
2개의 좋아요
메시지 버스 요청을 다른 도메인에서 처리할 수 있도록 설정하는 고급 옵션이 몇 가지 있습니다. 다만 매우 복잡한 구조입니다.
1개의 좋아요
즉, "long polling base url"은 Rails 콘솔을 통해 설정해야 합니다. 관리 대시보드에서 이 설정이 제거되었기 때문입니다. 사이트가 Full site CDN 모드에서 정상적으로 작동하려면 이 설정이 여전히 필요함에도 불구하고, 왜 제거되었는지에 대한 이유가 이전에 어디에 게시되었는지 제가 놓친 것 같습니다.
마찬가지로, DISCOURSE_ENABLE_CORS: true도 app.yml 파일에서 설정해야 합니다.
app.yml에서 환경 변수(DISCUSS_LONG_POLLING_BASE_URL)를 사용하여 설정해야 합니다. 이 옵션은 숨겨져 있는데, 이는 이 값을 설정해야 하는 사용자가 매우 적고, 설정을 수행하는 사용자는 해당 작업의 의미를 알고 있을 것으로 전제되기 때문입니다.
1개의 좋아요
감사합니다, @pfaffman! 대문자로 작성된 변수들은 모두 app.yml에 넣어야 한다는 것을 알았어야 했습니다.
그렇다면 message-bus의 어떤 사용 사례가 실제로 효과를 발휘하게 되나요? 예를 들어, 게시물에 대한 답글이 알림을 트리거하는 경우 같은 것들이 있을까요? DISCOURSE_LONG_POLLING_BASE_URL이 설정되지 않은 상태에서 제 사이트에서 message-bus가 의도한 대로 작동하는지 확인하기 위해 사용 사례 테스트를 해보겠습니다.
안녕하세요,
관리자 대시보드에서 “long polling base url” 설정이 제거되었나요? 아니면 rails 콘솔을 통해 이 설정을 할 수 있나요?
long_polling_base_url은 숨겨진 사이트 설정이지만, app.yml에서 환경 변수를 사용하지 않는 경우라면 rails 콘솔에서 설정할 수 있습니다:
3개의 좋아요
이 목록은 확실히 Discourse에 대한 더 많은 통찰력을 제공합니다.
저는 웹사이트에 CDN을 설정했고, 엣지 캐시에 도달했지만, 응답 헤더에서 메시지 버스 문제를 경험하지는 않았습니다. 그럼에도 불구하고 여전히 안정적이라고 느끼지 못합니다. 또한 CORS 설정도 하지 않았습니다.
Cache-Control: must-revalidate, private, max-age=0
안녕하세요,
다른 스레드(Full Site CDN Using AWS CloudFront - #2 by Hyan)에 제 질문을 게시했습니다. 동일한 구성을 수행하고 #DISCOURSE_CDN_URL: https://discourse-cdn.example.com을 그대로 두었습니다. 이 값을 웹사이트와 동일한 URL, 예를 들어 http://forum.example.com으로 설정해도 될까요? 그렇지 않으면 도메인 이름 없이 상대 경로로만 표시되는 자산 URL이 생성됩니다.
@sam 또는 @pfaffman 님이 힌트를 주시면 감사하겠습니다.
Cloudflare를 CDN으로 사용하는 것을 추천하지 않습니다. 그렇게 하는 사람들도 있긴 합니다. 아마도 도움을 줄 수 있을지도 모르죠.
수정: 아, 죄송합니다. 여기는 “전체 사이트 CDN…” 관련이군요. 제가 여기서 답변을 드리는 건 적절하지 않을 것 같습니다.
아니요, 저는 캐시 동적 콘텐츠를 지원하는 Akamai CDN을 사용하고 있습니다.
이 스레드의 첫 번째 게시글을 보면, 웹사이트 URL과 CDN URL이 동일하더라도 전체 사이트 CDN처럼 동작하려면 DISCOURSE_CDN_URL을 설정해야 하는 것 같습니다. 하지만 이 설정이 사이트가 깨지거나, 결국 소프트웨어를 처음부터 다시 설치해야 하는 등 돌이킬 수 없는 결과를 초래하는지 확신이 서지 않습니다. 이 게시물(Full Site CDN Using AWS CloudFront)의 작성자는 DISCOURSE_CDN_URL을 설정하지 않고 기본값 그대로 두었으며, message-bus/long-polling을 서빙하기 위해 별도의 URL이 필요하지 않았습니다. 저는 이 해결책을 적용했고, 현재까지 웹사이트는 잘 작동하고 있습니다. 이 해결책의 유일한 단점은 DISCOURSE_CDN_URL 값이 비어 있어 페이지 소스에 많은 상대적 URL(기본 URL이 없는 상태)이 표시되어, 프로덕션 수준의 웹사이트처럼 보이지 않는다는 점입니다.
질문을 이어가면서, 이 포스트에서 묻는 것과 유사한 내용을 다룬 다른 게시물을 발견했습니다: CloudFront not caching static files - #4 by Falco
@Falco 님의 답변에 감사드립니다. 전체 사이트 CDN 설정에서 DISCOURSE_CDN_URL을 DISCOURSE_HOSTNAME과 동일하게 설정할 수 있을까요? 전체 사이트 CDN은 호스트명의 URL을 CDN이 가속한다는 의미이므로, DISCOURSE_CDN_URL과 DISCOURSE_HOSTNAME이 동일해져야 한다고 생각합니다. 하지만 메타 포럼에는 이에 대한 적절한 문서가 없습니다.
여보세요, 버니에 사용할 수 있는 템플릿이 있나요?
이를 위해 템플릿은 필요하지 않습니다. bunny를 설정하여 discourse 사이트에서 데이터를 가져오게 하고, app.yml에서 DISCOURSE_CDN_URL을 bunny가 제공한 CDN 엔드포인트로 설정하면 됩니다.
1개의 좋아요
Bunny DNS를 사용하면서 VPS IP로 "CDN 가속"을 시도해 보고 있습니다. 작동은 하지만, 모든 사용자에게 동일한 IP가 할당됩니다.
방금 설정을 찾았는데, "X-Real-Ip"라고 되어 있네요.