Mnoho společností přešlo od jednoho dominantního operačního systému k koexistenci se servery Windows, Linuxem, fyzickými počítači, veřejnými cloudy a lokálními prostředími , která musí bezproblémově komunikovat, aniž by cokoli narušila. Otázkou již není, zda je hybridní pracovní prostor možný, ale jak tyto pracovní postupy organizovat tak, aby byly bezpečné, opakovatelné a snadno se udržovaly.
Když kombinujete Windows a Linux s více cloudy, potřebujete víc než jen dobré skripty. Potřebujete jasnou strategii pro vytváření hybridních pracovních postupů Windows-Linux , které integrují automatizaci, orchestraci, zabezpečení a monitorování s využitím správných prvků: Azure Automation a Hybrid Runbook Worker, Logic Apps v hybridním režimu, Ansible, AWS Systems Manager, desktopové nástroje jako WinApps a celou moderní vrstvu pro vývoj a spolupráci v Microsoft 365 a Windows.
Proč hybridní pracovní postupy Windows-Linux již nejsou volitelné?
Ve většině dnešních organizací běží na počítačích s Linuxem kritické aplikace, zatímco na serverech s Windows běží interní služby, databáze a starší aplikace . Udržování dvou izolovaných prostředí, z nichž každé má své vlastní nástroje, vede k duplicitě úsilí a dramatickému nárůstu lidských chyb.
Když začnete spravovat desítky nebo stovky smíšených serverů , manuální postupy a samostatné skripty se stávají nepraktickými. Potřebujete vrstvu automatizace a orchestrace, která vám umožní definovat procesy jednou a spouštět je kdekoli je potřeba, ať už ve Windows, Linuxu, v cloudu nebo ve vašem datovém centru.
V této souvislosti se objevuje několik klíčových prvků: Azure Automation s Hybrid Runbook Worker pro automatizaci vaší sítě, Logic Apps v hybridním režimu pro integraci distribuovaných systémů , Ansible jako společný jazyk mezi Linuxem a Windows, AWS Systems Manager pro hybridní uzly a nástroje jako WinApps, které umožňují bezproblémové používání aplikací Windows z linuxových desktopů.
Hybridní automatizace s Azure Automation a Hybrid Runbook Worker
Klíčovým prvním krokem při vytváření hybridních pracovních postupů je nasazení runbooků Azure Automation na vaše místní servery Windows a Linux nebo servery v jiných cloudech . Zde přichází na řadu funkce Hybrid Runbook Worker, která vám umožňuje spouštět runbooky přímo na počítačích hostujících tuto roli.
Runbooky zůstávají uloženy a spravovány v Azure Automation , ale jsou doručovány do jednoho nebo více počítačů registrovaných jako hybridní Runbook Workers. To umožňuje automatizovat místní nebo cloudové prostředky, aniž byste je museli přímo vystavovat internetu nebo přepisovat celou automatizaci mimo Azure.
Rozšíření vs. klasický agent: Dva způsoby instalace hybridního Runbook Workeru
Dnes můžete nasadit uživatelskou roli Hybrid Runbook Worker pomocí dvou různých instalačních platforem: založené na rozšířeních a založené na agentech . Po instalaci je chování spouštění Runbooku stejné, ale přístup založený na rozšířeních radikálně zjednodušuje onboarding a údržbu.
Tradiční přístup se spoléhal na agenta Log Analytics , což vedlo k delšímu a chybovějšímu procesu. Model založený na rozšířeních se nativně integruje s frameworkem rozšíření virtuálních počítačů Azure a pro virtuální počítače Azure používá agenta Azure VM a pro počítače bez Azure, včetně serverů s podporou Azure Arc a VMware vSphere s podporou Arc , používá agenta Azure Connected Machine.
Oba typy hybridního Runbook Workeru mohou koexistovat na stejném počítači a instalace založená na rozšířeních nezasahuje do instancí, které jste již nasadili pomocí tradičního agenta, což usnadňuje bezproblémové, inkrementální migrace.
Klíčové výhody přístupu založeného na rozšíření
Model založený na rozšířeních výrazně snižuje provozní tření při nasazení uživatelského Hybrid Runbook Workeru eliminací zbytečných závislostí. Mezi klíčové výhody patří:
- Mnohem plynulejší nástupUž se nespoléháte na agenta Log Analytics pro registraci pracovníků, čímž se vyhnete vícekrokovým procesům a běžným chybám v ručních instalacích.
- Centralizovaná správa se již škálujePřímá integrace s identitou Azure Resource Manager (ARM), která umožňuje správu rozsáhlých nasazení pomocí zásady, šablony ARM, Bicep, PowerShell nebo CLI.
- Ověřování pomocí přihlašovacího ID Microsoftu: spravované identity přiřazené systémem se využívají na virtuálních počítačích, takže Přihlašovací údaje jsou spravovány jednotným způsobem a bez jejich ukládání do prostého textu ve skriptech nebo konfiguracích.
- Stejný model pro Azure a Azure ArcSpravují se jak počítače v Azure, tak fyzické servery nebo virtuální počítače u jiných poskytovatelů (prostřednictvím Azure Arc). se stejnou zkušenostíTo výrazně zjednodušuje hybridní a multicloudová prostředí.
- Více způsobů, jak se připojitRoli lze nainstalovat z Azure Portal, PowerShellu, Bicepu, šablon ARM, Azure REST nebo CLI, případně přímo z karty Rozšíření každého virtuálního počítače nebo serveru s podporou Arc.
- Automatické aktualizace dílčích verzíVe výchozím nastavení se Workers založené na rozšířeních automaticky aktualizují na nové podverze, což snižuje zátěž údržby spojenou s udržováním aktuálního stavu. opravy a vylepšení zabezpečeníHlavní verze však stále vyžadují manuální aktualizace.
Omezení a organizace hybridních Runbook Workerů
Z hlediska kapacity umožňuje každý účet Automation až 4 000 systémových hybridních Runbook Workerů a 4 000 uživatelských hybridních Runbook Workerů . Pokud potřebujete spravovat více než 4 000 počítačů, doporučuje se vytvořit nový účet Automation pro rozdělení pracovní zátěže.
Každý uživatelský proces Hybrid Runbook Worker patří do skupiny Workerů , kterou definujete během instalace. Skupina může hostovat jednu nebo více instancí pro zajištění vysoké dostupnosti. Jeden počítač může odesílat prezenční signály pouze jednomu účtu Automation , to znamená, že jej nelze registrovat jako Worker ve více účtech současně.
Skupiny jsou navrženy tak, aby nabízely vysokou dostupnost a vyvažování zátěže distribucí úloh mezi svými členy. Workeři používají mechanismus dotazování: každý aktivní Worker se dotazuje služby každých 30 sekund a může shromáždit až 4 úlohy na „ping“. Pokud míra příchodu úloh překročí kombinovanou kapacitu Workerů, některé mohou být pozastaveny s chybou.
Pokud žádný pracovník ve skupině neodeslal příkaz ping na službu v posledních 30 minutách, Azure považuje skupinu za skupinu bez aktivních pracovníků . V takovém případě se úlohy třikrát zopakují a poté se pozastaví. Toto chování je klíčové pro správné dimenzování počtu pracovníků na základě očekávané pracovní zátěže.
Možnosti a limity provádění v Hybrid Runbook Worker
Důležitým detailem je, že instance Hybrid Runbook Worker není omezena limity sandboxu Azure, pokud jde o disk, paměť nebo síťové sokety. Skutečná omezení jsou dána fyzickými prostředky samotného serveru, což je nezbytné pro spouštění dlouhodobých nebo vysoce náročných automatizací.
Pokud se hostitelský počítač hybridního Runbook Workeru restartuje během běhu Runbooku, úloha se restartuje od začátku nebo od posledního kontrolního bodu v případě runbooků PowerShell Workflow. Pokud se stejná úloha restartuje více než třikrát, je pozastavena, aby se zabránilo nekonečným smyčkám.
Ve Windows se úlohy spouštějí pod lokálním systémovým účtem a v Linuxu pod účtem nxautomation . Protože tyto runbooky často přistupují k prostředkům mimo Azure, nemohou se spoléhat pouze na typický mechanismus ověřování runbooků Azure; vyžadují lokální ověřování specifické pro daný prostředek nebo použití správně nakonfigurovaných spravovaných identit a spouštěcích účtů.
Pro lepší organizaci pracovních postupů můžete zaregistrovat stejný počítač ve více skupinách Hybrid Runbook Worker v rámci stejného účtu a směrovat různé Runbooky do každé skupiny na základě typu úlohy, plánů nebo kritičnosti.
Typické scénáře s hybridním Runbook Workerem
Nejběžnější případy použití pro Hybrid Runbook Worker kombinují prostředky Windows a Linuxu v Azure i mimo něj, čímž vytvářejí skutečně hybridní pracovní postupy:
- Správa hostovaných počítačůSpouštějte runbooky přímo na virtuálních počítačích Azure nebo na serverech mimo Azure registrovaných v Azure Arc (včetně VMware s podporou Arc), ať už se jedná o Windows nebo Linux.
- Překonávání omezení sandboxuPro operace, které překračují tříhodinový limit cloudové práce, spotřebovávají mnoho zdrojů nebo vyžadují zvýšená oprávnění, poskytují hybridní pracovníci prostředí flexibilnější a bez těchto omezení.
- Požadavky na suverenitu a bezpečnostV organizacích, kde není povoleno zpracování určitých dat v cloudu, je můžete uchovávat v Lokální počítače převedené na hybridní pracovníky a tím dodržovat interní i externí předpisy.
- Automatizace v multicloudovém a on-premise prostředíJednoduše přidejte počítač, například pracovníka, a spusťte automatizaci na dalších počítačích v místní síti nebo v různých cloudech, a to jak s Windows, tak s Linuxem.
- Soukromý přístup ke službám z virtuálních sítíSpouštění runbooků na pracovních procesech připojených k virtuální síti Azure a soukromý přístup k dalším službám. bez nutnosti otevírat internetové připojení.
Chcete-li nasadit instanci Hybrid Runbook Worker ve Windows nebo Linuxu pomocí nového přístupu k rozšířením, jednoduše postupujte podle průvodce nasazením pomocí rozšíření v Azure Automation , který podrobně popisuje použití rozšíření virtuálních počítačů a Azure ARC pro servery.
Plánování sítě a popisky služeb pro Hybrid Runbook Worker
Před samovolným otevřením portů je vhodné zkontrolovat konfiguraci sítě Azure Automation , protože ta určuje porty, adresy URL a další požadavky, které musí pracovní procesy s danou službou splňovat.
Azure Automation podporuje značky služeb virtuální sítě , počínaje značkou GuestAndHybridManagement. Místo uvádění konkrétních rozsahů IP adres v pravidlech NSG nebo Azure Firewall můžete tuto značku přímo použít ve zdroji nebo cíli pravidel k povolení nebo zakázání provozu služby Automation.
Značka GuestAndHybridManagement zahrnuje IP adresy používané například ke spouštění webhooků z virtuální sítě nebo k povolení komunikace mezi Hybrid Runbook Worker a State Configuration agenty s Azure Automation. Neumožňuje omezení na základě regionu, ale výrazně zjednodušuje správu zabezpečení sítě.
Podpora datových částí IL5 v Azure Government
Pokud pracujete s velmi vysokými požadavky na zabezpečení, Azure Automation podporuje úlohy s dopadem úrovně 5 (IL5) v Azure Government pomocí Hybrid Runbook Worker ve dvou konfiguracích:
- Izolované virtuální stroje které spotřebují celý fyzický hostitel a poskytují tak úroveň izolace požadovanou IL5.
- Vyhrazený hostitel Azurekde jeden nebo více virtuálních počítačů běží na fyzických serverech vyhrazených pro vaše předplatné, což zaručuje izolaci na úrovni hardwaru.
Azure Logic Apps (Standard) v hybridním režimu pro toky Windows-Linux
Další klíčovou součástí pro vytváření hybridních pracovních postupů Windows-Linux je model hybridního nasazení Azure Logic Apps (Standard) . Tato možnost umožňuje vytvářet a hostovat integrační řešení v částečně propojených prostředích, která vyžadují lokální zpracování a úložiště spolu s interním přístupem k síti.
V tomto modelu je běhové prostředí Logic Apps hostováno na vaší infrastruktuře jako součást rozšíření Azure Container Apps a může se nacházet v lokálních systémech, privátních nebo veřejných cloudech a připojovat se k serverům Windows nebo Linux nebo službám SaaS.
Aktuální omezení hybridního modelu Logic Apps
Při práci v hybridním režimu s Logic Apps Standard je třeba vzít v úvahu některá omezení:
- Je k dispozici pouze v určité oblasti Azure (Střední a východní USA, východní Asie, jihovýchodní Asie, střední Švédsko, jižní Spojené království, západní Evropa, západ USA a další uvedené v oficiální dokumentaci).
- V částečně připojeném režimu může běhové prostředí zůstat odpojeno až na 24 hodin s uchováním datových protokolůPo uplynutí této doby by se protokoly mohly ztratit.
- Několik funkcí jednoklientské platformy Logic Apps Standard není v hybridním prostředí podporováno, například Implementační sloty, sledování obchodních procesů, stav zdrojů na portálu nebo ověřování pomocí spravovaných identit pro určité operace konektoru v clusterech Kubernetes s podporou Azure ARC.
- Některé spouštěče založené na funkcích (například Blob, Cosmos DB nebo Event Hubs) vyžadují konfiguraci připojovacího řetězce účtu úložiště v proměnné aplikace AzureWebJobsStoragebuď v Azure Portal, nebo v souboru local.settings.json projektu Logic Apps ve VS Code.
Předpoklady pro hybridní implementaci
Chcete-li nastavit hybridní pracovní postup se službou Logic Apps Standard, potřebujete kromě předplatného Azure také řadu lokálních prostředků ve stejné síti:
- Un Cluster služeb Azure Kubernetes připojený k Azure ARC, která bude sloužit jako spouštěcí platforma pro kontejnery Logic Apps.
- A lokální SQL databáze pro ukládání historie provádění, vstupů a výstupů pracovních postupů.
- Un Sdílení souborů SMB pro ukládání artefaktů používaných toky.
Pro vývoj a nasazení těchto postupů se běžně používá Visual Studio Code s rozšířením Azure Logic Apps (Standard) , které usnadňuje úpravy, testování a publikování v hybridním prostředí, které jste si nastavili.
Verzování, telemetrie a škálování v hybridních Logic Apps
Pokaždé, když uložíte změny do podřízeného toku ve standardní logické aplikaci nakonfigurované pro hybridní hosting, automaticky se vytvoří nová revize Azure Container Apps . Aktivace této revize může chvíli trvat, proto je vhodné před testováním změn chvíli počkat.
Pro sledování těchto pracovních postupů můžete v Application Insights povolit vylepšenou telemetrii s podporou OpenTelemetry. To vám poskytne metriky výkonu v reálném čase a podrobný přehled o stavu systému spolu s kontrolou nad tím, která data se odesílají, a optimalizovat tak náklady na úložiště.
Na úrovni prostředků můžete upravit paměť a virtuální procesory (vCPU) přidělené kontejneru Logic App Standard z portálu Azure. Můžete měnit počet jader procesoru (například z 0,25 na 2 virtuální procesory) a paměť (například z 0,1 na 4 GiB), což přímo ovlivňuje výkon toku i fakturaci.
Můžete také definovat škálování replik vytvářených v reakci na spouštěcí události. Konfiguruje se minimální a maximální počet replik (až 1000) a pokročilejší pravidla škálování se spravují z Azure Container Apps, což vám umožňuje dynamicky se přizpůsobovat špičkám zatížení v integračních tocích ovlivňujících systémy Windows a Linux.
Vstup, ověřování a tajné kódy v hybridních prostředích
Služby Logic Apps Standard lze zpřístupnit veřejnému webu, virtuální síti nebo jiným aplikacím Logic Apps ve stejném prostředí konfigurací možnosti příchozího provozu. Azure zpracovává směrování příchozího provozu HTTP nebo TCP, aniž by vyžadoval ruční zřizování nástrojů pro vyrovnávání zátěže nebo dalších veřejných IP adres.
V clusterech Kubernetes s podporou Azure ARC nemůže spravované ověřování připojení API nativně používat spravované identity. Místo toho je nutné vytvořit registraci aplikace v Microsoft Entra ID a použít ji jako základ pro připojení.
- Z portálu Azure Portal nebo rozhraní Azure CLI vytvoříte aplikaci a shromažďujete ID klienta, ID nájemníka, ID objektu a Tajný identifikátor klienta.
- Pak tyto hodnoty sečtete jako Proměnné prostředí v prostředku Logic Apps Standard (například WORKFLOWAPP_AAD_CLIENTID, WORKFLOWAPP_AAD_OBJECTID, WORKFLOWAPP_AAD_TENANTID, WORKFLOWAPP_AAD_CLIENTSECRET).
- Volitelně můžete uložit clientId a clientSecret jako tajemství samotného zdroje a poté se na ně odkazovat z proměnných prostředí pro větší bezpečnost.
Takto nakonfigurovaná logika ověřování umožňuje hybridním tokům komunikovat s rozhraními Azure API a dalšími chráněnými službami a zároveň zachovat robustní model přihlašovacích údajů.
Běžné problémy a řešení v hybridních logických aplikacích
V hybridních prostředích se vždy mohou vyskytnout překvapení. Pro diagnostiku problémů s konfigurací prostředí nebo neúspěšných nasazení z portálu společnost Microsoft publikuje v oficiálním repozitáři Logic Apps skript PowerShellu s názvem troubleshoot.ps1, který kontroluje typické body selhání.
V clusterech Kubernetes připojených k Azure Arc lze někdy pozorovat vzorce vysokého využití paměti . V takových případech se doporučuje škálovat skupiny uzlů horizontálně nebo povolit automatické škálování clusteru.
Pokud se aplikace Logic App nespustí správně, je vhodné zkontrolovat stav prostředků z Azure Portal a v případě chyby použít kubectl ke kontrole podů . Zprávy jako „Příliš mnoho podů“ označují nedostatečnou kapacitu uzlu, zatímco varování o nevázaných PersistentVolumeClaims obvykle poukazují na problémy s ovladačem SMB CSI . V takovém případě je před pokračováním nezbytným krokem instalace ovladače smb.csi.k8s.io pomocí Helmu.
Sjednocená automatizace s Ansible pro Windows a Linux
Kromě ekosystému Azure je účinným přístupem k hybridním pracovním postupům Windows-Linux použití platformy Red Hat Ansible Automation Platform (AAP) jako jednotného jazyka. Ansible boří historické oddělení mezi bash skripty v Linuxu a PowerShellem nebo plánovanými úlohami ve Windows.
S jedinou příručkou napsanou v YAML můžete konfigurovat, nasazovat a spravovat servery Windows i Linux . Ansible nabízí nativní moduly pro obě prostředí, které pokrývají vše od instalace balíčků a konfigurace služeb až po vytváření uživatelů a nasazení aplikací.
Například v jednom playbooku můžete nainstalovat Apache na servery Red Hat a IIS na počítače se systémem Windows , spustit služby a povolit je při spuštění pomocí podmínek založených na rodině operačních systémů. Provedení se redukuje na spuštění playbooku Ansible na inventáři, který kombinuje oba typy serverů.
To se promítá do několika jasných výhod: méně nástrojů k údržbě, standardizované konfigurace bez ohledu na operační systém, škálovatelnost na stovky serverů s reportingem a kontrolou verzí a hmatatelné zlepšení zabezpečení a dodržování předpisů, protože vše, co se dělá, je zaznamenáváno a auditovatelné.
AWS Systems Manager v hybridních a multicloudových prostředích Linux-Windows
Pokud se část vašeho hybridního prostředí nachází na AWS, je Systems Manager dalším nástrojem, který je vhodné zvážit pro orchestraci pracovních postupů napříč uzly Windows a Linux , které nemusí být nutně instancemi EC2. Klíčem je SSM Agent, kterého můžete nainstalovat na počítače se systémy Linux a Windows mimo EC2 pomocí procesu hybridní aktivace.
Během aktivace se vygeneruje aktivační ID a kód , které se přiřadí k vašemu účtu AWS. Ty se poté použijí k registraci každého počítače jako spravovaného uzlu. V systému Linux příkaz `ssm-setup-cli` stáhne a nainstaluje agenta, zastaví ho a zaregistruje instanci. Od této chvíle se uzel stává spravovaným uzlem s identifikátorem, který obvykle začíná na „my-“, aby se odlišil od instancí EC2.
Po integraci můžete spouštět vzdálené příkazy, nasazovat záplaty, aplikovat konfigurace nebo dokonce používat Change Manager a další funkce (mějte na paměti, že některé, jako například dashboard CloudWatch pro Systems Manager, oznámily datum ukončení podpory).
Agenta SSM lze také nakonfigurovat tak, aby automaticky rotoval privátní klíč v hybridních a multicloudových prostředích (počínaje verzí 3.0.1031.0), čímž se posílí zabezpečení. Tato nastavení jsou konfigurována v konfiguračním souboru agenta a každá změna vyžaduje restartování služby.
Pokud potřebujete zrušit registraci a znovu zaregistrovat uzel Linuxu, k dispozici je operace DeregisterManagedInstance v rozhraní AWS CLI a následně se doporučuje vymazat položky, jako například IdentityConsumptionOrder v souboru amazon-ssm-agent.json, a spustit volbu -register -clear agenta podle typu instalace.
Pokud jde o typické problémy, kódy jako DeliveryTimedOut lze očekávat při změně ID uzlu během instalace napříč účty. Chybové zprávy o FingerprintDoesNotMatch ukazují na ID počítačů, která se neukládají po restartu, což lze vyřešit vynucením generování a uchování ID počítačů v Linuxu.
Aplikace Windows integrované do desktopů s Linuxem pomocí WinApps
Nejde jen o back-endové procesy: mnoho hybridních pracovních postupů Windows-Linux přímo ovlivňuje uživatelskou zkušenost. WinApps je nástroj s otevřeným zdrojovým kódem, který umožňuje spouštět nativní aplikace Windows z desktopů GNU/Linux (KDE, GNOME, XFCE), jako by se jednalo o lokální aplikace.
Díky bezproblémové integraci mohou sady jako Microsoft 365 nebo Adobe Creative Cloud běžet na vzdáleném počítači s Windows, ale zobrazovat se a spravovat jako nativní okna Linuxu. Pro koncového uživatele jsou ikony, zástupci a okna integrovány s prostředím plochy, což snižuje zátěž systémů s oběma operačními systémy.
Nejjednodušší způsob nasazení WinApps je prostřednictvím Dockeru s využitím veřejně dostupného obrazu a pluginu WorkflowUIPlugin v ComfyUI, pokud chcete tuto integraci kombinovat s generováním obsahu nebo pracovními postupy s umělou inteligencí. Specializované společnosti vám mohou pomoci definovat architektury, kde desktopy s Linuxem využívají aplikace Windows hostované v cloudu (AWS, Azure) a zároveň zachovat centralizované řízení přístupu, kybernetickou bezpečnost a monitorování.
Hybridní práce, spolupráce a moderní vývoj v Microsoftu 365 a Windows
Hybridní pracovní postupy Windows-Linux neexistují odděleně od lidí; jsou hluboce propojeny s tím, jak zaměstnanci spolupracují, sdílejí informace a vyvíjejí aplikace . Microsoft 365, a zejména Teams, se staly „organizační vrstvou“ pro mnoho společností s miliony uživatelů pracujících na dálku a v hybridních prostředích.
Společnost Microsoft mnoho z těchto řešení nazývá aplikacemi pro spolupráci : aplikacemi, které upřednostňují synchronní a asynchronní spolupráci se schůzkami, chatem, spoluvytvářením dokumentů a automatizací obchodních procesů, to vše integrované do jednoho rozhraní. Pro vývojáře to otevírá příležitost vytvářet aplikace, které fungují konzistentně v systémech Windows, macOS, webu, iOS, Androidu a Linuxu.
Teams nabízí API a body rozšiřitelnosti pro bohaté aplikace pro schůzky (integrace sdílených fází, události zahájení/ukončení schůzky, vlastní scény v konferenčním režimu, mediální API se souhlasem specifickým pro daný zdroj) a integruje se s Azure Communication Services, aby uživatelům Teams umožnila komunikovat s externími klienty prostřednictvím vlastních hlasových, video a chatovacích aplikací.
Kromě toho je spolupráce napříč platformami vylepšena o komponenty Fluid v Teams (tabulky, seznamy a bloky, které lze upravovat v reálném čase a také sdílet s Outlookem a Office) a o opakovaně použitelná rozšíření zpráv v Outlooku a Teams. Power Platform (Power Apps, Power Automate, Power Virtual Agents) doplňuje tento ekosystém o boty a nízkokódové toky, které lze nasadit v Teams.
Aby Microsoft vývojářům usnadnili život, nabízí sadu nástrojů Teams Toolkit pro Visual Studio a VS Code se zjednodušeným ověřováním a používáním Graphu, integrací s Azure Functions a SPFx a portálem pro vývojáře Teams, kde můžete registrovat, konfigurovat a spravovat aplikace v centralizované konzoli, včetně aspektů, jako jsou plány SaaS a analýzy využití.
Data, zabezpečení a rozšiřitelnost s Microsoft Graphem a moderním Windows
V pozadí je mnoho z těchto kolaborativních prostředí postaveno na platformě Microsoft Graph , která zpřístupňuje komunikaci, obsah a data lidí pomocí ovládacích prvků ochrany osobních údajů a zabezpečení, které využívá Azure AD. Nové funkce, jako je průběžné vyhodnocování přístupu, umožňují okamžitější odvolání tokenů v reakci na kritické události a metoda ověřování a externí rozhraní API pro identitu poskytují větší kontrolu nad tím, kdo k čemu přistupuje.
Pro ty, kteří potřebují přenášet data do Microsoft 365, umožňují konektory Microsoft Graph indexovat externí zdroje, jako je Jira nebo Confluence, obohacovat uživatelské profily a účastnit se funkcí, jako je Microsoft Search nebo eDiscovery. Datové připojení Microsoft Graph zároveň umožňuje export datových sad produktivity do Azure pro pokročilou analýzu nebo trénování modelů umělé inteligence.
V oblasti desktopových aplikací pomáhá Project Reunion (nyní součást strategie modernizace aplikací pro Windows ) s WinUI 3 a WebView 2 a podporou pro .NET 5 a verze Windows 10 od 1809 novějších, novým i stávajícím aplikacím lépe využívat zařízení s Windows a zároveň se integrovat s cloudovými službami.
Nástroje jako Windows Terminal (konfigurovatelný jako výchozí terminál s režimy jako Quake) a Windows Subsystem pro Linux s podporou grafických aplikací výrazně usnadňují vývoj a správu hybridních prostředí z Windows a kombinují klasické CLI, linuxové shell a grafické nástroje v jednom pracovním postupu.
Závěrečné úvahy
Na druhou stranu, Power Automate Desktop a funkce jako Process Advisor zavádějí ve Windows 10 RPA bez nutnosti kódování, což vám umožňuje identifikovat úzká hrdla a opakující se úlohy, které lze snadno automatizovat, často v kombinaci s linuxovými back-endovými systémy nebo cloudovými službami.
Kombinací všech těchto prvků – Azure Automation, Logic Apps, Ansible, AWS Systems Manager, WinApps, Teams, Graph a vylepšení Windows a WSL – je možné vybudovat skutečně robustní hybridní pracovní postupy Windows-Linux, kde jsou automatizace, integrace, zabezpečení a spolupráce koordinovány, takže se lidé mohou soustředit na poskytování hodnoty, nikoli na potíže s nepropojenými nástroji nebo křehkými manuálními procesy. Sdílejte tyto informace, aby se o nich dozvědělo více lidí.