高可用性和容錯是架構完善的解決方案的重要元件。 穩健的配置包含針對意外故障的緊急計畫，以減少停機時間並保持系統自動運作。
當你將應用程式部署到雲端時，你會選擇該雲端的一個區域作為應用程式基礎架構。 如果你只在某個區域部署應用程式，而該區域無法使用，該應用程式也同樣無法使用。 根據應用程式的服務水準協議（SLA）條款，缺乏可用性可能是不可接受的。 為確保可用性，應將應用程式及其服務部署於雲端多個區域。
本教學說明如何部署一個高度可用的多區域網頁應用程式。 此程序實作一個簡單情境，包含一個網頁應用程式與
在本教學課程中，您會：
- 在不同區域建立相同的 App Service 應用程式
- 建立 Azure Front Door 並設置存取限制以阻止公眾對於 App Service 的存取
先決條件
如果你沒有Azure帳號，請在開始前先建立一個free帳號。
若要完成本教學課程：
請使用 Azure Cloud Shell 的 Bash 環境。 欲了解更多資訊，請參見開始使用 Azure Cloud Shell。
如果你喜歡在本地執行 CLI 參考指令，install Azure CLI。 如果你是在 Windows 或 macOS 上運行，可以考慮在 Docker 容器中執行 Azure CLI。 更多資訊請參見 如何在 Docker 容器中執行Azure CLI。
如果你使用本地安裝，請使用
az login 指令登入 Azure CLI。 請遵循您終端機上顯示的步驟，以完成驗證流程。 如需其他登入選項，請參見使用 Azure CLI 驗證 Azure。 當系統提示時，首次使用時安裝 Azure CLI 擴充功能。 欲了解更多擴充功能的資訊，請參閱
使用 Azure CLI 。執行 az version (部分機器翻譯) 以尋找已安裝的版本和相依程式庫。 若要升級至最新版本，請執行 az upgrade。
檢視情境架構
下列架構圖顯示您在本教學課程中建立的基礎結構。 它由兩個相同的 App Service 應用程式組成，分布在不同區域。 作用中區域內的第一個 Web 應用程式。 它是主要負責處理進來流量的應用程式。 第二個應用程式在 待機 區域，等待主要應用程式的可用性。 Azure Front Door 嘗試將流量導向主要的網頁應用程式。 當主要區域無法使用時，流量會導向待機網路。 圖中虛線代表根據區域狀態的流量路由。 存取限制已設定為封鎖從網際網路直接存取應用程式。
Azure 提供多種負載平衡與流量路由選項。 Azure Front Door 被選用於此教學，因為它涉及在多個區域部署的 Azure App 服務 上，面向網際網路的網頁應用程式。 如果你的設定與本教學範例不同，請參閱 「選擇負載平衡解決方案」來符合你的情境。
本教學中的情境提供以下行為：
- 相同的 App Service 應用程式會部署在兩個不同區域。
- 直接傳送到網頁應用程式的公開流量會被封鎖。
- Azure Front Door 會將流量路由到主要區域的活躍應用程式。
- 次要區域的待命應用程式可視需要提供流量服務。
建立資源群組
你需要兩個在不同 Azure 區域執行的網頁應用程式實例來做這個教學。
檢視可用的 區域配對 ，並為你的網頁應用程式選擇兩個配對區域。
在本教學中，這兩個區域分別稱為
<primary-region>（eastus）和<standby-region>（westus）。為你在教學中設定的所有資源建立資源群組。 這個教學會在該
<primary-region>地點建立資源群組。az group create --name <resource-group> --location <primary-region>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --name<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--location<primary-region>資源群組的區域位置。 這個教學使用與資源群組和主要 Web 應用程式相同的區域位置。 eastus在實際實作中，每個區域/資源使用不同的資源群組。 分離方式允許在災難復原情境下隔離資源。
更多資訊請參閱 az 群組 create 指令參考。
建立兩個 App Service 計劃
建立兩個 App Service 方案，分別對應每個網頁應用程式。 在您預期建立相應應用程式的區域創建每個計劃。
你利用之前選擇的 區域配對 來執行這個指令。 主網頁應用程式使用主動區域，備用網頁應用程式使用被動區域。
執行以下指令建立主要網頁應用程式的 App Service 計畫，然後再執行該指令建立備用應用程式的計畫。
az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`
請將以下 <placeholder> 參數值替換為您自身資源的資訊：
| 參數 | 值 | 說明 | 範例 |
|---|---|---|---|
--name |
<app-service-plan> |
Web 應用程式的 App Service 方案名稱。 每個計畫實例必須有唯一的名稱。 | zava-primary-planzava-standby-plan |
--resource-group |
<resource-group> |
包含本教學中建立資源的資源群組。 | zava-resource-group |
--location |
<region> |
網頁應用程式的區域位置。 | - 主要網頁應用程式，活躍區域 eastus - 待命網頁應用程式，被動區域 westus |
欲了解更多資訊，請參閱 az appservice plan 建立 指令參考。
建立兩個應用程式
建立兩個 App Service 網頁應用程式。 將每個應用程式放入對應的 App Service 方案和區域位置。
確認網頁應用程式的
--runtime語言版本。你可以執行以下指令來查看可用執行時的清單：
az webapp list-runtimes如果你打算使用本教學中描述的範例 Node.js 應用程式，請將值設
<language-version>為NODE:24-lts。建立兩個網頁應用程式。 執行以下指令建立主要網頁應用程式，再執行一次指令建立備用應用程式。
az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --name<web-app-name>Web 應用程式的名稱。 每個應用程式必須擁有全球獨一無二的名稱。 有效字元為 a-z、0-9、-和 。zava-primary-appzava-standby-app--resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--name<app-service-plan>Web 應用程式的 App Service 方案名稱。 zava-primary-planzava-standby-plan--runtime<language-version>網頁應用程式的執行時語言版本。 NODE:24-lts欲了解更多資訊，請參閱 az webapp create command reference。
辨識每個網路應用程式的
defaultHostName數值。 主機名稱格式為<web-app-name>.azurewebsites.net。掃描每個網頁應用程式的指令輸出並找到該值，或執行以下指令：
az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --name<web-app-name>Web 應用程式的名稱。 zava-primary-appzava-standby-app--resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group在 Azure 入口網站，每個應用程式的主機名稱會顯示在網頁應用程式Overview頁面上。
記錄主機名稱的數值以備後用。 你可以用主機名稱來定義 Azure Front Door 部署的後端位址。
確認你能存取新的網頁應用程式。
在瀏覽器中，輸入主要網頁應用程式的主機名稱，例如
zava-primary-app.azurewebsites.net。連線成功時，你會看到以下訊息：
用你的待機網頁應用程式主機名稱重複測試。
配置 Azure Front Door
多區域部署可採用 主動-主動 或 主動-被動 配置。 主要區域為主動區域，備用區域為被動區域。
- 主動-主動設定會將要求分散到多個作用中區域。
- 主動-被動配置會在待機（被動）區域持續執行實例，但除非主要（主動）區域失敗，否則不會將流量送往該區域。
Azure Front Door 允許你啟用這兩種設定。 欲了解更多設計高可用性與容錯應用程式的資訊，請參閱 設計審查可靠性檢查清單。
建立個人檔案
建立一個 Azure Front Door Premium 的實例，用來路由流量到你的網頁應用程式。
請檢視 Azure Front Door 層級比較 並選擇部署所需的層級。
本教學使用 Azure Front Door Premium（
Premium_AzureFrontDoor）。如果你偏好部署 Azure Front Door Standard，請記得 Standard 層級不支援使用 WAF Policy 部署管理規則。
執行以下指令來建立設定檔：
az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --profile-name<front-door-profile>Azure Front Door 設定檔的名稱。 名稱必須是資源群組中唯一的。 zava-profile--resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--sku<front-door-tier>用於部署的 Azure Front Door 層級 SKU。 Premium_AzureFrontDoor（推薦）
Standard_AzureFrontDoor如需詳細資訊，請參閱 az afd profile create 命令參考。
新增端點。
在你的個人檔案中建立一個端點。 建立第一個端點後，你可以在設定檔中建立多個端點。
az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled
請將以下 <placeholder> 參數值替換為您自身資源的資訊：
| 參數 | 值 | 說明 | 範例 |
|---|---|---|---|
--resource-group |
<resource-group> |
包含本教學中建立資源的資源群組。 | zava-resource-group |
--endpoint-name |
<front-door-endpoint> |
在 Azure Front Door 設定檔下的端點名稱。 此名稱必須是全域唯一的。 | zava-endpoint |
--profile-name |
<front-door-profile> |
您的 Azure Front Door 設定檔名稱。 | zava-profile |
更多資訊請參閱 az afd endpoint create command reference。
新增來源群組
當你部署到 Azure Front Door 時，你需要一個 Origin 作為網頁應用後端的端點。 更多資訊請參閱Azure Front Door 的原點與原點群組。 來源會儲存在來源組中。
在你的 Azure Front Door 設定檔建立一個起源群組，包含你兩個網頁應用程式的起源。
az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
--probe-request-type <probe-request> \
--probe-protocol <probe-protocol> \
--probe-interval-in-seconds <probe-interval> \
--probe-path <probe-path> \
--sample-size <sample-size> \
--successful-samples-required <required-samples> \
--additional-latency-in-milliseconds <extra-latency>
請將以下 <placeholder> 參數值替換為您自身資源的資訊：
| 參數 | 值 | 說明 | 範例 |
|---|---|---|---|
--resource-group |
<resource-group> |
包含本教學中建立資源的資源群組。 | zava-resource-group |
--origin-group-name |
<front-door-origin-group> |
Azure Front Door 來源群組的名稱。 此名稱必須是全域唯一的。 | zava-origin-group |
--profile-name |
<front-door-profile> |
您的 Azure Front Door 設定檔名稱。 | zava-profile |
--probe-request-type |
<probe-request> |
健康檢查請求類型。 | GET |
--probe-protocol |
<probe-protocol> |
用於健全狀態探查的通訊協定。 | Http |
--probe-interval-in-seconds |
<probe-interval> |
健康狀態探查的間隔秒數。 | 60 |
--probe-path |
<probe-path> |
相對於原點的路徑，用於判斷原點的狀態。 |
/ (反斜線) |
--sample-size |
<sample-size> |
要針對負載平衡決策進行考量的樣本數。 | 4 |
--successful-samples-required |
<required-samples> |
取樣期間必須成功的樣本數。 | 3 |
--additional-latency-in-milliseconds |
<extra-latency> |
以毫秒為單位的額外延遲，以使探查落入最低的延遲貯體。 | 50 |
欲了解更多資訊，請參閱 az afd origin-group create command reference。
將來源新增至來源群組
為你的每個網站應用程式在 Azure Front Door 來源群組中新增一個來源。
為 主要 網頁應用程式新增一個來源。 將
--priority參數設為1，這會告知Azure Front Door這個應用程式是流量的主要接收器。az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \ --origin-group-name <front-door-origin-group> \ --origin-name <web-app-origin-name> \ --origin-host-header <web-app-name>.azurewebsites.net \ --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \ --http-port <origin-port> --https-port <origin-secure-port>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--host-name<web-app-name>.azurewebsites.net你 主要 網頁應用程式的主機名稱。 主機名稱結合了網頁應用程式名稱，例如 zava-primary-app與主機識別碼。azurewebsites.netzava-primary-app.azurewebsites.net--profile-name<front-door-profile>您的 Azure Front Door 設定檔名稱。 zava-profile--origin-group-name<front-door-origin-group>Azure Front Door 來源群組的名稱。 zava-origin-group--origin-name<web-app-origin-name>主要 網頁應用程式的來源名稱。 名稱必須在起源群體中獨一無二。 primary-origin--origin-host-header<web-app-name>.azurewebsites.net主機標頭用來發送請求到 主要 網頁應用程式的來源。 如果你沒有指定某個值，請求主機名稱會決定這個值。 Azure CDN 起源，例如 Web Apps、Blob 儲存體 和 Cloud Services，預設要求此主機標頭值必須與來源主機名稱相符。 zava-primary-app.azurewebsites.net--priority<origin-priority>這個來源在來源群組中的優先順序。 對於 主要 網頁應用程式，優先權設為 1。 Azure Front Door 使用優先權值來在起源與活躍區域間進行負載平衡。 數值必須介於1到5之間。 1 --weight<origin-weight>來源群組內用於負載平衡的來源權重。 數值必須介於1到1000之間。 1000 --enabled-state<origin-state>請指示是否啟用此起始點接收流量。 Enabled--http-port<origin-port>用於來源 HTTP 要求的連接埠。 80 --https-port<origin-secure-port>用於安全 HTTPS 請求至原始伺服器的埠。 443 欲了解更多資訊，請參閱 az afd origin create 指令參考。
再執行一次指令，並為 待命 網頁應用程式新增一個 Origin。 指令使用相同的參數，但具有以下獨特的參數值：
參數 值 說明 範例 --host-name<web-app-name>.azurewebsites.net你 待命 網頁應用程式的主機名稱。 zava-standby-app.azurewebsites.net--origin-name<web-app-origin-name>這是待命網頁應用程式的起源名稱。 standby-origin--origin-host-header<web-app-name>.azurewebsites.net用來向 待命 網頁應用程式來源發送請求的主機標頭。 zava-standby-app.azurewebsites.net--priority<origin-priority>這個來源在來源群組中的優先順序。 對於 待命 網頁應用程式，請將優先權設為 2。 Azure Front Door 嘗試將所有流量導向主要來源。 當主要起始點無法使用時，流量會導向備用起始點。 2
新增路線規則
新增一個路由規則，將 Azure Front Door 端點映射到原始群組。 路由會將端點的請求轉發到你的原始群組。
建立一條路由規則，將 Azure Front Door 端點映射到 origin 群組：
az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> ` --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> ` --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--profile-name<front-door-profile>您的 Azure Front Door 設定檔名稱。 zava-profile--endpoint-name<front-door-endpoint>Azure Front Door 設定檔底下端點的名稱。 zava-endpoint--forwarding-protocol<protocol-type>此路由規則在將流量轉發到後端應用程式時所使用的協定。 MatchRequest--route-name<route-rule-name>路由規則的名稱。 在 Azure Front Door 設定檔內必須是唯一的。 zava-route-rule--https-redirect<secure-redirect>指示是否自動將 HTTP 流量重新導向至 HTTPS 流量。 Enabled--origin-group-name<front-door-origin-group>Azure Front Door 來源群組的名稱。 zava-origin-group--supported-protocols<protocol-list>此路由規則所支援的協定清單。 用空格來區分協定類型。 Http Https--link-to-default-domain<domain-link>請指示此路由是否連結到預設端點網域。 Enabled更多資訊請參閱 az afd route create command reference。
預留約15分鐘完成部署。 這些變化在全球傳播可能需要一些時間。
只透過 Azure Front Door 限制存取
目前你可以直接在瀏覽器輸入主機名稱來存取你的網頁應用程式。 如果你對應用程式設定存取限制，就能確保流量只能透過 Azure Front Door 到達你的應用程式。
Azure Front Door 的功能在流量僅透過服務時效果最佳。 最佳做法是設定你的網頁應用程式來源來阻擋非透過 Azure Front Door 傳送的流量。 否則，流量可能會繞過 Azure Front Door 網頁應用防火牆、DDoS 防護及其他安全功能。
從 Azure Front Door 到 App 的流量來自一組在 AzureFrontDoor.Backend 服務標籤中定義的知名 IP 範圍。 透過使用服務標籤限制規則，你可以限制流量只來自 Azure Front Door。
取得您的 Azure Front Door 設定檔識別碼。
您需要設定檔 ID，才能確保流量僅來自您的特定 Azure Front Door 執行個體。 存取限制會根據你 Azure Front Door 設定檔發送的獨特 HTTP 標頭，進一步過濾收到的請求。
az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--profile-name<front-door-profile>您的 Azure Front Door 設定檔名稱。 zava-profile指令輸出顯示設定檔 ID（32 字元字母數字值）：
"0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"在下一個步驟中，您會使用設定檔 ID 做為
<profile-identifier>值。執行以下指令來設定主要網頁應用程式的存取限制，然後再執行一次對待機應用程式設定限制。
az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> ` --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--name<web-app-name>你設定存取限制的網頁應用程式名稱。 zava-primary-appzava-standby-app--priority<access-priority>在針對設定檔定義的所有規則中，指定存取限制規則的優先順序。 值越低，優先權越高。 100 --service-tag<tag-name>由 Azure Front Door 識別的服務標籤名稱。 存取限制適用於服務標籤所指示的 IP 範圍。 AzureFrontDoor.Backend--http-headerx-azure-fdid=<profile-identifier>指定一個或多個獨特的 HTTP 標頭，以加強對進來流量的過濾。 存取限制會根據你 Azure Front Door 設定檔發送的唯一 HTTP 標頭來過濾收到的請求。 標頭結合了 Azure Front Door 前綴與您 Azure Front Door 實例的設定檔識別碼。 x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee更多資訊請參閱 az webapp config access-restriction add 指令參考。
測試存取限制
確認你的存取權限限制是否禁止直接存取你的應用程式。
在瀏覽器中，輸入主要網頁應用程式的主機名稱，例如
zava-primary-app.azurewebsites.net。連線應會因以下訊息而失敗：
請用你待命網頁應用程式的主機名稱重複測試，例如
zava-standby-app.azurewebsites.net。
測試 Azure Front Door 部署
當你建立 Azure Front Door Standard 或 Premium 設定檔時，設定要全域部署可能需要一些時間。 部署完成後，你可以存取前端主機。
取得你 Azure Front Door 端點的主機名稱：
az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"請將以下
<placeholder>參數值替換為您自身資源的資訊：參數 值 說明 範例 --resource-group<resource-group>包含本教學中建立資源的資源群組。 zava-resource-group--profile-name<front-door-profile>您的 Azure Front Door 設定檔名稱。 zava-profile--endpoint-name<front-door-endpoint>Azure Front Door 設定檔底下端點的名稱。 zava-endpoint指令輸出會顯示端點主機名稱：
"zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"主機名稱由端點名稱、唯一的字母數字雜湊值、識別碼以及 Azure Front Door 後綴組成。 在下一個步驟中，您會使用端點主機名稱。
欲了解更多資訊，請參閱 az afd endpoint show command reference。
在瀏覽器中，輸入端點主機名稱，例如
zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net。你的請求應該會自動導向你在活躍區域的主要應用程式。
測試已配對區域中應用程式之間的即時全域容錯移轉。
在瀏覽器中，輸入端點主機名稱，例如
zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net。透過執行 az webapp stop 指令來停止主要應用程式。
請將以下
<placeholder>參數值替換為您自身資源的資訊：az webapp stop --name <primary-web-app> --resource-group <resource-group>重新整理您的瀏覽器。
如果流量正確地導向到另一個區域的 待機 應用程式，你應該會看到 相同的頁面和訊息。
秘訣
您可能需要多次重新整理頁面，才能完成故障轉移。
你可以透過查看 Azure 入口網站中網頁應用程式的狀態來確認 Azure Front Door 是否會重新導向備用應用程式。 在主要網頁應用程式的 概覽 頁面上， 開始選項應該 會顯示（不會變灰）。 在待命網頁應用程式的 概覽 頁面， 開始 選項不應該出現（灰色）。
再執行一次
az webapp stop指令，然後停止 你的待機 應用程式。請將以下
<placeholder>參數值替換為您自身資源的資訊：az webapp stop --name <standby-web-app> --resource-group <resource-group>再次重新整理瀏覽器。
如果待命應用程式也停止，所有網路流量路由都應該停止。 這次，你應該會看到錯誤訊息：
執行指令
az webapp start並重新啟動 你的待機 應用程式。請將以下
<placeholder>參數值替換為您自身資源的資訊：az webapp start --name <standby-web-app> --resource-group <resource-group>更新您的瀏覽器，您應該會看到應用程式已成功連線。
驗證確認你現在可以透過 Azure Front Door 存取你的應用程式，且故障轉移功能如預期般運作。
如果你完成了故障轉移測試，請重新啟動 主要的 應用程式。
清除資源
在前面的步驟中，你在資源群組中建立了 Azure 資源。 如果你未來不打算再需要這些資源，請在 Cloud Shell 執行以下指令刪除資源群組。
將<placeholder>的參數值替換為你自己的資源資訊：
az group delete --name <resource-group>
執行此命令可能需要幾分鐘的時間。
在 ARM 或 Bicep 中進行部署
你在這教學中建立的資源，可以透過使用 Azure Resource Manager 範本（ARM 範本）或 Bicep 範本來部署。 你可以從 GitHub 上的高度可用的多區域網頁應用程式 Bicep 檔案開始。 這個範本幫助你建立一個安全、高度可用的多區域端對端解決方案，並在 Azure Front Door 後面使用兩個不同區域的網頁應用程式。
欲了解如何部署 ARM 與 Bicep 範本，請參閱 Deploy Bicep 檔案，使用Azure CLI。
常見問題集
在這個教學中，你部署了一個基礎架構來啟用多區域的網頁應用程式。 App Service 提供功能，幫助您確保執行的應用程式遵循安全最佳實務與建議。
本節包含常見問題解答，幫助您進一步保護應用程式，並依照最佳實務部署與管理資源。
管理與部署基礎設施與 Azure 資源
在這個教學中，你使用 Azure CLI 來部署基礎架構資源。 請考慮設定持續部署機制來管理應用程式基礎結構。 因為你在不同區域部署資源，你需要獨立管理這些資源。 為確保資源在各區域間相同，應使用如 ARM template 或 Terraform 的基礎設施即程式碼（IaC），搭配如 Azure Pipelines 或 GitHub Actions 的部署管線。 當你適當設定此設定時，任何資源變更都會觸發所有部署區域的更新。 若要瞭解更多資訊，請參見 設定 Azure App 服務 的持續部署 (Configure continuous deployment to Azure App 服務)。
使用暫存槽以確保安全部署到生產環境
不建議直接將應用程式程式碼部署到生產應用程式和位置。 在推送到生產環境前，有一個安全的空間來測試和驗證變更非常重要。 結合暫存槽與槽位交換，將程式碼從測試環境移至生產環境。
在這個教程中，你建立了支援使用暫存插槽的基礎設施。 你可以為每個網頁應用程式實例建立部署時段，並使用 GitHub Actions 設定持續部署到這些暫存時段。 與基礎架構管理一樣，建議為應用程式原始碼設定持續部署，以確保區域間的變更同步。如果你沒有設定持續部署，每次程式碼變更時，就必須手動更新每個區域的應用程式。
使用分段槽位時，請依照以下程序操作：
在這個過程中，你需要一個準備好部署到你的 App Service 應用程式的應用程式。
如果你完成了教學，就可以使用你的主要網頁應用程式和待命網頁應用程式。 不過，你需要一個支援足夠部署插槽的 App Service 計劃方案。 欲了解更多資訊，請參閱Azure訂閱與服務限制、配額與限制。
如果你沒有應用程式，可以從 Node.js Hello World 範例應用程式 開始。 復刻 GitHub 儲存庫，這樣你就有自己的版本可以進行修改。
為你的網頁應用程式設定 App Service 堆疊設定。
堆疊設定指的是你應用程式所使用的語言版本或執行環境。
你可以在Azure入口網站設定設定，或使用
az webapp config set指令。 如果你用的是 Node.js 取樣，請把堆疊設定設為Node 24 LTS。在Azure 入口網站，進入你的主要 Web應用程式。
在左側功能表中，選取 設定>設定。
在 堆疊設定 標籤中，設定以下事項：
選擇堆 疊 值，例如 節點。
選擇 版本 值，例如 Node 24 LTS。
選取 ，然後套用。
重複這個流程，設定你的 待機 網頁應用程式的 App Service 堆疊設定。
在 Azure 入口網站設定持續部署。 如需如何與供應商如 GitHub Actions 配置持續部署的詳細指引，請參閱 將持續部署配置為 Azure App 服務。
執行以下指令，為你的
stage網頁應用程式建立一個名為的暫存環境。az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>再執行一次
az webapp deployment slot create指令，並建立一個為stage網頁應用程式命名的暫存槽。為每個部署階段設定持續部署，使用 GitHub Actions：
在Azure 入口網站，進入你的主要 Web應用程式。
在左側功能表中，選取 [部署>部署位置]。
在列表中找到 舞台 槽位，選擇該槽位開啟詳細資料窗格。
在左側選單中，選擇 部署>部署中心。
在 Settings 標籤中，將 Source 選項設為 GitHub：
如果你是第一次從 GitHub 部署，請選擇 Authorize並依照授權提示操作。 如果您想要從不同的使用者存放庫進行部署，請選取 [變更帳戶]。
在你用 GitHub 授權你的 Azure 帳號後，選擇 Organization、Repository，以及 Branch 來設定 CI/CD。 如果你找不到組織或倉庫，可能需要在 GitHub 上啟用更多權限。 欲了解更多資訊，請參閱 管理使用者存取您組織資料庫。
如果您使用 Node.js 範例應用程式，請使用下列設定。
設定 值 組織 <your-GitHub-organization>儲存庫 nodejs-docs-hello-world 分支 主要 選取 [儲存]。
所選存放庫和分支中的新認可，現在會持續部署到 App Service 應用程式插槽。 您可以在 [記錄] 索引標籤上追蹤認可和部署。
一個使用發佈設定檔來認證 App Service 的預設工作流程檔案會被加入你的 GitHub 儲存庫。 您可以移至 <repo-name>/.github/workflows/ 目錄來檢視此檔案。
在 App Service 中關閉基本認證
你可以透過
如果你使用持續部署工具來部署應用程式原始碼，關閉基本認證需要 額外步驟來配置持續部署。 例如，您無法使用發佈設定檔，因為它不是使用 Microsoft Entra 認證。 相反地，你需要使用 服務主體或 OpenID Connect 憑證。
以下指令會停用 App Service 主要網頁應用程式與暫存槽，以及待命網頁應用程式與暫存槽的基本認證。 請將以下 <placeholder> 參數值替換為你自己資源的資訊。
針對您的主要 Web 應用程式停用對實際執行網站和預備位置的 FTP 存取：
az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<web-app-name> --set properties.allow=false az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<web-app-name>/slots/stage --set properties.allow=false重新執行備援網頁應用程式的指令。
針對您的主要 Web 應用程式，停用對實際執行網站和預備位置的 WebDeploy 連接埠和 SCM 網站進行基本驗證存取：
az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<primary-web-app> --set properties.allow=false az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \ --parent sites/<primary-web-app>/slots/stage --set properties.allow=false重新執行備援網頁應用程式的指令。
關於停用基本認證的更多資訊，包括如何測試與監控登入，請參見 「在 App Service 部署中停用基本驗證」。
當停用基本認證時，建議使用持續佈署（Continuous Deployment）
如果你選擇在 App Service 應用程式上允許基本認證，你可以使用任何可用的部署方式。 例如，你可以使用你在 暫存時段 區段設定的發佈設定檔。
如果你停用了 App Service 應用程式的基本認證，持續部署就需要服務主體或 OpenID Connect 來進行認證。 如果您使用 GitHub Actions 做為程式碼存放庫，請參閱使用 GitHub Actions 部署至 Azure App 服務。 本教學課程提供逐步指示，引導您建立服務主體或 OpenID Connect，以便透過 GitHub Actions 將其部署至 App Service。 您也可以依照下一節的程序完成此流程。
使用 GitHub Actions 建立服務主體與憑證
用 GitHub Actions 和服務主體來配置持續部署：
建立你的主要網頁應用程式與備用網頁應用程式的 服務主體 ：
請將以下
<placeholder>參數值替換為你自己資源的資訊。az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \ /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \ /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>輸出是 JSON 物件，其中有角色指派認證可讓您存取 App Service 應用程式。
{ "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444", "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888", "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a", "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee", "activeDirectoryEndpointUrl": "https://login.microsoftonline.com", "resourceManagerEndpointUrl": "https://management.azure.com/", "activeDirectoryGraphResourceId": "https://graph.windows.net/", "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/", "galleryEndpointUrl": "https://gallery.azure.com/", "managementEndpointUrl": "https://management.core.windows.net/" }JSON 包含你的客戶端密鑰，僅在此時可見。
秘訣
給予最低存取權限是個好做法。 在這個例子中，範圍僅限於應用程式，而非整個資源群組。
複製 JSON 物件，這樣你就有客戶端秘密的紀錄。
將您的服務主體憑證提供給 Azure 登入 操作，作為 GitHub Action 工作流程的一部分。
你可以直接在工作流程中提供這些數值，或將它們儲存在 GitHub 秘密中，並在你的工作流程中被引用。 將這些值儲存為 GitHub 機密是更安全的選擇。
打開你的應用程式的 GitHub 倉庫。
請前往 設定>安全>秘密與變數>動作。
選擇 新儲存庫秘密 ，並為以下每個設定建立一個秘密。 用你的 JSON 輸出來取值。
設定 值 範例 AZURE_APP_ID <application/client-id>00001111-aaaa-2222-bbbb-3333cccc4444AZURE_PASSWORD <client-secret>ffffffff-5a5a-6b6b-7c7c-888888888888AZURE_TENANT_ID <tenant-id>aaaabbbb-6666-cccc-7777-dddd8888eeeeAZURE_SUBSCRIPTION_ID <subscription-id>cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a
建立 GitHub Actions 工作流程
當你有一個服務主體可以存取你的 App Service 應用程式後，編輯應用程式的預設工作流程。 這些工作流程在你設定持續部署時會自動產生。
驗證必須使用您的服務主體來完成，而非使用發佈設定檔。 如需範例工作流程，請參閱 Service principal 標籤中的 將工作流程檔案加入您的 GitHub 儲存庫。 以下範例工作流程可用於 Node.js 範例應用程式。
打開你的應用程式的 GitHub 倉庫。
移至
<repo-name>/.github/workflows/目錄。 您應該會看到自動產生的工作流程。對於每個工作流程檔案，選擇 「編輯 」（鉛筆）。
將工作流程檔案的內容替換為以下內容。 程式碼會假設您已建立認證的 GitHub 秘密。
在本
env區段中，請設定以下設定：-
AZURE_WEBAPP_NAME：將<web-app-name>佔位符替換為你的網路應用程式名稱。 -
NODE_VERSION： 指定要使用的節點版本。 對於 Node.js 樣本，值為'24.x'。 -
AZURE_WEBAPP_PACKAGE_PATH： 指定你的網頁應用程式專案的路徑。 預設為儲存庫根節點。'.' -
AZURE_WEBAPP_SLOT_NAME請說明你的申請名額名稱。 其通用名稱為stage。
name: Build and deploy Node.js app to Azure Web App on: push: branches: - main workflow_dispatch: env: AZURE_WEBAPP_NAME: <web-app-name> # Your application name NODE_VERSION: '24.x' # Node version to use AZURE_WEBAPP_PACKAGE_PATH: '.' # Path to your web app project AZURE_WEBAPP_SLOT_NAME: stage # Application slot name jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Node.js version uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} - name: npm install, build run: | npm install npm run build --if-present - name: Upload artifact for deployment job uses: actions/upload-artifact@v4 with: name: node-app path: . deploy: runs-on: ubuntu-latest needs: build environment: name: 'stage' url: ${{ steps.deploy-to-webapp.outputs.webapp-url }} steps: - name: Download artifact from build job uses: actions/download-artifact@v4 with: name: node-app - uses: azure/login@v2 with: creds: | { "clientId": "${{ secrets.AZURE_APP_ID }}", "clientSecret": "${{ secrets.AZURE_PASSWORD }}", "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}", "tenantId": "${{ secrets.AZURE_TENANT_ID }}" } - name: 'Deploy to Azure Web App' id: deploy-to-webapp uses: azure/webapps-deploy@v3 with: app-name: ${{ env.AZURE_WEBAPP_NAME }} slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }} package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }} - name: logout run: | az logout-
把工作流程檔案變更直接儲存並提交到你儲存庫的主分支。
提交會觸發 GitHub 動作再次執行並部署你的程式碼。 這次，服務主體名稱被用來驗證。
透過使用 slot 流量路由來測試應用程式更新
使用位置的流量路由可讓您將使用者流量預先定義的部分導向至每個位置。 一開始，100% 的流量會導向至生產網站。 不過，您可以將 10% 的流量傳送到預備位置。 這種路由位置流量的方法會自動將 10% 嘗試存取的使用者傳送至預備位置。 此方法不需要對您的 Azure Front Door 實例進行任何變更。 欲了解更多關於 App Service 中的槽位交換與暫存環境，請參閱 在 Azure App 服務 設定暫存環境。
將程式碼從暫存槽移到生產槽
在預備位置完成測試和驗證後，您就可以從預備位置執行目標為實際執行網站的位置交換。 完成每個區域中所有應用程式執行個體的交換。 在位置交換期間，App Service 平台可確保目標位置不會經歷停機。
執行主要 Web 應用程式的交換：
az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production替換你的 待機 網頁應用程式：
az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production幾分鐘後，進入 Azure 入口網站的 Azure Front Door 端點，確認插槽交換是否成功。
此時，您的應用程式已上線運作，且您對應用程式原始程式碼所做的任何變更都會自動觸發兩個預備位置的更新。 當您準備好將該程式代碼移至生產環境時，您可以重複位置交換程式。
透過多區域部署，避免中斷與連續性問題
您可以暫時從 Azure Front Door 來源群組中移除正在進行位置交換的網站，此舉可避免持續運作可能發生中斷或出現問題。 此舉有助於防止客戶同時看到不同版本的應用程式。 當你對應用程式做重大修改時，這也非常有用。 暫時移除會使所有流量重新導向另一個起點。
在 Azure 入口網站中，前往你的 Azure Front Door 實例。
在左側選單中，選擇 設定>起源群組。
在起源群組清單中，選擇包含你想暫時移除欄位的原始群組。
在 「更新來源」群組 面板中，找到要移除的欄位，從 「起源主機名稱 」清單中移除。
選擇 更多動作 （...） >刪除後，選擇 更新。
套用變更可能需要好幾分鐘。
當你準備好允許流量進入已移除的槽位時，回到 更新來源群組 窗格。
在最上方選擇 + 新增原點 ，將原點欄位重新加入原點群組。
建立額外的起點群組並更改路線關聯
如果您不想要刪除並再次加回來源，您可以為 Azure Front Door 執行個體建立額外的來源群組。 接著你可以將路線關聯到指向預期原點的原點群組。
例如，你可以建立兩個額外的起源群組，一個給你的主要（主動）區域，另一個給備用（被動）區域。 如果你的主要區域正在變動，請將該路由與你的待機區域關聯起來。 如果你的備用區域正在變動，請將該路由與你的主要區域關聯起來。 當所有變更都完成時，您可以將路由與包含這兩個區域的原始原始來源群組產生關聯。 這個方法可運作，因為路由一次只能與一個原始群組相關聯。
考慮一個包含三個原點群的配置：
- 該
Main-Origin群組包含主要與待命網頁應用程式，各自位於各自區域。 - 該
Primary-Origin群組僅包含活躍區域的主要網頁應用程式。 -
Standby-Origin該群組僅包含被動區域的備用網頁應用程式。
假設主要的網頁應用程式正在進行變更。 在變更開始前，Main-Origin 群組的路線關聯會改為 Secondary-Origin 群組。 此動作確保所有流量會流向其區域內的待機網頁應用程式，而主要網頁應用程式在該區域內則正在進行變更。
請依照以下步驟更改原點群組的路線關聯：
在 Azure 入口網站中，前往你的 Azure Front Door 實例。
在左側選單中，選擇 設定>起源群組。
在起點群組清單中，找到一個在路線欄位顯示非關聯指示器的起點群組。
選擇 更多動作 （...） >關聯端點與路由。
在 「關聯路由 」面板中，選擇一個或多個路由與原始群組關聯，然後選擇 「關聯」。
限制存取進階工具網站
使用 Azure App 服務時，SCM/進階工具網站用來管理你的應用程式並部署應用程式原始碼。 請考慮鎖定 SCM/進階工具網站，因為此網站很可能不需要透過 Front Door 連線。 例如，只允許您進行測試，並從您選擇的工具啟用持續部署，您可以設定存取限制。 如果您使用部署位置，特別是針對生產位置，您可以拒絕幾乎所有 SCM 網站的存取權，因為您的測試和驗證是使用預備位置完成的。