Azure 應用程式組態最佳做法

  • 發行項

本文討論使用 Azure 應用程式組態時的常見模式和最佳做法。

索引鍵群組

應用程式組態提供兩個選項來組織索引鍵：

  • 索引鍵前置詞
  • 標籤

您可以使用一或兩個選項來分組索引鍵。

索引鍵前置詞是索引鍵的開頭部分。 您可以在名稱中使用相同的前置詞，以邏輯方式將一組索引鍵分組。 前置詞可以包含多個由分隔符號連接的元件，例如類似於 URL 路徑的 /，以形成命名空間。 當您將許多應用程式和微服務的索引鍵儲存在一個應用程式組態存放區時，這類階層很有用。

請記住，索引鍵是應用程式程式碼參考的索引鍵，以擷取對應設定的值。 索引鍵不應該變更，否則每次發生時都必須修改程式碼。

標籤是索引鍵上的屬性。 其用來建立索引鍵的變體。 例如，您可以將標籤指派給多個版本的索引鍵。 版本可能是反覆項目、環境或其他內容資訊。 您的應用程式可以藉由指定另一個標籤來要求一組完全不同的索引鍵值。 因此，所有索引鍵參考都會在程式碼中保持不變。

索引鍵/值組合

應用程式組態會將與其一起儲存的所有索引鍵視為獨立實體。 應用程式組態不會嘗試推斷索引鍵之間的任何關聯性，或根據其階層繼承索引鍵值。 不過，您可以使用結合應用程式程式碼中適當設定堆疊的標籤來彙總多個索引鍵集。

讓我們看看下列範例。 假設您有一個名為 Asset1 的設定，其值可能會根據開發環境而有所不同。 您可以建立名為「Asset1」的索引鍵，其中包含空白標籤和名為「開發」的標籤。 在第一個標籤中，您會放置 Asset1 的預設值，並在後者中放置「開發」的特定值。

在您的程式碼中，您會先擷取不含任何標籤的索引鍵值，然後使用「開發」標籤第二次擷取相同的索引鍵值集。 當您第二次擷取值時，會覆寫先前的索引鍵值。 .NET Core 組態系統可讓您將多組設定資料堆疊在彼此之上。 如果索引鍵存在於多個集合中，則會使用包含索引鍵的最後一個集合。 如果您使用原生設定提供者來存取應用程式組態，您可以使用新式程式設計架構 (例如 .NET Core)，免費取得此堆疊功能。 下列程式碼片段示範如何在 .NET Core 應用程式中實作堆疊：

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

使用標籤為不同環境啟用不同的設定會提供完整範例。

外部資料的參考

應用程式組態的設計目的是儲存您通常會儲存在設定檔或環境變數中的任何設定資料。 不過，某些類型的資料可能更適合存放在其他來源。 例如，將祕密儲存在金鑰保存庫、Azure 儲存體中的檔案、Microsoft Entra 群組中的成員資格資訊，或資料庫中的客戶清單。

您仍然可以藉由將外部資料的參考儲存在索引鍵/值中，來利用應用程式組態。 您可以使用內容類型來區分每個資料來源。 當應用程式讀取參考時，其會從參考的來源載入實際資料，假設其具有來源的必要權限。 如果您變更外部資料的位置，您只需要更新應用程式組態中的參考，而不是更新和重新部署整個應用程式。

在此案例中，應用程式組態金鑰保存庫參考功能是範例。 其可讓應用程式視需要更新所需的祕密，而基礎祕密本身會保留在金鑰保存庫中。

應用程式組態啟動程序

若要存取應用程式組態存放區，您可以使用可在 Azure 入口網站中使用的連接字串。 因為連接字串包含認證資訊，所以會被視為祕密。 這些祕密必須儲存在 Azure 金鑰保存庫中，而且您的程式碼必須向金鑰保存庫進行驗證才能擷取這些祕密。

更好的選項是使用 Microsoft Entra ID 中的受控識別功能。 使用受控識別時，您只需要應用程式組態端點 URL，才能啟動對應用程式組態存放區的存取。 例如，您可以在應用程式程式碼 (例如，appsettings.json 檔案) 內嵌 URL。 如需詳細資料，請參閱使用受控識別來存取應用程式組態。

Azure Kubernetes Service 對應用程式組態的存取

下列選項適用於裝載在 Azure Kubernetes Service (AKS) 中的工作負載，以存取 Azure 應用程式組態。 這些選項通常也適用於 Kubernetes。

  • 將 Azure 應用程式組態 Kubernetes 提供者新增至 AKS 叢集。 Kubernetes 提供者會以 Pod 的形式在叢集中執行。 它可以依據應用程式組態存放區中的索引鍵/值和 Key Vault 參考來建構 ConfigMap 和秘密。 ConfigMap 和秘密均可當成環境變數或掛接的檔案取用，不需要對應用程式程式碼進行任何修改。 如果您在相同的 AKS 叢集中執行多個應用程式，這些應用程式都可以存取產生的 ConfigMap 和秘密，而不需要對應用程式組態提出個別要求。 Kubernetes 提供者也支援動態設定更新。 如果您可以的話，建議使用此選項。

  • 更新您的應用程式以使用 Azure 應用程式組態提供者程式庫。 提供者程式庫有許多架構和語言，例如 ASP.NET、.NET、Java Spring、JavaScript/Node.js 和 Python。 此方法可讓您完整存取應用程式組態功能，包含動態組態和功能管理。 您可以細微控制要載入哪些資料，以及每個應用程式使用的應用程式組態存放區。

  • 使用 Helm 與 Kubernetes 部署整合。 如果您不想更新應用程式或將新的 Pod 新增至 AKS 叢集，您可以選擇使用 Helm 並透過部署，將資料從應用程式組態擷取到 Kubernetes 叢集。 這個方法可讓您的應用程式繼續從 Kubernetes 變數和祕密存取設定。 每當您想要讓應用程式納入新的設定變更時，都可以執行 Helm 升級。

App Service 或 Azure Functions 對應用程式組態的存取

使用應用程式組態提供者或 SDK 程式庫，直接在應用程式中存取應用程式組態。 此方法可讓您完整存取應用程式組態功能，包含動態組態和功能管理。 App Service 或 Azure Functions 上執行的應用程式可以透過下列方式，取得應用程式組態存放區的存取：

您也可以將應用程式組態資料作為應用程式設定或環境變數，以讓應用程式存取。 透過此方法，您可以避免變更應用程式程式碼。

減少對應用程式組態提出的要求

對應用程式組態的過多要求可能會導致節流或超額費用。 若要減少提出的要求數目：

  • 增加重新整理逾時，特別是如果您的設定值不常變更時。 使用 SetCacheExpiration 方法指定新的重新整理逾時。

  • 監看單一 sentinel 金鑰，而不是監看個別金鑰。 只有在 sentinel 金鑰變更時，才重新整理所有設定。 請參閱在 ASP.NET Core 應用程式中使用動態設定，來取得範例。

  • 使用 Azure 事件方格在設定變更時接收通知，而不是持續輪詢任何變更。 如需詳細資訊，請參閱使用事件方格來取得應用程式組態資料變更通知。

  • 在應用程式組態存放區中啟用異地複寫，並將要求分散到多個複本。 例如，全域部署的應用程式在每個地理區域都使用不同的複本。 每個應用程式組態複本都有其各自的要求配額。 此設定可讓您的模型在發生暫時性與區域中斷時有更好的可擴縮性和復原能力。

將設定資料匯入應用程式組態

應用程式組態提供選項，可讓您使用 Azure 入口網站或 CLI，從目前的設定檔大量匯入設定。 您也可以使用相同的選項，從應用程式組態匯出索引鍵/值，例如相關存放區之間的索引鍵/值。 如果您想要在 GitHub 或 Azure DevOps 中設定與存放庫進行持續同步處理，您可以使用 GitHub 動作或 Azure 管線推送工作，以便在取得應用程式組態的優點時繼續使用現有的原始檔控制做法。

應用程式組態中的多區域部署

如果您的應用程式部署在多個區域中，建議您啟用應用程式組態存放區的異地複寫。 您可以讓應用程式與應用程式執行個體部署區域的複本建立主要連線，並允許容錯移轉至其他區域中的複本。 此設定可將應用程式與應用程式組態之間的延遲降到最低並分散負載，因為每個複本都有個別的節流配額，可增強應用程式在發生暫時性與區域中斷時的復原能力。 如需詳細資訊，請參閱復原和災害復原。

建置具有高復原能力的應用程式

應用程式通常仰賴設定來啟動，這讓 Azure 應用程式組態的高可用性變得至關重要。 為了改善復原能力，應用程式應運用應用程式組態的可靠性功能，並考慮根據您的特定需求採取下列措施。

  • 使用 Azure 可用性區域支援在區域中佈建。 可用性區域可讓應用程式在資料中心中斷服務時復原。 應用程式組態為所有客戶提供區域備援，無需支付任何額外費用。 建議在支援可用性區域的區域中建立應用程式組態存放區。 您可以參閱區域清單，瞭解哪些區域的應用程式組態已啟用可用性區域支援。
  • 啟用異地複寫並允許您的應用程式在複本之間容錯移轉。 此設定可讓您的模型在發生暫時性故障與區域中斷時有更好的可擴縮性和復原能力。 如需詳細資訊，請參閱復原和災害復原。
  • 使用安全部署做法部署設定。 不正確或意外的設定變更經常會導致應用程式停機。 您應避免進行會對生產環境造成直接影響的設定變更，例如盡可能使用 Azure 入口網站。 在安全部署實務 (SDP) 中，您可以使用漸進式曝光部署模型，將部署造成的問題潛在爆炸半徑降到最低。 如果您採用 SDP，則可以先建置和測試設定快照集，然後再部署至生產環境。 在部署期間，您可以更新應用程式的執行個體，以漸進方式挑選新的快照集。 如果偵測到問題，您可以重新部署上次已知的良好設定 (LKG) 快照集來復原變更。 快照集是不可變的，以保證所有部署的一致性。 您可以使用快照集以及動態設定。 針對緊急設定覆寫和功能旗標使用基礎設定和動態設定的快照集。
  • 將設定納入應用程式。 如果您想要確保應用程式一律可以存取設定複本，或者您想要避免應用程式組態的執行階段相依性，您可以在建置或發行期間從應用程式組態提取設定，並將它納入應用程式中。 若要深入了解，請參閱整合應用程式組態與 CI/CD 管線或 Kubernetes 部署的範例。
  • 使用應用程式組態提供者。 應用程式是達成高復原能力的重要關鍵，因為它們可以考慮執行階段期間所產生的問題 (例如網路問題)，並且更快速地回應失敗。 應用程式組態提供者提供一系列的內建復原功能，包括自動複本探索、複本容錯移轉、透過可自訂的逾時設定啟動重試、設定快取，以及重新整理可靠設定的彈性策略。 強烈建議您使用應用程式組態提供者來發揮這些功能的作用。 如果這不是選項，則您應考慮在自訂解決方案中實作類似的功能，以達到最高層級的復原能力。

應用程式組態中的用戶端應用程式

當您在用戶端應用程式中使用應用程式組態時，請確定您考慮兩個主要因素。 首先，如果您在用戶端應用程式中使用連接字串，則可能會將應用程式組態存放區的存取金鑰公開給大眾。 其次，用戶端應用程式的一般規模可能會導致對應用程式組態存放區過多的要求，這可能會導致超額費用或節流。 如需節流的詳細資訊，請參閱常見問題集。

若要解決這些疑慮，建議您在用戶端應用程式與應用程式組態存放區之間使用 Proxy 服務。 Proxy 服務可以安全地向您的應用程式組態存放區進行驗證，而不會發生洩漏驗證資訊的安全性問題。 您可以使用其中一個應用程式組態提供者程式庫來建置 Proxy 服務，以便利用內建快取和重新整理功能，將傳送至應用程式組態的要求量最佳化。 如需使用應用程式組態提供者的詳細資訊，請參閱快速入門和教學課程中的文章。 Proxy 服務會將設定從快取提供給用戶端應用程式，並避免本節中討論的兩個潛在問題。

應用程式組態中的多租用戶應用程式

多租用戶應用程式是以一個架構為基礎，其中應用程式的共用執行個體會為多個客戶或租用戶提供服務。 例如，您可能有一個電子郵件服務，可為使用者提供個別的帳戶和自訂體驗。 您的應用程式通常會為每個租用戶管理不同的組態。 以下是在多租用戶應用程式中使用應用程式組態的一些架構考量。

設定即程式碼

設定即程式碼是管理原始檔控制系統下設定檔的做法，例如 Git 存放庫。 其提供任何設定變更的可追蹤性和核准程序等優點。 如果您採用設定即程式碼，應用程式組態有工具可協助您管理檔案中的設定資料，並將其部署為組建、發行或 CI/CD 程序的一部分。 如此一來，您的應用程式就可以從應用程式組態存放區存取最新資料。

  • 針對 GitHub，您可以為存放庫啟用應用程式組態同步 GitHub 動作。 每當合併提取要求時，設定檔的變更都會自動同步處理至應用程式組態。
  • 針對 Azure DevOps，您可以在組建或發行管線中包含 Azure 應用程式組態推送 (一種 Azure 管線工作)，以進行資料同步處理。
  • 您也可以使用 Azure CLI 做為 CI/CD 系統的一部分，將設定檔匯入應用程式組態。 如需詳細資訊，請參閱 az appconfig kv import。

此模型可讓您在將資料認可至應用程式組態之前，先包含驗證和測試步驟。 如果您使用多個應用程式組態存放區，您也可以將設定資料以累加方式或全部推送至這些存放區。

下一步