設置CloudFront來託管您的Web應用程序

在我的上一篇文章中，我們介紹瞭如何設置一個網絡應用程序，該應用程序可提供來自CloudFront的CSS和JavaScript的大量和捆綁。我們將其集成到VITE中，以便當應用程序在瀏覽器中運行時，從應用程序的根HTML文件中請求的資產將從CloudFront中作為CDN提取。

雖然CloudFront的邊緣緩存確實提供了好處，但是從這些位置為您的應用程序的資源服務並非沒有自己的成本。讓我們看一下我自己的Web應用程序的WebPagetest跟踪，並使用上一篇博客文章的配置運行。

這篇文章將向您展示如何解決這個問題。我們將介紹如何在CloudFront上託管整個Web應用程序，並將CloudFront轉發（或“代理”）不可訪問的數據，AUTH等請求到我們的基礎Web服務器。

請注意，這比我們在上一篇文章中看到的要多得多，並且根據您的Web應用程序的確切需求，指令可能會有所不同，因此里程可能會有所不同。我們將更改DNS記錄，根據您的Web應用程序，您可能必須添加一些緩存標頭，以防止某些資產被緩存。我們將參與這一切！

您可能想知道，我們在上一篇文章中涵蓋的設置是否甚至提供了任何好處，因為我們在本文中所做的事情。考慮到較長的連接時間，我們會更好地放棄CDN，而是從Web服務器提供所有資產以避免更長的等待？我使用自己的網絡應用程序測量了這一點，上面的CDN版本確實更快，但效果不大。最初的LCP頁面加載速度約為200-300ms。請記住，這僅適用於初始負載。設置此連接後，Edge緩存將為您隨後的所有異步加載的塊增加更多的價值。

設置我們的DNS

我們的最終目標是從CloudFront服務整個Web應用程序。這意味著，當我們擊中域時，我們希望結果來自云層，而不是當前鏈接到的任何Web服務器。這意味著我們必須修改DNS設置。我們將使用AWS 53。

我正在以MyDemo.Technology為例，這是我擁有的領域。我在這裡向您展示所有步驟。但是到您閱讀本文時，我將從我的Web應用程序中刪除此域。因此，稍後，當我開始向您展示實際的CNAME記錄時，這些記錄將不再存在。

轉到53號公路主頁，然後單擊託管區域：

單擊創建託管區域並輸入應用程序域：

我們還沒有真正完成任何成就。我們告訴AWS，我們希望它為我們管理這個域，AWS給我們提供了該名稱服務器，它將路由我們的流量。為了生效，我們需要去任何域註冊的地方。您應該有一個地方可以輸入自己的自定義名稱服務器。

請注意，我的領域已在Godaddy註冊，這在本文的屏幕截圖中反映了。 UI，設置和選項可能與您在註冊​​服務商中看到的不同。

警告：我建議在更改之前寫下原始名稱服務器以及所有DNS記錄。這樣一來，如果某些事情失敗，您就有所有需要在開始之前恢復事物的一切。即使一切正常，您仍然需要將任何其他記錄重新添加到53號公路，即MX記錄等。

設置CloudFront分發

讓我們進行雲範圍發行以託管我們的Web應用程序。我們在上一篇文章中介紹了基礎知識，因此我們將正確地了解。從上次開始的一個很大的變化是我們輸入的原始域。不要放置頂級域，例如your-app.net。您需要的是託管應用程序的基礎域。如果那是Heroku，然後輸入Heroku為您提供的URL。

接下來，如果您打算通過安全的HTTPS連接使用此站點，請確保更改默認協議：

這部分至關重要。如果您的Web應用程序正在運行身份驗證，託管數據或其他任何內容，請務必啟用其他動詞。如果您跳過此部分，則任何帖子請求對身份驗證，突變數據等的請求將被拒絕並失敗。如果您的Web應用程序除了服務資產外什麼都不做，並且所有這些內容都是由外部服務處理的，那麼出色！您的設置很棒，您可以跳過此步驟。

與上次相比，我們必須對緩存密鑰和Origin請求設置進行多次更改：

我們需要創建一個最低ttl的緩存策略，因此我們將寄回的非臨床標頭將得到適當尊重。您可能還需要啟用所有查詢字符串。當多個GraphQl請求與不同的查詢字符串一起忽略時，我看到了怪異的行為，從而使所有這些請求從CloudFront的角度出現相同。

我的政策看起來像這樣：

對於原始請求策略，如果需要，我們應確保向諸如身份驗證和數據查詢之類的問題發送查詢字符串和cookie。需要明確的是，這決定了Cookie和查詢字符串是否會從CloudFront向下發送到您的Web服務器（例如Heroku，還是類似）。

我的看起來像這樣：

最後，對於響應標頭策略，我們可以從列表中選擇“具有前跨前任的CORS”。最後，您的前兩個將具有不同的名稱，具體取決於您的設置方式。但是我的看起來像這樣：

讓我們將我們的域（無論它是什麼）連接到這個雲沿線分佈。不幸的是，這比您預期的要多。我們需要向AWS證明我們實際上擁有該領域，因為，亞馬遜都知道，我們沒有。我們在53號公路上創建了一個託管區。我們將其給我們的名字服務員並向我們註冊了Godaddy（或者您的域名人物）。但是亞馬遜還不知道。我們需要向亞馬遜證明，實際上，我們確實控制了該領域的DNS。

首先，我們請求SSL證書。

接下來，讓我們請求證書鏈接：

現在，我們將選擇要請求公共證書選項的選項：

我們需要提供域：

而且，就我而言，證書正在等待：

所以，我要單擊它：

這證明了我們擁有並控制該領域。在單獨的選項卡中，返回53號公路，然後打開我們的託管區域：

現在，我們需要創建CNAME記錄。複製記錄名稱的第一部分。例如，如果cname是_xhyqtrajdkrr.mydemo.technology，則將_xhyqtrajdkrr零件放置。對於記錄值，請複制整個值。

假設您將AWS名稱服務器註冊為您的域主機，GoDaddy或Whor，AWS很快就可以在要求您創建的DNS條目中進行ping ping，請參閱其期望的響應並驗證您的證書。

您在開始時設置的名稱服務器可能需要時間。從理論上講，它可能需要長達72個小時，但通常在一個小時內更新。

您會在域上看到成功：

…以及證書：

哎呀！快要完成了。現在，讓我們將所有這些連接到我們的CloudFront發行版。我們可以回到CloudFront設置屏幕。現在，在自定義SSL證書下，我們應該查看我們創建的內容（以及您過去創建的任何其他）：

然後，讓我們添加該應用程序的頂級域：

剩下的就是告訴53號路線將我們的域將其路由到這個雲層分佈。因此，讓我們回到53號公路並創建另一個DNS記錄。

我們需要輸入IPv4的A記錄，以及IPv6的AAAA記錄。對於這兩者，請將記錄名稱留為空，因為我們只在註冊我們的頂級域，而沒有其他內容。

選擇A記錄類型。接下來，將記錄指定為別名，然後將別名映射到雲方分佈。這應該打開一個選擇您的CloudFront發行版的選項，並且由於我們以前在CloudFront上註冊了該域，因此您應該看到該分佈，並且只有在進行選擇時才看到該分佈。

我們為IPv6支持所需的AAAA記錄類型重複了完全相同的步驟。

運行您的網絡應用程序，並確保它實際上可以正常工作。它應該！

測試和驗證的事情

好的，雖然從技術上講我們在這裡完成，但仍有一些事情要滿足您的Web應用程序的確切需求。不同的應用程序有不同的需求，到目前為止，我所展示的內容已引導我們完成了通過雲層路由事物以提高性能的共同步驟。您的應用程序獨有的東西可能需要更多的愛。因此，為此，讓我介紹您在設置期間可能遇到的一些其他可能的項目。

首先，請確保您擁有的任何帖子正確發送到了您的來源。假設正確配置了CloudFront將cookie轉發到您的來源，則應該已經起作用，但是檢查沒有害處。

更大的問題是將發送到您的Web應用程序的所有其他獲取請求。默認情況下，如果被緩存，請通過緩存響應將CloudFront收到的任何GET請求都將接收到您的Web應用程序。這可能是災難性的。 CDN將任何帶有GET發送的REST或GRAPHQL端點的數據請求都會緩存。而且，如果您要運送服務工作者，那也將被緩存，而不是正常行為，在後台下發送當前版本並在有更改（如果有更改）中進行更新。

為了告訴CloudFront不要緩存某些東西，請確保將“緩存控制”標頭設置為“無緩存”。如果您正在使用諸如Express之類的框架，則可以使用類似的內容設置中間件以訪問數據：

 app.use（“/graphql”，（req，res，next）=> {
  res.set（“ CACH-CONTROL”，“ NO NO-CACHE”）;
  下一個（）;
}）;
app.use（
  “/graphql”，
  ExpressGraphQl（{
    架構：執行措施，
    graphiql：是的，
    root值：root
  }））
）；

對於諸如服務工作者之類的事情，您可以在靜態中間件之前為這些文件放置特定的規則：

 app.get（“/service-worker.js”，express.static（__ dirname“/react/dist”，{setheaders：resp => resp.set（“ cache-control”，“ not-cache”）}）;
app.get（“/sw-index-bundle.js”，express.static（__ dirname“/react/dist”，{setheaders：resp => resp.set（“ cache-controll”，“ not-cache”，“ not-cache”）}）;
app.use（express.static（__ dirname“/react/dist”，{maxage：432000 * 1000 * 10}））;

等等。徹底測試所有內容，因為可能會出錯。每次更改之後，請確保在雲層中運行完整的無效，並在重新運行Web應用程序之前清除緩存，以測試正確排除在緩存中的內容。您可以從CloudFront的“無效”選項卡中執行此操作。將其打開並放入 /*以獲取值，以清除所有內容。

工作的雲方面實現

現在我們已經運行了所有內容，讓我們在WebPagetest中重新運行我們的跟踪：

就像這樣，我們不再像以前看到的那樣設置連接。對於我自己的Web應用程序，我看到LCP的500毫秒有了實質性改善。那是一個可靠的勝利！

在CDN上託管整個Web應用程序可以提供所有世界中最好的。我們獲得了靜態資源的邊緣緩存，但沒有連接成本。不幸的是，這種改進不是免費的。正確設置所有必要的代理並不完全直觀，然後仍然需要設置高速緩存標頭，以避免在CDN的緩存中掛起不可接受的請求。

以上是設置CloudFront來託管您的Web應用程序的詳細內容。更多資訊請關注PHP中文網其他相關文章！