DevOps-Bereitstellung für Workflows für Standardlogik-Apps in Azure Logic Apps

Gilt für: Azure Logic Apps (Standard)

Da Integrationsworkloads über Entwicklungs-, Test- und Produktionsumgebungen hinweg wachsen, werden manuelle Bereitstellung und Updates für Standardlogik-App-Workflows langsam, fehleranfällig und schwer konsistent zu halten. Mit dem Trend zu verteilten und nativen Cloud-Apps müssen Teams mehr verteilte Komponenten in mehr Umgebungen verwalten. Ihr Team benötigt eine Möglichkeit, Workflowänderungen zuverlässig zu erstellen, zu testen und freizugeben, indem sie dieselben DevOps-Methoden verwenden, die Sie auf Anwendungscode anwenden.

Standard-Logik-App-Workflows in Einzelmandanten-Azure-Logic-Apps unterstützen kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) mit den DevOps-Tools, die Sie bereits verwenden. Im Gegensatz zum Multitenant-Modell trennt Azure Logic Apps App-Code von der Infrastruktur, sodass Sie Ihre Workflows unabhängig – lokal, in Containern oder über automatisierte Pipelines – versionieren, erstellen und bereitstellen können.

Dieser Artikel bietet eine Einführung und einen Überblick über die aktuelle CI/CD-Erfahrung (Continuous Integration und Continuous Deployment) für Standard-Logik-App-Workflows in Single-Tenant Azure Logic Apps.

Einzelmandanten im Vergleich zu mehreren Mandanten

In multitenant Azure Logic Apps basiert die Ressourcenbereitstellung auf Azure Resource Manager Vorlagen (ARM-Vorlagen). Diese Vorlagen kombinieren und behandeln die Ressourcenbereitstellung sowohl für Ressourcen der Verbrauchslogik-App als auch für die Infrastruktur. In single-tenant Azure Logic Apps ist die Bereitstellung einfacher, da Sie die Ressourcenbereitstellung zwischen Standardlogik-App-Ressourcen und Infrastruktur trennen können.

Wenn Sie eine Standard-Logik-App-Ressource erstellen, werden Ihre Workflows von der neu gestalteten Einzelmandanten-Azure-Logic-Apps-Runtime unterstützt. Diese Runtime wendet das Azure Functions-Erweiterbarkeitsmodell an und wird als Erweiterung der Azure Functions-Runtime gehostet. Dieser Entwurf bietet Portabilität, Flexibilität und eine höhere Leistung für Ihre Standard-Logik-Apps sowie weitere Funktionen und Vorteile der Azure Functions-Plattform und des Azure App Service-Ökosystems.

Beispielsweise können Sie die neu gestaltete Containerruntime und die Workflows als Teil Ihrer Standard-Logik-App zusammen verpacken. Sie können generische Schritte oder Aufgaben verwenden, die Ihre Logik-App-Ressourcen zu einsatzbereiten Artefakten aufbauen, zusammenstellen und komprimieren. Um Standard-Logik-Apps bereitzustellen, kopieren Sie die Artefakte in die Hostumgebung und starten dann Ihre Apps, um die Workflows auszuführen. Oder integrieren Sie Ihre Artefakte in Bereitstellungspipelines mithilfe der Tools und Prozesse, die Sie bereits kennen und verwenden. Wenn Ihr Szenario beispielsweise Container erfordert, können Sie Ihre Standard-Logik-Apps containerisieren und in Ihre vorhandenen Pipelines integrieren.

Zum Einrichten und Bereitstellen Ihrer Infrastrukturressourcen, z. B. virtuelle Netzwerke und Konnektivität, können Sie weiterhin ARM-Vorlagen verwenden und diese Ressourcen zusammen mit anderen Prozessen und Pipelines, die Sie für diese Zwecke verwenden, separat bereitstellen.

Mit Verwendung von Standardoptionen für Build und Bereitstellung können Sie sich getrennt von der Infrastrukturbereitstellung auf die App-Entwicklung konzentrieren. So erhalten Sie ein allgemeineres Projektmodell, in dem Sie viele ähnliche oder identische Bereitstellungsoptionen wie für eine generische App anwenden können. Außerdem profitieren Sie von einer konsistenteren Umgebung zum Erstellen von Bereitstellungspipelines für Ihre App-Projekte und zum Ausführen der erforderlichen Tests und Überprüfungen vor der Veröffentlichung in der Produktion. Unabhängig davon, welchen Technologiestapel Sie verwenden, können Sie Logik-Apps mithilfe Ihrer eigenen ausgewählten Tools bereitstellen.

DevOps-Bereitstellungsfunktionen

Azure Logic Apps-Instanzen mit nur einem Mandanten erben viele Funktionen und Vorteile von der Azure Functions-Plattform und dem Azure App Service-Ökosystem. Diese Updates bieten ein völlig neues Bereitstellungsmodell und weitere Möglichkeiten, DevOps für Ihre Logik-App-Workflows zu verwenden.

Lokale Entwicklung und Tests

Wenn Sie Visual Studio Code mit der Erweiterung Azure Logic Apps (Standard) verwenden, können Sie Standard-Logik-App-Workflows lokal in Ihrer Entwicklungsumgebung entwickeln, erstellen und ausführen, ohne eine Bereitstellung in Azure durchführen zu müssen. Wenn Für Ihr Szenario eine lokale Bereitstellung mithilfe der von Ihnen gesteuerten Infrastruktur erforderlich ist, lesen Sie "Erstellen von Standardlogik-App-Workflows für die Hybridbereitstellung in Ihrer eigenen Infrastruktur".

Diese Funktion ist eine wesentliche Verbesserung und bietet einen bedeutenden Vorteil im Vergleich zum Multitenant-Modell, das erfordert, dass Sie gegen eine vorhandene und laufende Ressource in Azure entwickeln.

Separate Belange

Das Einzelmandantenmodell bietet Ihnen die Möglichkeit, die Verantwortlichkeiten zwischen Ihrer Logik-App und der zugrunde liegenden Infrastruktur zu trennen. Beispielsweise können Sie Ihre App separat als unveränderliches Artefakt in verschiedenen Umgebungen entwickeln, erstellen, zippen und bereitstellen. Logik-App-Workflows verfügen in der Regel über „Anwendungscode“, den Sie häufiger aktualisieren als die zugrunde liegende Infrastruktur. Indem Sie diese Ebenen trennen, können Sie sich mehr auf die Erstellung des Workflows Ihrer Logik-App konzentrieren und müssen weniger Arbeit in die Bereitstellung der erforderlichen Ressourcen in mehreren Umgebungen investieren.

Ressourcenstruktur einer Logik-App

Im mehrinstanzenfähigen Azure Logic Apps-Modell kann die verbrauchsbasierte Logik-App-Ressourcenstruktur nur einen einzelnen Workflow enthalten. Aufgrund dieser 1:1-Beziehung werden Logik-App und Workflow häufig als synonym betrachtet und entsprechend referenziert. Im Azure Logic Apps-Modell mit einzelnem Mandanten kann die Ressourcenstruktur der Standard-Logik-App jedoch mehrere Workflows umfassen. Diese 1:N-Beziehung bedeutet, dass Workflows in derselben Logik-App andere Ressourcen freigeben und wiederverwenden können. In Workflows innerhalb derselben Logik-App und desselben Mandanten wird durch die gemeinsame Infrastruktur und die räumliche Nähe ebenfalls eine verbesserte Leistung erzielt. Diese Ressourcenstruktur ähnelt Azure Functions, wo eine Funktions-App viele Funktionen hosten kann.

Weitere Informationen und bewährte Methoden zum Organisieren von Workflows, Leistung und Skalierung in Ihrer Logik-App finden Sie im ähnlichen Leitfaden für Azure Functions, den Sie im Allgemeinen auf Azure Logic Apps mit einzelnem Mandanten anwenden können.

Projektstruktur einer Logik-App

In Visual Studio Code verfügt Ihr Logik-App-Projekt über einen der folgenden Typen:

• Der Standardtyp ist ein auf Erweiterungs-Bundles basierender Typ (Node.js).
• NuGet-paketbasiertes (.NET), das Sie vom Standardtyp konvertieren können

Basierend auf diesen Typen kann Ihr Projekt geringfügig unterschiedliche Ordner oder Dateien enthalten. Beispielsweise verfügt ein paketbasiertes Nuget-Projekt über einen .bin Ordner, der Pakete und andere Bibliotheksdateien enthält. Ein paketbasiertes Erweiterungsprojekt enthält diesen .bin Ordner nicht.

Für einige Szenarien ist ein paketbasiertes NuGet-Projekt erforderlich, damit Ihre App ausgeführt werden kann, z. B. wenn Sie benutzerdefinierte integrierte Vorgänge entwickeln und ausführen möchten. Weitere Informationen zum Konvertieren Ihres Projekts für die Verwendung von NuGet finden Sie unter Aktivieren der Erstellung von Connectoren.

Das standardmäßige paketbasierte Erweiterungsprojekt verfügt über eine Ordner- und Dateistruktur, die dem folgenden Beispiel ähnelt:

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

Auf der Stammebene Ihres Projekts finden Sie die folgenden Ordner und Dateien zusammen mit anderen Elementen:

Containerbereitstellung

Single-Tenant-Azure Logic Apps unterstützt die Bereitstellung in Containern. Sie können Ihre Logik-App-Workflows containerisieren und dort ausführen, wo Container ausgeführt werden können. Nach dem Containerisieren Ihrer App funktioniert die Bereitstellung größtenteils wie jeder andere Container, den Sie bereitstellen und verwalten.

Beispiele, die Azure DevOps enthalten, finden Sie unter CI/CD für Container.

App-Einstellungen und -Parameter

Bei mehrinstanzenfähigem Azure Logic Apps stellen ARM-Vorlagen eine Herausforderung dar, wenn Sie Umgebungsvariablen für Logik-Apps in verschiedenen Entwicklungs-, Test- und Produktionsumgebungen verwalten müssen. Sie definieren alles in einer ARM-Vorlage bei der Bereitstellung. Wenn Sie nur eine einzelne Variable ändern müssen, müssen Sie alles erneut bereitstellen.

In Azure Logic Apps-Instanzen mit nur einem Mandanten können Sie Ihre Umgebungsvariablen zur Laufzeit aufrufen und darauf verweisen, indem Sie App-Einstellungen und -Parameter verwenden, sodass Sie nicht so häufig erneut bereitstellen müssen.

Verwaltete Konnektoren und integrierte Operationen

Das Azure Logic Apps-Ökosystem bietet über 1.000 von Microsoft verwaltete und in Azure gehostete Konnektoren und integrierte Vorgänge als Teil einer ständig wachsenden Sammlung, die Sie in Azure Logic Apps für Mandanten verwenden können. Die Art und Weise, wie Microsoft die verwalteten Connectors handhabt, bleibt in Single-Tenant-Azure-Logic-Apps weitgehend gleich wie bei Multitenant-Azure-Logic-Apps.

Die wichtigste Verbesserung ist, dass der Single-Tenant-Dienst mehr beliebte verwaltete Konnektoren als integrierte Vorgänge bereitstellt. So können Sie etwa integrierte Vorgänge für Azure Service Bus, Azure Event Hubs, SQL und viele weitere nutzen. In der Zwischenzeit sind die verwalteten Connectorversionen weiterhin verfügbar und arbeiten weiterhin.

Die Verbindungen, die Sie mithilfe von Azure dienstbasierten integrierten Vorgängen erstellen, werden als integrierte Verbindungen oder serviceanbieterbasierte Verbindungen bezeichnet. Integrierte Vorgänge und die zugehörigen Verbindungen werden lokal in demselben Prozess ausgeführt wie Ihre Workflows. Beide werden in der neu gestalteten Azure Logic Apps-Runtime gehostet. Im Gegensatz dazu werden verwaltete Verbindungen oder API-Verbindungen separat als Azure Ressourcen erstellt und ausgeführt, die Sie mithilfe von ARM-Vorlagen bereitstellen. Aufgrund der Nähe zu Ihren Workflows bieten integrierte Vorgänge und deren Verbindungen eine bessere Leistung. Dieses Design ist auch für Bereitstellungspipelines geeignet, da die Dienstanbieterverbindungen in dasselbe Build-Artefakt gepackt werden.

Wenn Sie in Visual Studio Code mit dem Designer Ihre Workflows entwickeln oder Änderungen an ihnen vornehmen, generiert die Single-Tenant Azure Logic Apps-Engine automatisch alle erforderlichen Verbindungsmetadaten in der Datei connections.json Ihres Projekts. In den folgenden Abschnitten werden die drei Arten von Verbindungen beschrieben, die Sie in Ihren Workflows erstellen können. Jeder Verbindungstyp hat eine andere JSON-Struktur. Es ist wichtig, dies zu verstehen, da Endpunkte sich ändern, wenn Sie zwischen Umgebungen wechseln.

Dienstanbieterverbindungen

Wenn Sie einen integrierten Vorgang für einen Dienst wie Azure Service Bus oder Azure Event Hubs in Azure Logic Apps-Instanzen mit nur einem Mandanten verwenden, erstellen Sie eine Dienstanbieterverbindung, die im selben Prozess wie Ihr Workflow ausgeführt wird. Diese Verbindungsinfrastruktur wird als Teil Ihrer Logik-App-Ressource gehostet und verwaltet, und Ihre App-Einstellungen speichern die Verbindungszeichenfolgen für jeden integrierten Vorgang auf Dienstanbieterbasis, den Ihre Workflows verwenden.

In Ihrem Standard-Logik-App-Projekt verfügt jeder Workflow über eine workflow.json-Datei, die die zugrunde liegende JSON-Definition des Workflows enthält. Diese Workflowdefinition verweist auf die erforderlichen Verbindungszeichenfolgen in der connections.json Datei Ihres Projekts.

Das folgende Beispiel zeigt, wie die Dienstanbieterverbindung für einen integrierten Azure Service Bus-Vorgang in der Datei connections.json Ihres Projekts aussieht:

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

Verwaltete Verbindungen

Wenn Sie einen verwalteten Connector zum ersten Mal in Ihrem Workflow verwenden, werden Sie aufgefordert, eine verwaltete API-Verbindung für den Zieldienst oder das Zielsystem zu erstellen und Ihre Identität zu authentifizieren. Das gemeinsam genutzte Connectors-Ökosystem von Azure verwaltet diese Verbindungen. Die API-Verbindungen sind vorhanden und werden als separate Ressourcen in Azure ausgeführt.

Während Sie in Visual Studio Code weiterhin Ihren Workflow mithilfe des Designers erstellen und entwickeln, erstellt die Single-Tenant Azure Logic Apps-Engine automatisch die erforderlichen Ressourcen in Azure für die verwalteten Connectoren in Ihrem Workflow. Die Engine fügt diese Verbindungsressourcen automatisch der Azure-Ressourcengruppe hinzu, die Sie für Ihre Logik-App entworfen haben.

Das folgende Beispiel zeigt, wie eine API-Verbindung für den verwalteten Azure Service Bus-Connector in der Datei connections.json Ihres Projekts aussieht:

"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-Verbindungen

Verwenden Sie den Azure Functions integrierten Vorgang, um in Azure Functions erstellte und gehostete Funktionen aufzurufen. Verbindungsmetadaten für Azure Functions Anrufe unterscheiden sich von anderen integrierten Verbindungen. Diese Metadaten werden in der Datei connections.json Ihres Logik-App-Projekts gespeichert, sehen jedoch anders aus:

"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}"
   },
   <...>
}

Authentifizierung

Im Single-Tenant-Modell von Azure Logic Apps ist das Hostingmodell für Logic-App-Workflows ein einzelner Microsoft Entra-Mandant, in dem Ihre Workloads von einer stärkeren Isolation profitieren als im Multi-Tenant-Modell. Darüber hinaus ist die Einzelmandanten-Azure-Logic-Apps-Laufzeit portierbar, was bedeutet, dass Sie Ihre Workflows in anderen Umgebungen, wie beispielsweise in Visual Studio Code lokal, ausführen können. Dennoch erfordert dieser Entwurf, dass Logik-Apps eine Möglichkeit erhalten, ihre Identität zu authentifizieren, damit sie auf das Ökosystem der verwalteten Connectors in Azure zugreifen können. Ihre Apps benötigen auch die richtigen Berechtigungen zum Ausführen von Vorgängen, wenn verwaltete Verbindungen verwendet werden.

Standardmäßig verfügt jede auf einem einzelnen Mandanten basierende Logik-App über eine automatisch aktivierte systemseitig zugewiesene verwaltete Identität. Diese Identität unterscheidet sich von den Authentifizierungsinformationen oder der Verbindungszeichenfolge, die für die Herstellung einer Verbindung verwendet werden. Zur Laufzeit verwendet Ihre Logik-App diese Identität, um die Verbindungen über Azure-Zugriffsrichtlinien zu authentifizieren. Wenn Sie diese Identität ausschalten, funktionieren die Verbindungen zur Laufzeit nicht.

Die folgenden Abschnitte enthalten weitere Informationen zu den Authentifizierungstypen, die Sie zum Authentifizieren verwalteter Verbindungen verwenden können, je nachdem, wo Ihre Logik-App ausgeführt wird. Für jede verwaltete Verbindung verfügt die Datei connections.json Ihres Logik-App-Projekts über ein authentication-Objekt, das den Authentifizierungstyp angibt, den Ihre Logik-App zum Authentifizieren dieser verwalteten Verbindung verwenden kann.

Verwaltete Identität

Für eine in Azure gehostete und ausgeführte Logik-App ist eine verwaltete Identität der standardmäßige und empfohlene Authentifizierungstyp zur Authentifizierung in Azure gehosteter und ausgeführter verwalteter Verbindungen. In der Datei connections.json Ihres Logik-App-Projekts verfügt die verwaltete Verbindung über ein authentication-Objekt, das ManagedServiceIdentity als Authentifizierungstyp angibt:

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

Rohzustand

Für Logik-Apps, die in Ihrer lokalen Entwicklungsumgebung mithilfe von Visual Studio Code ausgeführt werden, authentifizieren unformatierte Authentifizierungsschlüssel verwaltete Verbindungen, die in Azure gehostet und ausgeführt werden. Verwenden Sie diese Schlüssel nur für die Entwicklung, nicht für die Produktion, da sie nach sieben Tagen ablaufen. In der connections.json-Datei Ihres Logik-App-Projekts enthält die verwaltete Verbindung ein authentication Objekt, das die folgenden Authentifizierungsinformationen angibt:

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

Verwandte Inhalte

• Einrichten der DevOps-Bereitstellung für Azure Logic Apps-Instanzen mit nur einem Mandanten