此參考架構示範使用 App Service 環境 第 3 版的常見企業工作負載。 它也會說明加強工作負載安全性的最佳做法。
注意
App Service 環境 第 3 版是此架構的主要元件。 第 3 版現已推出。 版本 1 和 2 將于 2024 年 8 月 31 日淘汰。
GitHub 上 提供此架構的參考實作。
架構
工作流程
App Service 環境第 3 版提供與舊版不同的功能，以及這些版本的優點。 如需詳細資訊，請參閱 功能差異 。 您可以透過兩種方式部署App Service 環境：
- 作為具有公用 IP 位址的外部App Service 環境
- 作為內部App Service 環境，其內部 IP 位址屬於內部負載平衡器 （ILB）
此參考架構會在內部App Service 環境中部署企業 Web 應用程式，也稱為 ILB App Service 環境。 當您的案例要求您執行下列作業時，請使用 ILB App Service 環境：
- 裝載雲端安全性增強的內部網路應用程式，並透過站對站 VPN 或 Azure ExpressRoute 加以存取。
- 使用 Web 應用程式防火牆 （WAF） 為應用程式提供一層保護。
- 在未列于公用 DNS 伺服器的雲端中裝載應用程式。
- 建立網際網路隔離的後端應用程式，您的前端應用程式可以透過高度安全的方式與它整合。
App Service 環境必須一律部署在企業虛擬網路中自己的子網，以嚴格控制傳入和傳出流量。 在此子網中，App Service 應用程式會部署在一或多個 App Service 方案中 ，這是執行應用程式所需的實體資源集合。 視複雜度和資源需求而定，App Service 方案可以在多個應用程式之間共用。 此參考實作會部署名為 Voting App 的 Web 應用程式 ，其會與私人 Web API 和函式互動。 它也會部署名為 Test App 的虛擬 Web 應用程式 ，以示範多應用程式部署。 每個 App Service 應用程式都會裝載在其自己的 App Service 方案中，並視需要個別調整每個應用程式。 這些裝載應用程式所需的所有資源，例如儲存體和計算，以及調整需求，都完全由App Service 環境基礎結構管理。
此實作中的簡單投票應用程式可讓使用者檢視現有的專案、建立新專案，以及投票處理現有的專案。 Web API 用於建立和擷取專案和投票。 資料本身會儲存在 SQL Server 資料庫中。 為了示範非同步資料更新，Web 應用程式會在 服務匯流排 實例中排入新加入的投票佇列。 函式會挑選佇列投票並更新 SQL 資料庫。 Azure Cosmos DB 用來儲存模擬廣告，Web 應用程式會擷取以在瀏覽器上顯示。 應用程式會使用 Azure Cache for Redis 進行快取管理。 系統會使用進階版層 Azure Cache for Redis，其允許在自己的子網中設定與App Service 環境相同的虛擬網路。 這會為快取提供增強的安全性和隔離。
Web 應用程式是唯一可透過應用程式閘道存取網際網路的元件。 API 和函式無法從網際網路用戶端存取。 輸入流量會受到在 應用程式閘道 上設定的 WAF 保護。
元件
下列服務是鎖定此架構中App Service 環境的關鍵：
Azure 虛擬網絡 是企業所擁有的私人 Azure 雲端網路。 它提供增強的網路型安全性和隔離。 App Service 環境是 App Service 部署至企業擁有虛擬網路的子網。 它可讓企業使用網路安全性群組和私人端點，嚴格控制該網路空間及其存取的資源。
應用程式閘道 是具有 TLS/SSL 卸載和 WAF 的應用程式層級 Web 流量負載平衡器。 它會接聽公用 IP 位址，並將流量路由傳送至 ILB App Service 環境中的應用程式端點。 由於這是應用層級路由，因此可以將流量路由傳送至相同 ILB App Service 環境內的多個應用程式。 如需詳細資訊，請參閱 應用程式閘道多個網站裝載 。
Azure 防火牆 用來限制來自 Web 應用程式的輸出流量。 不會通過私人端點通道和App Service 環境所需路由表的傳出流量會導向至防火牆子網。 為了簡單起見，此架構會設定服務子網上的所有私人端點。
Microsoft Entra ID 或 Microsoft Entra ID 提供 Azure 資源和服務的存取權限和版權管理。 受控識別 會將身分識別指派給服務與應用程式，由 Microsoft Entra ID 自動管理。 這些身分識別可用來向任何支援 Microsoft Entra 驗證的服務進行驗證。 這樣就不需要明確設定這些應用程式的認證。 此架構會將受控識別指派給 Web 應用程式。
Azure 金鑰保存庫 會儲存應用程式所需的任何秘密和認證。 在應用程式中直接儲存秘密時，請使用此選項。
GitHub Actions 在此架構中提供持續整合和持續部署功能。 由於App Service 環境位於虛擬網路中，因此虛擬機器會作為虛擬網路內的 jumpbox，以在 App Service 方案中部署應用程式。 動作會建置虛擬網路外部的應用程式。 如需增強的安全性和順暢的 RDP/SSH 連線能力，請考慮使用 Azure Bastion 作為 jumpbox。
多月臺設定
內部App Service 環境可以裝載數個具有 HTTP 端點的 Web 應用程式和 API。 這些應用程式會從公用網際網路鎖定，因為 ILB IP 只能從虛擬網絡記憶體取。 應用程式閘道可用來選擇性地將這些應用程式公開至網際網路。 App Service 環境將預設 URL 指派給每個 App Service 應用程式作為 <default-appName>.<app-service-environment-domain>.appserviceenvironment.net 。 系統會 建立私人 DNS 區域 ，將App Service 環境功能變數名稱對應至 App Service 環境 ILB IP 位址。 這可避免使用自訂 DNS 來存取虛擬網路內的應用程式。
應用程式閘道已設定為接 聽程式 接聽 HTTPS 埠，以取得閘道 IP 位址的要求。 為了簡單起見，此實作不會使用公用 DNS 名稱註冊。 您必須修改電腦上的 localhost 檔案，以將任意選擇的 URL 指向應用程式閘道 IP。 為了簡單起見，接聽程式會使用自我簽署憑證來處理這些要求。 應用程式閘道每個 App Service 應用程式的預設 URL 都有 後端集 區。 路由規則 已設定為將接聽程式連線到後端集區。 系統會建立 HTTP 設定 ，以判斷閘道與App Service 環境之間的連線是否會加密。 這些設定也可用來覆寫從後端集區挑選的主機名稱來覆寫傳入的 HTTP 主機標頭。 此實作會使用針對閘道信任的預設App Service 環境應用程式 URL 所建立的預設憑證。 要求會重新導向至對應應用程式的預設 URL。 連結至虛擬網路 的私人 DNS 會將此要求轉送至 ILB IP。 App Service 環境接著將此轉送至要求的應用程式服務。 App Service 環境應用程式中的任何 HTTP 通訊都會通過私人 DNS。 請注意，每個App Service 環境應用程式的應用程式閘道上都必須設定接聽程式、後端集區、路由規則和 HTTP 設定。
檢閱 appgw.bicep 和 dns.bicep ，以瞭解如何進行這些設定以允許多個網站。 名為 testapp 的 Web 應用程式是建立來示範此設定的空白應用程式。 您可以從部署腳本 commands_std.azcli 存取這些 JSON 檔案。 commands_ha.azcli 也會存取 這些專案，用於 高可用性多月臺App Service 環境部署 。
案例詳細資料
Azure App 服務 是 PaaS 服務，可用來在 Azure 上裝載各種應用程式：Web 應用程式、API 應用程式、函式和行動應用程式。 App Service 環境 可讓企業將其 App Service 應用程式部署在自己的 Azure 虛擬網絡 子網中，為雲端工作負載提供隔離、高度可調整且專用的環境。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
App Service 環境
內部App Service 環境會部署在企業虛擬網路中，從公用網際網路隱藏。 它可讓企業鎖定其後端服務，例如網路層級的 Web API 和函式。 任何具有 HTTP 端點的App Service 環境應用程式，都可以從虛擬網路內的 ILB 存取。 應用程式閘道設定為透過 ILB 將要求轉送至 Web 應用程式。 Web 應用程式本身會透過 ILB 來存取 API。 重要的後端元件，也就是 API 和函式，實際上無法從公用網際網路存取。
預設憑證會針對App Service 環境指派的預設功能變數名稱，為每個應用程式服務建立。 此憑證可以加強閘道與應用程式之間流量的安全性，而且在某些情況下可能需要此憑證。 這些憑證無法透過用戶端瀏覽器顯示。 它只能回應應用程式閘道上設定的憑證。
應用程式閘道
參考實作會以程式設計方式在 appgw.bicep 中 設定應用程式閘道。 部署閘道時，commands_std.azcli 檔案 會使用此組態：
az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)
加密
如使用 應用程式閘道 的 TLS 終止和端對端 TLS 概觀中所述 ，應用程式閘道可以使用傳輸層安全性 （TLS）/安全通訊端層 （SSL） 來加密和保護來自網頁瀏覽器的所有流量。 加密可以透過下列方式進行設定：
加密在閘道 終止。 在此情況下，後端集區已針對 HTTP 進行設定。 加密會在閘道停止，且閘道與 App Service 之間的流量未加密。 由於加密需要大量 CPU，因此後端的未加密流量可改善效能，並允許更簡單的憑證管理。 這可提供合理的安全性層級，因為後端會受到網路設定保護。
端對端加密 。 在某些情況下，例如特定的安全性或合規性需求，可能需要在閘道與應用程式之間加密流量。 這可透過使用 HTTPS 連線，並在後端集區設定憑證來達成。
此參考實作會使用自我簽署憑證進行應用程式閘道。 針對生產程式碼，應該使用憑證授權單位單位所簽發的憑證。 如需支援的憑證類型清單，請參閱 TLS 終止 支援的憑證。 請參閱 使用 Azure 入口網站 設定具有 TLS 終止的應用程式閘道，以瞭解如何建立閘道終止加密。 appgw.bicep 中的下列幾行程式碼會以程式設計方式設定：
httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
frontendIPConfiguration: {
id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
}
frontendPort: {
id: '${appgwId}/frontendPorts/port_443'
}
protocol: 'Https'
sslCertificate: {
id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
}
hostName: item.hostName
requireServerNameIndication: true
}
}]
參考實作示範應用程式閘道與App Service 環境上 Web 應用程式之間的流量端對端加密。 會使用預設 SSL 憑證。 此實作中的後端集區會設定為重新導向 HTTPS 流量，且主機名稱已由與 Web 應用程式相關聯的預設功能變數名稱覆寫。 應用程式閘道信任預設 SSL 憑證，因為它們是由 Microsoft 發行。 如需如何進行這些設定的詳細資訊，請參閱 使用 應用程式閘道 設定 App Service。 來自 appgw.bicep 的下列程式碼示範如何在參考實作中設定：
backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
port: 443
protocol: 'Https'
cookieBasedAffinity: 'Disabled'
pickHostNameFromBackendAddress: true
requestTimeout: 20
probe: {
id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
}
}
}]
Web 應用程式防火牆
應用程式閘道上的 Web 應用程式防火牆 （WAF） 可保護 Web 應用程式免于遭受惡意攻擊，例如 SQL 插入式攻擊。 它也會與 Azure 監視器整合，以使用即時記錄來監視攻擊。 必須在閘道上啟用 WAF，如使用 Azure 入口網站 建立具有Web 應用程式防火牆的應用程式閘道中所述 。 參考實作會在 appgw.bicep 檔案中使用下列程式碼片段，以程式設計方式啟用 WAF：
webApplicationFirewallConfiguration: {
enabled: true
firewallMode: 'Detection'
ruleSetType: 'OWASP'
ruleSetVersion: '3.0'
}
虛擬網路
網路安全性群組 可以與虛擬網路中的一或多個子網相關聯。 這些是允許或拒絕流量在各種 Azure 資源之間流動的安全性規則。 此架構會將每個子網的個別網路安全性群組建立關聯。 這允許根據子網中包含的服務，微調每個子網的這些規則。 例如，請參閱 "type": "Microsoft.Network/networkSecurityGroups" 檔案 ase.bicep 中App Service 環境子網網路安全性群組的組態，以及 應用程式閘道 子網網路安全性群組的 appgw.bicep 檔案 。
私人端點可 透過私人網路啟用用戶端與 Azure 服務之間的增強安全性私人連線。 他們會為 Azure 服務提供可私用存取的 IP 位址，讓 Azure Private Link 資源能夠增強安全性流量。 平臺會驗證網路連線，只允許那些連線到指定的 Private Link 資源。 私人端點支援網路原則，例如網路安全性群組、使用者定義路由和應用程式安全性群組。 若要改善安全性，您應該為支援這些服務的任何 Azure 服務啟用私人端點。 然後，您可以停用公用存取，有效地封鎖來自公用網際網路的任何存取，藉此改善虛擬網路中服務的安全性。 此架構會為支援的服務設定私人端點：Azure 服務匯流排、SQL Server、金鑰保存庫和 Azure Cosmos DB。 您可以在 privatendpoints.bicep 中看到 組態。
若要啟用私人端點，您也需要設定私人 DNS 區域。 如需詳細資訊，請參閱 Azure 私人端點 DNS 設定。
防火牆
Azure 防火牆和私人端點彼此互補。 私人端點只允許來自您虛擬網路的流量，協助保護資源。 Azure 防火牆可讓您限制來自應用程式的輸出流量。 我們建議您允許所有輸出流量通過防火牆子網，包括私人端點流量。 這可讓您更妥善地監視輸出流量。 為了簡單起見，此參考架構會設定服務子網上的所有私人端點，而不是在防火牆子網上設定。
若要瞭解如何Azure 防火牆與App Service 環境整合，請參閱 使用您的App Service 環境設定Azure 防火牆 。 不會周遊私人端點和虛擬網路路由表的任何流量，會受到防火牆的監視和閘道。
Microsoft Entra ID
Microsoft Entra ID 提供安全性功能來驗證應用程式，並授權存取資源。 此參考架構使用 Microsoft Entra ID 的兩個主要功能：受控識別和 Azure 角色型存取控制。
在雲端應用程式上，必須保護向雲端服務驗證所需的認證。 在理想情況下，認證不應該出現在開發人員工作站上，或簽入原始檔控制。 Azure 金鑰保存庫提供安全地儲存認證和秘密的方法，但應用程式仍必須進行驗證，才能金鑰保存庫擷取認證。 適用于 Azure 資源的 受控識別可為 Azure 服務提供 Microsoft Entra ID 中的自動受控識別。 此身分識別可用來向任何支援 Microsoft Entra 驗證的服務進行驗證，包括金鑰保存庫，而不需要應用程式中的任何認證。
Azure 角色型存取控制 （Azure RBAC） 可管理對 Azure 資源的存取。 這包括：
- 哪個實體具有存取權：使用者、受控識別、安全性主體。
- 其存取類型：擁有者、參與者、讀者、系統管理員。
- 存取範圍：資源、資源群組、訂用帳戶或管理群組。
您可以嚴格控制每個應用程式所需的角色和存取類型，以鎖定App Service 環境應用程式的存取權。 如此一來，就可以將多個應用程式部署在不同的開發小組的相同App Service 環境上。 例如，前端可能由一個小組處理，而後端則由另一個小組處理。 Azure RBAC 可用來限制每個小組正在處理的應用程式存取權。 探索 Azure 自訂角色 ，以建立適合您組織的角色。
Key Vault
某些服務支援受控識別，但使用 Azure RBAC 來設定應用程式的許可權。 例如，請參閱 Azure Cosmos DB 中的內建服務匯流排 角色 和 Azure RBAC。 即使具有 參與者存取權的人員可以部署這些服務，也需要擁有訂用帳戶的擁有 者 存取權才能授與這些許可權。 為了讓更廣泛的開發人員小組能夠執行部署腳本，下一個最佳選項是使用服務的原生存取控制原則：
然後，這些存取控制原則的連接字串會儲存在金鑰保存庫中。 保存庫本身是透過需要 Azure RBAC 的受控識別來存取。 適當地設定這些連接字串的存取原則。 例如，後端的唯讀、前端的唯讀等等，而不是使用預設的根存取原則。
services.bicep 中的 下列程式碼會顯示這些服務的金鑰保存庫組態：
resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'CosmosKey'
properties: {
value: cosmosName.listKeys().primaryMasterKey
}
}
resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'ServiceBusListenerConnectionString'
properties: {
value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
}
}
resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'ServiceBusSenderConnectionString'
properties: {
value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
}
}
這些連接字串值是由參考金鑰保存庫索引鍵/值組的應用程式存取。 這會在 sites.bicep 檔案中 完成，如投票應用程式的下列程式碼所示：
properties: {
enabled: true
hostingEnvironmentProfile: {
id:aseId
}
serverFarmId: votingWebPlanName.id
siteConfig: {
appSettings: [
{
name: 'ConnectionStrings:sbConnectionString'
value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
}
{
name: 'ConnectionStrings:RedisConnectionString'
value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
}
{
name: 'ConnectionStrings:CosmosKey'
value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
}
]
}
}
函式也會以類似的方式存取服務匯流排接聽程式連接字串。
延展性
設計可調整的應用程式
此參考架構中的應用程式會結構化，以便根據使用量調整個別元件。 每個 Web 應用程式、API 和函式都會部署在其自己的 App Service 方案中。 您可以監視每個應用程式是否有任何效能瓶頸，然後 視需要相應增加 。
自動調整應用程式閘道
您可以在 Azure 應用程式閘道 V2 上啟用自動調整。 這可讓應用程式閘道根據流量負載模式相應增加或減少。 此參考架構會在 autoscaleConfiguration appgw.bicep 檔案 中設定，以在零到 10 個額外的實例之間進行調整。 如需詳細資訊，請參閱 調整應用程式閘道和 WAF v2 。
部署
此參考架構中的部署腳本可用來部署App Service 環境、其他服務和App Service 環境內的應用程式。 部署這些應用程式之後，企業可能會想要規劃持續整合和部署應用程式維護和升級。 本節說明開發人員使用APP SERVICE 環境應用程式 CI/CD 的一些常見方式。
應用程式只能從虛擬網路內部部署至內部App Service 環境。 下列三種方法廣泛使用來部署App Service 環境應用程式：
手動在虛擬網絡內： 使用部署所需的工具，在App Service 環境虛擬網路內建立虛擬機器。 使用 NSG 組態開啟 VM 的 RDP 連線。 將您的程式碼成品複製到 VM、建置和部署至App Service 環境子網。 這是設定初始組建和測試開發環境的簡單方式。 不過，不建議用於生產環境，因為它無法調整所需的部署輸送量。
從本機工作站點對站連線： 這可讓您將App Service 環境虛擬網路延伸至開發電腦，並從該處部署。 這是設定初始開發環境的另一種方式，不建議用於生產環境。
透過 Azure Pipelines： 這會實作完整的 CI/CD 管線，以位於虛擬網路內的代理程式結尾。 這適用于需要高部署輸送量的生產環境。 組建管線會完全保留在虛擬網路外部。 部署管線會將建置的物件複製到虛擬網路內的組建代理程式，然後部署到App Service 環境子網。 如需詳細資訊，請閱讀有關 Pipelines 與 App Service 環境 虛擬網路 之間自我裝載組建代理程式的討論 。
建議針對生產環境使用 Azure Pipelines。 使用 Azure Pipelines YAML 架構 的協助 編寫 CI/CD 腳本，有助於將建置和部署程式自動化。 azure-pipelines.yml 會 在此參考實作中為 Web 應用程式實作這類 CI/CD 管線。 Web API 和 函 式也有類似的 CI/CD 腳本 。 請參閱 使用 Azure Pipelines 來瞭解如何使用這些管線將每個應用程式的 CI/CD 自動化。
某些企業可能不想在虛擬網路內維護永久建置代理程式。 在此情況下，您可以選擇在 DevOps 管線內建立組建代理程式，並在部署完成後將其卸載。 這會在 DevOps 中新增另一個步驟，但會降低維護 VM 的複雜度。 您甚至可以考慮使用容器作為組建代理程式，而不是 VM。 建置代理程式也可以完全避免，方法是從 位於虛擬網路 外部的壓縮檔部署，通常是在儲存體帳戶中。 儲存體帳戶必須可從App Service 環境存取。 管線應該能夠存取儲存體。 在發行管線結束時，壓縮的檔案可以放入 Blob 儲存體中。 然後，App Service 環境可以挑選並部署。 請注意此方法的下列限制：
- DevOps 與實際部署程式之間有中斷連線，導致監視和追蹤任何部署問題時發生困難。
- 在具有安全流量的鎖定環境中，您可能需要變更規則，以存取儲存體上的壓縮檔案。
- 您必須在App Service 環境上安裝特定的擴充功能和工具，才能從 zip 部署。
若要深入瞭解應用程式可以部署到 App Service 方案的方式，請閱讀 以部署策略 為重點的 App Service 文章。
成本最佳化
使用 Azure 定價計算機 來預估成本。 Microsoft Azure 架構良好架構 中的 成本一節會說明其他考慮。 Azure 保留可協助您節省成本，方法是為許多 Azure 資源承諾一年或三年方案。 如需詳細資訊，請參閱購買保留 一文 。
以下是此架構中所使用的一些重要服務需要考慮的一些要點。
App Service 環境 v3
App Service 提供各種 定價選項。 使用隔離 v2 服務方案部署App Service 環境。 在此方案中，CPU 大小有多個選項，從 I1v2 到 I6v2。 此參考實作會針對每個實例使用三個 I1v2。
應用程式閘道
應用程式閘道定價 提供各種定價選項。 此實作會使用 應用程式閘道 Standard v2 和 WAF v2 SKU，其支援自動調整和區域備援。 如需此 SKU 所用定價模式的詳細資訊，請參閱 調整 應用程式閘道 v2 和 WAF v2 。
Azure Cache for Redis
Azure Cache for Redis 定價 提供此服務的各種定價選項。 此架構會 針對虛擬網路支援使用進階版 SKU 。
以下是用來鎖定App Service 環境之其他服務的定價頁面：
部署此案例
若要部署此架構的參考實作，請參閱 GitHub 讀我檔案 ，並遵循標準部署 的 腳本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 達納什裡·克斯希爾薩加 |資深內容 PM
其他投稿人：
- Deep Bhattacharya |雲端解決方案架構師
- Suhas Rao |雲端解決方案架構師
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
- 直接從 ZIP 套件Azure App 服務執行您的應用程式
- Azure Pipelines YAML 架構
- 從 API 取得您的管理位址
- Azure Key Vault
- Azure Pipelines
相關資源
若要瞭解如何擴充此架構以支援高可用性，請參閱 使用 App Services 環境 部署高可用性應用程式。