此範例案例顯示原本設計為在 Kubernetes 上執行的現有工作負載範例，可以改為在 Azure Container Apps 中執行。 Azure Container Apps 非常適合用於棕色地帶工作負載，小組想要簡化複雜的基礎結構和容器協調流程。 此範例工作負載會執行容器化微服務應用程式。
此範例會採用 Azure Kubernetes Service 上的微服務架構中使用的 工作負載，並將其重新裝載于 Azure Container Apps 作為其應用程式平臺。
提示
此架構是由 範例實 作所支援，說明本文所述的一些設計選擇。
架構
在此案例中，容器映射的來源是來自 Azure Container Registry，並部署至 Container Apps 環境。
共用相同環境的服務受益于：
- 內部輸入和服務探索
- 執行時間記錄的單一 Log Analytics 工作區
- 保護秘密和憑證的管理
工作流程服務容器應用程式是以單一修訂模式執行。 在單一修訂模式中執行的容器應用程式會有一個由零多複本支援的單一修訂。 複本是由應用程式容器和任何必要的 Sidecar 容器所組成。 此範例並未使用 Sidecar 容器，因此每個容器應用程式複本都代表單一容器。 由於此範例不會採用調整，因此每個容器應用程式只會有一個複本執行。
工作流程會使用混合式方法來管理秘密。 受控識別用於這類實作不需要變更程式碼的服務中。 無人機排程器和傳遞服務會使用使用者指派的受控識別向 Azure 金鑰保存庫進行驗證，以存取儲存在那裡的秘密。 其餘服務會透過應用層級的 Container Apps 服務來儲存秘密。
此圖說明解決方案的執行時間架構。
資料流程
- 擷取服務： 接收用戶端要求、緩衝處理，並透過Azure 服務匯流排傳送至工作流程服務。
- 工作流程服務： 取用來自Azure 服務匯流排的訊息，並將其分派至基礎服務。
- 封裝服務： 管理套件。
- 無人機排程器服務： 排程無人機，並監視飛行中的無人機。
- 遞送服務： 管理已排程或傳輸中的交付。
元件
無人機遞送服務會使用一系列 Azure 服務，彼此搭配使用。
Azure 容器應用程式
Azure Container Apps 是主要元件。
先前 AKS 架構的許多複雜度都會由這些功能所取代：
- 內建服務探索
- 完全受控的 HTTP 和 HTTP/2 端點
- 整合式負載平衡
- 記錄和監視
- 根據 KEDA 所提供的 HTTP 流量或事件自動調整
- 應用程式升級和版本控制
外部儲存體和其他元件
Azure 金鑰保存庫 服務，用於安全地儲存和存取秘密，例如 API 金鑰、密碼和憑證。
Azure Container Registry 會儲存私人容器映射。 您也可以使用其他容器登錄，例如 Docker Hub。
Azure Cosmos DB 會使用適用于 MongoDB 的開放原始碼 Azure Cosmos DB 來儲存資料。 微服務通常是無狀態的，並將其狀態寫入外部資料存放區。 Azure Cosmos DB 是 NoSQL 資料庫，具有適用于 MongoDB 和 Cassandra 的開放原始碼 API。
Azure 服務匯流排 提供可靠的雲端傳訊即服務和簡單的混合式整合。 服務匯流排支援微服務應用程式通用的非同步傳訊模式。
Azure Cache for Redis 會將快取層新增至應用程式架構，以改善大量流量負載的速度和效能。
Azure 監視器 會從應用程式收集及儲存計量和記錄。 使用此資料來監視應用程式、設定警示和儀表板，以及執行失敗的根本原因分析。 此案例會使用 Log Analytics 工作區來全面監視基礎結構和應用程式。
Application Insights 為服務提供可延伸的應用程式效能管理 （APM） 和監視。 每個服務都會使用 Application Insights SDK 進行檢測，以監視應用程式，並將資料導向 Azure 監視器。
替代項目
此範例的替代案例是使用 Kubernetes 的 Fabrikam 無人機傳遞應用程式，其可在 Azure Kubernetes Service （AKS） Fabrikam 無人機傳遞 存放庫的 GitHub 上取得。
案例詳細資料
您的企業可以使用 Azure Container Apps 來簡化微服務容器的部署和管理。 Container Apps 提供完全受控的無伺服器環境，可用來建置和部署新式應用程式。
Fabrikam， Inc. （虛構的公司） 已實作無人機遞送應用程式，使用者可以要求無人機挑選貨物進行遞送。 當客戶排程取貨時，後端系統會指派無人機，並以預估的交貨時間通知使用者。
微服務應用程式已部署至 Azure Kubernetes Service （AKS） 叢集。 但是，Fabrikam 小組並未利用進階或平臺特定的 AKS 功能。 他們最終會將應用程式移轉至 Azure Container Apps，而不會產生太多額外負荷。 藉由將其解決方案移植到 Azure Container Apps，Fabrikam 能夠：
- 移轉應用程式幾乎如往上移轉：將應用程式從 AKS 移至 Azure Container Apps 時，需要最少的程式碼變更。
- 使用 Bicep 範本部署基礎結構和工作負載：部署其應用程式容器不需要 Kubernetes YAML 資訊清單。
- 透過 Managed 輸入公開應用程式：外部 HTTPs 型輸入的內建支援，以公開擷取服務已移除設定自己的輸入需求。
- 從 ACR 提取容器映射：Azure Container Apps 不需要特定的基底映射或登錄。
- 管理應用程式生命週期：修訂功能支援執行特定容器應用程式的多個修訂，以及針對 A/B 測試或藍/綠部署案例，跨它們進行流量分割。
- 使用受控識別：Fabrikam 小組能夠使用受控識別向 Azure 金鑰保存庫和 Azure Container Registry 進行驗證。
潛在的使用案例
- 將布朗菲爾德微服務型應用程式部署到平臺即服務 （PaaS） 供應專案，以避免管理容器協調器的作業複雜度。
- 將容器化服務遷移至支援原生縮放至零的平臺，將作業和管理優化。
- 執行長時間執行的背景進程，例如單一修訂模式中的工作流程服務。
Container Apps 的其他常見用法包括：
- 在無伺服器耗用量型平臺上執行容器化工作負載。
- 根據 KEDA 支援的 HTTP/HTTPS 流量和/或事件驅動觸發程式自動調整應用程式
- 將容器化應用程式的維護額外負荷降到最低
- 部署 API 端點
- 裝載背景處理應用程式
- 處理事件驅動處理
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
可用性
Container Apps 可讓您更輕鬆地部署、管理、維護和監視應用程式。 這些主要功能可以確保可用性：
- 修訂可協助您以零停機時間部署應用程式更新。 您可以使用修訂來管理應用程式更新的部署，並在修訂之間分割流量，以支援藍/綠部署和 A/B 測試（目前未在此範例工作負載中使用）。
- 使用容器應用程式端對端可檢視功能，您可以全面檢視執行中的應用程式。 Container Apps 與 Azure 監視器和 Log Analytics 整合，可讓您追蹤容器應用程式執行，並根據計量和事件設定警示。
- 當應用程式意外終止時，Container Apps 服務會自動重新開機它。
- 您可以啟用自動調整規則，以符合流量和工作負載增加的需求。
- 效能已由容器應用程式的動態負載平衡功能優化（目前未在此範例工作負載中使用）。
卓越營運
卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 營運卓越支柱 概觀。
為了達到卓越營運，Container Apps 服務會提供這些功能：
- 用來設定自動化 CI/CD 部署的 GitHub Actions 整合。
- 使用流量分割的多修訂模式，以測試應用程式程式碼和調整規則的變更。
- 與 Azure 監視器和 Log Analytics 整合，以提供容器化應用程式的深入解析。
效能效益
效能效率是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 如需詳細資訊，請參閱 效能效率要素概觀 。
此解決方案中的效能考慮：
- 工作負載會分散于多個微服務應用程式。
- 每個微服務都是獨立的，不會與其他微服務共用任何專案，因此它們可以獨立調整。
- 當工作負載增加時，可以啟用自動調整。
- 要求會動態負載平衡。
- 計量，包括 CPU 和記憶體使用率、頻寬資訊和儲存體使用率，都可透過 Azure 監視器取得。
- Log Analytics 提供記錄匯總，以收集每個 Container Apps 環境的資訊。
可靠性
可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性要素 概觀。
Container Apps 會嘗試重新開機失敗的容器，並將硬體從使用者中抽象化。 Microsoft 會處理暫時性失敗和備份計算資源的高可用性。
透過 Log Analytics 和 Azure 監視器的效能監視可讓您評估負載下的應用程式。 計量和記錄資訊可讓您識別趨勢所需的資料，以防止失敗，並在發生失敗時執行根本原因分析。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
密碼
- 您的容器應用程式可以將敏感性值儲存並擷取為秘密。 為容器應用程式定義秘密之後，應用程式可以使用它和任何相關聯的縮放規則。 如果您以多重修訂模式執行，所有修訂都會共用相同的秘密。 因為秘密會被視為應用程式範圍變更，如果您變更秘密的值，則不會建立新的修訂。 不過，若要讓任何執行中的修訂載入新的秘密值，您必須重新開機它們。 在此案例中，會使用應用程式和環境變數值。
- 環境變數：敏感性值可以安全地儲存在應用層級。 當環境變數變更時，容器應用程式將會繁衍新的修訂。
網路安全性
- 輸入：若要限制外部存取，只會針對外部輸入設定擷取服務。 後端服務只能透過 Container Apps 環境中的內部虛擬網路來存取。 只有在需要的情況下，才會將服務公開至網際網路。 由於此架構使用內建的外部輸入功能，因此此解決方案無法完全將輸入點放置在 Web 應用程式防火牆 （WAF） 後面，或將其包含在 DDoS 保護方案中。 所有面向 Web 的工作負載都應該前面加上 Web 應用程式防火牆。
- 虛擬網路：當您建立環境時，您可以提供自訂虛擬網路;否則，虛擬網路會自動由 Microsoft 產生和管理。 您無法操作此 Microsoft 管理的虛擬網路，例如新增網路安全性群組 （NSG） 或強制將流量通道傳送至輸出防火牆。 此範例會使用自動產生的虛擬網路。
如需更多網路拓撲選項，請參閱 Azure Container Apps 中的網路架構。
工作負載身分識別
- Container Apps 支援 Microsoft Entra 受控識別，讓您的應用程式能夠向受 Microsoft Entra ID 保護的其他資源進行驗證，例如 Azure 金鑰保存庫，而不需要管理容器應用程式中的認證。 容器應用程式可以使用系統指派、使用者指派，或這兩種類型的受控識別。 對於不支援 AD 驗證的服務，您應該將秘密儲存在 Azure 金鑰保存庫，並使用受控識別來存取秘密。
- 使用受控識別進行 Azure Container Registry 存取。 Azure Container Apps 針對工作負載支援針對工作負載使用不同的受控識別，而不是容器登錄存取，建議您在受控識別上達成細微的存取控制。
成本最佳化
- Microsoft Azure 架構 架構中的成本一節說明成本考慮。 使用 Azure 定價計算機 來預估特定案例的成本。
- Azure Container Apps 具有以使用量為基礎的定價模型。
- Azure Container Apps 支援調整為零。 當容器應用程式調整為零時，不收取任何費用。
- 在此案例中，Azure Cosmos DB 和 Azure Cache for Redis 是主要的成本驅動因素。
部署此案例
請遵循 Azure Container Apps 範例案例 存放庫中 README.md 中的步驟來部署此案例。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 凱薩琳·邦迪 |技術寫入器