DevOps-distribution för standardlogikappar i Azure Logic Apps med en enda klientorganisation

Gäller för: Azure Logic Apps (Standard)

Med trenden mot distribuerade och inbyggda molnappar hanterar organisationer mer distribuerade komponenter i fler miljöer. För att upprätthålla kontroll och konsekvens kan du automatisera dina miljöer och distribuera fler komponenter snabbare och säkrare med hjälp av DevOps-verktyg och -processer.

Den här artikeln innehåller en introduktion och översikt över den aktuella ci/CD-upplevelsen (kontinuerlig integrering och kontinuerlig distribution) för arbetsflöden för standardlogikappar i Azure Logic Apps med en enda klientorganisation.

Enskild klientorganisation jämfört med flera klientorganisationer

I Azure Logic Apps för flera klientorganisationer baseras resursdistributionen på Azure Resource Manager-mallar (ARM-mallar), som kombinerar och hanterar resursetablering för både förbrukningslogikappens resurser och infrastruktur. I Azure Logic Apps för en klientorganisation blir distributionen enklare eftersom du kan separera resursetablering mellan standardlogikappresurser och infrastruktur.

När du skapar en standardlogikappresurs drivs arbetsflöden av den omdesignade Azure Logic Apps-körningen med en enda klientorganisation. Den här körningen använder utökningsmodellen för Azure Functions och hanteras som ett tillägg på Azure Functions-körningen. Den här designen ger portabilitet, flexibilitet och mer prestanda för standardlogikappar plus andra funktioner och fördelar som ärvs från Azure Functions-plattformen och Azure App Service-ekosystemet.

Du kan till exempel paketera de omdesignade containerbaserade körningsmiljön och arbetsflödena tillsammans som en del av standardlogikappen. Du kan använda allmänna steg eller uppgifter som skapar, monterar och zippar dina logikappresurser i färdiga artefakter. Om du vill distribuera standardlogikappar kopierar du artefakterna till värdmiljön och startar sedan dina appar för att köra dina arbetsflöden. Eller integrera artefakterna i distributionspipelines med hjälp av de verktyg och processer som du redan känner till och använder. Om ditt scenario till exempel kräver containrar kan du containerisera standardlogikappar och integrera dem i dina befintliga pipelines.

Om du vill konfigurera och distribuera dina infrastrukturresurser, till exempel virtuella nätverk och anslutningar, kan du fortsätta använda ARM-mallar och separat etablera dessa resurser tillsammans med andra processer och pipelines som du använder för dessa ändamål.

Genom att använda standardversions- och distributionsalternativ kan du fokusera på apputveckling separat från infrastrukturdistribution. Därför får du en mer allmän projektmodell där du kan använda många liknande eller samma distributionsalternativ som du använder för en allmän app. Du kan också dra nytta av en mer konsekvent upplevelse för att skapa distributionspipelines runt dina appprojekt och för att köra nödvändiga tester och valideringar innan du publicerar till produktion. Oavsett vilken teknikstack du använder kan du distribuera logikappar med dina egna valda verktyg.

DevOps-distributionsfunktioner

Azure Logic Apps med en klientorganisation ärver många funktioner och fördelar från Azure Functions-plattformen och Azure App Service-ekosystemet. De här uppdateringarna innehåller en helt ny distributionsmodell och fler sätt att använda DevOps för dina logikapparbetsflöden.

Lokal utveckling och testning

När du använder Visual Studio Code med Tillägget Azure Logic Apps (Standard) kan du lokalt utveckla, skapa och köra standardarbetsflöden för logikappar i utvecklingsmiljön utan att behöva distribuera till Azure. Om ditt scenario kräver containrar kan du skapa och distribuera via Azure Arc-aktiverade Logic Apps.

Den här funktionen är en stor förbättring och ger en betydande fördel jämfört med modellen med flera klientorganisationer, vilket kräver att du utvecklar mot en befintlig och löpande resurs i Azure.

Separata problem

Modellen med en klientorganisation ger dig möjlighet att separera problemen mellan logikappen och den underliggande infrastrukturen. Du kan till exempel utveckla, skapa, zippa och distribuera appen separat som en oföränderlig artefakt till olika miljöer. Logikapparbetsflöden har vanligtvis "programkod" som du uppdaterar oftare än den underliggande infrastrukturen. Genom att separera dessa lager kan du fokusera mer på att skapa logikappens arbetsflöde och ägna mindre tid åt att distribuera de resurser som krävs i flera miljöer.

Logikappens resursstruktur

I Azure Logic Apps-modellen för flera klientorganisationer kan resursstrukturen för förbrukningslogikappen endast innehålla ett enda arbetsflöde. På grund av den här en-till-en-relationen anses och refereras ofta både logikappen och arbetsflödet synonymt. I Azure Logic Apps-modellen med en enda klientorganisation kan dock standardlogikappens resursstruktur innehålla flera arbetsflöden. Den här en-till-många-relationen innebär att arbetsflöden i samma logikapp kan dela och återanvända andra resurser. Arbetsflöden i samma logikapp och klientorganisation ger också bättre prestanda på grund av den här delade innehavarorganisationen och närheten till varandra. Den här resursstrukturen ser ut och fungerar på samma sätt som i Azure Functions där en funktionsapp kan vara värd för många funktioner.

Mer information och metodtips för att organisera arbetsflöden, prestanda och skalning i logikappen finns i den liknande vägledningen för Azure Functions som du vanligtvis kan använda för Azure Logic Apps med en enda klientorganisation.

Projektstruktur för logikapp

I Visual Studio Code har logikappprojektet någon av följande typer:

• Tilläggspaketbaserad (Node.js), som är standardtypen
• NuGet-paketbaserad (.NET), som du kan konvertera från standardtypen

Baserat på dessa typer innehåller projektet lite olika mappar och filer. Ett NuGet-baserat projekt innehåller en .bin mapp som innehåller paket och andra biblioteksfiler. Ett paketbaserat projekt innehåller inte mappen .bin och andra filer. Vissa scenarier kräver ett NuGet-baserat projekt för att appen ska kunna köras, till exempel när du vill utveckla och köra anpassade inbyggda åtgärder. Mer information om hur du konverterar projektet till att använda NuGet finns i Aktivera redigering av inbyggd anslutningsapp.

För det standardpaketbaserade projektet har projektet en mapp och filstruktur som liknar följande exempel:

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

På projektets rotnivå hittar du följande filer och mappar med andra objekt:

Containerdistribution

Azure Logic Apps med en klientorganisation stöder distribution till containrar, vilket innebär att du kan containerisera dina logikapparbetsflöden och köra dem där containrar kan köras. När du har containeranpassat din app fungerar distributionen mestadels på samma sätt som alla andra containrar som du distribuerar och hanterar.

Exempel som inkluderar Azure DevOps finns i CI/CD för containrar.

Appinställningar och -parametrar

I Azure Logic Apps för flera klientorganisationer utgör ARM-mallar en utmaning när du måste underhålla miljövariabler för logikappar i olika utvecklings-, test- och produktionsmiljöer. Allt i en ARM-mall definieras vid distributionen. Om du bara behöver ändra en enda variabel måste du distribuera om allt.

I Azure Logic Apps för en klientorganisation kan du anropa och referera till miljövariabler vid körning med hjälp av appinställningar och parametrar, så att du inte behöver distribuera om så ofta.

Hanterade anslutningsappar och inbyggda åtgärder

Azure Logic Apps-ekosystemet tillhandahåller över 1 000 Microsoft-hanterade och Azure-värdbaserade anslutningsappar och inbyggda åtgärder som en del av en ständigt växande samling som du kan använda i Azure Logic Apps med en enda klientorganisation. Det sätt som Microsoft underhåller hanterade anslutningsappar på förblir mestadels detsamma i Azure Logic Apps för en klientorganisation som i Azure Logic Apps med flera klientorganisationer.

Den viktigaste förbättringen är att tjänsten med en enda klientorganisation gör mer populära hanterade anslutningsappar tillgängliga som inbyggda åtgärder. Du kan till exempel använda inbyggda åtgärder för Azure Service Bus, Azure Event Hubs, SQL och många andra. Under tiden är de hanterade anslutningsversionerna fortfarande tillgängliga och fortsätter att fungera.

De anslutningar som du skapar med hjälp av Azure Service-baserade inbyggda åtgärder kallas för inbyggda anslutningar eller tjänstleverantörsbaserade anslutningar. Inbyggda åtgärder och deras anslutningar körs lokalt i samma process som kör dina arbetsflöden. Båda finns på den omdesignade Azure Logic Apps-körningen. Däremot skapas hanterade anslutningar eller API-anslutningar och körs separat som Azure-resurser som du distribuerar med ARM-mallar. Därför ger inbyggda åtgärder och deras anslutningar bättre prestanda på grund av närheten till dina arbetsflöden. Den här designen fungerar också bra med distributionspipelines eftersom tjänstleverantörens anslutningar paketeras i samma byggartefakt.

När du använder designern i Visual Studio Code för att utveckla eller göra ändringar i dina arbetsflöden genererar Azure Logic Apps-motorn för en enda klient automatiskt alla nödvändiga anslutningsmetadata i projektets connections.json-fil . I följande avsnitt beskrivs de tre typer av anslutningar som du kan skapa i dina arbetsflöden. Varje anslutningstyp har en annan JSON-struktur, vilket är viktigt att förstå eftersom slutpunkterna ändras när du flyttar mellan miljöer.

Tjänstleverantörsanslutningar

När du använder en inbyggd åtgärd för en tjänst, till exempel Azure Service Bus eller Azure Event Hubs i Azure Logic Apps med en enda klientorganisation, skapar du en tjänstleverantörsanslutning som körs i samma process som arbetsflödet. Den här anslutningsinfrastrukturen hanteras och hanteras som en del av din logikappresurs, och appinställningarna lagrar anslutningssträng för alla tjänstleverantörsbaserade inbyggda åtgärder som dina arbetsflöden använder.

I standardlogikappprojektet har varje arbetsflöde en workflow.json fil som innehåller arbetsflödets underliggande JSON-definition. Den här arbetsflödesdefinitionen refererar sedan till de nödvändiga anslutningssträng i projektets connections.json-fil.

I följande exempel visas hur tjänstleverantörsanslutningen för en inbyggd Azure Service Bus-åtgärd visas i projektets connections.json-fil :

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

Hanterade anslutningar

När du använder en hanterad anslutningsapp för första gången i arbetsflödet uppmanas du att skapa en hanterad API-anslutning för måltjänsten eller systemet och autentisera din identitet. Dessa anslutningsappar hanteras av ekosystemet för delade anslutningsappar i Azure. API-anslutningarna finns och körs som separata resurser i Azure.

I Visual Studio Code, medan du fortsätter att skapa och utveckla ditt arbetsflöde med hjälp av designern, skapar Azure Logic Apps-motorn för en enda klient automatiskt de resurser som behövs i Azure för de hanterade anslutningsprogrammen i arbetsflödet. Motorn lägger automatiskt till dessa anslutningsresurser till den Azure-resursgrupp som du har utformat för att innehålla logikappen.

I följande exempel visas hur en API-anslutning för den hanterade Azure Service Bus-anslutningsappen visas i projektets connections.json-fil :

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

Om du vill anropa funktioner som skapats och finns i Azure Functions använder du den inbyggda Azure Functions-åtgärden. Anslutningsmetadata för Azure Functions-anrop skiljer sig från andra inbyggda anslutningar. Dessa metadata lagras i logikappprojektets connections.json-fil , men ser annorlunda ut:

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

Autentisering

I Azure Logic Apps för en klientorganisation är värdmodellen för logikapparbetsflöden en enda Microsoft Entra-klientorganisation där dina arbetsbelastningar drar nytta av mer isolering än i modellen med flera klientorganisationer. Dessutom är Azure Logic Apps-körningen med en enda klient portabel, vilket innebär att du kan köra dina arbetsflöden i andra miljöer, till exempel lokalt i Visual Studio Code. Den här designen kräver dock ett sätt för logikappar att autentisera sin identitet så att de kan komma åt ekosystemet för hanterade anslutningsappar i Azure. Dina appar behöver också rätt behörigheter för att köra åtgärder när du använder hanterade anslutningar.

Som standard har varje enskild klientbaserad logikapp en automatiskt aktiverad systemtilldelad hanterad identitet. Den här identiteten skiljer sig från autentiseringsuppgifterna eller anslutningssträng som används för att skapa en anslutning. Vid körning använder logikappen den här identiteten för att autentisera sina anslutningar via Azure-åtkomstprinciper. Om du inaktiverar den här identiteten fungerar inte anslutningar vid körning.

Följande avsnitt innehåller mer information om de autentiseringstyper som du kan använda för att autentisera hanterade anslutningar, baserat på var logikappen körs. För varje hanterad anslutning har logikappprojektets connections.json-fil ett authentication objekt som anger den autentiseringstyp som logikappen kan använda för att autentisera den hanterade anslutningen.

Hanterad identitet

För en logikapp som finns och körs i Azure är en hanterad identitet standard och rekommenderad autentiseringstyp att använda för att autentisera hanterade anslutningar som finns och körs i Azure. I logikappprojektets connections.json-fil har den hanterade anslutningen ett authentication objekt som anger som autentiseringstyp ManagedServiceIdentity :

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

Raw

För logikappar som körs i din lokala utvecklingsmiljö med Visual Studio Code används råa autentiseringsnycklar för att autentisera hanterade anslutningar som finns och körs i Azure. Dessa nycklar är endast utformade för utveckling, inte produktion, och har en 7-dagars förfallotid. I logikappprojektets connections.json-fil har den hanterade anslutningen ett authentication objekt som anger följande autentiseringsinformation:

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

Nästa steg

• Konfigurera DevOps-distribution för Azure Logic Apps för enskild klientorganisation