單一租使用者 Azure Logic Apps 中標準邏輯應用程式的 DevOps 部署
適用於:Azure Logic Apps (標準)
隨著採用分散式和原生雲端應用程式的趨勢逐漸上升,組織也需要在更多種環境中處理更多分散式元件。 為了保有控制權並維持一致性,您可以使用 DevOps 工具和程序更快且更安心地將環境自動化,並部署更多元件。
本文提供單一租使用者 Azure Logic Apps 中標準邏輯應用程式工作流程之目前持續整合和持續部署體驗的簡介和概觀。
單一租用戶與多租用戶的比較
在 多租使用者 Azure Logic Apps 中,資源部署是以 Azure Resource Manager 範本 (ARM 範本)為基礎,可結合並處理取用邏輯應用程式資源和基礎結構的資源布建。 在 單一租 使用者 Azure Logic Apps 中,部署會變得更容易,因為您可以在標準邏輯應用程式資源和基礎結構之間分隔資源布建。
當您建立標準邏輯應用程式資源時,工作流程會由重新設計的單一租使用者 Azure Logic Apps 運行時間提供。 此執行階段會使用 Azure Functions 擴充性模型,且裝載為 Azure Functions 執行階段的延伸模組 (英文)。 此設計可為標準邏輯應用程式提供可移植性、彈性和更多效能,以及繼承自 Azure Functions 平臺和 Azure App 服務 生態系統的其他功能和優點。
例如,您可以將重新設計的容器化運行時間和工作流程封裝在一起,作為標準邏輯應用程式的一部分。 您可以使用一般步驟或工作,建置及組合邏輯應用程式資源,並壓縮為可立即部署的成品。 若要部署標準邏輯應用程式,請將成品複製到主機環境,然後啟動您的應用程式以執行工作流程。 或者,利用您已知道並使用的工具和程序,將成品整合到部署管線中。 例如,如果您的案例需要容器,您可以將標準邏輯應用程式容器化,並將其整合到現有的管線中。
若要設定及部署如虛擬網路和連線能力等基礎結構資源,您可以繼續使用 ARM 範本,並分別佈建這些資源還有不同用途所使用的其他程序及管線。
使用標準建置和部署選項,可讓您專注於應用程式開發,基礎結構部署則另外處理。 因此,您會獲得一個更通用的專案模型,讓您可在其中套用許多針對一般應用程式使用的類似或相同部署選項。 您也可以透過為應用程式專案建置部署管線,以及在發佈至實際執行環境之前執行必要的測試和驗證,以享有更一致的體驗。 無論您使用哪種技術堆疊,都能透過自己選擇的工具部署邏輯應用程式。
DevOps 部署功能
單一租用戶 Azure Logic Apps 從 Azure Functions 平台與 Azure App Service 生態系統繼承了許多功能和優點, 這些更新中包含一個全新部署模型和更多在邏輯應用程式工作流程中使用 DevOps 的方法。
本機開發和測試
當您搭配 Azure Logic Apps (Standard) 擴充功能使用 Visual Studio Code 時,您可以在開發環境中本機開發、建置及執行標準邏輯應用程式工作流程,而不需要部署至 Azure。 如果您的案例需要容器,您可以透過已啟用 Azure Arc 的 Logic Apps 執行建立和部署作業。
相較於必須根據 Azure 執行中的現有資源進行開發的多租用戶模型,這項功能是一大改善且提供顯著的優點。
分隔考量
單一租使用者模型可讓您區分邏輯應用程式與基礎結構之間的疑慮。 例如,您可以將應用程式分別開發、組件、壓縮為不可變的成品並部署至不同環境。 邏輯應用程式工作流程一般具有「應用程式碼」,更新頻率比基礎結構高; 藉由分隔這些層級,您便能更加專注於建置邏輯應用程式的工作流程,也能減少將必要資源部署至多個環境時所耗費的心力。
邏輯應用程式資源結構
在多租用戶 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.json、launch.json、settings.json 和 tasks.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 生態系統提供 超過 1,000 個Microsoft受控和 Azure 裝載的連接器 和 內建作業 ,作為您可在單一租使用者 Azure Logic Apps 中使用的不斷成長集合的一部分。 Microsoft維護受控連接器的方式大多與多租使用者 Azure Logic Apps 中的單一租使用者 Azure Logic Apps 相同。
最重要的改進是,單一租用戶服務可讓更熱門的受控連接器作為內建作業使用。 例如,您可以針對 Azure 服務匯流排、Azure 事件中樞、SQL 和其他許多作業使用內建作業。 同時,受控連接器版本仍可使用且持續運作。
您使用 Azure 服務型內建作業建立的連線稱為內建連線,或 以服務提供者為基礎的連線。 內建作業及其連線會在執行您工作流程的相同程序中本機執行。 這兩者都裝載在重新設計的 Azure Logic Apps 運行時間上。 相反地,受控連線 (或 API 連線) 是以您使用 ARM 範本部署的 Azure 資源的形式所另外建立和執行。 由於內建作業及其連線鄰近工作流程,因此能夠提供更高效能。 因為服務提供者連線會封裝為相同的組建成品,所以,此設計也適用於部署管線。
在 Visual Studio Code 中,當您使用設計工具來開發或變更工作流程時,單一租使用者 Azure Logic Apps 引擎會自動在專案的 connections.json 檔案中產生任何必要的連線元數據。 下列各節會說明您可在工作流程中建立的三種連線, 每種連線類型都有不同的 JSON 結構。請務必了解其結構,因為當您在環境之間移動時,端點會變更。
服務提供者連線
當您在單一租用戶 Azure Logic Apps 中使用 Azure 服務匯流排或 Azure 事件中樞等服務的內建作業時,會建立與工作流程以相同程序執行的服務提供者連線。 此連線基礎結構裝載於邏輯應用程式資源中並受其管理,而工作流程所使用的任何服務提供者內建作業的連接字串,都會儲存於您的應用程式設定中。
重要
當您有敏感性資訊時,例如包含使用者名稱和密碼的連接字串,請務必使用最安全的驗證流程。 例如,Microsoft 建議您在支援可用時,使用受控識別來驗證 Azure 資源的存取權,並指派具有最低必要許可權的角色。
如果無法使用這項功能,請務必透過其他方法來保護連接字串,例如 Azure Key Vault,您可以透過應用程式設定使用。 然後您可以直接參考安全字串,例如連接字串和金鑰。 類似於您可以於部署期間定義環境變數的 ARM 範本,您可以在邏輯應用程式工作流程定義中定義應用程式設定。 然後,您可以擷取動態產生的基礎結構值,例如連線端點、儲存體字串等等。 如需詳細資訊,請參閱 Microsoft 身分識別平台的應用程式類型。
在您的標準邏輯應用程式專案中,每個工作流程都有一個 包含工作流程基礎 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 中,當您繼續使用設計工具建立及開發工作流程時,單一租使用者 Azure Logic Apps 引擎會自動為工作流程中的受控連接器在 Azure 中建立必要的資源。 引擎會自動將這些連線資源新增至您設計用於納入邏輯應用程式的 Azure 資源群組。
下列範例顯示 Azure 服務匯流排 Managed 連接器的 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 並在其中執行的受控連線進行驗證。 這些金鑰專為開發用途 (而非生產) 設計,有為期 7 天的使用期限。 在邏輯應用程式專案的connections.json檔案中,受控連線具有 authentication
物件,指定下列驗證資訊:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}