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 resource-implementatie gebaseerd op ARM-sjablonen (Azure Resource Manager) die resource-inrichting combineren en verwerken voor zowel de resources van uw logische app-verbruik als de infrastructuur. In Azure Logic Apps met één tenant wordt de implementatie eenvoudiger omdat u het inrichten van resources van standard logische apps 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 de uitbreidbaarheid van het Azure Functions-model 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 Azure-app Service-ecosysteem.
U kunt bijvoorbeeld de opnieuw ontworpen runtime en werkstromen verpakken als onderdeel van uw standaard logische 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 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 containers zijn vereist, kunt u logische apps met Azure Arc maken en implementeren.
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 logische app en tenant bieden ook verbeterde prestaties vanwege deze gedeelde tenancy en nabijheid van 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 logische app-project
In Visual Studio Code heeft uw logische app-project een van de volgende typen:
- Uitbreidingsbundel (Node.js), het standaardtype
- NuGet-pakket (.NET), dat u kunt converteren van het standaardtype
Op basis van deze typen bevat uw project iets verschillende mappen en bestanden. Een NuGet-project bevat een .bin map die pakketten en andere bibliotheekbestanden bevat. Een op bundel gebaseerd project bevat niet de .bin map en andere bestanden. Voor sommige scenario's is een NuGet-project vereist dat uw app wordt uitgevoerd, 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 om NuGet te gebruiken.
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 | Beschrijving |
|---|---|---|
| .vscode | Map | Bevat bestanden met betrekking tot Visual Studio Code-instellingen, 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 | Bestand | Bevat informatie met betrekking tot uw geïnstalleerde Azure Functions Core Tools. |
| connections.json | Bestand | Bevat de metagegevens, eindpunten en sleutels voor beheerde verbindingen en Azure-functies die door uw werkstromen worden gebruikt. Belangrijk: Als u voor elke omgeving verschillende verbindingen en functies wilt gebruiken, moet u ervoor zorgen dat u dit connections.json bestand parameteriseert en de eindpunten bijwerkt. |
| host.json | Bestand | 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 host.json metagegevensbestand 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-uphost.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 er 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)) Verwijder de extra momentopnamebestanden uit uw opslagcontainer om deze fout op te lossen. |
| local.settings.json | Bestand | Bevat app-instellingen, verbindingsreeks s en andere instellingen die uw werkstromen gebruiken tijdens het lokaal uitvoeren. 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 worden deze 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 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. 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 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 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 service met één tenant 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 verbindingsreeks s op voor elke ingebouwde bewerking op basis van serviceproviders die door uw werkstromen worden gebruikt.
Belangrijk
Wanneer u gevoelige informatie hebt, zoals verbindingsreeks s die gebruikersnamen en wachtwoorden bevatten, moet u ervoor zorgen dat u de veiligste verificatiestroom gebruikt die beschikbaar is. Microsoft raadt u bijvoorbeeld aan om toegang tot Azure-resources te verifiëren met een beheerde identiteit wanneer ondersteuning beschikbaar is en een rol toe te wijzen die de minst vereiste bevoegdheid heeft.
Als deze mogelijkheid niet beschikbaar is, moet u verbindingsreeks beveiligen via andere metingen, zoals Azure Key Vault, die u kunt gebruiken met app-instellingen. U kunt vervolgens rechtstreeks verwijzen naar beveiligde tekenreeksen, zoals verbindingsreeks s en sleutels. Net als bij ARM-sjablonen, waar u omgevingsvariabelen tijdens de implementatie kunt definiëren, kunt u app-instellingen definiëren binnen de werkstroomdefinitie van uw logische app. Vervolgens kunt u dynamisch gegenereerde infrastructuurwaarden vastleggen, zoals verbindingseindpunten, opslagreeksen en meer. Zie Toepassingstypen voor het Microsoft Identity Platform voor meer informatie.
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 verbindingsreeks s 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}"
},
<...>
}
Verificatie
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 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"
}
Onbewerkt
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')"
}