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

Artikel
01/04/2024

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 Azure Logic Apps med en enda klientorganisation.

Enskild klientorganisation jämfört med flera klientorganisationer

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

När du skapar logikappar med resurstypen Logikapp (Standard) drivs dina arbetsflöden av den omdesignade Azure Logic Apps-körningen med en enda klient. Den här körningen använder Azure Functions utökningsmodellens utökningsbarhet och finns som ett tillägg på Azure Functions-körningen. Den här designen ger portabilitet, flexibilitet och mer prestanda för dina logikappar samt andra funktioner och fördelar som ärvts från Azure Functions-plattformen och Azure App Service ekosystem.

Du kan till exempel paketera de omdesignade containerbaserade körnings- och arbetsflödena tillsammans som en del av logikappen. Du kan använda allmänna steg eller uppgifter som skapar, monterar och zippar dina logikappresurser i färdiga artefakter. Om du vill distribuera dina appar 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 dina logikappar 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 alternativ för standardversion och distribution 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 enda klient ärver många funktioner och fördelar med Azure Functions plattform och Azure App Service ekosystem. De här uppdateringarna innehåller en helt ny distributionsmodell och fler sätt att använda DevOps för logikappens arbetsflö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 arbetsflöden för en klientbaserad logikapp 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 appen 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 de här lagren kan du fokusera mer på att skapa logikappens arbetsflöde och lägga mindre tid på att distribuera de resurser som krävs i flera miljöer.

Konceptuellt diagram som visar separata distributionspipelines för appar och infrastruktur.

Logikappens resursstruktur

I Azure Logic Apps-modellen med 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 betraktas och refereras ofta både logikappen och arbetsflödet synonymt. I Azure Logic Apps-modellen med en enda klientorganisation kan dock resursstrukturen för standardlogikappen 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 hyresrätten och närheten till varandra. Den här resursstrukturen ser ut och fungerar på samma sätt som 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.

Logikappens projektstruktur

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:

Name	Mapp eller fil	Beskrivning
.vscode	Mapp	Innehåller Visual Studio Code-relaterade inställningsfiler, till exempel extensions.json-, launch.json-, settings.json- och tasks.json-filer .
Artifacts	Mapp	Innehåller integrationskontoartefakter som du definierar och använder i arbetsflöden som stöder B2B-scenarier (business-to-business). Exempelstrukturen innehåller till exempel kartor och scheman för XML-transformerings- och valideringsåtgärder.
*<WorkflowName>*	Mapp	För varje arbetsflöde < innehåller mappen WorkflowName> en workflow.json-fil som innehåller arbetsflödets underliggande JSON-definition.
workflow-designtime	Mapp	Innehåller miljörelaterade inställningsfiler för utveckling.
.funcignore	Fil	Innehåller information om dina installerade Azure Functions Core Tools.
connections.json	Fil	Innehåller metadata, slutpunkter och nycklar för alla hanterade anslutningar och Azure-funktioner som dina arbetsflöden använder. Viktigt: Om du vill använda olika anslutningar och funktioner för varje miljö kontrollerar du att du parameteriserar filen connections.json och uppdaterar slutpunkterna.
host.json	Fil	Innehåller körningsspecifika konfigurationsinställningar och värden, till exempel standardgränserna för Azure Logic Apps-plattformen med en enda klient, logikappar, arbetsflöden, utlösare och åtgärder. På logikappprojektets rotnivå innehåller metadatafilen host.json de konfigurationsinställningar och standardvärden som alla arbetsflöden i samma logikapp använder när de körs, antingen lokalt eller i Azure. Obs! När du skapar logikappen skapar Visual Studio Code en *säkerhetskopieringsvärd.snapshot..json-fil** i lagringscontainern. Om du tar bort logikappen tas inte den här säkerhetskopieringsfilen bort. Om du skapar en annan logikapp med samma namn skapas en annan ögonblicksbildsfil. Du kan bara ha upp till 10 ögonblicksbilder för samma logikapp. Om du överskrider den här gränsen får du följande fel: `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))` Lös det här felet genom att ta bort de extra ögonblicksbildfilerna från lagringscontainern.
local.settings.json	Fil	Innehåller appinställningar, anslutningssträngar och andra inställningar som dina arbetsflöden använder när de körs lokalt. Med andra ord gäller dessa inställningar och värden endast när du kör dina projekt i din lokala utvecklingsmiljö. Under distributionen till Azure ignoreras filen och inställningarna och ingår inte i distributionen. Den här filen lagrar inställningar och värden som lokala miljövariabler som används av dina lokala utvecklingsverktyg som `appSettings` värden. Du kan anropa och referera till dessa miljövariabler både vid körning och distribution med hjälp av appinställningar och parametrar. Viktigt: Filen local.settings.json kan innehålla hemligheter, så se till att du även undantar den här filen från projektkällans kontroll.

Containerdistribution

Azure Logic Apps med en klient 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 andra containrar som du distribuerar och hanterar.

Exempel som inkluderar Azure DevOps finns i CI/CD for Containers.

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 med en enda klientorganisation kan du anropa och referera till dina miljövariabler vid körning med hjälp av appinställningar och parametrar, så du behöver inte distribuera om så ofta.

Hanterade anslutningsappar och inbyggda åtgärder

Azure Logic Apps-ekosystemet tillhandahåller hundratals Microsoft-hanterade 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 på vilket Microsoft underhåller dessa anslutningsappar och inbyggda åtgärder förblir mestadels detsamma i Azure Logic Apps med en enda klientorganisation.

Den viktigaste förbättringen är att tjänsten för 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 andra. Under tiden är de hanterade anslutningsversionerna fortfarande tillgängliga och fortsätter att fungera.

De anslutningar som du skapar med hjälp av inbyggda åtgärder kallas för inbyggda anslutningar eller tjänstleverantörsanslutningar. Inbyggda åtgärder och deras anslutningar körs lokalt i samma process som kör dina arbetsflöden. Båda finns på den omdesignade Logic Apps-körningen. Hanterade anslutningar eller API-anslutningar skapas däremot 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 deras närhet till dina arbetsflöden. Den här designen fungerar också bra med distributionspipelines eftersom tjänstprovideranslutningarna 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 Logic Apps-motorn 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 som en del av logikappens resurs, och appinställningarna lagrar anslutningssträngarna för alla tjänstleverantörsbaserade inbyggda åtgärder som dina arbetsflöden använder.

I logikappprojektet 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ängarna i projektets connections.json-fil.

I följande exempel visas hur tjänstleverantörsanslutningen för en inbyggd 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 Logic Apps-motorn automatiskt nödvändiga resurser 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 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 med en enda klientorganisation är värdmodellen för logikapparbetsflöden en enda 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. Men den här designen kräver 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ängen 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"
}

Rådata

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