Azure Logic Apps 中標準邏輯應用程式工作流程的 DevOps 部署

適用於：Azure Logic Apps (標準)

隨著整合工作負載在開發、測試及生產環境中成長，手動部署與更新標準邏輯應用程式工作流程變得緩慢、易出錯且難以保持一致性。 隨著分散式與原生雲端應用的趨勢，團隊必須管理更多分散式元件，跨越更多環境。 你的團隊需要一種可靠的方式，能夠使用與應用程式碼相同的 DevOps 實務來建立、測試並發布工作流程變更。

單租戶 Azure Logic Apps 中的標準邏輯應用工作流程支援你現有使用的 DevOps 工具進行持續整合與持續部署（CI/CD）。 與多租戶模式不同，單租戶 Azure Logic Apps 將應用程式程式碼與基礎架構分離，因此你可以獨立地進行版本化、建置與部署工作流程——無論是本地、容器或自動化管線。

本文提供單一租使用者 Azure Logic Apps 中標準邏輯應用程式工作流程之目前持續整合和持續部署體驗的簡介和概觀。

單一租用戶與多租用戶的比較

在 multitenant Azure Logic Apps 中，資源部署基於Azure Resource Manager模板（ARM 模板）。 這些範本結合並處理消耗邏輯應用資源與基礎設施的資源配置。 在 單租戶 Azure Logic Apps 中，部署更為簡便，因為你可以將資源佈建分開在標準邏輯應用程式資源與基礎架構之間。

當您建立 Standard 邏輯應用程式資源時，工作流程會由重新設計的單一租戶 Azure Logic Apps 執行環境提供。 此執行環境會使用 Azure Functions 擴充性模型，並作為擴充功能裝載於Azure Functions 執行環境。 此設計可為標準邏輯應用程式提供可移植性、彈性和更多效能，以及繼承自 Azure Functions 平臺和 Azure App 服務 生態系統的其他功能和優點。

例如，您可以將重新設計的容器化運行時間和工作流程封裝在一起，作為標準邏輯應用程式的一部分。 您可以使用一般步驟或工作，建置及組合邏輯應用程式資源，並壓縮為可立即部署的成品。 若要部署標準邏輯應用程式，請將成品複製到主機環境，然後啟動您的應用程式以執行工作流程。 或者，利用你已經熟悉且使用的工具與流程，將你的產物整合進部署流程中。 例如，如果您的案例需要容器，您可以將標準邏輯應用程式容器化，並將其整合到現有的管線中。

若要設定及部署如虛擬網路和連線能力等基礎結構資源，您可以繼續使用 ARM 範本，並分別佈建這些資源還有不同用途所使用的其他程序及管線。

使用標準建置和部署選項，可讓您專注於應用程式開發，基礎結構部署則另外處理。 因此，您會獲得一個更通用的專案模型，讓您可在其中套用許多針對一般應用程式使用的類似或相同部署選項。 您也可以透過為應用程式專案建置部署管線，以及在發佈至實際執行環境之前執行必要的測試和驗證，以享有更一致的體驗。 無論你使用哪種技術堆疊，都能透過自己選擇的工具部署邏輯應用程式。

DevOps 部署功能

單一租用戶 Azure Logic Apps 從 Azure Functions 平台與 Azure App 服務 生態系統繼承了許多功能和優勢。 這些更新中包含一個全新部署模型和更多在邏輯應用程式工作流程中使用 DevOps 的方法。

本機開發和測試

當您搭配 Azure Logic Apps （Standard） 擴充功能使用 Visual Studio Code 時，您可以在開發環境中本機開發、建置及執行標準邏輯應用程式工作流程，而不需要部署至 Azure。 如果您的案例需要使用您控制的基礎結構進行內部部署，請參閱在 您自己的基礎結構上建立標準邏輯應用程式工作流程，以進行混合式部署。

這項功能是一項重大改進，與多租戶模式相比，帶來顯著的優勢，後者需要你在 Azure 中針對現有且正在執行的資源進行開發。

分隔考量

單一租戶模式可讓您將邏輯應用程式與基礎結構之間的責任分離。 例如，您可以將應用程式分別開發、組件、壓縮為不可變的成品並部署至不同環境。 邏輯應用程式工作流程一般具有「應用程式碼」，更新頻率比基礎結構高； 藉由分隔這些層級，您便能更加專注於建置邏輯應用程式的工作流程，也能減少將必要資源部署至多個環境時所耗費的心力。

邏輯應用程式資源結構

在多租用戶 Azure Logic Apps 模型中，取用邏輯應用程式資源結構只能包含單一工作流程。 由於這種一對一關聯性，邏輯應用程式和工作流程通常會被視為同義詞並加以參考。 在單租戶 Azure Logic Apps 模型中，標準邏輯應用程式資源結構可包含多個工作流程。 這種一對多關聯性代表在同一邏輯應用程式中，工作流程可以共用及重複使用其他資源。 相同邏輯應用程式和租用戶中的工作流程，也因共用此租用與彼此接近，而提供更好的效能。 此資源結構的外觀和運作方式都類似於 Azure Functions，讓單一函式應用程式能裝載許多函式。

如需有關在邏輯應用程式中組織工作流程、效能和調整的詳細資訊與最佳做法，請檢閱類似的 Azure Functions 指引，通常可將其套用到單一租用戶 Azure Logic Apps。

邏輯應用程式專案結構

在 Visual Studio Code 中，邏輯應用程式專案具有下列其中一種類型：

• 延伸模組套件組合型（使用 Node.js）是預設類型
• NuGet 以套件為基礎的 (.NET)，可以從預設類型轉換。

根據這些類型，您的專案可能包含稍微不同的資料夾或檔案。 例如，Nuget 套件型專案具有包含套件和其他程式庫檔案的 .bin 資料夾。 延伸模組套件組合型專案不包含此 .bin 資料夾。

某些案例需要 NuGet 套件型專案，您的應用程式才能執行，例如，當您想要開發和執行自訂內建作業時。 如需將專案轉換為使用 NuGet 的詳細資訊，請參閱啟用內建連接器撰寫。

預設延伸模組套件組合型專案具有資料夾和檔案結構，類似於下列範例：

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

在專案的根層級，您可以找到下列資料夾和檔案以及其他項目：

容器部署

單租戶 Azure Logic Apps 支援部署到容器。 你可以將 Logic App 的工作流程容器化，並在容器能執行的地方執行它們。 將應用程式容器化之後，部署的運作方式大致與您部署和管理的任何其他容器相同。

包含Azure DevOps的範例，請參見 CI/CD for Containers。

應用程式設定和參數

在多租戶 Azure Logic Apps 中，當你需要維護各種開發、測試及生產環境的邏輯應用環境變數時，ARM 範本會帶來挑戰。 你在部署時用 ARM 範本定義所有東西。 如果你只需要改變一個變數，就必須重新部署所有東西。

在單一租用戶 Azure Logic Apps 中，您可以使用應用程式設定和參數在執行階段呼叫和參考環境變數，因此不需要經常重新部署。

受控連接器和內建作業

Azure Logic Apps 生態系統提供 超過 1,000 個 Microsoft 受控和 Azure 裝載的連接器 和 內建作業 ，作為您可在單一租戶 Azure Logic Apps 中使用的不斷成長集合的一部分。 Microsoft 維護管理連接器的方式在單租戶 Azure Logic Apps 中與在多租戶 Azure Logic Apps 中大致相同。

最重要的改進是，單一租用戶服務可讓更受歡迎的託管連接器作為內建功能使用。 例如，您可以針對 Azure 服務匯流排、Azure 事件中樞、SQL 和其他許多專案使用內建作業。 同時，受控連接器版本仍可使用且持續運作。

你透過Azure服務基礎內建操作所建立的連線稱為內建連接，或服務提供者基礎連接。 內建作業及其連線會在執行您工作流程的相同程序中本機執行。 這兩者都裝載在重新設計的 Azure Logic Apps 執行環境上。 相較之下，管理連線或 API 連線則是作為 Azure 資源獨立建立並執行，並透過 ARM 範本部署。 由於內建作業及其連線鄰近工作流程，因此能夠提供更高效能。 因為服務提供者連線會封裝為相同的建置成品，所以此設計也適用於部署管線。

在 Visual Studio Code 中，當您使用設計工具來開發或變更工作流程時，單一租使用者 Azure Logic Apps 引擎會自動在專案的 connections.json 檔案中產生任何必要的連線元數據。 下列各節會說明您可在工作流程中建立的三種連線， 每種連線類型都有不同的 JSON 結構。請務必了解其結構，因為當您在環境之間移動時，端點會變更。

服務提供者連線

在單一租用戶 Azure Logic Apps 中，當您對 Azure 服務匯流排或 Azure 事件中樞等服務使用內建作業時，您會建立服務提供者連線，該連線會在與工作流程相同的處理程序中執行。 此連線基礎結構裝載於邏輯應用程式資源中並受其管理，而工作流程所使用的任何服務提供者內建作業的連接字串，都會儲存於您的應用程式設定中。

在您的標準邏輯應用程式專案中，每個工作流程都有一個 包含工作流程基礎 JSON 定義的workflow.json 檔案。 此工作流程定義會參考專案 connections.json 檔案中所需的連接字串。

下列範例顯示 Azure 服務匯流排內建作業的服務提供者連線，在專案的 connections.json 檔案中的顯示方式：

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

受控連線

當您第一次在工作流程中使用受控連接器時，系統會提示您為目標服務或系統建立受控 API 連線，並驗證您的身分識別， Azure 的共享連接器生態系統負責管理這些連接器。 在 Azure 中，API 連線以個別資源的形式執行。

在 Visual Studio Code 中，當你持續使用 Designer 建立和開發工作流程時，單一租戶的 Azure Logic Apps 引擎會自動在 Azure 中建立管理式連接器所需的資源。 引擎會自動將這些連線資源新增至您設計用於納入邏輯應用程式的 Azure 資源群組。

下列範例顯示 Azure 服務匯流排受控連接器的 API 連線，在專案的 connections.json 檔案中的顯示方式：

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

Azure Functions 連線

若要呼叫在 Azure Functions 中建立並託管的函式，請使用 Azure Functions 內建的操作。 Azure Functions 呼叫的連線元資料與其他內建連線不同。 此元資料會儲存在邏輯應用程式專案的 connections.json 檔案中，但看起來不同：

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

驗證

在單租戶的 Azure Logic Apps 中，邏輯應用工作流程的主機模型是單一的 Microsoft Entra 租戶，讓你的工作負載比多租戶模式享有更高的隔離性。 此外，單租戶的 Azure Logic Apps 執行環境是可攜性的，這意味著你可以在其他環境中執行工作流程，例如本地的 Visual Studio Code。 不過，這種設計必須提供讓邏輯應用程式驗證其身分識別的方式，才能存取 Azure 中的受控連接器生態系統。 您的應用程式也需要正確的權限，才能在使用受控連線時執行作業。

根據預設，每個以單一租用戶為基礎的邏輯應用程式，都會自動啟用系統指派的受控識別。 此身分識別與您建立連線時所使用的驗證認證或連接字串不同。 在執行階段，邏輯應用程式會使用此身分識別透過 Azure 存取原則驗證連線。 如果你停用這個身份，連線在執行時就無法運作。

下列各節會根據邏輯應用程式的執行位置，進一步說明可以使用哪些驗證類型來驗證受控連線。 針對每個受控連線，邏輯應用程式專案的 connections.json 檔案具有 物件 authentication ，指定邏輯應用程式可用來驗證該受控連線的驗證類型。

受控識別

針對裝載於 Azure 並在其中執行的邏輯應用程式，預設和建議的驗證類型為受控識別，可用於驗證裝載於 Azure 並在其中執行的受控連線。 在邏輯應用專案的 connections.json 檔案中，受管理的連線有一個 authentication 物件，指定 ManagedServiceIdentity 作為身份驗證類型。

"authentication": {
   "type": "ManagedServiceIdentity"
}

Raw

對於在本地開發環境中使用 Visual Studio Code 執行的邏輯應用程式，原始認證金鑰會驗證託管並運行於 Azure 的管理連線。 這些金鑰只用於開發，不要用於生產，因為它們在七天後過期。 在您的 Logic App 專案的 connections.json 檔案中，管理連線包含一個 authentication 物件，指定以下認證資訊：

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

相關內容

• 設定單一租用戶 Azure Logic Apps 的 DevOps 部署