如何為動態網站的動態網域數量設定 AWS Cloudfront?

如何為動態網站的動態網域數量設定 AWS Cloudfront?

設定
我們有一個類似 webs/wix/etc 的網站管理系統,我們正在嘗試與 CloudFront 一起使用。它具有以下域和子域。
- ourdomain:我們的主網站
- admin.ourdomain:每個網站的管理介面,可透過 https 存取
- images.ourdomain:一個 S3 儲存桶
- router.ourdomain:見下文
- [customersomething].ourdomain:我們免費用戶的子域
- [customersomething.com]:我們的優質客戶的域名

這個系統的工作方式是,大多數網域都是CNAME-d 到router.ourdomain(因為對於我們的客戶來說,這是使用不同網域註冊商等的最簡單方法),而router.ourdomain 是我們的A別名ELB,然後 EC2 上的 PHP 正在根據 HTTP_HOST 值處理站點,而圖像來自 S3。

我們的計畫
現在我們想把這一切都放在 CloudFront 後面。大多數事情都是微不足道的。很容易將S3置於CF之後。透過 asset.ourdomain 子域將每個 ourdomain/*.(js|css) 放在 CF 後面很容易。令人高興的是,我們可以使用*.images.ourdomain 在子網域之間動態分片,減少客戶端載入時間等。免費網站)放在CF 後面進入 CF 參數。

問題
但是我們無法解決的一件事是如何將所有動態建立的帶有自訂網域的 PHP 網站放在 CF 後面。提醒一下:這些是 router.ourdomain 的 CNAME-d。將每個域放入 CF 參數中並不是一種選擇,因為我們需要能夠處理數以萬計的域名,並且我們需要在不需要對每個域進行手動配置的情況下做到這一點。

所以我們的想法是,我們應該將 router.ourdomain 作為備用網域放入 CF 配置中,將 router.ourdomain 指向路由 53 中的 CF,並將 CF 指向我們的 ELB 作為來源。我們發現這是每次收到此訊息的好方法:「錯誤請求無法滿足。錯誤的請求。由cloudfront(CloudFront)產生」。實際上不是每個時間,作為萬維網.ourdomain 以其應有的方式工作(它被CNAME 到router.ourdomain),但每個其他子域都會出現上述錯誤(*.ourdomain 被CNAME 到router.ourdomain,但即使對於那些CNAME 到router 的子域也是如此。所以現在我們不僅不知道應該如何解決這個問題,我們甚至不明白,如果它不適用於其他任何地方,為什麼它適用於 www,反之亦然。

任何想法和想法將不勝感激,謝謝。

答案1

提醒一下:這些是 router.ourdomain 的 CNAME-d

是的,你提到過這一點。事情是這樣的:

沒關係。

是的,CloudFront 將備用主機名稱為 CNAME。是的,CNAME DNS 記錄是您將給定網站的流量路由到 CloudFront 的典型方式。但不,將主機名稱配置為指向您的 CloudFront 指派的 CNAME 與現在的 Cloudfront 或一般的 HTTP 工作無關。

當瀏覽器想要連接到 Web 伺服器時,它會從 DNS 尋找 IP 位址。如果路徑中存在 CNAME,則該資訊將被丟棄。瀏覽器關心的只是“我要連接到哪個 IP 位址?”

假設 www.example.org 是 webfarm.example.com 的 CNAME。瀏覽器尋找 www.example.org 並最終獲得 webfarm.example.com 的 IP 位址。

有了答案,瀏覽器就會建立與 Web 伺服器的連線並傳送請求。

GET / HTTP/1.1
Host: www.example.com

瀏覽器傳送的 http 請求中的標Host:頭包含網址列中顯示的主機名稱。 CNAME 資訊對於瀏覽器或 Web 伺服器來說完全不可用且未知。

那麼 CNAME 與請求解析和第 7 層路由有什麼關係呢?不可能。 CNAME 目標僅用作尋找要連接的 IP 位址的路徑。

您的發行版並不是 Cloudfront 中唯一使用這些 IP 位址的發行版。還有數百或數千個其他人。歸結為Host:標題。

「CNAME」(備用主機名稱)清單是 CloudFront 在傳入Host:標頭中匹配的一組主機名,以確定請求應被視為屬於你的分配。它是Host:瀏覽器可能發送的標頭清單。Host:在標頭與分配中的配置值相符之前,與該請求關聯的分配是未知且未定義的。

如果 Cloudfront 無法將傳入Host:標頭與任何分配相匹配,它會做什麼?

HTTP/1.1 400 Bad Request

因此,您看到的行為是預期的且正確的。在 CloudFront 設定中,通配符確實有效,只要它們構成備用主機名稱配置行中唯一的最左側元素即可。但這與DNS無關。

如果您希望客戶擁有的其他網域使用您的分配,則無法避免在 CloudFront 中配置這些網域。

但是,您可以透過 API 以程式方式修改它們,而不是手動修改它們:

http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html

每個分發的此類別名稱限制為 100 個,但您可以透過向 AWS 支援提交表單來要求增加。但事實上,您最好將它們分解為多個發行版,因為 CloudFront 不會在請求中使用一台主機在給定路徑上快取對象,並將其作為不同主機的快取響應返回。在相同的發行版中,如果您將主機標頭轉送到原始伺服器(如果原始伺服器要能夠區分差異,則必須這樣做)。它不能,因為請求中的一個重要參數已從一個請求更改為另一個請求。

相關內容