Många företag har gått från att ha ett enda "dominerande" operativsystem till att samexistera med Windows-servrar, Linux-servrar, fysiska maskiner, publika moln och lokala miljöer De behöver kommunicera med varandra utan att störa något. Frågan är inte längre om hybridarbete är möjligt, utan hur man organiserar dessa arbetsflöden för att göra dem säkra, repeterbara och enkla att underhålla.
När du kombinerar Windows och Linux, tillsammans med flera moln, behöver du mer än bara bra skript. Du behöver en tydlig strategi för skapa hybrida Windows-Linux-arbetsflöden som integrerar automatisering, orkestrering, säkerhet och övervakning med hjälp av rätt delar: Azure Automation och Hybrid Runbook Worker, Logic Apps i hybridläge, Ansible, AWS Systems Manager, skrivbordsverktyg som WinApps och hela det moderna utvecklings- och samarbetslagret i Microsoft 365 och Windows.
Varför är hybrida Windows-Linux-arbetsflöden inte längre valfria?
I de flesta nuvarande organisationer samexisterar de Linux-maskiner med kritiska applikationer och Windows-servrar med interna tjänster, databaser och äldre applikationerAtt upprätthålla två isolerade världar, var och en med sina egna verktyg, leder till dubbelarbete och en brutal ökning av mänskliga fel.
När du börjar hantera dussintals eller hundratals blandade servrarManuella procedurer och fristående skript är inte längre gångbara. Ni behöver ett automatiserings- och orkestreringslager som låter er definiera processer en gång och köra dem där de behövs, oavsett om det är på Windows, Linux, i molnet eller i ert datacenter.
I detta sammanhang framträder flera viktiga delar: Azure Automation med Hybrid Runbook Worker för att automatisera ditt nätverk, Logic Apps i hybridläge för att integrera distribuerade systemAnsible som ett gemensamt språk mellan Linux och Windows, AWS Systems Manager för hybridnoder och verktyg som WinApps som låter dig använda Windows-applikationer från Linux-skrivbord sömlöst.
Hybridautomatisering med Azure Automation och Hybrid Runbook Worker
En första pelare för att skapa hybridarbetsflöden är Flytta Azure Automation-runbooks till dina lokala Windows- och Linux-servrar eller andra molnmiljöer.Det är här funktionen Hybrid Runbook Worker kommer in i bilden, vilket gör att runbooks kan köras direkt på de datorer som är värdar för den här rollen.
Runbooks fortsätter lagras och hanteras i Azure AutomationDe levereras dock till ett eller flera team som är registrerade som Hybrid Runbook Workers. Detta gör att ni kan automatisera resurser lokalt eller i andra moln utan att de direkt exponeras för internet eller behöver skriva om all er automatisering utanför Azure.
Tillägg kontra klassisk agent: Två sätt att installera Hybrid Runbook Worker
Idag kan du distribuera användarrollen Hybrid Runbook Worker genom att Två distinkta installationsplattformar: tilläggsbaserade och agentbaseradeEfter installationen är körningsbeteendet för runbooken detsamma, men tilläggsmetoden förenklar radikalt onboarding och underhåll.
Det klassiska alternativet berodde på Log Analytics-agentDetta resulterade i en längre och mer felbenägen process. Den tilläggsbaserade modellen integreras direkt med Azures ramverk för virtuella maskiner, med hjälp av Azure VM-agenten för virtuella Azure-maskiner och Azure Connected Machine-agenten för icke-Azure-maskiner, inklusive Azure Arc-aktiverade servrar och VMware vSphere-aktiverade för Arc.
Båda typerna av Hybrid Runbook Worker kan lever i samma maskinOch den tilläggsbaserade installationen stör inte instanser som du redan har distribuerat med den traditionella agenten, vilket underlättar sömlösa, stegvisa migreringar.
Viktiga fördelar med den utvidgningsbaserade metoden
Den tilläggsbaserade modellen minskar avsevärt den operativa friktionen vid distribution av en användares Hybrid Runbook Worker genom att eliminera onödiga beroenden. Viktiga fördelar inkluderar:
- Mycket smidigare onboardingDu är inte längre beroende av Log Analytics-agenten för att registrera arbetare, vilket undviker flerstegsprocesser och vanliga fel vid manuella installationer.
- Centraliserad hantering skalbar redanDirekt integration med Azure Resource Manager (ARM)-identitet, vilket möjliggör styrning av storskalig distribution med hjälp av policyer, ARM-mallar, Bicep, PowerShell eller CLI.
- Autentisering med Microsofts inloggnings-IDSystemtilldelade hanterade identiteter utnyttjas på virtuella maskiner, så att Referenser hanteras på ett enhetligt sätt och utan att lagra dem i klartext i skript eller konfigurationer.
- Samma modell för Azure och Azure ArcBåde maskiner inom Azure och fysiska servrar eller virtuella maskiner hos andra leverantörer (via Azure Arc) hanteras. med samma erfarenhetDetta förenklar hybrid- och multimolnmiljöer avsevärt.
- Flera sätt att gå medRollen kan installeras från Azure Portal, PowerShell, Bicep, ARM-mallar, Azure REST eller CLI, eller direkt från fliken i Förlängningar för varje Arc-aktiverad virtuell maskin eller server.
- Automatiska uppdateringar av mindre versionerSom standard uppdateras tilläggsbaserade Workers automatiskt till nya delversioner, vilket minskar underhållsbördan med att hålla sig uppdaterad. säkerhetsfixar och förbättringarHuvudversionerna kräver dock fortfarande manuella uppdateringar.
Begränsningar och organisation av Hybrid Runbook Workers
Kapacitetsmässigt kan du för varje Automation-konto ha upp till 4000 Hybrid Runbook Workers-system och 4000 användareOm du behöver hantera fler än 4000 maskiner rekommenderas det att skapa ett nytt Automation-konto för att fördela belastningen.
Varje användares Hybrid Runbook Worker tillhör en grupp av arbetare som du definierar när du installerar den. En grupp kan vara värd för en enskild instans eller flera instanser för hög tillgänglighet. En enskild maskin kan bara skicka pulsslag till ett Automation-kontoDet vill säga, du kan inte vara registrerad som arbetare på flera konton samtidigt.
Grupperna är utformade för att erbjuda hög tillgänglighet och lastbalansering genom att fördela jobb bland sina medlemmar. Arbetare använder en avfrågningsmekanism: varje aktiv arbetare frågar tjänsten var 30:e sekund och kan samla in upp till 4 jobb per "ping". Om antalet jobb som anländer överstiger arbetarnas kombinerade kapacitet kan vissa bli avstängda med ett felmeddelande.
Om ingen arbetare i en grupp har pingat tjänsten under de senaste 30 minuterna anser Azure att gruppen är aktiv. Den har inga aktiva arbetareI så fall görs omförsök på jobb tre gånger och pausas sedan. Detta beteende är avgörande för att korrekt dimensionera antalet arbetare baserat på den förväntade arbetsbelastningen.
Funktioner och körningsgränser i Hybrid Runbook Worker
En viktig detalj är att en instans av Hybrid Runbook Worker Den är inte begränsad av gränserna för Azure-sandlådan När det gäller diskutrymme, minne eller nätverksuttag bestäms de verkliga begränsningarna av serverns fysiska resurser, vilket är avgörande för att köra långvariga eller mycket intensiva automatiseringar.
Om värddatorn för en Hybrid Runbook Worker startas om medan en Runbook körs, startas jobbet om från början eller från sista kontrollpunkten När det gäller PowerShell Workflow-runbooks pausas samma jobb för att förhindra oändliga loopar om det startas om mer än tre gånger.
I Windows körs jobb i lokalt systemkontooch på Linux under kontot nxautomationEftersom dessa runbooks ofta använder resurser utanför Azure kan de inte enbart förlita sig på den typiska autentiseringsmekanismen för Azures runbooks; de behöver specifik autentisering för lokala resurser eller använd korrekt konfigurerade hanterade identiteter och körningskonton.
För att bättre organisera arbetsflöden kan du registrera samma maskin i flera Hybrid Runbook Worker-grupper inom samma konto, och dirigera olika runbooks till varje grupp beroende på typ av belastning, scheman eller kritiska aspekter.
Typiska scenarier med Hybrid Runbook Worker
De vanligaste användningsfallen för Hybrid Runbook Worker kombinerar Windows- och Linux-resurser både i och utanför Azure, vilket skapar verkligt hybrida arbetsflöden:
- Hantering av gästmaskinerKör Runbooks direkt på virtuella Azure-maskiner eller på servrar utanför Azure som är registrerade med Azure Arc (inklusive Arc-aktiverade VMware), oavsett om det är Windows eller Linux.
- Att övervinna sandlådans begränsningarFör operationer som överskrider gränsen för tre timmars molnarbete, förbrukar många resurser eller kräver utökade behörigheter, tillhandahåller Hybrid Workers en miljö. mer flexibel och utan dessa begränsningar.
- Suveränitets- och säkerhetskravI organisationer där det inte är tillåtet att behandla viss data i molnet kan du spara den Lokala maskiner konverterade till hybridarbetare och därmed följa interna och externa föreskrifter.
- Automatisering i multimoln- och lokala miljöerLägg helt enkelt till en maskin som Worker för att starta automatisering till andra maskiner i det lokala nätverket eller olika moln, både Windows och Linux.
- Privat åtkomst till tjänster från virtuella nätverkKör runbooks på arbetare som är anslutna till ett virtuellt Azure-nätverk och få privat åtkomst till andra tjänster utan att behöva öppna internetanslutningar.
För att distribuera en Hybrid Runbook Worker-instans på Windows eller Linux med den nya tilläggsmetoden, följ helt enkelt guiden i Implementering med tillägg i Azure Automation, som beskriver användningen av VM-tillägg och Azure Arc för servrar.
Nätverksplanering och tjänstetiketter för Hybrid Runbook Worker
Innan du öppnar portar mot förmodan är det en bra idé att kontrollera Azure Automation-nätverkskonfiguration, eftersom den anger portar, URL:er och andra krav för att arbetare ska kunna kommunicera korrekt med tjänsten.
Azure Automation-stöd etiketter för virtuella nätverkstjänsterBörjar med taggen GuestAndHybridManagement. Istället för att lista specifika IP-intervall i NSG- eller Azure Firewall-regler kan du använda den här taggen direkt i källan eller destinationen för reglerna för att tillåta eller neka trafik till Automation-tjänsten.
Taggen GuestAndHybridManagement täcker IP-adresser som används till exempel för aktivera webhooks inifrån ett VNet eller tillåta Hybrid Runbook Worker och State Configuration-agenter att kommunicera med Azure Automation. Det tillåter inte regionbaserade begränsningar, men det förenklar nätverkssäkerhetshanteringen avsevärt.
Stöd för IL5-nyttolaster i Azure Government
Om du arbetar med mycket höga säkerhetskrav stöder Azure Automation Nivå 5-påverkansarbetsbelastningar (IL5) i Azure Government med Hybrid Runbook Worker i två konfigurationer:
- Isolerade virtuella maskiner som förbrukar en hel fysisk värd, vilket ger den isoleringsnivå som krävs av IL5.
- Azure dedikerad värddär en eller flera virtuella maskiner körs på fysiska servrar dedikerade till din prenumeration, vilket garanterar isolering på hårdvarunivå.
Azure Logic Apps (Standard) i hybridläge för Windows-Linux-flöden
En annan viktig komponent för att skapa hybrida Windows-Linux-arbetsflöden är modellen för Hybridimplementering av Azure Logic Apps (Standard)Det här alternativet låter dig bygga och vara värd för integrationslösningar i delvis anslutna miljöer som kräver lokal bearbetning och lagring samt åtkomst till ett internt nätverk.
I den här modellen finns Logic Apps-körningen i din infrastruktur som en del av ett Azure Container Apps-tillägg, kunna finnas på lokala system, privata moln eller publika moln, och ansluta till både Windows- och Linux-servrar eller SaaS-tjänster.
Nuvarande begränsningar för Logic Apps hybridmodell
När man arbetar i hybridläge med Logic Apps Standard måste vissa begränsningar beaktas:
- Den är endast tillgänglig i vissa Azure-regioner (Centrala och östra USA, Östasien, Sydostasien, Centralsverige, södra Storbritannien, Västeuropa, västra USA, bland annat listade i den officiella dokumentationen).
- I delvis anslutet läge kan körtiden förbli frånkopplad i upp till 24 timmar medan dataloggar upprätthållsUtöver den perioden kan loggar gå förlorade.
- Flera funktioner i Logic Apps Standard för enskilda klienter stöds inte i hybrid, till exempel Implementeringsplatser, affärsprocessspårning, resurshälsa i portalen eller autentisering med hanterade identiteter för vissa kopplingsåtgärder i Azure Arc-aktiverade Kubernetes-kluster.
- Vissa funktionsbaserade triggers (t.ex. Blob, Cosmos DB eller Event Hubs) kräver att anslutningssträngen för lagringskontot konfigureras i programvariabeln AzureWebJobsStorageantingen i Azure Portal eller i local.settings.json-filen för Logic Apps-projektet i VS Code.
Förutsättningar för en hybridimplementering
För att konfigurera ett hybridarbetsflöde med Logic Apps Standard behöver du, utöver en Azure-prenumeration, en serie lokala resurser på samma nätverk:
- Un Azure Kubernetes-tjänstkluster anslutet till Azure Arc, som kommer att fungera som exekveringsplattform för Logic Apps-containrar.
- en lokal SQL-databas för att lagra körningshistorik, indata och utdata från arbetsflödena.
- Un SMB-fildelning för att lagra de artefakter som används av flödena.
För att utveckla och distribuera dessa arbetsflöden är det vanligt att använda Visual Studio Code med Azure Logic Apps-tillägg (standard)vilket underlättar redigering, testning och publicering i den hybridmiljö du har skapat.
Versionshantering, telemetri och skalning i hybrid Logic Apps
Varje gång du sparar ändringar i ett underordnat flöde till en Standard Logic App som är konfigurerad för hybridhosting, visas en ny version av Azure Container AppsDet kan ta en liten stund att aktivera den här uppdateringen, så det är bäst att vänta en liten stund innan du testar ändringarna.
För att övervaka dessa arbetsflöden kan du aktivera Förbättrad telemetri i Application Insightsmed stöd för OpenTelemetry. På så sätt får du prestandamätningar i realtid och detaljerad insyn i systemets hälsa, med kontroll över vilka data som skickas för att optimera lagringskostnaderna.
När det gäller resurser kan du justera från Azure Portal minne och vCPU tilldelad till Standard Logic App-behållaren. Det är tillåtet att variera CPU-kärnorna (till exempel från 0,25 till 2 vCPU:er) och minnet (till exempel från 0,1 till 4 GiB), med en direkt inverkan på både flödesprestanda och fakturering.
Du kan också definiera replikskala vilket skapas som svar på utlösande händelser. Ett minsta och högsta antal repliker (upp till 1000) konfigureras, och mer avancerade skalningsregler hanteras från Azure Container Apps, vilket möjliggör dynamisk anpassning till belastningstoppar i integrationsflöden som påverkar Windows- och Linux-system.
Inmatning, autentisering och hemligheter i hybridmiljöer
Logic Apps Standard kan exponeras för den offentliga webben, ett virtuellt nätverk eller andra Logic Apps från samma miljö Genom att konfigurera ingress-alternativet hanterar Azure tillämpningen av regler för att dirigera inkommande HTTP- eller TCP-trafik utan att du behöver etablera ytterligare belastningsutjämnare eller offentliga IP-adresser manuellt.
I Azure Arc-aktiverade Kubernetes-kluster kan autentisering av hanterade API-anslutningar inte använda hanterade identiteter direkt. Istället måste du skapa en Registrering av Microsoft-program Ange ID och använd det som grund för kopplingarna:
- Från Azure Portal eller Azure CLI skapar du en applikation och samlar in klient-ID, hyresgäst-ID, objekt-ID och klienthemlighet.
- Sedan lägger du till dessa värden som Miljövariabler i Logic Apps Standard-resursen (till exempel WORKFLOWAPP_AAD_CLIENTID, WORKFLOWAPP_AAD_OBJECTID, WORKFLOWAPP_AAD_TENANTID, WORKFLOWAPP_AAD_CLIENTSECRET).
- Valfritt kan du lagra clientId och clientSecret som hemligheterna hos själva resursen och sedan referera till dem från miljövariabler för ökad säkerhet.
Autentiseringslogiken som konfigurerats på detta sätt gör det möjligt för hybridflöden att kommunicera med Azure API:er och andra skyddade tjänster samtidigt som en robust autentiseringsuppgiftsmodell bibehålls.
Vanliga problem och lösningar i hybrida logikappar
I hybridmiljöer kan överraskningar alltid uppstå. För att diagnostisera problem med miljökonfigurationen eller misslyckade distributioner från portalen publicerar Microsoft en Felsökning av PowerShell-skript.ps1 i det officiella Logic Apps-arkivet som granskar typiska felpunkter.
I Kubernetes-kluster anslutna till Azure Arc, mönster av hög minnesanvändningI dessa fall är rekommendationen att skala nodgrupperna horisontellt eller aktivera automatisk klusterskalbarhet.
Om Logic App inte startar korrekt är det en bra idé att kontrollera resursstatusen från Azure Portal och, om det finns ett fel, hämta från kubectl för att kontrollera poddarnaMeddelanden som "För många poddar" indikerar otillräcklig nodkapacitet, medan varningar om olänkade PersistentVolumeClaims vanligtvis pekar på problem i SMB CSI-drivrutinI så fall är installation av smb.csi.k8s.io-drivrutinen med Helm det nödvändiga steget innan du fortsätter.
Enhetlig automatisering med Ansible för Windows och Linux
Utöver Azure-ekosystemet är en mycket kraftfull metod för hybrida Windows-Linux-arbetsflöden att använda Red Hat Ansible Automation Platform (AAP) som ett enhetligt språk. Ansible bryter ner den historiska separationen mellan bash-skript i Linux och PowerShell eller schemalagda uppgifter i Windows.
Med samma handbok skriven i YAML kan du Konfigurera, driftsätta och underhålla Windows- och Linux-servrarAnsible har inbyggda moduler för båda världarna, som täcker allt från paketinstallation till tjänstkonfiguration, användarskapande och applikationsdistribution.
Till exempel, i en enda playbook kan du installera Apache på Red Hat-servrar och IIS på Windows-maskinerStarta tjänsterna och aktivera dem vid start med villkor baserade på operativsystemfamiljen. Utförandet innebär i huvudsak att en Ansible-playbook startas mot inventeringen som blandar båda typerna av servrar.
Detta leder till flera tydliga fördelar: färre verktyg att underhålla, standardiserade konfigurationer Oavsett operativsystem skalas den upp till hundratals servrar med rapportering och versionshantering, och ger en påtaglig förbättring av säkerhet och efterlevnad genom att registrera och granska allt som görs.
AWS Systems Manager i hybrid- och multimolnmiljöer för Linux och Windows
Om en del av din hybridmiljö använder AWS är Systems Manager ytterligare en del att överväga. orkestrera arbetsflöden över Windows- och Linux-noder vilka inte nödvändigtvis är EC2-instanser. Nyckeln är SSM-agenten, som du kan installera på Linux- och Windows-maskiner utanför EC2 med hjälp av en hybridaktiveringsprocess.
Under aktiveringen, en Aktiverings-ID och en kod kopplade till ditt AWS-konto, vilka sedan används för att registrera varje maskin som en hanterad nod. På Linux laddar och installerar kommandot ssm-setup-cli agenten, stoppar den och registrerar instansen; från och med då blir den en hanterad nod, med en identifierare som vanligtvis börjar med "my-" för att skilja den från EC2-instanser.
När du väl är integrerad kan du köra fjärrkommandon, distribuera patchar, tillämpa konfigurationer eller till och med använda Change Manager och andra funktioner (med tanke på att vissa, som CloudWatch-instrumentpanelen för Systems Manager, har aviserade pensionsdatum).
SSM-agenten kan också konfigureras för att rotera den privata nyckeln automatiskt I hybrid- och multimolnmiljöer (från och med version 3.0.1031.0) stärker detta säkerhetsställningen. Dessa justeringar görs i agentens konfigurationsfil, och varje ändring kräver att tjänsten startas om.
Om du behöver avregistrera och omregistrera en Linux-nod finns åtgärden DeregisterManagedInstance i AWS CLI, och efteråt rekommenderas det att rensa upp poster som IdentitetKonsumtionsordning i amazon-ssm-agent.json och kör alternativet -register -clear för agenten enligt installationstypen.
Angående typiska problem, koder som Leveranstiden överskred Detta beteende kan förväntas när nod-ID ändras under en installation över flera konton. Felmeddelanden om `FingerprintDoesNotMatch` indikerar maskin-ID:n som inte finns kvar efter omstarter, vilket kan lösas genom att tvinga fram generering och bevarande av maskin-ID:n i Linux.
Windows-applikationer integrerade i Linux-skrivbord med WinApps
Det handlar inte bara om backend-processer: många hybrida Windows-Linux-arbetsflöden påverkar direkt användarupplevelsen. WinApps är ett verktyg med öppen källkod som gör det möjligt Kör inbyggda Windows-program från GNU/Linux-skrivbord (KDE, GNOME, XFCE) som om de vore lokala applikationer.
Tack vare den sömlösa integrationen, sviter som Microsoft 365 eller Adobe Creative Cloud De kan köras på en fjärransluten Windows-maskin men visas och hanteras som inbyggda Linux-fönster. För slutanvändaren är ikonerna, genvägarna och fönstren integrerade med skrivbordsmiljön, vilket minskar friktionen på maskiner där båda systemen samexisterar.
Det enklaste sättet att driftsätta WinApps är via HamnarbetareGenom att använda den offentligt tillgängliga bilden och utnyttja WorkflowUIPlugin-pluginet i ComfyUI när denna integration kombineras med innehållsgenerering eller AI-arbetsflöden, kan specialiserade företag hjälpa till att definiera arkitekturer där Linux-skrivbord använder Windows-applikationer som finns i molnet (AWS, Azure) samtidigt som centraliserade åtkomstkontroller, cybersäkerhet och övervakning bibehålls.
Hybridarbete, samarbete och modern utveckling på Microsoft 365 och Windows
Hybrida Windows-Linux-arbetsflöden existerar inte isolerat från människor; de är starkt kopplade till hur teamet samarbetar, delar information och utvecklar applikationerMicrosoft 365, och specifikt Teams, har blivit det "organisatoriska lagret" för många företag, med miljontals användare som arbetar på distans och i hybridläge.
Microsoft hänvisar till många av dessa lösningar samarbetsapplikationerAppar som prioriterar synkront och asynkront samarbete med möten, chatt, samredigering av dokument och automatisering av affärsprocesser, allt integrerat i ett enda gränssnitt. För utvecklare öppnar detta upp en möjlighet att skapa applikationer som fungerar konsekvent i Windows, macOS, webb, iOS, Android och Linux.
Teams erbjuder API:er och utökningspunkter för Förbättrade mötesapplikationer (integrering av delade faser, start-/sluthändelser för möten, anpassade scener i konferensläge, medie-API:er med resursspecifikt samtycke) och integreras med Azure Communication Services för att tillåta Teams-användare att interagera med externa klienter via anpassade röst-, video- och chattapplikationer.
Dessutom främjas samarbete mellan flera plattformar med Flytande komponenter i Teams (tabeller, listor och block som kan redigeras i realtid och även delas med Outlook och Office) och återanvändbara meddelandetillägg i Outlook och Teams. Power Platform (Power Apps, Power Automate, Power Virtual Agents) kompletterar detta ekosystem med robotar och flöden med låg kod som kan distribueras i Teams.
För att göra livet enklare för utvecklare erbjuder Microsoft en Teams-verktygslåda för Visual Studio och VS Codemed förenklad autentisering och Graph-användning, integration med Azure Functions och SPFx, och Teams Developer Portal där du kan registrera, konfigurera och hantera applikationer i en centraliserad konsol, inklusive aspekter som SaaS-planer och användningsanalys.
Data, säkerhet och utökningsmöjligheter med Microsoft Graph och moderna Windows
I bakgrunden är många av dessa gemensamma erfarenheter baserade på Microsoft Graphvilket exponerar kommunikation, innehåll och persondata med sekretess- och säkerhetskontroller som drivs av Azure AD. Nya funktioner som kontinuerlig åtkomstbedömning De möjliggör mer omedelbar återkallelse av tokens vid kritiska händelser, och autentiseringsmetoder och API:er för externa identiteter ger mer kontroll över vem som har åtkomst till vad.
För de som behöver hämta data till Microsoft 365, Microsoft Graph-kopplingar De möjliggör indexering av externa källor som Jira eller Confluence, berikande av användarprofiler och deltagande i upplevelser som Microsoft Search eller eDiscovery. Microsoft Graphs dataanslutning möjliggör under tiden export av produktivitetsdatauppsättningar till Azure för avancerad analys eller AI-modellträning.
Inom området för skrivbordsapplikationer, Project Reunion (nu en del av strategin för Modernisering av Windows-apparMed WinUI 3 och WebView 2, samt stöd för .NET 5 och Windows 10-versioner från 1809, hjälper det nya och befintliga appar att dra bättre nytta av Windows-enheter, samtidigt som det integrerar med molntjänster.
Verktyg som Windows Terminal (konfigurerbar som standardterminal, med lägen som Quake) och Windows-undersystemet för Linux med stöd för GUI-applikationer gör det mycket enklare att utveckla och hantera hybridmiljöer från Windows, genom att blanda klassiska CLI:er, Linux-skal och grafiska verktyg i samma arbetsflöde.
Slutliga överväganden
Å andra sidan, Power Automate Desktop och funktioner som rådgivare för processer De introducerar kodfri RPA i Windows 10, vilket möjliggör identifiering av flaskhalsar och repetitiva uppgifter som enkelt kan automatiseras, ofta i kombination med Linux backend-system eller molntjänster.
Genom att kombinera alla dessa delar – Azure Automation, Logic Apps, Ansible, AWS Systems Manager, WinApps, Teams, Graph och förbättringarna i Windows och WSL – är det möjligt att bygga verkligt robusta hybridarbetsflöden mellan Windows och Linux, där automatisering, integration, säkerhet och samarbete De samordnar så att människor kan fokusera på att skapa värde och inte på att kämpa med frånkopplade verktyg eller ömtåliga manuella processer. Dela informationen så att fler kan lära sig om ämnet.