DevOps-implementatie voor standaard logische apps in Azure Logic Apps met één tenant

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. Als u controle en consistentie wilt 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 standaardwerkstromen voor logische apps in Azure Logic Apps met één tenant.

Eén tenant versus meerdere tenants

In Azure Logic Apps met meerdere tenants is de implementatie van resources gebaseerd op ARM-sjablonen (Azure Resource Manager-sjablonen), die de provisioning van resources voor zowel de verbruikende logische app-bronnen als de infrastructuur combineren en verwerken. In single-tenant Azure Logic Apps wordt de implementatie eenvoudiger omdat u de resource-provisioning van Standard logische app-resources en infrastructuur kunt scheiden.

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

U kunt bijvoorbeeld de opnieuw ontworpen gegcontaineriseerde runtime en werkstromen samen verpakken als onderdeel van uw ‘Standard Logic App’. U kunt algemene stappen of taken gebruiken die uw resources voor logische apps bouwen, samenstellen en zippen in kant-en-klare artefacten. Als u logische standaard-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 Standaard logische apps in een container zetten en deze integreren in uw bestaande pijplijnen.

Als u uw infrastructuurbronnen, 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 richten op app-ontwikkeling afzonderlijk van 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 hulpprogramma's.

DevOps-implementatiemogelijkheden

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

Lokale ontwikkeling en testen

Wanneer u Visual Studio Code gebruikt met de Azure Logic Apps-extensie (Standard), kunt u lokaal werkstromen voor logische apps ontwikkelen, bouwen en uitvoeren in uw ontwikkelomgeving zonder dat u in Azure hoeft te implementeren. Als voor uw scenario on-premises implementatie is vereist met behulp van de infrastructuur die u bepaalt, raadpleegt u Standaardwerkstromen voor logische apps maken voor hybride implementatie in uw eigen infrastructuur.

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

Afzonderlijke zorgen

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

Resourcestructuur voor logische apps

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 apps als werkstromen vaak als synoniem beschouwd en waarnaar wordt verwezen. In het Azure Logic Apps-model met één tenant kan de resourcestructuur van de standaard logische 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 logic app en tenant bieden ook verbeterde prestaties dankzij deze gedeelde huur en hun nabijheid tot elkaar. Deze resourcestructuur ziet er ongeveer uit en werkt op dezelfde manier als Azure Functions, waar een functie-app veel functies kan hosten.

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

Structuur van Logic App-project

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

• Uitbreidingsbundel (Node.js), het standaardtype
• NuGet-pakketgebaseerd (.NET), dat u kunt converteren van het standaardtype

Op basis van deze typen kan uw project enigszins verschillende mappen of bestanden bevatten. Een Nuget-pakketproject heeft bijvoorbeeld een .bin map die pakketten en andere bibliotheekbestanden bevat. Een op uitbreidingsbundel gebaseerd project bevat deze .bin map niet.

Voor sommige scenario's is een op NuGet-packages gebaseerd project vereist om uw app te laten draaien, bijvoorbeeld wanneer u aangepaste ingebouwde functies wilt ontwikkelen en uitvoeren. Zie Ingebouwde connector-ontwikkeling inschakelen voor meer informatie over het omzetten van uw project naar NuGet.

Het standaardproject op basis van de extensiebundel heeft een map- en bestandsstructuur die vergelijkbaar is met het volgende voorbeeld:

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

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

Containerimplementatie

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

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

App-instellingen en -parameters

In Azure Logic Apps met meerdere tenants vormen ARM-sjablonen een uitdaging wanneer u omgevingsvariabelen moet onderhouden voor logische apps in verschillende ontwikkel-, test- en productieomgevingen. Alles in een ARM-sjabloon wordt gedefinieerd bij 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 Ecosysteem van Azure Logic Apps biedt meer dan 1000 door Microsoft beheerde en door Azure gehoste 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 beheerde connectors onderhoudt, blijft meestal hetzelfde in Azure Logic Apps met één tenant als in Azure Logic Apps met meerdere tenants.

De belangrijkste verbetering is dat de ééntenantservice meerdere populaire beheerde connectors beschikbaar maakt als ingebouwde bewerkingen. U kunt bijvoorbeeld ingebouwde bewerkingen gebruiken voor Azure Service Bus, Azure Event Hubs, SQL en vele 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 op basis van Azure Service, worden ingebouwde verbindingen of op serviceproviders gebaseerde verbindingen genoemd. Ingebouwde bewerkingen en de bijbehorende verbindingen worden lokaal uitgevoerd in hetzelfde proces waarin uw werkstromen worden uitgevoerd. Beide worden gehost in de opnieuw ontworpen Azure 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. Hierdoor 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 uw werkstromen te ontwikkelen of te wijzigen, genereert de Azure Logic Apps-engine met één tenant automatisch alle benodigde verbindingsmetagegevens in het connections.json-bestand 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, wat belangrijk is 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 door uw werkstromen worden gebruikt.

In uw Standaard-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 connections.json-bestand van uw project.

In het volgende voorbeeld ziet u hoe de verbinding van de serviceprovider voor een ingebouwde Azure Service Bus-bewerking wordt weergegeven in het connections.json-bestand 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 een beheerde connector voor de eerste keer 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 blijft maken en ontwikkelen met behulp van de ontwerpfunctie, maakt de Azure Logic Apps-engine met één tenant 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 Azure Service Bus-connector wordt weergegeven in het connections.json-bestand 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 bewerking van Azure Functions. Verbindingsmetagegevens voor Azure Functions-aanroepen verschillen van andere ingebouwde verbindingen. Deze metagegevens worden opgeslagen in het connections.json-bestand van uw logische app-project, maar ziet 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}"
   },
   <...>
}

Authentication

In Azure Logic Apps met één tenant is het hostingmodel voor werkstromen van logische apps één Microsoft Entra-tenant waarbij uw workloads profiteren van meer isolatie dan in het multitenantmodel. 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. Dit ontwerp vereist echter 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 door het systeem toegewezen beheerde identiteit. Deze identiteit verschilt van de verificatiereferenties of verbindingsreeks die worden 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.

In de volgende secties vindt u 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 heeft het connections.json-bestand 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 standaard en aanbevolen verificatietype dat moet worden gebruikt voor het verifiëren van beheerde verbindingen die worden gehost en uitgevoerd in Azure. In het connections.json-bestand van uw logische app-project heeft de beheerde verbinding een authentication object dat aangeeft ManagedServiceIdentity als het verificatietype:

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

Raw

Voor logische apps die worden uitgevoerd in uw lokale ontwikkelomgeving met 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 verlooptijd van 7 dagen. In het connections.json-bestand van uw logische app-project bevat de beheerde verbinding een authentication object met de volgende verificatiegegevens:

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

Verwante inhoud

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