Använda Windows-containrar för att "containerisera" befintliga program
Gäller för: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016
Windows-containrar är en bra mekanism för att modernisera traditionella eller äldre program. Även om du kan höra denna metod kallas "lyfta och flytta till containrar" kommer lyfta-och-flytta-metaforen från att överföra arbetslaster från fysiska till virtuella datorer och används när man talar om att överföra arbetslaster till molnet. I dag tillämpas den här termen på ett mer lämpligt sätt för migrering av virtuella datorer (VM). Men containrar är inte virtuella datorer, och att tänka på dem som virtuella datorer kan leda till förvirring om hur ett program är containerbaserat, eller om det kan eller bör vara containerbaserat.
Det här avsnittet innehåller praktisk vägledning om hur du flyttar traditionella program till Windows-containrar. Det syftar till att hjälpa dig att prioritera vilka program som ska containeriseras genom att förklara särskilda överväganden i förväg.
Introduktion
Vilka Windows-containrar är och vad de inte är
Den generiska termcontainern refererar till en teknik som virtualiserar operativsystemet (OS). Den här virtualiseringen ger en nivå av isolering från operativsystemet för själva servern/värden, vilket i sin tur ger mer flexibilitet för programutvecklare och driftsteam.
Windows-containrar är en specifik implementering av containerteknik. De tillhandahåller instanser av virtualiserade operativsystem som är isolerade från Windows-operativsystemet. Men det totala beroendet mellan container och värd är omöjligt: en Windows-container måste samordna sin efterfrågan på resurser och funktioner med Windows-operativsystemet. Varför är detta viktigt? Eftersom en Windows-container inte är en hel virtualiserad server och vissa av de saker du kanske vill göra med ett program inte kan göras med endast ett virtualiserat operativsystem.
Du kan läsa mer om det här avsnittet i Containrar jämfört med virtuella datorer. Men några bra punkter som hjälper dig att komma ihåg skillnaden mellan container och virtuell dator är:
- Containrar är inte en lösning som motsvarar virtualisering av skrivbordsprogram. De stöder endast program på serversidan som inte kräver en interaktiv session. Eftersom de körs på specialiserade containeravbildningar stöder de bara de program som inte behöver en grafisk klientdel.
- Containrar är tillfälliga av naturen. Det innebär att det som standard inte finns någon mekanism för att spara tillståndet för en containerinstans. Om en instans misslyckas kommer en annan instans att ta dess plats.
Containertekniken började på Linux, med Docker som standard. Microsoft har haft ett nära samarbete med Docker för att säkerställa att containerfunktionen är så mycket densamma i Windows som möjligt. Inbyggda skillnader mellan Linux och Windows kan uppstå på sätt som verkar vara begränsningar för Windows-containrar när de i själva verket bara är skillnaderna mellan Linux och Windows. Å andra sidan tillhandahåller Windows-containrar vissa unika implementeringar, till exempel Hyper-V isolering, som kommer att omfattas senare. Det här avsnittet hjälper dig att förstå dessa skillnader och hur du kan hantera dem.
Fördelar med att använda containrar
Precis som när du kör flera virtuella datorer på en enda fysisk värd kan du köra flera containrar på en enda fysisk eller virtuell värd. Men till skillnad från virtuella datorer behöver du inte hantera operativsystemet för en container, vilket ger dig flexibiliteten att fokusera på programutveckling och underliggande infrastruktur. Det innebär också att du kan isolera ett program så att det inte påverkas av andra processer som stöds av operativsystemet.
Containrar är en enkel metod för att skapa och dynamiskt stoppa de resurser som krävs för ett fungerande program. Det är möjligt att skapa och distribuera virtuella datorer när programefterfrågan ökar, men det går snabbare att använda containrar för utskalning. Med containrar kan du också starta om snabbt i händelse av en krasch eller maskinvaruavbrott. Med containrar kan du ta alla appar från utveckling till produktion med liten eller ingen kodändring, eftersom de "innehåller" programberoenden så att de fungerar i olika miljöer. Möjligheten att containerisera ett befintligt program med minimala kodändringar på grund av Docker-integreringen i Microsofts utvecklarverktyg är också en kraftfull faktor för programutveckling och underhåll.
Slutligen är en av de viktigaste fördelarna med att använda containrar den flexibilitet du får för apputveckling, eftersom du kan ha olika versioner av en app som körs på samma värd utan resurskonflikter.
Du hittar en mer fullständig lista över fördelar med att använda containrar för befintliga program på dokumentationssidan för Microsoft .NET.
Viktigt begrepp om isoleringsnivå
Windows-containrar ger isolering från Windows-operativsystemet, isolering som är fördelaktig när du skapar, testar och marknadsför en app till produktion. Men det sätt på vilket isoleringen uppnås är viktigt att förstå när du funderar på att containerisera ett program.
Windows-containrar erbjuder två distinkta lägen för körningsisolering: process och Hyper-V-. Containrar under båda lägena skapas och hanteras identiskt och fungerar identiskt. Så, vad är skillnaderna och varför ska du bry dig?
I processisoleringkörs flera containrar samtidigt på en enda värd med isolering via namnrymd, resurskontroll och andra funktioner. Containrar i processisoleringsläge delar samma kernel med värden och varandra. Det här är ungefär samma som hur Linux-containrar körs.
I Hyper-V isoleringkörs flera containrar också samtidigt på en enda värd, men containrarna körs inuti mycket optimerade virtuella datorer, där var och en effektivt får sin egen kernel. Förekomsten av den här virtuella datorn – i praktiken en "verktygsdator" – ger isolering på maskinvarunivå mellan varje container och containervärden.
På sätt och vis är Hyper-V isoleringsläge nästan som en hybrid av en virtuell dator och container, vilket ger ett extra säkerhetslager som är särskilt användbart om din app behöver flera klientorganisationer. Men de möjliga kompromisserna med att använda Hyper-V isoleringsläge är:
- Längre starttid för containern och en sannolik inverkan på den övergripande appprestandan.
- Alla verktyg fungerar inte naturligt med Hyper-V-isolering.
- Varken Azure Kubernetes Service (AKS) eller AKS på Azure Stack HCI stöder Hyper-V isolering just nu.
Du kan läsa mer om hur de två isoleringslägena implementeras i avsnittet isoleringslägen. När du först containeriserar en app måste du välja mellan de två lägena. Lyckligtvis är det mycket enkelt att ändra från ett läge till ett annat senare, eftersom det inte kräver några ändringar i vare sig programmet eller containern. Men tänk på att när du containeriserar en app är valet mellan de två lägena en av de första sakerna du måste göra.
Containerorkestrering
Möjligheten att köra flera containrar på en eller flera värdar utan att behöva hantera operativsystemet ger dig stor flexibilitet, vilket hjälper dig att gå mot en mikrotjänstbaserad arkitektur. En kompromiss för den flexibiliteten är dock att en miljö baserad på containrar och mikrotjänster snabbt kan växa till många rörliga delar – för många för att hålla reda på. Lyckligtvis ansvarar en containerorkestrerare för hantering av belastningsutjämning, hög tillgänglighet, containerschemaläggning, resurshantering och mycket mer.
Orkestratorer är kanske felnamnade; de är mer som dirigenter i en orkester på det sättet att de samordnar aktiviteten hos flera containrar för att musiken ska fortsätta spela. På sätt och vis hanterar de schemaläggning och resursallokering för containrar på ett sätt som liknar hur ett operativsystem fungerar. När du övergår till att containerisera dina program måste du därför välja bland de orkestratorer som stöder Windows-containrar. Några av de vanligaste är Kubernetes och Docker Swarm.
Vilka saker kan inte flyttas till Windows-containrar
När du funderar på om en app kan containeriseras eller inte är det förmodligen enklast att börja med listan över faktorer som helt utesluter Windows-containrar som ett alternativ.
I följande tabell sammanfattas de typer av appar som inte kan flyttas till Windows-containrar och varför inte. Orsakerna förklaras mer fullständigt i underavsnitten efter tabellen. Att förstå orsakerna till dessa begränsningar kan ge dig en tydligare uppfattning om vilka containrar som verkligen är, inklusive hur de skiljer sig från virtuella datorer. Detta hjälper dig i sin tur att bättre utvärdera funktionerna i Windows-containrar som du kan använda med befintliga appar som du kan använda i container.
Obs! Listan nedan är inte en fullständig lista. I stället är det en kompilering av appar som Microsoft har sett kunder försöka containerisera.
| Program/funktioner stöds inte | Varför stöds inte | Kan du kringgå det här? |
|---|---|---|
| Program som kräver ett skrivbord | Containrar stöder inte grafiskt användargränssnitt (GUI) | Om programmet bara kräver att ett GUI installeras kan det vara en lösning att ändra det till en tyst installation |
| Program som använder RDP (Remote Desktop Protocol) | RDP är för interaktiva sessioner, så principen ovan gäller även här | Du kanske kan använda Windows Admin Center (WAC) eller Remote PowerShell som ett alternativ för fjärrhantering |
| Tillståndskänsliga program | Containrar är tillfälliga | Ja, vissa program kan kräva minimal ändring, så att de inte lagrar data eller tillstånd i containern |
| Databasprogram | Containrar är tillfälliga | Ja, vissa program kan kräva minimal ändring, så att de inte lagrar data eller tillstånd i containern |
| Active Directory | Designen och syftet med Active Directory utesluter körning i en container | Nej. Appar som är Beroende av Active Directory kan dock använda grupphanterade tjänstkonton (gMSA). Mer information om gMSA finns nedan |
| Äldre Windows Server-versioner | Endast Windows Server 2016 eller senare stöds | Nej. Programkompatibilitet kan dock vara ett alternativ – de flesta Windows Server 2008/R2 och äldre appar körs på nyare versioner av Windows Server |
| Appar som använder .NET Framework version 2.0 eller äldre | Specifika containeravbildningar krävs för att stödja .NET Framework, och endast nyare versioner stöds | Tidigare versioner än 2.0 stöds inte alls, men se nedan för de containeravbildningar som krävs för senare versioner |
| Appar som använder andra ramverk från tredje part | Microsoft certifierar eller stöder inte specifikt användning av icke-Microsoft-ramverk i Windows-containrar | Kontrollera supportprincipen för Windows-containrar med leverantören av det specifika ramverket eller appen. Mer information finns nedan |
Låt oss överväga var och en av dessa begränsningar i tur och ordning.
Program som kräver ett skrivbord
Containrar är idealiska för tillfälliga funktioner som anropas från andra program, inklusive de med användarinteraktioner. Men du kan inte använda dem för program som själva har GUI:er. Detta gäller även om själva programmet inte har ett GUI men har ett installationsprogram som förlitar sig på ett GUI. I allmänhet kan Windows Installer anropas med PowerShell, men om din applikation kräver installation via ett GUI, utesluter det kravet den som kandidat för containerisering.
Det här är inte ett problem med hur Windows-containrar har implementerats, utan snarare ett grundläggande koncept för hur containrar fungerar.
Det är en annan sak om en app behöver GUI-API:er. API:erna stöds även om det GUI som hanteras av dessa API:er inte är det. Detta förklaras mer fullständigt i avsnittet Nano Server x Server Core x Server – Vilken basavbildning är den rätta för dig?
Program som använder RDP
Eftersom hela syftet med RDP (Remote Desktop Protocol) är att upprätta en interaktiv, visuell session gäller även gui-begränsningen som beskrivs. Ett program som använder RDP kan inte containeriseras as-is.
Ett bra alternativ är dock ett fjärrhanteringsverktyg som Windows Admin Center. Du kan använda Windows Admin Center för att hantera värdar för Windows-containrar och själva containrarna utan att behöva använda RDP för att fjärransluta till dem. Du kan också öppna en PowerShell-fjärrsession till värden och/eller containrarna för att hantera dem.
Tillståndskänsliga program
Program som behöver bevara tillståndsdata kan endast containeriseras om du isolerar de data som behövs från en session till en annan och lagrar dem i beständig lagring. Detta kan kräva viss "omarbetning", vilket kan vara trivialt eller inte, men om du fortsätter med det elimineras den här barriären för containerisering.
Ett exempel på tillstånd är ett webbprogram som lagrar bilder eller musikfiler i en lokal mapp. I en traditionell Windows-miljö sparas en fil på disk när skrivåtgärden avslutas, så om instansen (en virtuell dator i det här fallet) misslyckas tar du bara upp den igen och filen kommer fortfarande att finnas där. Om en containerinstans som utför en skrivåtgärd däremot misslyckas kommer den nya containerinstansen inte att inkludera filen. Därför bör du överväga att använda beständig lagring så att alla containerinstanser kan lagra tillståndsdata eller filer på en centraliserad och varaktig plats. Den här typen av omarbetning kräver inte att du ändrar programmets kod, bara den typ av lagring som används av Windows-instansen. Mer information finns i dokumentationen för Windows-containern om lagring.
Detta medför dock ett annat relaterat ämne...
Databasprogram
Som en allmän regel är databasprogram inte bra kandidater för containerisering. Även om du kan köra en databas i en container, är det vanligtvis inte idealiskt att containerisera en befintlig databas, av två skäl.
För det första kan de prestanda som behövs för en databas kräva hela de maskinvaruresurser som är tillgängliga för värden – vilket devalverar konsolideringsfördelarna. För det andra behöver flera instanser av en enda databasnivå samordning för dess skrivåtgärder. Container-orkestrering kan lösa det, men för befintliga databaser kan orkestrering innebära en merkostnad. De flesta databaser, till exempel Microsoft SQL Server, har en inbyggd belastningsutjämning och mekanism för hög tillgänglighet.
Infrastrukturroller på Windows Server
Windows Server-infrastrukturroller hanterar främst funktioner närmare operativsystemet (till exempel AD, DHCP och Filserver). Därför är de inte tillgängliga för körande containrar. Därför är program som behöver dessa roller alltid svåra att containerisera.
Det finns några grå områden. Vissa funktioner som DNS kan till exempel fungera på Windows-containrar även om de egentligen inte är avsedda att användas i containrar. Andra infrastrukturroller tas helt enkelt bort från bascontaineravbildningen och kan inte installeras, till exempel Active Directory, DHCP och andra.
Active Directory (AD)
Active Directory släpptes för mer än tjugo år sedan längs Windows 2000 Server. Den använder en mekanism där varje enhet eller användare representeras av ett objekt som lagras i databasen. Den här relationen är nära kopplad och objekt sparas i databasen även om den faktiska användaren eller enheten inte längre är i spel. Den metoden för Active Directory strider direkt mot containrarnas tillfälliga karaktär, som förväntas vara kortvariga eller tas bort när de stängs av. Att upprätthålla den här en-till-en-relationen med Active Directory är inte idealiskt för dessa scenarier.
Därför kan Windows-containrar inte vara domänanslutna. Därför kan du inte köra Active Directory Domain Services som en infrastrukturroll i Windows-containrar. Du kan köra PowerShell-modulen för fjärrhantering av domänkontrollanter i en Windows-container.
För program som körs på Windows-containrar som är Active Directory-beroende använder du Grupphanterade tjänstkonton (gMSA), vilket förklaras ytterligare.
Appar som använder .NET Framework version 2.0 eller äldre
Om ditt program kräver .NET beror din möjlighet att containerisera helt på vilken version av .NET Framework det använder. Alla versioner före .NET Framework 2.0 stöds inte alls. högre versioner kräver användning av specifika bilder enligt beskrivningen senare.
Appar som använder ramverk från tredje part (icke-Microsoft)
Generellt sett kan Microsoft inte certifiera ramverk eller program från tredje part, eller stödja dem som körs på Windows-containrar – eller fysiska och virtuella datorer för den delen. Microsoft utför dock sina egna interna tester för användbarhet av flera ramverk och verktyg från tredje part, inklusive Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat och många andra.
För ramverk eller programvara från tredje part kontrollerar du dess support på Windows-containrar med leverantören som tillhandahåller det.
Idealiska kandidater för containerisering
Nu när vi har övervägt de hårda begränsningarna för att containerisera appar är det lättare att se vilka typer av appar som lättare lämpar sig för Windows-containrar. De idealiska kandidaterna för Windows-containrar och eventuella särskilda överväganden för att containerbelägga dem finns i följande tabell.
| Typ av program | Varför dessa är bra kandidater | Särskilda överväganden |
|---|---|---|
| Konsolapplikationer | Utan begränsningar i användargränssnittet är konsolappar idealiska kandidater för containrar. | Använd lämplig bascontaineravbildning beroende på programmets behov. |
| Windows-tjänster | Eftersom det här är bakgrundsprocesser som inte kräver någon direkt användarinteraktion | Använd lämplig bascontaineravbildning beroende på programmets behov. Du måste skapa en förgrundsprocess för att hålla alla containerbaserade bakgrundsprocesser igång. Se avsnittet om bakgrundstjänster nedan. |
| WCF-tjänster (Windows Communication Foundation) | Eftersom de är tjänstorienterade appar som också körs i bakgrunden | Använd lämplig bascontaineravbildning beroende på programmets behov. Du kan behöva skapa en förgrundsprocess för att hålla alla containerbaserade bakgrundsprocesser igång. Se avsnittet om bakgrundstjänster nedan. |
| Webbappar | Webbprogram är i grunden bakgrundstjänster som lyssnar på en specifik port och är därför bra kandidater för containerisering, eftersom de utnyttjar skalbarheten som erbjuds av containrar | Använd lämplig bascontaineravbildning beroende på programmets behov. |
Obs! Även dessa idealiska kandidater för containerisering kan förlita sig på viktiga Windows-funktioner och komponenter som måste hanteras på olika sätt i Windows-containrar. Nästa avsnitt, som går in på mer information om sådana praktiska överväganden, kommer att bättre förbereda dig för att utnyttja funktionerna i Windows-containrar.
Praktiska överväganden för program som kan containeriseras
Apprenoveringsprojekt tar vanligtvis hänsyn till om en viss app kan containeriseras utifrån appens affärsfunktion. Men affärsfunktionerna är inte den faktor som avgör om det är tekniskt möjligt. Det som är viktigt är appens arkitektur, dvs. vilka tekniska komponenter den förlitar sig på. Därför finns det inget enkelt svar på en fråga som "Kan jag containerisera mitt HR-program?" eftersom det inte är vad programmet gör, det är hur (och vilka Windows-komponenter/-tjänster det använder) som gör skillnaden.
Det här är en viktig skillnad, för om ditt program inte skapas med en arkitektur för mikrotjänster till att börja med är det förmodligen svårare att containerisera. När du fortsätter att containerisera den kan vissa funktioner behöva särskild hantering. Vissa kan bero på att appen använder viktiga Windows-komponenter och -ramverk som inte stöds i Windows-containrar. Andra, till exempel händelseloggning och övervakning, beror på inneboende skillnader mellan Linux och Windows som bara blir synliga när du containeriserar appen. Andra, till exempel schemalagda uppgifter och bakgrundstjänster, måste förstås utifrån perspektivet att en container inte är en virtuell dator utan är tillfällig och därför behöver särskild hantering.
I följande tabell visas en snabb sammanfattning av komponenterna/funktionerna i program som behöver beaktas särskilt när du funderar på att använda container. De underavsnitt som följer ger dig mer information, inklusive exempel som illustrerar tekniker för att hantera varje scenario. Listan nedan omfattar scenarier som stöds i Windows-containrar, men dessa scenarier måste fortfarande respektera vägledningen från föregående kapitel. Även om bakgrundstjänster till exempel stöds stöds inte körning av en bakgrundstjänst på .NET Framework 1.1.
| Windows-funktion/komponent som kräver särskild hantering | Förnuft |
|---|---|
| Microsoft Messaging Queueing (MSMQ) | MSMQ har sitt ursprung långt innan containrar och inte alla dess distributionsmodeller för meddelandeköer är kompatibla med containerarkitekturen. |
| Microsoft Distributed Transaction Coordinator (MSDTC) | Namnmatchning mellan MSDTC och containern kräver särskild hänsyn. |
| IIS | IIS är detsamma som i en virtuell dator, men det finns viktiga saker att tänka på när du kör det i en containermiljö, till exempel certifikathantering, databasanslutningssträngar med mera. |
| Schemalagda aktiviteter | Windows-containrar kan köra schemalagda uppgifter, precis som alla Windows-instanser. Du kan dock behöva köra en förgrundsaktivitet för att behålla containerinstansen igång. Beroende på programmet kanske du vill överväga en händelsedriven metod. |
| Bakgrundstjänster | Eftersom containrar körs som tillfälliga processer behöver du ytterligare hantering för att få containern att fortsätta köra. |
| .NET Framework och .NET (tidigare .Net Core) | Se till att använda rätt bild för att säkerställa kompatibilitet, enligt beskrivningen i underavsnittet nedan. |
Andra stödkomponenter
| Komponent som kräver särskild hantering | Förnuft | Alternativt tillvägagångssätt |
|---|---|---|
| Händelseloggning/-övervakning | Eftersom sättet som Windows skriver händelser och loggar på skiljer sig från Linux stdout | Använd det nya Log Monitor-verktyget för att normalisera data och kombinera från både Linux och Windows. |
| Säkerhet för Windows-containrar | Många säkerhetsmetoder är desamma, men containrar kräver ytterligare säkerhetsåtgärder. | Använd ett specialbyggt register- och avbildningsgenomsökningsverktyg – mer information senare. |
| Säkerhetskopiering av Windows-containrar | Behållare bör inte innehålla data eller tillståndsinformation. | Säkerhetskopiera all beständig lagring som används av containrar samt containeravbildningar. |
Windows-komponenter/-funktioner
Nu ska vi titta närmare på information om program och komponenter som kan containeriseras, men som kräver ytterligare hantering.
MSMQ
Om ditt program är beroende av MSMQ beror om du kan containerisera det på dess MSMQ-distributionsscenario. MSMQ innehåller flera distributionsalternativ. Faktorerna för privata eller offentliga köer, transaktionella eller inte, och autentiseringstypen utgör en matris med scenarier som MSMQ ursprungligen utformades för att stödja. Alla dessa kan inte enkelt flyttas till Windows-containrar. I följande tabell visas de scenarier som stöds:
| Omfattning | Transaktionell? | Köplats | Autentiseringstyp | Vill du skicka och ta emot? |
|---|---|---|---|---|
| Privat | Ja | Samma behållare (enkel behållare) | Anonym | Ja |
| Privat | Ja | Beständiga volymer | Anonym | Ja |
| Privat | Ja | Domänkontrollant | Anonym | Ja |
| Privat | Ja | Enskild värd (två containrar) | Anonym | Ja |
| Offentlig | Nej | Två värdar | Anonym | Ja |
| Offentlig | Ja | Två värdar | Anonym | Ja |
Några kommentarer om dessa scenarier som stöds, som har verifierats av Microsofts interna utvecklingsteam:
- Isoleringsläge: Både processläge och Hyper-V läge för isolering fungerar med de scenarier som anges ovan.
- Minimal os- och containeravbildning: Den lägsta operativsystemversion som rekommenderas för användning med MSMQ är Windows Server 2019.
- Beständiga volymer: Scenarierna ovan verifierades när MSMQ kördes på Azure Kubernetes Service (AKS) med hjälp av Azure-filer för beständig lagring.
När du sätter ihop dessa överväganden med tabellen ovan kan du se att det enda scenario som inte stöds är för köer som kräver autentisering med Active Directory. Integreringen av gMSAs (grupphanterade tjänstkonton) med MSMQ stöds för närvarande inte eftersom MSMQ har beroenden i Active Directory som ännu inte finns på plats.
Du kan också använda Azure Service Bus i stället för MSMQ. Azure Service Bus är en helt hanterad företagsmeddelandebroker med funktioner för meddelandeköer och publiceringsprenumerationer (i ett namnområde). Om du byter från MSMQ till Azure Service Bus krävs kodändringar och omarkitektur för program, men du får flexibiliteten att gå över till en modern plattform.
MSDTC
Microsoft Distributed Transaction Coordinator (MSDTC) används mycket i äldre Windows-program bland stora företag. MSDTC kan installeras på Windows-containrar, men det finns vissa scenarier som inte fungerar och som inte kan återskapas i Windows-containrar.
- När du skapar containern måste du skicka parametern --name till kommandot docker run. Den här namnparametern är det som gör att containrarna kan kommunicera via Docker-nätverket. Om du använder gMSA måste namnet matcha värdnamnet som måste matcha gMSA-kontonamnet.
- Här är ett exempel på körningskommandot med gMSA:
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
- Behållare måste kunna kommunicera med varandra med hjälp av NETBIOS-namn. Om det finns problem med detta är det bästa sättet att lösa det att lägga till namn och ip för containrarna till varandras värdfiler.
- Uuid för msdtc på båda containrarna måste vara unik. Du hittar uuid genom att köra "Get-Dtc" i PowerShell på containrarna. Om de inte är unika är ett sätt att lösa det genom att avinstallera och installera om msdtc på en av containrarna. Dessa PowerShell-kommandon kan användas – «uninstall-dtc», «install-dtc».
- MSDTC stöds för närvarande inte i Azure Kubernetes Services. Om du har ett specifikt behov av att köra MSDTC på AKS, meddela Windows-containerteamet genom att öppna ett ärende i repository Windows-containrar på GitHub.
Så här fungerar IIS i en container jämfört med en virtuell dator
IIS fungerar på samma sätt på en Windows-container som på en virtuell dator. Det finns dock vissa aspekter av att köra en IIS-instans som bör beaktas när du kör i en containermiljö:
- Beständig lagring för lokala data: Mappar där appen skriver/läser filer till/från är ett bra exempel på något som du skulle ha kvar på en virtuell dator för en IIS-instans. Med containrar vill du inte att några data skrivs direkt till containern. Containrar använder ett "scratch space" för lokal lagring och när en ny container kommer upp för samma program har den ingen åtkomst till det området från en tidigare container. Därför använder du beständig lagring för data som måste vara tillgängliga för webbprogrammet, så att alla containerinstanser kan ha åtkomst till lagringen.
- Certifikat: Även om du kan ha lokala certifikat på containerinstanser bör du undvika att göra det, för om ett certifikat behöver uppdateras måste du återskapa containeravbildningen. Du kan också använda en containerorkestrerare med Ingress-kontroll. Ingresskontrollanter kan tillämpa nätverksprinciper och även hantera certifikathanteringen för den webbplats som finns bakom den. Fördelen är att du frikopplar certifikatets livscykelhantering från webbplatshanteringen.
- Databasanslutningssträngar: För traditionell IIS-distribution kan du skicka DB-anslutningssträngen som en del av programdistributionen. Windows-containrar gör att du kan följa den modellen, men du kan överväga att avkoda DB-anslutningssträngen från containern till en centraliserad konfiguration som tillhandahålls av containerorkestreraren, från vilken programmet kan läsa. På så sätt kan du hantera och uppdatera DB-anslutningssträngen oberoende av programmet. Om databasen ändras (till exempel vid Lift and Shift till molnet) kan du enkelt ändra anslutningssträngen utan att återskapa containeravbildningen. Med den här metoden kan du också behålla hemligheter (till exempel användarnamn och lösenord för att ansluta till databasen) i ett hemligt arkiv.
- Horisontell automatisk skalning: När belastningen ökar tenderar beräkningssystem att sakta ned den upplevda prestandan när de försöker bearbeta samtidiga begäranden. Det finns vanligtvis två sätt att undvika prestandapåverkan– lodrät eller vågrät skala. Lodrät skalning ökar de resurser som är tillgängliga för befintliga beräkningsinstanser (mer CPU, minne osv.). Vågrät skala ökar antalet instanser som stöder begäranden (fler fysiska värdar, virtuella datorer eller containrar). För webbnivåer som IIS tenderar horisontell skalning att vara effektivare än vertikal, men lokala miljöer kan stöta på resursbegränsningar och belastningsutjämningsproblem. Med molnmiljöer är horisontell skalning mycket enklare eftersom resurser är lättillgängliga (till en extra kostnad) och molnleverantören utformar vanligtvis sin belastningsutjämningsmekanism med horisontell skalning i åtanke. Windows-containrar kan använda horisontell skalning för IIS, men den tillfälliga aspekten av containrar spelar en viktig roll. Det är absolut nödvändigt att containrarna har samma konfiguration och att inget tillstånd eller data lagras för att kunna skala upp eller ned antalet instanser som stöder webbappen.
Schemalagda aktiviteter
Schemalagda aktiviteter används för att anropa ett program, en tjänst eller ett skript när som helst i en Windows-miljö. Traditionellt har du en Windows-instans igång hela tiden och när en utlösare uppfylls körs uppgiften. Detta är möjligt med Windows-containrar och – förutom att du behöver konfigurera och hantera schemalagda uppgifter via Azure PowerShell – fungerar de exakt likadant.
Med en mikrotjänstarkitektur har du dock några alternativ för att undvika att hålla en container igång för att vänta på en utlösare:
- Använd en händelsedriven PaaS (Plattform som en tjänst) som Azure Function för att lagra din kod och definiera en utlösare för appen. Azure Functions stöder till och med Windows-containeravbildningar som körs när en trigger aktiveras.
- Använd Windows-containrar tillsammans med en containerorkestrerare. Containern kan bara köras när utlösaren uppfylls och anropas från andra delar av programmet. I det här fallet hanterar containerorkestreraren schemaläggningen och utlösaren för programmet.
- Låt slutligen en Windows-container köras för att köra en schemalagd aktivitet. Du behöver en förgrundstjänst (till exempel Service Monitor) för att behålla containern igång.
Bakgrundstjänster
Även om containrar vanligtvis är för tillfälliga processer kan du containerisera ett bakgrundsprogram, förutsatt att du skapar en förgrundsprocess för att både starta den och hålla den igång.
Ett bra exempel på detta är ServiceMonitor, som är en körbar Windows-fil som är utformad för att användas som en startpunktsprocess när IIS körs i containrar. Även om det har skapats för IIS erbjuder ServiceMonitor-verktyget en modell som också kan användas för att övervaka andra tjänster, med vissa begränsningar.
Mer information om ServiceMonitor finns i dokumentationen för på Github.
.NET Framework och .NET
Windows-containrar stöder både .NET Framework och .NET (tidigare .NET Core). .NET-teamet skapar sina egna officiella avbildningar för båda ramverken ovanpå Windows-bascontaineravbildningarna. Det är viktigt att välja lämplig avbildning för att säkerställa kompatibilitet. .NET-teamet tillhandahåller .Net Framework-avbildningar ovanpå Server Core-bascontaineravbildningen och .NET-avbildningar ovanpå både Server Core- och Nano Server-bascontaineravbildningarna. Server Core har en större API-uppsättning än Nano Server, vilket möjliggör större kompatibilitet, men också en större bildstorlek. Nano Server har en kraftigt reducerad API-yta, men en mycket mindre bildstorlek.
I vissa fall kan du behöva skapa en egen .NET Framework- eller .NET-avbildning ovanpå Windows- eller Server-bascontaineravbildningarna. Detta kan vara nödvändigt om ditt program inte bara har ett ramverksberoende utan även ett OS-beroende. Du kommer att kunna identifiera sådana beroenden genom att testa ditt program med en viss bascontaineravbildning.
Till exempel har Server Core- och Nano Server-bascontaineravbildningarna bara ett teckensnitt tillgängligt, för att minska bildstorleken. Om programmet kräver ett annat teckensnitt måste du antingen installera teckensnittet eller använda Server- eller Windows-avbildningarna, som har en större API-uppsättning och innehåller alla standardteckensnitt i Windows. Ur kompatibilitetssynpunkt gör detta att praktiskt taget alla appar (så länge de respekterar containrars natur, till exempel inga GUI) kan containeriseras. På nackdelen blir de mycket större i storlek, vilket kan påverka prestanda.
När du verifierar om programmet som ska containeriseras fungerar på Windows-containrar rekommenderar Microsoft följande:
| För det här ramverket | Testa med den här containeravbildningen först | Återställning till den här containeravbildningen om den första inte fungerar | Basbild |
|---|---|---|---|
| .NET Framework-versionerna 2.X och 3.X | .NET Framework 4.x | .NET Framework 3.5 | Windows Server Core |
| .NET Framework 4.x-versioner | .NET Framework 4.x | Skapa din .NET Framework-containeravbildning med Server- eller Windows-avbildningar | Windows Server Core |
| .NET 6 eller 7 | .NET 6 respektive 7 | Skapa din .NET-containeravbildning med Windows- eller Server-basavbildningar | Windows Nano Server eller Server Core |
Andra stödkomponenter
Komponenterna och avsnitten nedan ger ytterligare vägledning för objekt som går bredvid eller som ger bättre klarhet i Windows-containrar.
Händelseloggning
Windows och Linux använder olika metoder för att lagra och presentera loggar och händelser för sina användare. Traditionellt har Windows använt EVT-formatet, som kan visas på ett strukturerat sätt i Loggboken. Linux har däremot tillhandahållit en effektiviserad metod med standardutdata (stdout) som andra verktyg, till exempel Docker, förlitar sig på.
Docker har alltid haft en mekanism för att extrahera loggar från Linux-containrar. Med kommandot "docker logs" med en standardkonfiguration för stdout tar Docker programloggar ut ur containern utan att öppna containern interaktivt. Fram till lanseringen av Log Monitor-verktyget fungerade dock inte samma teknik i Windows.
Verktyget Log Monitor visar Windows-loggarna i stdout-format så att andra verktyg, till exempel Docker, kan samla in den information som krävs för att visa den. Ytterligare fördelar med att använda Log Monitor är följande:
- Att kunna filtrera vilka typer av händelser/loggar som du vill exponera på stdout. Du kan till exempel filtrera programloggen efter "fel" och "varningsmeddelanden" endast om du inte är intresserad av "informationshändelser".
- Möjligheten att välja mellan händelseloggar, anpassade loggfiler eller händelsespårning för Windows (ETW). Detta är särskilt användbart om programmet skriver på en annan loggkälla. Ett exempel på detta är IIS-loggarna som finns i mappen "C:\inetpub".
- Det faktum att Log Monitor gör att Windows-containrar fungerar ungefär som Linux-containrar, vilket gör att verktyg som letar efter stdout och interagerar med containermiljön fungerar som förväntat. Om du till exempel flyttar från Docker till ContainerD som containerkörning bör loggarna fortfarande vara synliga från containervärden via (till exempel crictl-loggar).
Du kan läsa mer om verktyget Log Monitor i det här blogginlägget.
Säkerhet för Windows-containrar
Windows-containrar bygger på samma bas som Windows-instanser som körs på fysiska eller virtuella datorer. Genom att förstå detaljerna i hur containrar implementeras, särskilt deras karaktär med delad kernel, kan du skydda ett containerbaserat program:
- Delade komponenter. Windows-containrar delar några av värdens komponenter i säkerhetssyfte. Detta omfattar Windows-brandväggen, Windows Defender (Antivirus) och andra begränsningar för resursåtkomst. Du behöver inte konfigurera dessa komponenter direkt på containern eftersom containervärden gör de nödvändiga justeringarna baserat på din containerarbetsbelastning. Om containern till exempel gör en webbbegäran vidarebefordrar containervärden den nödvändiga trafiken via brandväggen för att containern ska kunna komma åt webben.
- Isoleringsläge. Som vi har diskuterat kan Windows-containrar distribueras i process- eller Hyper-V isoleringsläge, med Hyper-V som ger den säkraste isoleringen. I processisolering delar containern sin kernel, sitt filsystem och sitt register med värden, vilket gör att en upphöjd process (administratör) kan interagera med containerprocesserna och -tjänsterna. Det är viktigt att välja rätt isoleringsläge för ditt program för att säkerställa rätt säkerhetsmodell.
- Windows-uppdateringar. Eftersom servicestacken inte finns på Windows-containrar tar Windows-containrar inte emot uppdateringar som allmänna Windows-instanser. I stället måste du återskapa Windows-containrar med den senaste tillgängliga bascontaineravbildningen. Kunder kan använda DevOps-pipelines för detta ändamål. Microsoft uppdaterar bascontaineravbildningarna för alla sina officiella avbildningar varje månad enligt Patch Tuesday-cykeln.
- Containeranvändarkonto. Som standard körs program i Windows-containrar med förhöjd behörighet under Användarkontot ContainerAdmin. Det här är användbart för att installera och konfigurera nödvändiga komponenter i containeravbildningen. Du bör dock överväga att ändra användarkontot till ContainerUser när du kör ett program som inte kräver förhöjd behörighet. För specifika scenarier kan du också skapa ett nytt konto med rätt behörighet.
- Avbildning och körningsgenomsökning. Containrar kräver att avbildningar på lagringsplatser och containrar är säkra. Microsoft rekommenderar att du använder Microsoft Defender för containrar för bildgenomsökning och körningstidsgenomsökning. Defender for Containers stöder Windows-containrar för sårbarhetsanalys med registergenomsökning och hotidentifiering under körning.
Mer information om ovanstående ämnen finns på Windows-containerns dokumentationssida .
Säkerhetskopiering av Windows-containrar
Du måste tänka på säkerhetskopieringar på olika sätt när du använder containrar. Som tidigare nämnts ska en container inte användas för att lagra tillstånd eller data med tanke på dess tillfälliga karaktär. Om du separerar tillstånd och data från containerinstansen ligger dina säkerhetskopieringsproblem utanför körningen av containerinstansen, som kan ersättas med en ny som all nödvändig beständig lagring fortfarande är tillgänglig för.
Det finns dock fortfarande komponenter som du ansvarar för att säkerhetskopiera. inklusive programmet, containeravbildningen och dockerfile som skapar containeravbildningen. De flesta av dessa åtgärder hanteras av den plattform där du kör dina produktions- och utvecklingsarbetsbelastningar. När du använder en DevOps-metod bör du tänka på de vanligaste fallen:
- Program: Ditt program finns förmodligen på en källlagringsplats, till exempel GitHub eller Azure DevOps. Dessa lagringsplatser ger versionskontroll, vilket gör att du kan återgå till en viss version av programmet. Om du äger källlagringsplatsen måste du följa rekommendationerna för säkerhetskopiering och hantering.
- Containeravbildning: För produktionsmiljöer bör containeravbildningen finnas i en centraliserad avbildningslagringsplats, till exempel Azure Container Registry (ACR). Du kan ladda upp dina containeravbildningar till ACR för att göra dem tillgängliga för andra värdar att hämta. ACR hanterar tillgängligheten för containeravbildningarna och fungerar som ett säkerhetskopieringsalternativ – tänk dock på att även om ACR hanterar tillgängligheten för avbildningen förhindrar det inte att en avbildning tas bort eller skrivs över. För andra lokala eller lokala avbildningslager följer du leverantörens rekommendation om att säkerhetskopiera befintliga register.
- Dockerfile: Dockerfiles skapar nya containeravbildningar och lagras vanligtvis tillsammans med programkällan. Eftersom dockerfile kanske inte har skapats med programmet, särskilt om det är ett befintligt program som är containerbaserat, ansvarar du för att se till att dockerfile lagras på en säker och säkerhetskopierad plats. Du bör också se till att alla andra tillgångar som krävs för att programmet ska fungera i en container säkerhetskopieras. Till exempel: YAML- och JSON-filer för Kubernetes-, Docker Swarm- och Azure ARM-mallar följer samma riktlinjer som ovan.
Planera processen för att lyfta och flytta
När du har utvärderat programmets beredskap för containerisering, följ följande allmänna vägledning för att planera processen:
- Ta reda på vilken basavbildning av Windows-operativsystemet du behöver: Windows Server Core, Nano Server, Windowseller Server-avbildningar.
- Bestäm typen av isoleringsläge för containern: välj mellan process- eller Hyper-V isoleringslägen. Obs! För närvarande stöder AKS och AKS på Azure Stack HCI endast processisolerade containrar. I en framtida version kommer både AKS och AKS på Azure Stack HCI också att stödja Hyper-V-isolerade containrar. För mer information, se isoleringslägen.
- Välj rätt Windows Server-version för ditt program i app-kompatibilitetssyfte. Den minimala Windows Server-versionen för containrar är Windows Server 2016, men Windows Server 2019 och Windows Server 2022 är de enda containervärdoperativsystem som stöds på AKS och AKS på Azure Stack HCI.
- Se till att företagets säkerhetsprinciper finns på plats för containermiljön. Detta omfattar anpassning till containerspecifika krav, till exempel registergenomsökning och hotidentifiering.
- Överväg belastningsutjämningsbehov. Själva containrarna flyttas inte. Du kan använda en orkestrerare i stället för att automatiskt starta eller stoppa containrar på klusternoder, eller för att hantera ändringar i belastning och tillgänglighet med automatisk horisontell skala.
- Överväg orkestreringsbehov. När programmet har containeriserats behöver det förmodligen automatiserad hantering med verktyg som Kubernetes, AKS eller AKS i Azure Stack HCI. Se Översikt över Windows containerorkestrering för en fullständig diskussion och guide för val bland verktygen.
- Containerisera appen.
- Ladda upp appen till ett bildlager. Detta gör att containervärdarna kan ladda ned avbildningen i alla miljöer, inklusive utveckling, testning och produktion.
Azure Migrate kan tillhandahålla en guidad process för att identifiera, utvärdera och migrera ditt befintliga Windows-program till Azure Kubernetes Service. Mer information finns på dokumentationssidan Azure Migrate.