Nasazení DevOps pro službu Azure Logic Apps pro jednoho tenanta

Platí pro: Azure Logic Apps (Standard)

S trendem směrem k distribuovaným a nativním cloudovým aplikacím se organizace zabývají více distribuovanými komponentami ve více prostředích. Abyste si zachovali kontrolu a konzistenci, můžete automatizovat prostředí a nasazovat další komponenty rychleji a s větší jistotou pomocí nástrojů a procesů DevOps.

Tento článek poskytuje úvod a přehled o aktuálním prostředí kontinuální integrace a průběžného nasazování (CI/CD) pro Azure Logic Apps s jedním tenantem.

Jeden tenant versus více tenantů

V Azure Logic Apps s více tenanty je nasazení prostředků založené na šablonách Azure Resource Manager (šablony ARM), které kombinují a zpracovávají zřizování prostředků pro aplikace logiky i infrastrukturu. V Azure Logic Apps s jedním tenantem je nasazení jednodušší, protože zřizování prostředků můžete oddělit mezi aplikacemi a infrastrukturou.

Když vytváříte aplikace logiky pomocí typu prostředku Aplikace logiky (Standard), vaše pracovní postupy využívají přepracovaný modul runtime Azure Logic Apps s jedním tenantem. Tento modul runtime používá rozšiřitelnost modelu rozšiřitelnosti Azure Functions a je hostovaný jako rozšíření v modulu runtime Azure Functions. Tento návrh poskytuje přenositelnost, flexibilitu a vyšší výkon pro aplikace logiky a další možnosti a výhody zděděné z platformy Azure Functions a ekosystému Azure App Service.

Jako součást aplikace logiky můžete například zabalit přepracovaný kontejnerizovaný modul runtime a pracovní postupy. Můžete použít obecné kroky nebo úlohy, které sestavují, sestavují a zazipují prostředky aplikace logiky do artefaktů připravených k nasazení. Pokud chcete nasadit aplikace, zkopírujte artefakty do hostitelského prostředí a pak spusťte aplikace, abyste mohli spouštět pracovní postupy. Nebo integrujte artefakty do kanálů nasazení pomocí nástrojů a procesů, které už znáte a používáte. Pokud například váš scénář vyžaduje kontejnery, můžete kontejnerizovat aplikace logiky a integrovat je do stávajících kanálů.

Pokud chcete nastavit a nasadit prostředky infrastruktury, jako jsou virtuální sítě a připojení, můžete dál používat šablony ARM a samostatně zřizovat tyto prostředky společně s dalšími procesy a kanály, které pro tyto účely používáte.

Pomocí standardních možností sestavení a nasazení se můžete zaměřit na vývoj aplikací odděleně od nasazení infrastruktury. V důsledku toho získáte obecnější model projektu, ve kterém můžete použít mnoho podobných nebo stejných možností nasazení, které používáte pro obecnou aplikaci. Můžete také využít konzistentnější prostředí pro vytváření kanálů nasazení kolem projektů aplikací a spouštění požadovaných testů a ověření před publikováním do produkčního prostředí. Bez ohledu na to, kterou sadu technologií používáte, můžete aplikace logiky nasadit pomocí vlastních zvolených nástrojů.

Možnosti nasazení DevOps

Azure Logic Apps s jedním tenantem dědí mnoho možností a výhod z platformy Azure Functions a ekosystému Azure App Service. Tyto aktualizace zahrnují zcela nový model nasazení a další způsoby použití DevOps pro pracovní postupy aplikací logiky.

Místní vývoj a testování

Když používáte Visual Studio Code s rozšířením Azure Logic Apps (Standard), můžete místně vyvíjet, sestavovat a spouštět pracovní postupy aplikací logiky založené na jednom tenantovi ve vývojovém prostředí, aniž byste je museli nasazovat do Azure. Pokud váš scénář vyžaduje kontejnery, můžete vytvářet a nasazovat prostřednictvím Logic Apps s podporou Azure Arc.

Tato funkce představuje významné vylepšení a poskytuje významnou výhodu ve srovnání s modelem s více tenanty, který vyžaduje vývoj na základě existujícího a spuštěného prostředku v Azure.

Samostatné záležitosti

Model s jedním tenantem umožňuje oddělit obavy mezi aplikací a základní infrastrukturou. Aplikaci můžete například vyvíjet, sestavovat, zazipovat a nasazovat samostatně jako neměnný artefakt do různých prostředí. Pracovní postupy aplikací logiky mají obvykle kód aplikace, který aktualizujete častěji než základní infrastrukturu. Oddělením těchto vrstev se můžete více zaměřit na sestavení pracovního postupu aplikace logiky a méně věnovat úsilí nasazení požadovaných prostředků do více prostředí.

Koncepční diagram znázorňující samostatné kanály nasazení pro aplikace a infrastrukturu

Struktura prostředků aplikace logiky

V modelu Azure Logic Apps s více tenanty může struktura prostředků aplikace logiky Consumption obsahovat pouze jeden pracovní postup. Vzhledem k tomuto vztahu 1:1 se aplikace logiky i pracovní postup často považují za synonyma a odkazují se na nich. V modelu Azure Logic Apps s jedním tenantem však může struktura prostředků aplikace logiky Standard zahrnovat několik pracovních postupů. Tato relace 1:N znamená, že ve stejné aplikaci logiky můžou pracovní postupy sdílet a opakovaně používat další prostředky. Pracovní postupy ve stejné aplikaci logiky a tenantovi také nabízejí lepší výkon díky této sdílené tenantské struktuře a vzájemné blízkosti. Tato struktura prostředků vypadá a funguje podobně jako Azure Functions, kde aplikace funkcí může hostovat mnoho funkcí.

Další informace a osvědčené postupy týkající se uspořádání pracovních postupů, výkonu a škálování v aplikaci logiky najdete v podobných doprovodných materiálech pro Azure Functions, které můžete obecně použít pro Azure Logic Apps s jedním tenantem.

Struktura projektu aplikace logiky

V editoru Visual Studio Code má projekt aplikace logiky některý z následujících typů:

  • Na základě sady rozšíření (Node.js), což je výchozí typ
  • Balíček NuGet (.NET), který můžete převést z výchozího typu

Na základě těchto typů projekt obsahuje mírně odlišné složky a soubory. Projekt založený na NuGetu obsahuje složku .bin, která obsahuje balíčky a další soubory knihovny. Projekt založený na sadách neobsahuje složku .bin a další soubory. Některé scénáře vyžadují, aby vaše aplikace běžela projekt založený na NuGetu, například když chcete vyvíjet a spouštět vlastní integrované operace. Další informace o převodu projektu na použití NuGetu najdete v tématu Povolení vytváření předdefinovaných konektorů.

Pro výchozí projekt založený na sadách má váš projekt strukturu složek a souborů, která se podobá následujícímu příkladu:

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

Na kořenové úrovni projektu můžete najít následující soubory a složky s dalšími položkami:

Name Složka nebo soubor Popis
.vscode Složka Obsahuje soubory nastavení související s editorem Visual Studio Code, jako jsou soubory extensions.json, launch.json, settings.json a tasks.json .
Artifacts Složka Obsahuje artefakty účtu integrace, které definujete a používáte v pracovních postupech, které podporují scénáře B2B (Business-to-Business). Ukázková struktura například obsahuje mapy a schémata pro operace transformace a ověření XML.
<Název pracovního postupu> Složka Pro každý pracovní postup < obsahuje složka WorkflowName> soubor workflow.json, který obsahuje základní definici JSON daného pracovního postupu.
workflow-designtime Složka Obsahuje soubory nastavení související s vývojovým prostředím.
.funcignore Soubor Obsahuje informace související s nainstalovanými nástroji Azure Functions Core Tools.
connections.json Soubor Obsahuje metadata, koncové body a klíče pro všechna spravovaná připojení a funkce Azure, které používají vaše pracovní postupy.

Důležité: Pokud chcete pro každé prostředí použít různá připojení a funkce, ujistěte se, že parametrizujete tento soubor connections.json a aktualizujete koncové body.
host.json Soubor Obsahuje nastavení konfigurace specifické pro modul runtime a hodnoty, například výchozí limity pro platformu Azure Logic Apps s jedním tenantem, aplikace logiky, pracovní postupy, triggery a akce. Na kořenové úrovni projektu aplikace logiky obsahuje soubor metadat host.json nastavení konfigurace a výchozí hodnoty, které při spuštění používají všechny pracovní postupy ve stejné aplikaci logiky, ať už místně nebo v Azure.

Poznámka: Při vytváření aplikace logiky vytvoří Visual Studio Code v kontejneru úložiště záložní soubor host.snapshot.*.json . Pokud aplikaci logiky odstraníte, tento záložní soubor se neodstraní. Pokud vytvoříte jinou aplikaci logiky se stejným názvem, vytvoří se další soubor snímku. Pro stejnou aplikaci logiky můžete mít maximálně 10 snímků. Pokud tento limit překročíte, zobrazí se následující chyba:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

Pokud chcete tuto chybu vyřešit, odstraňte z kontejneru úložiště soubory snímků navíc.
local.settings.json Soubor Obsahuje nastavení aplikace, připojovací řetězce a další nastavení, která vaše pracovní postupy používají při místním spuštění. Jinými slovy, tato nastavení a hodnoty platí jenom při spouštění projektů v místním vývojovém prostředí. Během nasazování do Azure se soubor a nastavení ignorují a nejsou součástí vašeho nasazení.

Tento soubor ukládá nastavení a hodnoty jako místní proměnné prostředí , které používají místní vývojové nástroje jako appSettings hodnoty. Tyto proměnné prostředí můžete volat a odkazovat jak za běhu, tak v době nasazení pomocí nastavení aparametrů aplikace.

Důležité: Soubor local.settings.json může obsahovat tajné kódy, proto se ujistěte, že jste tento soubor také vyloučili ze správy zdrojového kódu projektu.

Nasazení kontejneru

Azure Logic Apps s jedním tenantem podporuje nasazení do kontejnerů, což znamená, že můžete kontejnerizovat pracovní postupy aplikací logiky a spouštět je tam, kde můžou kontejnery běžet. Po kontejnerizaci aplikace funguje nasazení většinou stejně jako jakýkoli jiný kontejner, který nasazujete a spravujete.

Příklady, které zahrnují Azure DevOps, najdete v tématu CI/CD pro kontejnery.

Nastavení a parametry aplikace

V Azure Logic Apps s více tenanty představují šablony ARM výzvu, když potřebujete udržovat proměnné prostředí pro aplikace logiky v různých vývojových, testovacích a produkčních prostředích. Všechno v šabloně ARM se definuje při nasazení. Pokud potřebujete změnit jenom jednu proměnnou, musíte všechno nasadit znovu.

V Azure Logic Apps s jedním tenantem můžete volat proměnné prostředí a odkazovat na je za běhu pomocí nastavení a parametrů aplikace, abyste je nemuseli nasazovat tak často.

Spravované konektory a předdefinované operace

Ekosystém Azure Logic Apps poskytuje stovky konektorů spravovaných Microsoftem a předdefinované operace jako součást neustále se rozšiřující kolekce, kterou můžete použít v Azure Logic Apps s jedním tenantem. Způsob, jakým Microsoft udržuje tyto konektory a předdefinované operace, zůstává ve službě Azure Logic Apps pro jednoho tenanta většinou stejný.

Nejvýznamnějším vylepšením je, že služba s jedním tenantem zpřístupňuje oblíbenější spravované konektory také jako předdefinované operace. Můžete například použít integrované operace pro Azure Service Bus, Azure Event Hubs, SQL a další. Mezitím jsou verze spravovaného konektoru stále dostupné a dál fungují.

Připojení, která vytvoříte pomocí předdefinovaných operací, se nazývají integrovaná připojení nebo připojení poskytovatele služeb. Předdefinované operace a jejich připojení běží místně ve stejném procesu, který spouští vaše pracovní postupy. Oba jsou hostované v přepracovaném modulu runtime Logic Apps. Naproti tomu spravovaná připojení nebo připojení rozhraní API se vytvářejí a spouští samostatně jako prostředky Azure, které nasazujete pomocí šablon ARM. V důsledku toho předdefinované operace a jejich připojení poskytují lepší výkon díky tomu, že jsou blízko k vašim pracovním postupům. Tento návrh také dobře funguje s kanály nasazení, protože připojení poskytovatele služeb jsou zabalená do stejného artefaktu sestavení.

Když v editoru Visual Studio Code použijete návrháře k vývoji nebo změnám pracovních postupů, modul Logic Apps automaticky vygeneruje všechna potřebná metadata připojení v souboru connections.json vašeho projektu. Následující části popisují tři druhy připojení, které můžete vytvořit v pracovních postupech. Každý typ připojení má jinou strukturu JSON, což je důležité pochopit, protože při přechodu mezi prostředími se koncové body mění.

Připojení poskytovatele služeb

Když použijete integrovanou operaci pro službu, jako je Azure Service Bus nebo Azure Event Hubs v Azure Logic Apps s jedním tenantem, vytvoříte připojení poskytovatele služeb, které běží ve stejném procesu jako váš pracovní postup. Tato infrastruktura připojení je hostovaná a spravovaná jako součást prostředku aplikace logiky a v nastavení aplikace se ukládají připojovací řetězce pro všechny integrované operace založené na poskytovateli služeb, které používají vaše pracovní postupy.

V projektu aplikace logiky má každý pracovní postup soubor workflow.json, který obsahuje základní definici JSON pracovního postupu. Tato definice pracovního postupu pak odkazuje na potřebné připojovací řetězce v souboru connections.json vašeho projektu.

Následující příklad ukazuje, jak se v souboru connections.json vašeho projektu zobrazí připojení poskytovatele služeb pro integrovanou operaci Service Bus:

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

Spravovaná připojení

Při prvním použití spravovaného konektoru v pracovním postupu se zobrazí výzva k vytvoření připojení spravovaného rozhraní API pro cílovou službu nebo systém a ověření vaší identity. Tyto konektory spravuje ekosystém sdílených konektorů v Azure. Připojení rozhraní API existují a běží v Azure jako samostatné prostředky.

Zatímco v editoru Visual Studio Code budete dál vytvářet a vyvíjet pracovní postupy pomocí návrháře, modul Logic Apps automaticky vytvoří v Azure potřebné prostředky pro spravované konektory ve vašem pracovním postupu. Modul automaticky přidá tyto prostředky připojení do skupiny prostředků Azure, kterou jste navrhli tak, aby obsahovala vaši aplikaci logiky.

Následující příklad ukazuje, jak se v souboru connections.json vašeho projektu zobrazí připojení rozhraní API pro spravovaný konektor Service Bus:

"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 připojení

K volání funkcí vytvořených a hostovaných v Azure Functions použijete integrovanou operaci Azure Functions. Metadata připojení pro volání Azure Functions se liší od jiných předdefinovaných připojení. Tato metadata se ukládají do souboru connections.json vašeho projektu aplikace logiky, ale vypadají jinak:

"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

V Azure Logic Apps s jedním tenantem je model hostování pracovních postupů aplikací logiky jedním tenantem, ve kterém vaše úlohy těží z větší izolace než v modelu s více tenanty. Modul runtime Azure Logic Apps s jedním tenantem je navíc přenosný, což znamená, že pracovní postupy můžete spouštět v jiných prostředích, například místně v editoru Visual Studio Code. Tento návrh ale vyžaduje, aby aplikace logiky ověřily svou identitu, aby mohly přistupovat k ekosystému spravovaných konektorů v Azure. Vaše aplikace také potřebují správná oprávnění ke spouštění operací při používání spravovaných připojení.

Ve výchozím nastavení má každá aplikace logiky založená na jednom tenantovi automaticky povolenou spravovanou identitu přiřazenou systémem. Tato identita se liší od ověřovacích přihlašovacích údajů nebo připojovacího řetězce použitého k vytvoření připojení. Za běhu používá vaše aplikace logiky tuto identitu k ověřování připojení prostřednictvím zásad přístupu Azure. Pokud tuto identitu zakážete, nebudou připojení za běhu fungovat.

V následujících částech najdete další informace o typech ověřování, které můžete použít k ověřování spravovaných připojení v závislosti na tom, kde vaše aplikace logiky běží. Pro každé spravované připojení obsahuje soubor connections.json vašeho projektu aplikace logiky authentication objekt, který určuje typ ověřování, který může vaše aplikace logiky použít k ověření spravovaného připojení.

Spravovaná identita

Pro aplikaci logiky, která je hostovaná a spuštěná v Azure, je spravovaná identita výchozím a doporučeným typem ověřování pro ověřování spravovaných připojení hostovaných a spuštěných v Azure. V souboru connections.json projektu aplikace logiky má authentication spravované připojení objekt, který určuje ManagedServiceIdentity jako typ ověřování:

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

Žádný

Pro aplikace logiky, které běží v místním vývojovém prostředí pomocí editoru Visual Studio Code, se k ověřování spravovaných připojení hostovaných a spuštěných v Azure používají nezpracované ověřovací klíče. Tyto klíče jsou určené pouze pro použití ve vývoji, ne pro produkční prostředí, a mají 7denní platnost. V souboru connections.json projektu aplikace logiky má spravované připojení objekt, který authentication určuje následující ověřovací informace:

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

Další kroky