Nasazení DevOps pro aplikace logiky Standard v Azure Logic Apps s jedním tenantem
Platí pro: Azure Logic Apps (Standard)
Díky trendu směrem k distribuovaným a nativním cloudovým aplikacím se organizace zabývají více distribuovanými komponentami napříč více prostředími. Pokud chcete zachovat kontrolu a konzistenci, můžete automatizovat prostředí a nasazovat více komponent rychleji a s jistotou pomocí nástrojů a procesů DevOps.
Tento článek obsahuje úvod a přehled aktuálního prostředí kontinuální integrace a průběžného nasazování (CI/CD) pro pracovní postupy standardních aplikací logiky v 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 Manageru (šablony ARM), které kombinují a zpracovávají zřizování prostředků pro prostředky aplikace logiky Consumption i infrastrukturu. V Azure Logic Apps s jedním tenantem je nasazení jednodušší, protože můžete oddělit zřizování prostředků mezi prostředky aplikace logiky Standard a infrastrukturou.
Při vytváření prostředku aplikace logiky Standard využívají pracovní postupy přepracovaný modul runtime Azure Logic Apps s jedním tenantem. Tento modul runtime používá rozšiřitelnost modelů rozšiřitelnosti služby 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 Standard a další možnosti a výhody zděděné z platformy Azure Functions a ekosystému služby Aplikace Azure Service.
Můžete například zabalit přepracovaný kontejnerizovaný modul runtime a pracovní postupy společně jako součást standardní aplikace logiky. Můžete použít obecné kroky nebo úlohy, které sestaví, sestaví a zazipují prostředky aplikace logiky do artefaktů připravených k nasazení. Pokud chcete nasadit standardní aplikace logiky, zkopírujte artefakty do hostitelského prostředí a pak spusťte své aplikace pro spouštění pracovních postupů. Nebo integrujte artefakty do kanálů nasazení pomocí nástrojů a procesů, které už znáte a používáte. Pokud váš scénář například vyžaduje kontejnery, můžete kontejnerizovat standardní 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ší projektový model, kde 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í v projektech 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 technologii 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 funkcí a výhody z ekosystému azure Functions a ekosystému služby Aplikace Azure Service. Tyto aktualizace zahrnují zcela nový model nasazení a další způsoby použití DevOps pro pracovní postupy aplikace logiky.
Místní vývoj a testování
Pokud 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 standardních aplikací logiky ve vývojovém prostředí, aniž byste 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 je významným vylepšením a přináší v porovnání s modelem s více tenanty významnou výhodu, která vyžaduje vývoj oproti existujícímu a běžícímu prostředku v Azure.
Samostatné obavy
Model s jedním tenantem umožňuje oddělit obavy mezi vaší aplikací logiky 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 obvykle obsahují "kód aplikace", který aktualizujete častěji než základní infrastruktura. Když tyto vrstvy rozdělíte, můžete se více zaměřit na vytvoření pracovního postupu aplikace logiky a trávit méně úsilí při nasazování požadovaných prostředků napříč několika prostředími.
Struktura prostředků aplikace logiky
V modelu Azure Logic Apps s více tenanty může struktura prostředků aplikace logiky Consumption zahrnovat pouze jeden pracovní postup. Vzhledem k tomuto vztahu 1:1 se aplikace logiky i pracovní postup často považují za synonymum a odkazují se na nich. V modelu Azure Logic Apps s jedním tenantem ale může struktura prostředků standardní aplikace logiky obsahovat několik pracovních postupů. Tento vztah 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 tomuto sdílenému tenantovi a vzájemné blízkosti. Tato struktura prostředků vypadá a funguje podobně jako Azure Functions, kde může aplikace funkcí hostovat mnoho funkcí.
Další informace a osvědčené postupy pro 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á váš projekt aplikace logiky některý z následujících typů:
- Sada 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ě neobsahuje složku .bin a další soubory. Některé scénáře vyžadují spuštění projektu založeného 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í integrovaných konektorů.
U výchozího projektu založeného na sadě má váš projekt strukturu složek a souborů, která je podobná 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 najdete následující soubory a složky s dalšími položkami:
| Název | Složka nebo soubor | Popis |
|---|---|---|
| .vscode | Složka | Obsahuje soubory nastavení související se sadou Visual Studio Code, například soubory extensions.json, launch.json, settings.json a tasks.json . |
| Artefakty | 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). Například ukázková struktura obsahuje mapy a schémata pro operace transformace a ověřování 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ích 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é vaše pracovní postupy používají. Důležité: Pokud chcete pro každé prostředí používat různá připojení a funkce, ujistěte se, že parametrizujete tento soubor connections.json a aktualizujete koncové body. |
| host.json | Soubor | Obsahuje nastavení a hodnoty konfigurace specifické pro modul runtime, například výchozí omezení 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 konfigurační nastavení a výchozí hodnoty, které všechny pracovní postupy ve stejné aplikaci logiky používají při spuštění, ať už místně nebo v Azure. Poznámka: Při vytváření aplikace logiky vytvoří Visual Studio Code soubor backup host.snapshot.*.json v kontejneru úložiště. Pokud odstraníte aplikaci logiky, tento záložní soubor se neodstraní. Pokud vytvoříte jinou aplikaci logiky se stejným názvem, vytvoří se jiný 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 extra snímkové soubory z kontejneru úložiště. |
| local.settings.json | Soubor | Obsahuje nastavení aplikace, připojovací řetězec a další nastavení, která vaše pracovní postupy používají při místním spuštění. Jinými slovy platí, že tato nastavení a hodnoty platí jenom v případě, že projekty spouštíte 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é jako hodnoty používají místní vývojové nástroje appSettings . Tyto proměnné prostředí můžete volat a odkazovat na tyto proměnné prostředí za běhu i v době nasazení pomocí nastavení a parametrů aplikace. Důležité: Soubor local.settings.json může obsahovat tajné kódy, proto se ujistěte, že tento soubor také vyloučíte ze správy zdrojového kódu projektu. |
Nasazení kontejnerů
Azure Logic Apps s jedním tenantem podporuje nasazení do kontejnerů, což znamená, že můžete kontejnerizovat pracovní postupy aplikace logiky a spouštět je tam, kde se kontejnery můžou spouštět. 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še v šabloně ARM je definováno při nasazení. Pokud potřebujete změnit jenom jednu proměnnou, musíte všechno znovu nasadit.
V Azure Logic Apps s jedním tenantem můžete volat a odkazovat na proměnné prostředí za běhu pomocí nastavení a parametrů aplikace, takže nemusíte nasazovat tak často.
Spravované konektory a integrované operace
Ekosystém Azure Logic Apps poskytuje více než 1 000 konektorů spravovaných Microsoftem a Azure hostovaných v Azure a integrovaných operací v rámci neustále rostoucí kolekce, kterou můžete použít v Azure Logic Apps s jedním tenantem. Způsob, jakým Microsoft udržuje spravované konektory, zůstává v Azure Logic Apps s jedním tenantem většinou stejný jako ve službě Azure Logic Apps s více tenanty.
Nejvýznamnějším vylepšením je, že služba s jedním tenantem zpřístupňuje oblíbenější spravované konektory jako integrované operace. Můžete například použít integrované operace pro Azure Service Bus, Azure Event Hubs, SQL a mnoho dalších. Mezitím jsou verze spravovaného konektoru stále dostupné a dál fungují.
Připojení, která vytvoříte pomocí integrovaných operací založených na službě Azure, se nazývají integrovaná připojení nebo připojení založená na poskytovateli služeb. Integrované 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 Azure 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. Díky tomu integrované operace a jejich připojení poskytují lepší výkon z důvodu jejich blízkosti k pracovním postupům. Tento návrh také dobře funguje s kanály nasazení, protože připojení poskytovatele služeb jsou zabalena do stejného artefaktu sestavení.
Když v editoru Visual Studio Code použijete návrháře k vývoji nebo provádění změn pracovních postupů, modul Azure Logic Apps s jedním tenantem automaticky vygeneruje všechna potřebná metadata připojení v souboru connections.json 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 se mění koncové body při přesouvání mezi prostředími.
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 pracovní postup. Tato infrastruktura připojení se hostuje a spravuje jako součást prostředku aplikace logiky a nastavení aplikace ukládají připojovací řetězec pro všechny integrované operace založené na poskytovateli služeb, které vaše pracovní postupy používají.
Důležité
Pokud máte citlivé informace, například připojovací řetězec, které obsahují uživatelská jména a hesla, ujistěte se, že používáte nejbezpečnější dostupný tok ověřování. Microsoft například doporučuje ověřit přístup k prostředkům Azure pomocí spravované identity , pokud je k dispozici podpora, a přiřadit roli s nejnižším požadovaným oprávněním.
Pokud tato funkce není dostupná, nezapomeňte zabezpečit připojovací řetězec prostřednictvím jiných měr, jako je Azure Key Vault, které můžete použít s nastavením aplikace. Pak můžete přímo odkazovat na zabezpečené řetězce, jako jsou připojovací řetězec a klíče. Podobně jako šablony ARM, kde můžete definovat proměnné prostředí v době nasazení, můžete definovat nastavení aplikace v definici pracovního postupu aplikace logiky. Pak můžete zaznamenávat dynamicky generované hodnoty infrastruktury, jako jsou koncové body připojení, řetězce úložiště a další. Další informace najdete v tématu Typy aplikací pro platformu Microsoft Identity Platform.
V projektu standardní aplikace logiky má každý pracovní postup workflow.json soubor, který obsahuje základní definici JSON pracovního postupu. Tato definice pracovního postupu pak odkazuje na nezbytné připojovací řetězec v souboru connections.json projektu.
Následující příklad ukazuje, jak se v souboru connections.json projektu zobrazuje připojení poskytovatele služeb pro integrovanou operaci služby Azure 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ěží jako samostatné prostředky v Azure.
V editoru Visual Studio Code během vytváření a vývoje pracovního postupu pomocí návrháře modul Azure Logic Apps s jedním tenantem automaticky vytvoří potřebné prostředky v Azure pro spravované konektory ve vašem pracovním postupu. Modul tyto prostředky připojení automaticky přidá do skupiny prostředků Azure, kterou jste navrhli tak, aby obsahoval vaši aplikaci logiky.
Následující příklad ukazuje, jak se v souboru connections.json projektu zobrazuje připojení rozhraní API pro spravovaný konektor Azure 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')"
},
},
<...>
}
Připojení Ke službě Azure Functions
Pokud chcete volat funkce vytvořené a hostované ve službě Azure Functions, použijte integrovanou operaci Azure Functions. Metadata připojení pro volání Azure Functions se liší od jiných integrovaných připojení. Tato metadata se ukládají do souboru connections.json 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}"
},
<...>
}
Ověřování
V Azure Logic Apps s jedním tenantem je model hostování pracovních postupů aplikací logiky jediný tenant Microsoft Entra, kde vaše úlohy využívají větší izolaci 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. I tak tento návrh vyžaduje způsob, jak aplikace logiky ověřit 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í.
Každá aplikace logiky založená na jednom tenantovi má ve výchozím nastavení automaticky povolenou spravovanou identitu přiřazenou systémem. Tato identita se liší od přihlašovacích údajů ověřování nebo připojovací řetězec používaných k vytvoření připojení. Aplikace logiky za běhu používá tuto identitu k ověření připojení prostřednictvím zásad přístupu Azure. Pokud tuto identitu zakážete, připojení nebudou za běhu fungovat.
Následující části obsahují další informace o typech ověřování, které můžete použít k ověřování spravovaných připojení na základě toho, kde vaše aplikace logiky běží. Pro každé spravované připojení má authentication soubor connections.json projektu logiky 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
U aplikace logiky 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"
}
Nezpracováno
U aplikací logiky, které běží v místním vývojovém prostředí pomocí editoru Visual Studio Code, se nezpracované ověřovací klíče používají k ověřování spravovaných připojení hostovaných a spuštěných v Azure. Tyto klíče jsou určené jenom pro použití ve vývoji, ne pro produkční prostředí a mají 7denní vypršení platnosti. V souboru connections.json projektu logiky má authentication spravované připojení objekt, který určuje následující ověřovací informace:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}