DevOps-Bereitstellung für Azure Logic Apps-Instanzen mit nur einem Mandanten
Gilt für: Azure Logic Apps (Standard)
Im Zuge des Trends zu verteilten und nativen Cloud-Apps haben Organisationen mit mehr verteilten Komponenten in mehr Umgebungen zu tun. Um die Kontrolle und Konsistenz zu gewährleisten, können Sie mithilfe von DevOps-Tools und -Prozessen Ihre Umgebungen automatisieren und schneller und sicherer mehr Komponenten bereitstellen.
Dieser Artikel bietet eine Einführung und eine Übersicht zur aktuellen CI/CD-Benutzeroberfläche (Continuous Integration und Continuous Deployment) für Azure Logic Apps-Instanzen mit nur einem Mandanten.
Mit nur einem Mandanten im Vergleich zu mehrinstanzenfähig
In mehrinstanzenfähigen Azure Logic Apps-Instanzen hängt die Ressourcenbereitstellung von ARM-Vorlagen (Azure Resource Manager) ab, die die Ressourcenbereitstellung für Logik-Apps und die Infrastruktur kombinieren und verarbeiten. In Azure Logic Apps-Instanzen mit nur einem Mandanten wird die Bereitstellung einfacher, da Sie die Ressourcenbereitstellung zwischen Apps und der Infrastruktur trennen können.
Wenn Sie Logik-Apps mithilfe des Ressourcentyps Logik-App (Standard) erstellen, werden Ihre Workflows von der neu gestalteten Azure Logic Apps-Runtime mit nur einem Mandanten unterstützt. Diese Runtime wendet die Erweiterbarkeit mithilfe des Azure Functions-Erweiterbarkeitsmodells 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 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 Logik-App zusammen verpacken. Sie können mit allgemeinen Schritten oder Aufgaben Ihre Logik-App-Ressourcen erstellen, zusammenstellen und in bereitstellungsbereite Artefakte zippen. Kopieren Sie zum Bereitstellen Ihrer Apps die Artefakte in die Hostumgebung. Starten Sie anschließend die Apps, um Ihre Workflows auszuführen. Alternativ können Sie Ihre Artefakte mithilfe der Tools und Prozesse, die Sie bereits kennen und verwenden, in Bereitstellungspipelines integrieren. Wenn Ihr Szenario beispielsweise Container erfordert, können Sie Ihre 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. Welchen Technologiestapel Sie auch verwenden, Sie können Logik-Apps mit den Tools Ihrer Wahl 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 auf einem einzelnen Mandanten basierende Logik-App-Workflows lokal in Ihrer Entwicklungsumgebung entwickeln, erstellen und ausführen, ohne eine Bereitstellung in Azure durchführen zu müssen. Wenn Ihr Szenario Container erfordert, können Sie über Logik-Apps mit Azure Arc-Unterstützung erstellen und bereitstellen.
Verglichen mit dem mehrinstanzenfähigen Modell, bei dem Sie für eine vorhandene, in Azure ausgeführte Ressource entwickeln müssen, bietet diese Funktion eine erhebliche Verbesserung und einen entscheidenden Vorteil.
Separate Aspekte
Das Modell mit nur einem Mandanten bietet Ihnen die Möglichkeit, die Aspekte der 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. Workflows in derselben Logik-App und demselben Mandanten bieten aufgrund dieses freigegebenen Mandanten und der Nähe zueinander auch eine verbesserte Leistung. 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:
- Erweiterungs-Bundle-basiert (Node.js), was der Standardtyp ist
- NuGet-paketbasiertes (.NET), das Sie vom Standardtyp konvertieren können
Basierend auf diesen Typen enthält Ihr Projekt leicht unterschiedliche Ordner und Dateien. Ein NuGet-basiertes Projekt enthält einen .bin-Ordner, der Pakete und andere Bibliotheksdateien enthält. Ein Bundle-basiertes Projekt enthält nicht den .bin Ordner und andere Dateien. Einige Szenarien erfordern ein NuGet-basiertes Projekt, 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 zur Verwendung von NuGet finden Sie unter Aktivieren der Erstellung Connector-Entwicklung.
Für das standardmäßige Bundle-basierte Projekt verfügt Ihr Projekt über eine Ordner- und Dateistruktur, die dem folgenden Beispiel ähnelt:
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
Auf der Stammebene Ihres Projekts finden Sie die folgenden Dateien und Ordner mit anderen Elementen:
| Name | Ordner oder Datei | Beschreibung |
|---|---|---|
| .vscode | Ordner | Enthält auf Visual Studio Code-bezogene Einstellungsdateien, z. B. extensions.json, launch.json, settings.json und tasks.json. |
| Artefakte | Ordner | Enthält Integrationskontoartefakte, die Sie definieren und in Workflows verwenden, die Business-to-Business-Szenarien (B2B-Szenarien) unterstützen. Die Beispielstruktur enthält beispielsweise Zuordnungen und Schemas für XML-Transformations- und -Validierungsvorgänge. |
| <WorkflowName> | Ordner | Für jeden Workflow enthält der <WorkflowName>-Ordner eine workflow.json-Datei, die die zugrunde liegende JSON-Definition dieses Workflows enthält. |
| workflow-designtime | Ordner | Enthält Entwicklungsumgebungsbezogene Einstellungsdateien. |
| .funcignore | File | Enthält Informationen zu Ihren installierten Azure Functions Core Tools. |
| connections.json | File | Enthält die Metadaten, Endpunkte und Schlüssel für alle verwalteten Verbindungen und Azure-Funktionen, die von Ihren Workflows verwendet werden. Wichtiger Hinweis: Um unterschiedliche Verbindungen und Funktionen in jeder Umgebung zu verwenden, stellen Sie sicher, dass Sie die Datei connections.json parametrisieren und die Endpunkte aktualisieren. |
| host.json | File | Enthält laufzeitspezifische Konfigurationseinstellungen und -werte, z. B. die Standardgrenzwerte für die Azure Logic Apps-Einzelmandanten-Plattform, Logik-Apps, Workflows, Auslöser und Aktionen. Auf der Stammebene Ihres Logik-App-Projekts enthält die host.json Metadatendatei die Konfigurationseinstellungen und Standardwerte, die alle Workflows in derselben Logik-App während der Ausführung verwenden, ob lokal oder in Azure. Hinweis: Wenn Sie Ihre Logik-App erstellen, erstellt Visual Studio Code eine host.snapshot.*.json-Sicherungsdatei in Ihrem Speichercontainer. Wenn Sie Ihre Logik-App löschen, wird diese Sicherungsdatei nicht gelöscht. Wenn Sie eine weitere Logik-App mit dem gleichen Namen erstellen, wird eine weitere Momentaufnahmedatei erstellt. Sie können nur bis zu 10 Momentaufnahmen für dieselbe Logik-App erstellen. Wenn Sie diesen Grenzwert überschreiten, erhalten Sie den folgenden Fehler: Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Um diesen Fehler zu beheben, löschen Sie die zusätzlichen Momentaufnahmedateien aus Ihrem Speichercontainer. |
| local.settings.json | File | Enthält App-Einstellungen, Verbindungszeichenfolgen und andere Einstellungen, die Ihre Workflows bei der lokalen Ausführung verwenden. Anders ausgedrückt, geltend diese Einstellungen und Werte nur, wenn Sie Ihre Projekte in Ihrer lokalen Entwicklungsumgebung ausführen. Während der Bereitstellung in Azure werden die Datei und die Einstellungen ignoriert und nicht in Ihre Bereitstellung einbezogen. Diese Datei speichert Einstellungen und Werte als lokale Umgebungsvariablen, die von Ihren lokalen Bereitstellungstools als appSettings-Werte verwendet werden. Sie können diese Umgebungsvariablen sowohl zur Laufzeit als auch zur Bereitstellungszeit aufrufen und beziehen, indem Sie App-Einstellungen und Parameter verwenden. Wichtiger Hinweis: Die Datei local.settings.json kann Geheimnisse enthalten. Stellen Sie daher sicher, dass Sie diese Datei auch aus der Quellcodeverwaltung Ihres Projekts ausschließen. |
Containerbereitstellung
Azure Logic Apps-Instanzen mit nur einem Mandanten unterstützen die Bereitstellung in Containern. Dies bedeutet, dass Sie Ihre Logik-App-Workflows containerisieren und überall dort ausführen können, 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 mit Azure DevOps finden Sie unter CI/CD für Container.
App-Einstellungen und -Parameter
In mehrinstanzenfähigen Azure Logic Apps-Instanzen stellen ARM-Vorlagen eine Herausforderung dar, wenn Sie Umgebungsvariablen für Logik-Apps in verschiedenen Entwicklungs-, Test- und Produktionsumgebungen verwalten müssen. Alles in einer ARM-Vorlage wird bei der Bereitstellung definiert. 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 Runtime aufrufen und darauf verweisen, indem Sie App-Einstellungen und -Parameter verwenden, sodass Sie nicht so oft erneut bereitstellen müssen.
Verwaltete Connectors und integrierte Vorgänge
Das Azure Logic Apps-Ökosystem bietet Hunderte von Microsoft verwaltete Connectors und integrierte Vorgänge als Teil einer ständig wachsenden Sammlung, die Sie in Azure Logic Apps-Instanzen mit nur einem Mandanten verwenden können. Die Art und Weise, wie Microsoft diese Connectors und integrierten Vorgänge verwaltet, bleibt in Azure Logic Apps-Instanzen mit nur einem Mandanten größtenteils gleich.
Die wichtigste Verbesserung ist, dass der Einzelmandantendienst beliebte verwaltete Connectors auch als integrierte Vorgänge zur Verfügung stellt. So können Sie etwa integrierte Vorgänge für Azure Service Bus, Azure Event Hubs, SQL usw. nutzen. In der Zwischenzeit sind die verwalteten Connectorversionen weiterhin verfügbar und funktionieren.
Die Verbindungen, die Sie mit integrierten Vorgängen erstellen, werden als integrierte Verbindungen oder Dienstanbieterverbindungen bezeichnet. Integrierte Vorgänge und ihre Verbindungen sowie Ihre Workflows werden lokal in demselben Prozess ausgeführt. Beide werden auf der neu gestalteten 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. Diese Methode ist auch für Bereitstellungspipelines geeignet, da die Dienstanbieterverbindungen in dasselbe Buildartefakt gepackt werden.
Wenn Sie in Visual Studio Code mit dem Designer Ihre Workflows entwickeln oder Änderungen an ihnen vornehmen, generiert die 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 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 dann auf die erforderlichen Verbindungszeichenfolgen in der Datei „connections.json“ des Projekts.
Das folgende Beispiel zeigt, wie die Dienstanbieterverbindung für einen integrierten Service Bus-Vorgang in der connections.json-Datei 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. Diese Connectors werden vom Ökosystem für freigegebene Connectors in Azure verwaltet. Die API-Verbindungen sind vorhanden und werden als separate Ressourcen in Azure ausgeführt.
In Visual Studio Code erstellt die Logic Apps-Engine automatisch für die verwalteten Connectors in Ihrem Workflow die erforderlichen Ressourcen in Azure, während Sie Ihren Workflow weiterhin mit dem Designer erstellen und entwickeln. 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 Service Bus-Connector in der connections.json-Datei 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
Zum Aufrufen in Azure Functions erstellter und gehosteter Funktionen verwenden Sie den integrierten Azure Functions-Vorgang. Verbindungsmetadaten für Azure Functions-Aufrufe unterscheiden sich von denen anderer integrierter Verbindungen. Diese Metadaten werden in der connections.json-Datei 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
In Azure Logic Apps-Instanzen mit nur einem Mandanten ist das Hostingmodell für Logik-App-Workflows ein einzelner Mandant, bei dem Ihre Workloads von einer größeren Isolation als beim mehrinstanzenfähigen Modell profitieren. Darüber hinaus ist die Azure Logic Apps-Runtime für Einzelmandanten portierbar, was bedeutet, dass Sie Ihre Workflows in anderen Umgebungen ausführen können, z. B. lokal in Visual Studio Code. 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 Anmeldeinformationen für die Authentifizierung oder der Verbindungszeichenfolge, die Sie verwenden, wenn Sie eine Verbindung herstellen. Zur Runtime verwendet Ihre Logik-App diese Identität, um ihre Verbindungen über Azure-Zugriffsrichtlinien zu authentifizieren. Wenn Sie diese Identität deaktivieren, funktionieren 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 connections.json-Datei 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 connections.json-Datei Ihres Logik-App-Projekts verfügt die verwaltete Verbindung über ein authentication-Objekt, das ManagedServiceIdentity als Authentifizierungstyp angibt:
"authentication": {
"type": "ManagedServiceIdentity"
}
Raw
Für in Ihrer lokalen Entwicklungsumgebung mithilfe von Visual Studio Code ausgeführte Logik-Apps werden unformatierte Authentifizierungsschlüssel zur Authentifizierung in Azure gehosteter und ausgeführter verwalteter Verbindungen verwendet. Diese Schlüssel sind nur für die Entwicklung und nicht für die Produktion konzipiert und laufen nach sieben Tagen ab. In der connections.json-Datei Ihres Logik-App-Projekts verfügt die verwaltete Verbindung über ein authentication-Objekt, das folgende Authentifizierungsinformationen angibt:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}