此範例案例顯示原本設計為在 Kubernetes 上執行的現有工作負載範例，可以改為在 Azure Container Apps 中執行。 Azure Container Apps 非常適合用於棕色地帶工作負載，小組想要簡化複雜的基礎結構和容器協調流程。 此範例工作負載會執行容器化微服務應用程式。
此範例會採用 Azure Kubernetes Service 上的微服務架構中使用的工作負載，並將其重新裝載於 Azure Container Apps 作為其應用程式平臺。
提示
此架構是由 範例實 作所支援，說明本文所述的一些設計選擇。
架構
下載此架構的 Visio 檔案。
在此案例中，容器映像的來源是來自 Azure Container Registry，並部署至 Container Apps 環境。
共用相同環境的服務受益於：
- 內部輸入和服務探索
- 運行時間記錄的單一 Log Analytics 工作區
- 保護秘密和憑證的管理
工作流程服務容器應用程式會以單一修訂模式執行。 在單一修訂模式中執行的容器應用程式具有單一修訂，由零多複本支援。 複本會由應用程式容器和任何必要的 Sidecar 容器所組成。 此範例並未使用 Sidecar 容器，因此每個容器應用程式複本都代表單一容器。 由於此範例不會採用調整，因此每個容器應用程式只會執行一個複本。
工作流程會使用混合式方法來管理秘密。 受控識別會用於這類實作不需要變更程式碼的服務中。 無人機排程器和傳遞服務會使用使用者指派的受控識別向 Azure Key Vault 進行驗證，以存取儲存在那裡的秘密。 其餘服務會透過應用程式層級的容器應用程式儲存秘密。
此圖說明解決方案的運行時間架構。
下載此架構的 Visio 檔案。
資料流程
- 擷取服務：接收用戶端要求、緩衝處理，並透過 Azure 服務匯流排 傳送至工作流程服務。
- 工作流程服務：取用來自 Azure 服務匯流排 的訊息，並將其分派至基礎服務。
- 封裝服務： 管理套件。
- 無人機排程器服務： 排程無人機，並監視飛行中的無人機。
- 遞送服務： 管理已排程或傳輸中的交付。
元件
無人機遞送服務會使用一系列 Azure 服務，彼此搭配使用。
Azure 容器應用程式
Azure Container Apps 是主要元件。
這些功能會取代先前 AKS 架構的許多複雜度：
- 內建的服務探索
- 完全受控的 HTTP 和 HTTP/2 端點
- 整合式負載平衡
- 記錄和監視
- 根據 KEDA 所提供的 HTTP 流量或事件自動調整自動調整 （以 Kubernetes 為基礎的事件驅動自動調整）
- 應用程式升級和版本設定
外部記憶體和其他元件
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 Registry）：Azure Container Apps 不需要特定的基底映射或登錄。
- 管理應用程式生命週期：修訂功能支援執行特定容器應用程式的多個修訂，以及針對 A/B 測試或藍 /綠部署案例，跨它們進行流量分割。
- 使用受控識別：Fabrikam 小組能夠使用受控識別向 Azure 金鑰保存庫 和 Azure Container Registry 進行驗證。
潛在使用案例
- 將布朗菲爾德微服務型應用程式部署至平臺即服務 （PaaS），以簡化管理，並避免執行容器協調器的複雜性。
- 將容器化服務遷移至支援原生縮放至零的平臺，將作業和管理優化。
- 執行長時間執行的背景進程，例如單一修訂模式中的工作流程服務。
Container Apps 的其他常見用法包括：
- 在無伺服器耗用量型平臺上執行容器化工作負載。
- 根據 KEDA 支援的 HTTP/HTTPS 流量和 / 或事件驅動觸發程式自動調整應用程式
- 將容器化應用程式的維護額外負荷降到最低
- 部署 API 端點
- 裝載背景處理應用程式
- 處理事件驅動處理
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
可用性
容器應用程式可讓您更輕鬆地部署、管理、維護及監視應用程式。 您可以透過下列主要功能來確保可用性：
- 修訂可協助您以零停機時間部署應用程式更新。 您可以使用修訂來管理應用程式更新的部署，並在修訂之間分割流量，以支援藍/綠部署和 A/B 測試（目前未在此範例工作負載中使用）。
- 使用容器應用程式端對端可檢視功能，您可以全面檢視執行中的應用程式。 Container Apps 與 Azure 監視器和 Log Analytics 整合，可讓您追蹤容器應用程式執行，並根據計量和事件設定警示。
- 當應用程式意外終止時，Container Apps 服務會自動重新啟動它。
- 您可以啟用自動調整規則，以符合流量和工作負載增加的需求。
- 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 標識符保護的其他資源進行驗證，例如 Azure 金鑰保存庫，而不需要管理容器應用程式中的認證。 容器應用程式可以使用系統指派、使用者指派，或這兩種類型的受控識別。 對於不支援 AD 驗證的服務，您應該將秘密儲存在 Azure 金鑰保存庫，並使用受控識別來存取秘密。
- 使用受控識別進行 Azure Container Registry 存取。 Azure Container Apps 可讓您針對工作負載使用不同於容器登錄存取的受控識別。 建議使用此方法來達成對受控識別的細微訪問控制。
成本最佳化
- Microsoft Azure Well-Architected Framework 中的成本一節說明成本考慮。 使用 Azure 定價計算機來預估特定案例的成本。
- Azure Container Apps 具有以使用量為基礎的定價模型。
- Azure Container Apps 支持調整為零。 當容器應用程式調整為零時，不收取任何費用。
- 在此案例中，Azure Cosmos DB 和 Azure Cache for Redis 是主要的成本驅動因素。
部署此案例
請遵循 Azure Container Apps 範例案例存放庫中 README.md 中的步驟。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- 凱薩琳·邦迪 |技術寫入器