Share via


Service 連線or 的已知限制

在本文中,瞭解服務連線或現有限制,以及如何減輕這些限制。

基礎結構即程式碼的限制 (IaC)

服務連線器的設計目的是要盡可能為盡可能多的 Azure 服務提供簡單、安全且一致的支援服務連線。 若要這樣做,服務連線or 已開發為擴充資源提供者。

不幸的是,IaC 支援有一些限制,因為服務連線或代表使用者修改基礎結構。 在此案例中,使用者一開始會使用 Azure Resource Manager(ARM)、Bicep、Terraform 或其他 IaC 範本來建立資源。 之後,他們會使用服務連線or 來設定資源連線。 在此步驟中,服務連線或代表使用者修改資源設定。 如果使用者稍後重新執行其 IaC 範本,則 Service 連線or 所做的修改會消失,因為它們未反映在原始的 IaC 範本中。 此行為的範例是使用 ARM 範本部署的 Azure Container Apps 預設會停用受控識別(MI),服務連線或代表使用者設定連線時啟用 MI。 如果使用者在不更新 MI 設定的情況下觸發相同的 ARM 範本,重新部署的容器應用程式將會再次停用 MI。

如果您在使用服務連線or 時遇到任何問題, 請向我們 提出問題。

方案

我們建議下列解決方案:

  • 參考 如何使用 IaC 工具來 建置連線,以建置您的基礎結構,或將現有的基礎結構轉譯為 IaC 範本。
  • 如果您的 CI/CD 管線包含來源計算或支援服務的範本,建議的流程是:重新套用範本、新增理智檢查或煙霧測試,以確保應用程式已啟動並執行,然後允許即時流量流向應用程式。 流程會在允許即時流量之前新增驗證步驟。
  • 使用 Service 連線or 將 Azure Container App 程式碼部署自動化時,建議您使用 多個修訂模式 ,以避免將流量路由傳送至暫時非功能性應用程式,然後服務連接器才能重新套用連線。
  • 執行自動化作業的順序非常重要。 在建立連線本身之前,請確定您的連線端點位於該處。 在理想情況下,請建立備份服務、計算服務,以及兩者之間的連線。 如此一來,Service 連線or 就可以適當地設定計算服務和備份服務。

下一步