Share via


教學課程:在 Azure App Service 中建立高可用性的多區域應用程式

高可用性和容錯是架構完善的解決方案的重要元件。 最好讓緊急方案縮短停機時間,並在發生問題時自動啟動並執行系統,為意外狀況做好準備。

當您將應用程式部署至雲端時,請選擇位於應用程式基礎結構所在雲端中的區域。 如果您的應用程式已部署到單一區域,區域會變得無法使用,您的應用程式也將無法使用。 缺乏可用性可能導致您應用程式的 SLA 條款無法接受這種情況。 若是如此,在多個區域中部署您的應用程式及其服務會是個不錯的解決方案。

在本教學課程中,您將了解如何部署高可用性的多區域 Web 應用程式。 將應用程式元件侷限為 Web 應用程式,並 Azure Front Door,讓此案例保持簡單,但概念可以擴充並套用至其他基礎結構模式。 例如,如果您的應用程式連線到 Azure 資料庫供應項目或儲存體帳戶,請參閱 SQL 資料庫的作用中異地復寫,以及儲存體帳戶的備援選項。 如需更詳盡參考架構的情況,請參閱高可用性多區域 Web 應用程式

下列架構圖顯示您在本教學課程中建立的基礎結構。 這是由不同區域中的兩個相同 App Service 所組成,一個是使用中或主要區域,另一個是待命或次要區域。 Azure Front Door 可用來將流量路由傳送至 App Service,並設定存取限制,以便封鎖從因特網直接存取應用程式。 虛線表示只有在作用中區域關閉時,才會將流量傳送到待命區域。

Azure 提供各種負載平衡和流量路由選項。 已針對此使用案例選取 Azure Front Door,因為這牽涉到裝載於多個區域中 Azure App Service 上的網際網路面向 Web 應用程式。 若要協助您決定與本教學課程不同的使用案例,請參閱 Azure 中負載平衡的決策樹

Architecture diagram of a multi-region App Service.

透過此結構:

  • 相同的 App Service 應用程式會部署在兩個不同區域。
  • 直接流入 App Service 應用程式的公用流量遭到封鎖。
  • Azure Front Door 會使用將流量路由傳送至主要/使用中區域。 次要區域具有 App Service,其中已啟動並執行,並已準備好在需要時提供流量。

您將學到什麼:

  • 在不同的區域中建立相同的。
  • 建立 Azure Front Door,其存取限制會封鎖對 App Service 的公用存取。

必要條件

如果您沒有 Azure 訂用帳戶,請在開始之前先建立 Azure 免費帳戶

完成本教學課程:

建立 Web 應用程式的兩個執行個體

本快速入門需要兩個 Web 應用程式執行個體,分別在不同的 Azure 區域中執行。 您可以使用區域組美國東部/美國西部作為兩個區域,並建立兩個空的 Web 應用程式。 若有需要,可以選擇自己的區域。

為了簡化管理和清除作業,您在本教學課程中會針對所有資源使用單一資源群組。 請考慮針對每個區域/資源使用不同的資源群組,以在災害復原情況下進一步隔離您的資源。

執行下列命令以建立您的資源群組。

az group create --name myresourcegroup --location eastus

建立 App Service 方案

如請執行下列命令來建立 App Service 方案。 將 <app-service-plan-east-us><app-service-plan-west-us> 預留位置取代為兩個唯一名稱,您可以在其中輕鬆識別其所在區域。

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

建立 Web 應用程式

建立 App Service 方案之後,請執行下列命令來建立 Web 應用程式。 將 <web-app-east-us><web-app-west-us> 的預留位置取代為兩個全域唯一名稱 (有效字元為 a-z0-9-),請務必注意 --plan 參數,以便您將一個應用程式放在每個方案中 (因此在每個區域中)。 將 <runtime> 參數取代為應用程式的語言版本。 針對可用執行階段的清單執行 az webapp list-runtimes。 如果您打算使用本教學課程中提供的範例 Node.js 應用程式,請使用 NODE:18-lts 作為您的執行階段。

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

記下每個 Web 應用程式的預設主機名稱,讓您可以在下一個步驟中部署 Front Door 時定義後端位址。 其格式應該是 <web-app-name>.azurewebsites.net。 執行下列命令或瀏覽至 Azure 入口網站中應用程式 [概觀] 頁面,即可找到這些主機名。

az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"

建立 Azure Front Door

多區域部署都可以作為主動/主動或主動/被動設定使用。 主動-主動設定會將要求分散到多個作用中區域。 主動-被動設定會讓執行中的執行個體繼續在次要區域中執行,但除非主要區域失敗,否則不會將流量傳送至該處。 Azure Front Door 具有內建功能,可讓您啟用這些設定。 如需設計高可用性和容錯應用程式的詳細資訊,請參閱建構 Azure 應用程式以進行復原和可用性

建立 Azure Front Door 設定檔

您現在會建立 Azure Front Door 進階版,將流量路由傳送至您的應用程式。

執行 az afd profile create 建立 Azure Front Door 設定檔。

注意

如果您想要部署 Azure Front Door 標準版而非進階版,請將 --sku 參數的值取代為 Standard_AzureFrontDoor。 如果您選擇 [標準層],將無法使用 WAF 原則部署受控規則。 如需定價層的詳細比較,請參閱 Azure Front Door 層比較

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
參數 數值 Description
profile-name myfrontdoorprofile Azure Front Door 設定檔的名稱,這是資源群組內唯一的名稱。
resource-group myresourcegroup 包含此教學課程資源的資源群組。
sku Premium_AzureFrontDoor Azure Front Door 設定檔的定價層。

新增端點

執行 az afd endpoint create,以在設定檔中建立端點。 完成建立體驗後,即可在設定檔中建立多個端點。

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
參數 數值 Description
endpoint-name myendpoint 設定檔下端點的名稱,這是全域唯一的。
enabled-state Enabled 是否啟用此端點。

新增來源群組

執行 az afd origin-group create 新增包含兩個 Web 應用程式的原點群組。

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
參數 數值 Description
origin-group-name myorigingroup 原始群組的名稱。
probe-request-type GET 所發出的健康狀態探查要求類型。
probe-protocol Http 用於健康狀態探查的通訊協定。
probe-interval-in-seconds 60 健康狀態探查的間隔秒數。
probe-path / 相對於來源的路徑,用來判斷來源的健康狀態。
sample-size 4 要針對負載平衡決策進行考量的樣本數。
successful-samples-required 3 取樣期間必須成功的樣本數。
additional-latency-in-milliseconds 50 以毫秒為單位的額外延遲,以使探查落入最低的延遲貯體。

將來源新增至群組

執行 az afd origin create,將來源新增至原始來源群組。 針對 --host-name 參數,請將 <web-app-east-us> 的預留位置取代為該區域中的應用程式名稱。 請注意,--priority 參數設定為 1,表示所有流量都會傳送至您的主要應用程式。

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
參數 數值 Description
host-name <web-app-east-us>.azurewebsites.net 主要 Web 應用程式的主機名。
origin-name primaryapp 原始的名稱。
origin-host-header <web-app-east-us>.azurewebsites.net 要傳送要求至此來源的主機標頭。 如果您將此保留空白,要求主機名會決定此值。 Azure CDN 來源,例如 Web Apps、Blob 儲存體和雲端服務,預設會要求此主機標頭值符合原始主機名。
priority 1 將此參數設定為 1,將所有流量導向至主要 Web 應用程式。
weight 1000 給定來源群組中用於負載平衡的來源權數。 必須介於 1 到 1000 之間。
enabled-state Enabled 是否啟用此原點。
http-port 80 用於來源 HTTP 要求的連接埠。
https-port 443 用於來源 HTTPS 要求的連接埠。

重複此步驟,來新增第二個來源。 請注意 --priority 參數。 針對這個來源,這會設定為 2。 此優先順序設定會指示 Azure Front Door 將所有流量導向主要來源,除非主要流量關閉。 如果您將此來源的優先順序設定為 1,Azure Front Door 會將這兩個來源視為作用中,並將流量導向這兩個區域。 請務必將 <web-app-west-us> 的這兩個預留位置執行個體取代為該 Web 應用程式的名稱。

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

新增路由

執行 az afd route create,將您的端點對應至原始群組。 此路由會將要求從端點轉送至來源群組。

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled 
參數 數值 Description
endpoint-name myendpoint 端點的名稱。
forwarding-protocol MatchRequest 此規則在將流量轉送至後端時所使用的通訊協定。
route-name route 路由的名稱。
https-redirect Enabled 是否要自動將 HTTP 流量重新導向至 HTTPS 流量。
supported-protocols Http Https 此路由支援通訊協定的清單。
link-to-default-domain Enabled 此路由是否連結至預設端點網域。

允許此步驟完成約 15 分鐘,因為此變更需要一些時間才能全域傳播。 在此期間之後,您的 Azure Front Door 將會正常運作。

限制 Web 應用程式對 Azure Front Door 執行個體的存取權

此時,您仍然可以直接使用其 URL 來存取您的應用程式。 為了確保流量只能透過 Azure Front Door 連線到您的應用程式,您可以針對每個應用程式設定存取限制。 Front Door 的功能在流量僅流經 Front Door 時的效果最佳。 您應該將來源設定為封鎖尚未透過 Front Door 傳送的流量。 否則,流量可能會略過 Front Door 的 Web 應用程式防火牆、DDoS 保護及其他安全性功能。 從 Azure Front Door 到應用程式的流量源自一組已知毒 IP 範圍 (在 AzureFrontDoor.Backend 服務標籤中定義)。 使用服務標籤限制規則時可讓流量僅限來自 Azure Front Door

設定 App Service 存取限制之前,請執行下列命令來記下 Front Door 識別碼。 需要此識別碼,以確保流量僅源自您的特定 Front Door 執行個體。 存取限制會根據 Azure Front Door 傳送的唯一 HTTP 標頭進一步篩選傳入要求。

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

執行下列命令來設定 Web 應用程式的存取限制。 將 <front-door-id> 預留位置取代為上一個命令的結果。 取代應用程式名稱的預留位置。

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

測試 Front Door

建立 Azure Front Door 標準/進階版設定檔時,全域性部署組態需要幾分鐘的時間。 完成後,即可存取所建立的前端主機。

執行 az afd endpoint show 以取得 Front Door 端點的主機名稱。

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

在瀏覽器中,移至上一個命令傳回的端點主機名:<myendpoint>-<hash>.z01.azurefd.net。 您的要求應該會自動路由至美國東部的主要應用程式。

若要測試立即全域故障轉移:

  1. 開啟瀏覽器,移至端點主機名稱:<myendpoint>-<hash>.z01.azurefd.net

  2. 執行 az webapp stop 停止主要應用程式。

    az webapp stop --name <web-app-east-us> --resource-group myresourcegroup
    
  3. 重新整理您的瀏覽器。 您應該會看到相同的資訊頁面,因為流量現在已導向美國西部的執行中應用程式。

    提示

    您可能需要多次重新整理頁面,才能完成故障轉移。

  4. 現在要停止次要應用程式。

    az webapp stop --name <web-app-west-us> --resource-group myresourcegroup
    
  5. 重新整理您的瀏覽器。 此時,您應該會看到一則錯誤訊息。

    Screenshot of the message: Both instances of the web app stopped.

  6. 執行 az webapp start 以重新啟動其中一個 Web 應用程式。 重新整理瀏覽器,您應該會再次看到應用程式。

    az webapp start --name <web-app-east-us> --resource-group myresourcegroup
    

您現在已驗證您可以透過 Azure Front Door 存取您的應用程式,以及如預期般運作的故障轉移功能。 如果您已完成故障轉移測試,請重新啟動其他應用程式。

若要測試您的存取限制,並確保您的應用程式只能透過 Azure Front Door 連線,請開啟瀏覽器並瀏覽至每個應用程式的 URL。 若要找到 URL,請執行下列命令:

az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"

az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"

您應該會看到錯誤頁面,指出無法存取應用程式。

清除資源

在上述步驟中,您已建立資源群組中的 Azure 資源。 如果您在未來不需要這些資源,請在 Cloud Shell 中執行下列命令,以刪除資源群組。

az group delete --name myresourcegroup

執行此命令可能需要幾分鐘的時間。

從 ARM/Bicep 部署

您可以使用 ARM/Bicep 範本來部署您在本教學課程中建立的資源。 高可用性多區域 Web 應用程式 Bicep 範本可讓您在 Azure Front Door 後方的不同區域中建立安全、高可用性、多區域端對端解決方案。

若要了解如何部署 ARM/Bicep 範本,請參閱如何使用 Bicep 和 Azure CLI 部署資源

常見問題集

在本教學課程中,您已部署基準基礎結構,以啟用多區域 Web 應用程式。 App Service 提供的功能可協助您確保執行應用程式符合安全性最佳做法和建議。

本節包含常見問題,可協助您進一步保護您的應用程式,並使用最佳做法部署和管理資源。

在本教學課程中,您已使用 Azure CLI 來部署基礎結構資源。 請考慮設定持續部署機制來管理應用程式基礎結構。 由於您要在不同區域中部署資源,因此您必須跨區域獨立管理這些資源。 為了確保每個區域的資源都相同,基礎結構即程序代碼 (IaC),例如 Azure Resource Manager 範本Terraform,應該與部署管線搭配使用,例如 Azure PipelinesGitHub Actions。 如此一來,如果適當地設定,資源的任何變更都會觸發您部署至之所有區域的更新。 如需詳細資訊,請參閱持續部署至 Azure App Service

如何使用預備位置來練習安全部署至生產環境?

不建議將應用程式程式代碼直接部署到生產應用程式/插槽。 這是因為您想要有一個安全的地方來測試您的應用程式,並在推送至生產環境之前驗證所做的變更。 使用預備位置與位置交換的組合,將程式代碼從測試環境移至生產環境。

您已為此情節建立基準基礎結構。 現在,您會為應用程式的每個執行個體建立部署位置,並使用 GitHub Actions 設定對這些預備位置的持續部署。 如同基礎結構管理,也建議為應用程式原始碼設定持續部署,以確保跨區域變更同步。如果您未設定持續部署,每次變更程式碼時,都必須手動更新每個區域中的每個應用程式。

針對本教學課程中其餘的步驟,您應該已準備好將應用程式部署至您的 App Service。 如果您需要範例應用程式,您可以使用 Node.js Hello World 範例應用程式。 派生該存放庫,以便擁有自己的複本。

請務必為您的應用程式設定 App Service 堆疊設定。 堆疊設定是指應用程式所使用的語言或運執行階段。 您可以使用 Azure CLI 搭配 az webapp config set 命令或在入口網站中使用下列步驟來設定此設定。 如果您使用 Node.js 範例,請將堆疊設定設為 Node 18 LTS

  1. 移至您的應用程式,然後選取左側目錄中組態
  2. 選取一般設定索引標籤。
  3. 在 [堆疊設定] 底下,為您的應用程式選擇適當的值。
  4. 選取 [儲存],然後選取 [繼續] 以確認更新。
  5. 針對其他應用程式重複這些步驟。

執行下列命令,為每個應用程式建立稱為「階段」的預備位置。 將 <web-app-east-us><web-app-west-us> 預留位置取代您應用程式名稱。

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>

若要設定持續部署,您應該使用 Azure 入口網站。 如需如何使用 GitHub Actions 等提供者設定持續部署的詳細指引,請參閱持續部署至 Azure App Service

若要使用 GitHub Actions 設定持續部署,請針對每個預備位置完成下列步驟。

  1. Azure 入口網站中,移至其中一個 App Service 應用程式插槽的管理頁面。

  2. 在左窗格中,選取 [部署中心]。 然後,選取 [設定]

  3. 在 [來源] 方塊中,選取其中 CI/CD 選項的「GitHub」:

    Screenshot that shows how to choose the deployment source

  4. 如果您是第一次從 GitHub 進行部署,請選取 [授權],然後遵循授權提示。 如果您想要從不同的使用者存放庫進行部署,請選取 [變更帳戶]

  5. 在您使用 GitHub 授權 Azure 帳戶之後,請選取要針對其設定 CI/CD的 [組織]、[存放庫] 和 [分支]。 如果找不到組織或存放庫,您可能需要在 GitHub 上啟用更多的權限。 如需詳細資訊,請參閱管理組織存放庫的存取權

    1. 如果您使用 Node.js 範例應用程式,請使用下列設定。

      設定
      組織 <your-GitHub-organization>
      存放庫 nodejs-docs-hello-world
      分行 main
  6. 選取 [儲存]。

    所選存放庫和分支中的新認可,現在會持續部署到 App Service 應用程式插槽。 您可以在 [記錄] 索引標籤上追蹤認可和部署。

使用發佈設定檔向 App Service 驗證的預設工作流程檔案會新增至您的 GitHub 存放庫。 您可以移至 <repo-name>/.github/workflows/ 目錄來檢視此檔案。

如何在 App Service 中停用基本驗證?

請考慮停用基本身份驗證,這會限制對 Microsoft Entra ID 所支援之使用者的 FTP 和 SCM 端點存取。 如果使用持續部署工具來部署應用程式原始碼,停用基本身份驗證需要額外的步驟來設定持續部署。 例如,您無法使用發行設定檔,因為這不使用 Microsoft Entra 認證。 相反地,您必須使用服務主體或 OpenID Connect

若要停用 App Service 的基本身份驗證,請以您的應用程式名稱取代 <web-app-east-us><web-app-west-us> 的預留位置,針對每個應用程式和位置執行下列命令。 第一組命令會停用生產網站和預備位置的 FTP 存取,而第二組命令會停用生產網站和預備位置的 WebDeploy 連接埠和 SCM 網站的基本驗證存取。

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

如需停用基本身份驗證的詳細資訊,包括如何測試和監視登入,請參閱停用 App Service 部署中的基本身份驗證

如果我停用基本身份驗證,該如何部署使用持續部署的程序代碼?

如果您選擇在 App Service 應用程式上允許基本身份驗證,您可以在 App Service 上使用任何可用的部署方法,包括使用預備位置區段中設定的發行設定檔。

如果您停用 App Service 的基本驗證,持續部署需要服務主體或 OpenID Connect 來進行驗證。 如果您使用 GitHub Actions 作為程式代碼存放庫,請參閱使用服務主體或 OpenID Connect 使用 GitHub Actions 部署至 App Service 的逐步教學課程,或完成下一節中的步驟。

使用 GitHub Actions 建立服務主體並設定認證

若要使用 GitHub Actions 設定持續部署和服務主體,請使用下列步驟。

  1. 執行下列命令來建立服務主體。 將預留位置取代為您的 <subscription-id> 和應用程式名稱。 輸出是 JSON 物件,其中有角色指派認證可讓您存取 App Service 應用程式。 複製此 JSON 物件以供後續步驟使用。 這包含您的用戶端密碼,只有目前會顯示此密碼。 最佳做法為一律只授與最低存取權。 此範例中的範圍僅限於應用程式,而非整個資源群組。

    az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth
    
  2. 您必須將服務主體的認證提供給 Azure/login 動作,作為您使用之 GitHub Action 工作流程的一部分。 這些值可以直接在工作流程中提供,也可以儲存在 GitHub 的秘密中,並在您的工作流程中參考。 將值儲存為 GitHub 秘密是較安全的選擇。

    1. 開啟您的 GitHub 存放庫,並移至 [設定]>[安全性]>[祕密和變數]>[動作]

    2. 選取 [新增存放庫密碼],然後為每個下列值建立祕密。 您可以在您稍早複製的 json 輸出中找到這些值。

      名稱
      AZURE_APP_ID <application/client-id>
      AZURE_PASSWORD <client-secret>
      AZURE_TENANT_ID <tenant-id>
      AZURE_SUBSCRIPTION_ID <subscription-id>

建立 GitHub Actions 工作流程

既然您有可存取 App Service 應用程式的服務主體,請編輯在您設定持續部署時為應用程式建立的預設工作流程。 驗證必須使用您的服務主體,而不是發佈設定檔來完成。 如需範例工作流程,請參閱將工作流程檔案新增至 GitHub 存放庫中的「服務主體」索引標籤。 下列範例工作流程可用於提供的 Node.js 範例應用程式。

  1. 開啟應用程式的 GitHub 存放庫,並移至 <repo-name>/.github/workflows/ 目錄。 您應該會看到自動產生的工作流程。

  2. 針對每個工作流程檔案,選取右上方的「鉛筆」按鈕以編輯檔案。 將內容取代為下列文字,假設您稍早已為認證建立 GitHub 祕密。 更新「env」區段下 <web-app-name> 的預留位置,然後直接認可至主要分支。 此認可會觸發 GitHub Action 再次執行並部署您的程式代碼,這次會使用服務主體進行驗證。

    
    name: Build and deploy Node.js app to Azure Web App
    
    on:
      push:
        branches:
          - main
      workflow_dispatch:
    
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
      NODE_VERSION: '18.x'                # set this to the node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
      AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name
    
    jobs:
      build:
        runs-on: ubuntu-latest
    
        steps:
          - uses: actions/checkout@v2
    
          - name: Set up Node.js version
            uses: actions/setup-node@v1
            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@v2
            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@v2
            with:
              name: node-app
    
          - uses: azure/login@v1
            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@v2
            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
    

插槽流量路由如何允許我測試對應用程式所做的更新?

使用位置的流量路由可讓您將使用者流量預先定義的部分導向至每個位置。 一開始,100% 的流量會導向至生產網站。 不過,您有能力將 10% 的流量傳送到預備位置。 如果您以這種方式設定位置流量路由,當使用者嘗試存取您的應用程式時,其中 10% 會自動路由至預備位置,而不會變更您的 Front Door 執行個體。 若要深入了解插槽交換和 App Service 中的預備環境,請參閱在 Azure App Service 中設定預備環境

如何將程式代碼從預備位置移至生產位置?

在預備位置中測試並驗證之後,您就可以執行從預備位置到生產網站的位置交換。 您必須針對每個區域中應用程式的所有執行個體執行此交換。 在位置交換期間,App Service 平台可確保目標位置不會經歷停機

若要執行交換,請針對每個應用程式執行下列命令。 取代 <web-app-name> 的預留位置。

az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production

幾分鐘后,您可以導覽至 Front Door 的端點,以驗證位置交換成功。

此時,您的應用程式已啟動並執行,而且您對應用程式原始程式碼所做的任何變更都會自動觸發兩個預備位置的更新。 當您準備好將該程式代碼移至生產環境時,您可以重複位置交換程式。

如何在多區域部署中使用 Azure Front Door?

如果您擔心跨區域的潛在中斷或持續性問題,例如某些客戶看到某個版本的應用程式,而另一個版本則看到另一個版本,或如果您對應用程式進行重大變更,您可以暫時移除從 Front Door 來源群組進行位置交換的網站。 然後,所有流量都會導向至其他來源。 導覽至 [更新來源群組] 窗格,然後 [刪除] 進行變更的來源。 完成所有變更並準備好再次提供流量之後,您就可以返回相同的窗格,然後選取 [ + 新增來源] 讀取來源。

Screenshot showing how to remove an Azure Front Door origin.

如果您想要不要刪除和讀取的來源,您可以為您的 Front Door 執行個體建立額外的原始來源群組。 然後,您可以將路由與指向預定來源的來源群組產生關聯。 例如,您可以建立兩個新的原始來源群組,一個用於主要區域,另一個用於次要區域。 當您的主要區域正在進行變更時,請將路由與您的次要區域產生關聯,當您的次要區域正在進行變更時也是。 當所有變更都完成時,您可以將路由與包含這兩個區域的原始原始來源群組產生關聯。 這個方法可運作,因為路由一次只能與一個原始群組相關聯。

為了示範使用多個原始來源,在下列螢幕快照中有三個原始群組。 「MyOriginGroup」包含兩個 Web 應用程式,而其他兩個原始群組則分別由各自區域中的 Web 應用程式所組成。 在此範例中,主要區域中的應用程式正在進行變更。 在開始該變更之前,路由會與「MySecondaryRegion」相關聯,因此所有流量都會在變更期間傳送至次要區域中的應用程式。 您可以選取 [未關聯的] 來更新路由,這會 [關聯路由] 窗格。

Screenshot showing how to associate routes with Azure Front Door.

如何限制進階工具網站的存取?

使用 Azure App Service 時,SCM/進階工具網站會用來管理您的應用程式及部署應用程式原始碼。 請考慮鎖定 SCM/進階工具網站,因為此網站很可能不需要透過 Front Door 連線。 例如,只允許您進行測試,並從您選擇的工具啟用持續部署,您可以設定存取限制。 如果您使用部署位置,特別是針對生產位置,您可以拒絕幾乎所有 SCM 網站的存取權,因為您的測試和驗證是使用預備位置完成的。

下一步