DevOps-implementatie voor Azure Logic Apps met een enkele tenant

Artikel
01/04/2024

Van toepassing op: Azure Logic Apps (Standard)

Met de trend naar gedistribueerde en systeemeigen cloud-apps hebben organisaties te maken met meer gedistribueerde onderdelen in meer omgevingen. Om de controle en consistentie te behouden, kunt u uw omgevingen automatiseren en meer onderdelen sneller en betrouwbaarder implementeren met behulp van DevOps-hulpprogramma's en -processen.

Dit artikel bevat een inleiding en een overzicht van de huidige ci/cd-ervaring (continue integratie en continue implementatie) voor Azure Logic Apps met één tenant.

Eén tenant versus meerdere tenants

In azure Logic Apps met meerdere tenants is de resource-implementatie gebaseerd op Azure Resource Manager-sjablonen (ARM-sjablonen), die het inrichten van resources combineren en verwerken voor zowel logische apps als infrastructuur. In Azure Logic Apps met één tenant wordt de implementatie eenvoudiger omdat u het inrichten van resources kunt scheiden tussen apps en infrastructuur.

Wanneer u logische apps maakt met behulp van het resourcetype Logic App (Standard), worden uw werkstromen mogelijk gemaakt door de opnieuw ontworpen Azure Logic Apps-runtime met één tenant. Deze runtime maakt gebruik van de uitbreidbaarheid van het Azure Functions uitbreidbaarheidsmodel en wordt gehost als een extensie op de Azure Functions runtime. Dit ontwerp biedt draagbaarheid, flexibiliteit en betere prestaties voor uw logische apps, plus andere mogelijkheden en voordelen die zijn overgenomen van het Azure Functions-platform en Azure App Service ecosysteem.

U kunt bijvoorbeeld de opnieuw ontworpen containerruntime en werkstromen samen verpakken als onderdeel van uw logische app. U kunt algemene stappen of taken gebruiken voor het bouwen, samenstellen en zippen van uw logische app-resources in kant-en-klare artefacten. Als u uw apps wilt implementeren, kopieert u de artefacten naar de hostomgeving en start u vervolgens uw apps om uw werkstromen uit te voeren. Of integreer uw artefacten in implementatiepijplijnen met behulp van de hulpprogramma's en processen die u al kent en gebruikt. Als voor uw scenario bijvoorbeeld containers zijn vereist, kunt u uw logische apps in een container plaatsen en deze integreren in uw bestaande pijplijnen.

Als u uw infrastructuurresources, zoals virtuele netwerken en connectiviteit, wilt instellen en implementeren, kunt u ARM-sjablonen blijven gebruiken en deze resources afzonderlijk inrichten samen met andere processen en pijplijnen die u voor deze doeleinden gebruikt.

Door standaardopties voor bouwen en implementeren te gebruiken, kunt u zich afzonderlijk richten op het ontwikkelen van apps en de implementatie van de infrastructuur. Als gevolg hiervan krijgt u een meer algemeen projectmodel waarin u veel vergelijkbare of dezelfde implementatieopties kunt toepassen die u voor een algemene app gebruikt. U profiteert ook van een consistentere ervaring voor het bouwen van implementatiepijplijnen rond uw app-projecten en voor het uitvoeren van de vereiste tests en validaties voordat u naar productie publiceert. Ongeacht welke technologiestack u gebruikt, kunt u logische apps implementeren met behulp van uw eigen gekozen hulpprogramma's.

DevOps-implementatiemogelijkheden

Azure Logic Apps met één tenant neemt veel mogelijkheden en voordelen over van het Azure Functions-platform en Azure App Service ecosysteem. Deze updates bevatten een geheel nieuw implementatiemodel en meer manieren om DevOps te gebruiken voor uw logische app-werkstromen.

Lokale ontwikkeling en testen

Wanneer u Visual Studio Code gebruikt met de Azure Logic Apps (Standard)-extensie, kunt u werkstromen voor logische apps met één tenant lokaal ontwikkelen, bouwen en uitvoeren in uw ontwikkelomgeving zonder dat u naar Azure hoeft te implementeren. Als uw scenario containers vereist, kunt u maken en implementeren via Logic Apps met Azure Arc.

Deze mogelijkheid is een belangrijke verbetering en biedt een aanzienlijk voordeel ten opzichte van het model met meerdere tenants, waarvoor u moet ontwikkelen op basis van een bestaande en actieve resource in Azure.

Afzonderlijke problemen

Het model met één tenant biedt u de mogelijkheid om de problemen tussen de app en de onderliggende infrastructuur te scheiden. U kunt uw app bijvoorbeeld afzonderlijk ontwikkelen, bouwen, zippen en implementeren als een onveranderbaar artefact in verschillende omgevingen. Werkstromen voor logische apps bevatten doorgaans 'toepassingscode' die u vaker bijwerkt dan de onderliggende infrastructuur. Door deze lagen te scheiden, kunt u zich meer richten op het uitbouwen van de werkstroom van uw logische app en minder besteden aan het implementeren van de vereiste resources in meerdere omgevingen.

Conceptueel diagram met afzonderlijke implementatiepijplijnen voor apps en infrastructuur.

Resourcestructuur van logische app

In het Azure Logic Apps-model met meerdere tenants kan de resourcestructuur van de logische app Verbruik slechts één werkstroom bevatten. Vanwege deze een-op-een-relatie worden zowel logische app als werkstroom vaak als synoniem beschouwd en waarnaar wordt verwezen. In het Azure Logic Apps-model met één tenant kan de resourcestructuur van de logische standaard-app echter meerdere werkstromen bevatten. Deze een-op-veel-relatie betekent dat in dezelfde logische app werkstromen andere resources kunnen delen en hergebruiken. Werkstromen in dezelfde logische app en tenant bieden ook verbeterde prestaties vanwege deze gedeelde tenancy en nabijheid tot elkaar. Deze resourcestructuur ziet eruit en werkt op dezelfde manier als Azure Functions waar een functie-app veel functies kan hosten.

Raadpleeg de vergelijkbare richtlijnen voor Azure Functions die u over het algemeen kunt toepassen op Azure Logic Apps met één tenant voor meer informatie en aanbevolen procedures voor het organiseren van werkstromen, prestaties en schalen in uw logische app.

Projectstructuur van logische app

In Visual Studio Code heeft uw logische app-project een van de volgende typen:

Uitbreidingsbundel (Node.js), het standaardtype
Op nuGet-pakketten (.NET) gebaseerd, die u kunt converteren van het standaardtype

Op basis van deze typen bevat uw project iets andere mappen en bestanden. Een NuGet-project bevat een .bin-map die pakketten en andere bibliotheekbestanden bevat. Een project op basis van een bundel bevat niet de map .bin en andere bestanden. Voor sommige scenario's is een op NuGet gebaseerd project vereist om uw app uit te voeren, bijvoorbeeld wanneer u aangepaste ingebouwde bewerkingen wilt ontwikkelen en uitvoeren. Zie Ontwerp van ingebouwde connector inschakelen voor meer informatie over het converteren van uw project voor het gebruik van NuGet.

Voor het standaardbundelproject heeft uw project een map- en bestandsstructuur die vergelijkbaar is met het volgende voorbeeld:

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

Op het hoofdniveau van uw project vindt u de volgende bestanden en mappen met andere items:

Naam	Map of bestand	Description
.vscode	Map	Bevat aan Visual Studio Code gerelateerde instellingenbestanden, zoals extensions.json-, launch.json-, settings.json- en tasks.json-bestanden .
Artefacten	Map	Bevat integratieaccountartefacten die u definieert en gebruikt in werkstromen die B2B-scenario's (business-to-business) ondersteunen. De voorbeeldstructuur bevat bijvoorbeeld toewijzingen en schema's voor XML-transformatie- en validatiebewerkingen.
*<WorkflowName>*	Map	Voor elke werkstroom bevat de < map WorkflowName> een workflow.json-bestand, dat de onderliggende JSON-definitie van die werkstroom bevat.
workflow-designtime	Map	Bevat bestanden met betrekking tot de ontwikkelomgeving.
.funcignore	File	Bevat informatie met betrekking tot uw geïnstalleerde Azure Functions Core Tools.
connections.json	File	Bevat de metagegevens, eindpunten en sleutels voor alle beheerde verbindingen en Azure-functies die uw werkstromen gebruiken. Belangrijk: als u verschillende verbindingen en functies voor elke omgeving wilt gebruiken, moet u dit bestand connections.json parameteriseren en de eindpunten bijwerken.
host.json	File	Bevat runtime-specifieke configuratie-instellingen en -waarden, bijvoorbeeld de standaardlimieten voor het Azure Logic Apps-platform met één tenant, logische apps, werkstromen, triggers en acties. Op het hoofdniveau van uw logische app-project bevat het metagegevensbestand host.json de configuratie-instellingen en standaardwaarden die alle werkstromen in dezelfde logische app gebruiken tijdens het uitvoeren, lokaal of in Azure. Opmerking: wanneer u uw logische app maakt, maakt Visual Studio Code een back-up *van het host.snapshot..json-bestand** in uw opslagcontainer. Als u uw logische app verwijdert, wordt dit back-upbestand niet verwijderd. Als u een andere logische app met dezelfde naam maakt, wordt een ander momentopnamebestand gemaakt. U kunt maximaal 10 momentopnamen voor dezelfde logische app hebben. Als u deze limiet overschrijdt, krijgt u de volgende fout: `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))` U kunt deze fout oplossen door de extra momentopnamebestanden uit uw opslagcontainer te verwijderen.
local.settings.json	File	Bevat app-instellingen, verbindingsreeksen en andere instellingen die uw werkstromen gebruiken wanneer ze lokaal worden uitgevoerd. Met andere woorden, deze instellingen en waarden zijn alleen van toepassing wanneer u uw projecten uitvoert in uw lokale ontwikkelomgeving. Tijdens de implementatie in Azure worden het bestand en de instellingen genegeerd en niet opgenomen in uw implementatie. In dit bestand worden instellingen en waarden opgeslagen als lokale omgevingsvariabelen die door uw lokale ontwikkelhulpprogramma's worden gebruikt als de `appSettings` waarden. U kunt deze omgevingsvariabelen zowel tijdens runtime als tijdens de implementatie aanroepen en ernaar verwijzen met behulp van app-instellingen en -parameters. Belangrijk: het bestand local.settings.json kan geheimen bevatten, dus zorg ervoor dat u dit bestand ook uitsluit van het broncodebeheer van uw project.

Containerimplementatie

Azure Logic Apps met één tenant ondersteunt implementatie in containers, wat betekent dat u uw werkstromen voor logische apps in een container kunt plaatsen en deze kunt uitvoeren waar containers kunnen worden uitgevoerd. Nadat u uw app in een container hebt geplaatst, werkt de implementatie grotendeels hetzelfde als elke andere container die u implementeert en beheert.

Raadpleeg CI/CD voor containers voor voorbeelden met Azure DevOps.

App-instellingen en -parameters

In Azure Logic Apps met meerdere tenants vormen ARM-sjablonen een uitdaging wanneer u omgevingsvariabelen voor logische apps in verschillende ontwikkel-, test- en productieomgevingen moet onderhouden. Alles in een ARM-sjabloon wordt gedefinieerd tijdens de implementatie. Als u slechts één variabele wilt wijzigen, moet u alles opnieuw implementeren.

In Azure Logic Apps met één tenant kunt u tijdens runtime uw omgevingsvariabelen aanroepen en ernaar verwijzen met behulp van app-instellingen en -parameters, zodat u niet zo vaak opnieuw hoeft te implementeren.

Beheerde connectors en ingebouwde bewerkingen

Het Azure Logic Apps-ecosysteem biedt honderden door Microsoft beheerde connectors en ingebouwde bewerkingen als onderdeel van een voortdurend groeiende verzameling die u kunt gebruiken in Azure Logic Apps met één tenant. De manier waarop Microsoft deze connectors en ingebouwde bewerkingen onderhoudt, blijft grotendeels hetzelfde in Azure Logic Apps met één tenant.

De belangrijkste verbetering is dat de service met één tenant meer populaire beheerde connectors ook beschikbaar maakt als ingebouwde bewerkingen. U kunt bijvoorbeeld ingebouwde bewerkingen gebruiken voor Azure Service Bus, Azure Event Hubs, SQL en andere. Ondertussen zijn de versies van de beheerde connector nog steeds beschikbaar en blijven ze werken.

De verbindingen die u maakt met behulp van ingebouwde bewerkingen, worden ingebouwde verbindingen of serviceproviderverbindingen genoemd. Ingebouwde bewerkingen en de bijbehorende verbindingen worden lokaal uitgevoerd in hetzelfde proces dat uw werkstromen uitvoert. Beide worden gehost op de opnieuw ontworpen Logic Apps-runtime. Beheerde verbindingen, of API-verbindingen, worden daarentegen afzonderlijk gemaakt en uitgevoerd als Azure-resources, die u implementeert met behulp van ARM-sjablonen. Als gevolg hiervan bieden ingebouwde bewerkingen en hun verbindingen betere prestaties vanwege de nabijheid van uw werkstromen. Dit ontwerp werkt ook goed met implementatiepijplijnen, omdat de verbindingen van de serviceprovider zijn verpakt in hetzelfde build-artefact.

Wanneer u in Visual Studio Code de ontwerpfunctie gebruikt om werkstromen te ontwikkelen of er wijzigingen in aan te brengen, genereert de Logic Apps-engine automatisch alle benodigde verbindingsmetagegevens in het bestand connections.json van uw project. In de volgende secties worden de drie soorten verbindingen beschreven die u in uw werkstromen kunt maken. Elk verbindingstype heeft een andere JSON-structuur. Dit is belangrijk om te begrijpen omdat eindpunten veranderen wanneer u tussen omgevingen navigeert.

Verbindingen van serviceproviders

Wanneer u een ingebouwde bewerking gebruikt voor een service zoals Azure Service Bus of Azure Event Hubs in Azure Logic Apps met één tenant, maakt u een serviceproviderverbinding die wordt uitgevoerd in hetzelfde proces als uw werkstroom. Deze verbindingsinfrastructuur wordt gehost en beheerd als onderdeel van uw logische app-resource, en uw app-instellingen slaan de verbindingsreeksen op voor elke ingebouwde bewerking op basis van serviceproviders die uw werkstromen gebruiken.

In uw logische app-project heeft elke werkstroom een workflow.json-bestand dat de onderliggende JSON-definitie van de werkstroom bevat. Deze werkstroomdefinitie verwijst vervolgens naar de benodigde verbindingsreeksen in het bestand connections.json van uw project.

In het volgende voorbeeld ziet u hoe de verbinding van de serviceprovider voor een ingebouwde Service Bus-bewerking wordt weergegeven in het bestand connections.json van uw project:

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

Beheerde verbindingen

Wanneer u voor het eerst een beheerde connector in uw werkstroom gebruikt, wordt u gevraagd om een beheerde API-verbinding te maken voor de doelservice of het doelsysteem en uw identiteit te verifiëren. Deze connectors worden beheerd door het ecosysteem van gedeelde connectors in Azure. De API-verbindingen bestaan en worden uitgevoerd als afzonderlijke resources in Azure.

Terwijl u in Visual Studio Code uw werkstroom maakt en ontwikkelt met behulp van de ontwerpfunctie, maakt de Logic Apps-engine automatisch de benodigde resources in Azure voor de beheerde connectors in uw werkstroom. De engine voegt deze verbindingsresources automatisch toe aan de Azure-resourcegroep die u hebt ontworpen om uw logische app te bevatten.

In het volgende voorbeeld ziet u hoe een API-verbinding voor de beheerde Service Bus-connector wordt weergegeven in het bestand connections.json van uw project:

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

Als u functies wilt aanroepen die zijn gemaakt en gehost in Azure Functions, gebruikt u de ingebouwde Azure Functions-bewerking. Verbindingsmetagegevens voor Azure Functions-aanroepen verschillen van andere ingebouwde verbindingen. Deze metagegevens worden opgeslagen in het bestand connections.json van uw logische app-project, maar zien er anders uit:

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

Verificatie

In Azure Logic Apps met één tenant is het hostingmodel voor werkstromen voor logische apps één tenant waarbij uw workloads profiteren van meer isolatie dan in het model met meerdere tenants. Bovendien is de Azure Logic Apps-runtime met één tenant draagbaar, wat betekent dat u uw werkstromen in andere omgevingen kunt uitvoeren, bijvoorbeeld lokaal in Visual Studio Code. Toch vereist dit ontwerp een manier voor logische apps om hun identiteit te verifiëren, zodat ze toegang hebben tot het ecosysteem van de beheerde connector in Azure. Uw apps hebben ook de juiste machtigingen nodig om bewerkingen uit te voeren bij het gebruik van beheerde verbindingen.

Standaard heeft elke logische app op basis van één tenant een automatisch ingeschakelde door het systeem toegewezen beheerde identiteit. Deze identiteit verschilt van de verificatiereferenties of connection string gebruikt voor het maken van een verbinding. Tijdens runtime gebruikt uw logische app deze identiteit om de verbindingen te verifiëren via Azure-toegangsbeleid. Als u deze identiteit uitschakelt, werken verbindingen niet tijdens runtime.

De volgende secties bevatten meer informatie over de verificatietypen die u kunt gebruiken om beheerde verbindingen te verifiëren, op basis van waar uw logische app wordt uitgevoerd. Voor elke beheerde verbinding bevat het bestand connections.json van uw logische app-project een authentication -object dat het verificatietype aangeeft dat uw logische app kan gebruiken om die beheerde verbinding te verifiëren.

Beheerde identiteit

Voor een logische app die wordt gehost en uitgevoerd in Azure, is een beheerde identiteit het standaardverificatietype en het aanbevolen verificatietype voor het verifiëren van beheerde verbindingen die worden gehost en uitgevoerd in Azure. In het bestand connections.json van uw logische app-project heeft de beheerde verbinding een authentication -object dat als verificatietype opgeeft ManagedServiceIdentity :

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

Onbewerkt

Voor logische apps die worden uitgevoerd in uw lokale ontwikkelomgeving met behulp van Visual Studio Code, worden onbewerkte verificatiesleutels gebruikt voor het verifiëren van beheerde verbindingen die worden gehost en uitgevoerd in Azure. Deze sleutels zijn alleen ontworpen voor gebruik in ontwikkeling, niet voor productie en hebben een verloop van zeven dagen. In het bestand connections.json van uw logische app-project bevat de beheerde verbinding een authentication -object waarmee de volgende verificatiegegevens worden opgegeven:

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

Volgende stappen

DevOps-implementatie voor Azure Logic Apps met een enkele tenant instellen