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

適用於:Azure Logic Apps (標準)

隨著採用分散式和原生雲端應用程式的趨勢逐漸上升,組織也需要在更多種環境中處理更多分散式元件。 為了保有控制權並維持一致性,您可以使用 DevOps 工具和程序更快且更安心地將環境自動化,並部署更多元件。

本文針對單一租用戶 Azure Logic Apps 目前的持續整合及持續部署 (CI/CD) 體驗提供介紹和概觀。

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

「多租用戶」Azure Logic Apps 中,資源部署以 Azure Resource Manager 範本 (ARM 範本) 為基礎,這些範本會合併及處理邏輯應用程式和基礎結構的資源佈建。 在單一租用戶 Azure Logic Apps 中,部署會變得更加容易,因為您可以在應用程式和基礎結構之間分隔資源佈建。

您使用 Logic Apps (標準) 資源類型建立邏輯應用程式時,工作流程會由重新設計的單一租用戶 Azure Logic Apps 執行階段提供支援。 此執行階段會使用 Azure Functions 擴充性模型,且裝載為 Azure Functions 執行階段的延伸模組 (英文)。 這種設計能為邏輯應用程式帶來可攜性、彈性和更高效能,還可提供繼承自 Azure Functions 平台與 Azure App Service 生態系統的其他功能和優點。

例如,您可以將重新設計的容器化執行階段和工作流程一併封裝為邏輯應用程式的一部分。 您可以使用一般步驟或工作,建置及組合邏輯應用程式資源,並壓縮為可立即部署的成品。 若要部署應用程式,請將成品複製到主機環境,接著啟動應用程式以執行工作流程。 或者,利用您已知道並使用的工具和程序,將成品整合到部署管線中。 例如,如果您的案例需要容器,您可以將邏輯應用程式容器化然後整合至現有的管線中。

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

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

DevOps 部署功能

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

本機開發和測試

將 Visual Studio Code 與 Azure Logic Apps (標準) 延伸模組搭配使用時,不需部署至 Azure 即可在開發環境中於本機開發、建置及執行單一租用戶型邏輯應用程式工作流程。 如果您的案例需要容器,您可以透過已啟用 Azure Arc 的 Logic Apps 執行建立和部署作業。

相較於必須根據 Azure 執行中的現有資源進行開發的多租用戶模型,這項功能是一大改善且提供顯著的優點。

分隔考量

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

Conceptual diagram showing separate deployment pipelines for apps and infrastructure.

邏輯應用程式資源結構

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

如需在邏輯應用程式中組織工作流程、效能和進行調整的詳細資料及最佳做法,請參閱一般適用於單一租用戶 Azure Logic Apps 的 Azure Functions 指引

邏輯應用程式專案結構

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

  • 延伸模組套件組合型 (Node.js) 為預設類型
  • NuGet 套件型 (.NET) 則能從預設類型轉換

根據這些類型,專案所包含的資料夾和檔案會稍有不同。 NuGet 型專案包含 .bin 資料夾 (其中包含套件和其他程式庫檔)。 套件組合型專案不包含 .bin 資料夾和其他檔案。 在某些案例下,需要以 NuGet 型專案才能執行應用程式,例如,當您想要開發和執行自訂內建作業的情況。 如需將專案轉換為使用 NuGet 的詳細資訊,請參閱啟用內建連接器製作

針對預設套件組合型專案,您的專案具有類似下列範例的資料夾和檔案結構:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

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

名稱 資料夾或檔案 描述
.vscode Folder 包含與 Visual Studio Code 相關的設定檔案,例如 extensions.jsonlaunch.jsonsettings.jsontasks.json 檔案。
成品 Folder 包含您在支援企業對企業 (B2B) 案例的工作流程中,所定義和使用的整合帳戶成品。 例如,範例結構包含 XML 轉換和驗證作業的對應和結構描述。
<WorkflowName> Folder 針對每個工作流程,<WorkflowName> 資料夾包含 workflow.json 檔案,其中包含該工作流程的基礎 JSON 定義。
workflow-designtime Folder 包含與開發環境相關的設定檔案。
.funcignore 檔案 包含與已安裝 Azure Functions Core Tools 相關的資訊。
connections.json 檔案 包含工作流程所使用的任何受控連線和 Azure 函式的中繼資料、端點和金鑰。

重要事項:若要在每個環境中使用不同的連線和函數,請確定您將 connections.json 檔案參數化,並更新端點。
host.json 檔案 包含執行階段特定的組態設定和值,例如,單一租用戶 Azure Logic Apps 平台、邏輯應用程式、工作流程、觸發程序和動作的預設限制。 在邏輯應用程式專案的根層級上,host.json 中繼資料檔案會包含相同邏輯應用程式中所有工作流程在本機或 Azure 中執行時所使用的組態設定和預設值。

注意:當您建立邏輯應用程式時,Visual Studio Code 會在您的儲存體容器中建立備份 host.snapshot.*.json 檔案。 當您刪除邏輯應用程式時,並不會刪除此備份檔案。 當您建立另一個具有相同名稱的邏輯應用程式時,則會建立另一個快照集檔案。 在相同邏輯應用程式中,最多只能有 10 個快照集。 如果超出此限制,您會收到下列錯誤:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

若要解決此錯誤,請從儲存體容器中刪除額外的快照集檔案。
local.settings.json 檔案 包含應用程式設定、連接字串,以及工作流程在本機執行時所使用的其他設定。 換句話說,只有在您於本機開發環境中執行專案時,才會套用這些設定和值。 在部署至 Azure 期間,檔案和設定將會被忽略,也不會包含在您的部署中。

此檔案會將設定和值儲存為本機環境變數,而本機開發工具會將其作為 appSettings 值使用。 您可以使用應用程式設定參數,在執行階段和部署時間呼叫和參考這些環境變數。

重要事項local.settings.json 檔案可能包含密碼,因此也請確定從專案原始檔控制中排除此檔案。

容器部署

單一租用戶 Azure Logic Apps 支援部署至容器,這表示您可以將邏輯應用程式工作流程容器化,然後在可執行容器的地方執行。 將應用程式容器化之後,部署的運作方式大致與您部署和管理的任何其他容器相同。

如需包含 Azure DevOps 的範例,請參閱適用於容器的 CI/CD

應用程式設定和參數

在多租用戶 Azure Logic Apps 中,若您必須在各種開發、測試和生產環境中維護邏輯應用程式的環境變數,則 ARM 範本會帶來挑戰。 ARM 範本中的所有內容均於部署時定義。 如果您只需要變更單一變數,則必須重新部署所有內容。

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

受控連接器和內建作業

Azure Logic Apps 生態系統提供數百個由 Microsoft 管理的連接器和內建作業集合,其數量還在持續增加,可供您在單一租用戶 Azure Logic Apps 中使用。 Microsoft 維護這些連接器和內建作業的方式,與在單一租用戶 Azure Logic Apps 中大致相同。

最顯著的改善是單一租用戶服務讓更熱門的受控連接器也可作為內建作業使用。 例如,內建作業可用於 Azure 服務匯流排、Azure 事件中樞、SQL 等。 同時,受控連接器版本仍可使用且持續運作。

使用內建作業建立的連線稱為「內建連線」或「服務提供者連線」。 內建作業及其連線會在執行您工作流程的相同程序中本機執行。 這兩者都裝載於經過重新設計的 Azure Logic Apps 執行階段。 相反地,受控連線 (或 API 連線) 是以您使用 ARM 範本部署的 Azure 資源的形式所另外建立和執行。 由於內建作業及其連線鄰近工作流程,因此能夠提供更高效能。 因為服務提供者連線會封裝為相同的組建成品,所以,此設計也適用於部署管線。

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

服務提供者連線

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

在您的邏輯應用程式專案中,每個工作流程都有一個 workflow.json 檔案,其中包含工作流程的基礎 JSON 定義; 此工作流程定義會參考您專案中 connections.json 檔案內的必要連接字串。

以下範例顯示內建服務匯流排作業的服務提供者連線如何出現在您專案的 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 中,若您持續使用設計工具建立及開發工作流程,則 Logic Apps 引擎會在 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 中,邏輯應用程式工作流程的裝載模型是單一租用戶,比起多租用戶模型,您的工作負載可享有更高的隔離性。 此外,單一租用戶 Azure Logic Apps 執行階段是可攜的,這表示您可以在其他環境中執行工作流程,例如在 Visual Studio Code 中本機執行。 不過,這種設計必須提供讓邏輯應用程式驗證其身分識別的方式,才能存取 Azure 中的受控連接器生態系統。 您的應用程式也需要正確的權限,才能在使用受控連線時執行作業。

每個單一租用戶型邏輯應用程式都具有自動啟用的系統指派受控識別。 此身分識別與您建立連線時所使用的驗證認證或連接字串不同。 在執行階段,邏輯應用程式會使用此身分識別透過 Azure 存取原則驗證連線。 如果停用此身分識別,則連線在執行階段會無法運作。

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

受控識別

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

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

Raw

針對使用 Visual Studio Code 在本機開發環境中執行的邏輯應用程式,請使用原始驗證金鑰對裝載於 Azure 並在其中執行的受控連線進行驗證。 這些金鑰專為開發用途 (而非生產) 設計,有為期 7 天的使用期限。 在邏輯應用程式專案的 connections.json 檔案中,受控連線具有指定下列驗證資訊的 authentication 物件:

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

下一步