Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016
Windows-containers bieden een uitstekend mechanisme voor het moderniseren van traditionele of verouderde toepassingen. Hoewel u deze benadering misschien 'lift and shift to containers' noemt, is de lift-and-shift-metafoor afkomstig van het verschuiven van workloads van fysieke naar virtuele machines en wordt gebruikt bij het verplaatsen van workloads naar de cloud. Tegenwoordig wordt deze term beter toegepast op het migreren van virtuele machines (VM's). Maar containers zijn geen VM's en denken eraan als VM's kunnen leiden tot verwarring over hoe een toepassing in een container wordt geplaatst, of dat deze wel of niet in een container kan worden geplaatst.
Dit onderwerp bevat praktische richtlijnen voor het verplaatsen van traditionele toepassingen naar Windows-containers. Het is bedoeld om u te helpen prioriteit te geven aan welke toepassingen in een container moeten worden geplaatst, door speciale overwegingen vooraf uit te leggen.
Introductie
Wat Windows-containers zijn en wat ze niet zijn
De algemene term container verwijst naar een technologie die het besturingssysteem (OS) virtualiseert. Deze virtualisatie biedt een isolatieniveau van het besturingssysteem van de server/host zelf, wat op zijn beurt meer flexibiliteit biedt voor toepassingsontwikkelaars en operationele teams.
Windows-containers zijn een specifieke implementatie van containertechnologie. Ze bieden exemplaren van gevirtualiseerde besturingssystemen die zijn geïsoleerd van het Windows-besturingssysteem. Maar de totale onderlinge afhankelijkheid tussen container en host is onmogelijk: een Windows-container moet de vraag naar resources en functies coördineren met het Windows-besturingssysteem. Waarom is dit belangrijk? Omdat een Windows-container geen volledige gevirtualiseerde server is en sommige dingen die u met een toepassing wilt doen, kunnen niet worden uitgevoerd met alleen een gevirtualiseerd besturingssysteem.
Meer informatie over dit onderwerp vindt u in Containers versus virtuele machines. Maar een paar goede punten die u helpen bij het onthouden van de container versus het verschil tussen VM's zijn:
- Containers zijn geen oplossing die gelijk is aan desktoptoepassingsvirtualisatie. Ze ondersteunen alleen toepassingen aan de serverzijde waarvoor geen interactieve sessie is vereist. Omdat ze draaien op gespecialiseerde containerafbeeldingen, ondersteunen ze alleen toepassingen die geen grafische front-end nodig hebben.
- Containers zijn van nature kortstondig. Dit betekent dat er standaard geen mechanisme is om de status van een containerinstantie op te slaan. Als een instantie uitvalt, vervangt een andere instantie deze.
De containertechnologie begon op Linux, met Docker opkomend als standaard. Microsoft heeft nauw samengewerkt met Docker om ervoor te zorgen dat de containerfunctionaliteit net zoveel hetzelfde is in Windows als redelijkerwijs mogelijk is. Inherente verschillen tussen Linux en Windows kunnen zich voordoen op manieren die als beperkingen van Windows-containers lijken, terwijl het in feite gewoon de verschillen tussen Linux en Windows zijn. Aan de andere kant bieden Windows-containers enkele unieke implementaties, zoals Hyper-V isolatie, die later worden behandeld. In dit onderwerp wordt uitgelegd hoe u deze verschillen begrijpt en hoe u deze kunt gebruiken.
Voordelen van het gebruik van containers
Net als bij het uitvoeren van meerdere VM's op één fysieke host, kunt u meerdere containers uitvoeren op één fysieke of virtuele host. Maar in tegenstelling tot vm's hoeft u het besturingssysteem niet te beheren voor een container, wat u de flexibiliteit biedt om u te richten op het ontwikkelen van toepassingen en onderliggende infrastructuur. Dit betekent ook dat u een toepassing kunt isoleren, zodat deze niet wordt beïnvloed door andere processen die door het besturingssysteem worden ondersteund.
Containers bieden een lichtgewicht methode voor het maken en dynamisch stoppen van de resources die nodig zijn voor een werkende toepassing. Hoewel het mogelijk is om VM's te maken en te implementeren naarmate de vraag naar toepassingen toeneemt, is het sneller om containers te gebruiken voor uitschalen. Met containers kunt u ook snel opnieuw opstarten in het geval van een crash of hardwareonderbreking. Met containers kunt u elke app van ontwikkeling naar productie nemen met weinig of geen codewijziging, omdat ze toepassingsafhankelijkheden bevatten, zodat ze in verschillende omgevingen werken. De mogelijkheid om een bestaande toepassing te containeriseren met minimale codewijzigingen, vanwege de Docker-integratie in microsoft-ontwikkelhulpprogramma's, is ook een krachtige factor in het ontwikkelen en onderhouden van toepassingen.
Ten slotte is een van de belangrijkste voordelen van het gebruik van containers de flexibiliteit die u krijgt voor het ontwikkelen van apps, omdat u verschillende versies van een app kunt hebben die op dezelfde host wordt uitgevoerd zonder conflicten met resources.
U vindt een volledigere lijst met voordelen voor het gebruik van containers voor bestaande toepassingen op de microsoft .NET-documentatiepagina.
Belangrijk concept van isolatieniveau
Windows-containers bieden isolatie van het Windows-besturingssysteem, isolatie die voordelig is wanneer u een app bouwt, test en promoveert naar productie. Maar de manier waarop de isolatie wordt bereikt, is belangrijk om te begrijpen wanneer u denkt aan het containeriseren van een toepassing.
Windows-containers bieden twee verschillende runtime-isolatiemodi: proces en Hyper-V-. Containers onder beide modi worden identiek gemaakt en beheerd en werken identiek. Dus, wat zijn de verschillen en waarom zou het u schelen?
In procesisolatieworden meerdere containers gelijktijdig uitgevoerd op één host met isolatie die wordt geleverd via naamruimte, resourcebeheer en andere functies. Containers in de procesisolatiemodus delen dezelfde kernel met de host en elkaar. Dit is ongeveer hetzelfde als de manier waarop Linux-containers worden uitgevoerd.
In Hyper-V isolatieworden meerdere containers ook gelijktijdig uitgevoerd op één host, maar de containers worden uitgevoerd binnen maximaal geoptimaliseerde virtuele machines, waarbij elk effectief een eigen kernel krijgt. De aanwezigheid van deze virtuele machine, een 'hulpprogramma'-VM, biedt isolatie op hardwareniveau tussen elke container en de containerhost.
Op een manier is Hyper-V isolatiemodus bijna als een hybride van een VIRTUELE machine en container, wat een extra beveiligingslaag biedt die met name handig is als uw app multitenancy nodig heeft. Maar de mogelijke afwegingen voor het gebruik van de isolatiemodus van Hyper-V zijn:
- Langere opstarttijd voor de container en een waarschijnlijke invloed op de algehele app-prestaties.
- Niet alle hulpprogramma's werken systeemeigen met Hyper-V isolatie.
- AKS (Azure Kubernetes Service) of AKS op Azure Stack HCI bieden momenteel geen ondersteuning voor Hyper-V isolatie.
Meer informatie over hoe de twee isolatiemodi worden geïmplementeerd in het onderwerp Isolatiemodi. Wanneer u een app voor het eerst in een container zet, moet u kiezen tussen de twee modi. Gelukkig is het heel eenvoudig om later van de ene modus naar de andere te schakelen, omdat er geen wijzigingen in de toepassing of de container nodig zijn. Maar houd er rekening mee dat wanneer u een app in een container zet, het kiezen tussen de twee modi een van de eerste dingen is die u moet doen.
Containerorchestratie
De mogelijkheid om meerdere containers uit te voeren op één of meerdere hosts zonder dat u zich zorgen hoeft te maken over het beheer van het besturingssysteem, biedt u veel flexibiliteit, zodat u kunt overstappen op een architectuur op basis van een microservice. Een afweging voor die flexibiliteit is echter dat een omgeving op basis van containers en microservices snel in veel bewegende onderdelen kan komen – te veel om bij te houden. Gelukkig is het beheren van load balancing, hoge beschikbaarheid, containerschedulering, beheer van middelen en nog veel meer de rol van een containerorchestrator.
Orchestrators hebben mogelijk een verkeerde naam; ze lijken meer op de dirigenten van een orkest, omdat ze de activiteit van meerdere containers coördineren om de muziek te laten spelen. In zekere zin verwerken ze de planning en resourcetoewijzing voor containers op een manier die vergelijkbaar is met het functioneren van een besturingssysteem. Dus wanneer u overstapt op het containeriseren van uw toepassingen, moet u kiezen uit de orchestrators die Ondersteuning bieden voor Windows-containers. Enkele van de meest voorkomende zijn Kubernetes en Docker Swarm.
Wat kan niet worden verplaatst naar Windows-containers
Wanneer u overweegt of een app in een container kan worden geplaatst of niet, is het waarschijnlijk het eenvoudigst om te beginnen met de lijst met factoren die Windows-containers volledig uitsluiten als optie.
De volgende tabel bevat een overzicht van de typen apps die niet kunnen worden verplaatst naar Windows-containers en waarom niet. De redenen worden uitgebreider uitgelegd in de subsecties na de tabel. Inzicht in de redenen voor deze beperkingen kan u een duidelijker beeld geven van wat containers echt zijn, inclusief hoe deze verschillen van VM's. Hierdoor kunt u beter de mogelijkheden beoordelen van Windows-containers die u kunt benutten met de bestaande apps die u kunt containeriseren.
Opmerking: de onderstaande lijst is geen volledige lijst. In plaats daarvan is het een compilatie van apps die Microsoft heeft gezien dat klanten proberen te containeriseren.
Toepassingen/functies worden niet ondersteund | Waarom niet ondersteund | Kun je dit omzeilen? |
---|---|---|
Toepassingen waarvoor een bureaublad is vereist | Containers bieden geen ondersteuning voor Graphic User Interface (GUI) | Als voor de toepassing alleen een GUI is vereist om te installeren, kan het een oplossing zijn om deze te wijzigen in een stille installatie |
Toepassingen die Remote Desktop Protocol (RDP) gebruiken | RDP is voor interactieve sessies, dus het bovenstaande principe is hier ook van toepassing | Mogelijk kunt u Windows Admin Center (WAC) of Remote PowerShell gebruiken als alternatief voor extern beheer |
Stateful toepassingen | Containers zijn vergankelijk | Ja, sommige toepassingen vereisen mogelijk minimale wijzigingen, zodat ze geen gegevens of status in de container opslaan |
Databasetoepassingen | Containers zijn vergankelijk | Ja, sommige toepassingen vereisen mogelijk minimale wijzigingen, zodat ze geen gegevens of status in de container opslaan |
Active Directory | Het ontwerp en doel van Active Directory verhindert uitvoering in een container | Nee. Apps die afhankelijk zijn van Active Directory, kunnen echter GMSA (Group Managed Service Accounts) gebruiken. Hieronder vindt u meer informatie over gMSA |
Oudere Versies van Windows Server | Alleen Windows Server 2016 of hoger wordt ondersteund | Nee. Compatibiliteit van toepassingen kan echter een optie zijn: de meeste Windows Server 2008/R2 en oudere apps worden uitgevoerd op nieuwere versies van Windows Server |
Apps met .NET Framework versie 2.0 of ouder | Er zijn specifieke containerinstallatiekopieën vereist ter ondersteuning van .NET Framework en alleen recentere versies worden ondersteund | Versies ouder dan 2.0 worden helemaal niet ondersteund, maar zie hieronder voor de containerinstallatiekopieën die vereist zijn voor latere versies |
Apps die gebruikmaken van andere frameworks van derden | Microsoft certificeert of ondersteunt niet specifiek het gebruik van niet-Microsoft-frameworks in Windows-containers | Neem contact op met de leverancier van het specifieke framework of de app om het ondersteuningsbeleid voor Windows-containers te controleren. Zie hieronder voor meer informatie |
Laten we eens kijken naar elk van deze beperkingen.
Toepassingen waarvoor een bureaublad is vereist
Containers zijn ideaal voor tijdelijke functies die worden aangeroepen vanuit andere toepassingen, met inbegrip van toepassingen met gebruikersinteracties. U kunt ze echter niet gebruiken voor toepassingen met GUI's zelf. Dit geldt zelfs als de toepassing zelf geen GUI heeft, maar een installatieprogramma heeft dat afhankelijk is van een GUI. Over het algemeen kan Windows Installer worden aangeroepen met behulp van PowerShell, maar als voor uw toepassing installatie via een GUI is vereist, wordt deze vereiste geëlimineerd als kandidaat voor containerisatie.
Dit is geen probleem met de manier waarop Windows-containers zijn geïmplementeerd, maar een fundamenteel concept van hoe containers werken.
Het is een andere kwestie als een app GUI-API's nodig heeft. De API's worden ondersteund, zelfs als de GUI die door deze API's wordt geleverd niet wordt ondersteund. Dit wordt uitgebreider uitgelegd in het onderwerp Nano Server x Server Core x Server - Welke basisimage is de juiste voor u?
Toepassingen die RDP gebruiken
Omdat het hele doel van Remote Desktop Protocol (RDP) is om een interactieve, visuele sessie tot stand te brengen, is de GUI-beperking die zojuist is beschreven ook van toepassing. Een toepassing die RDP gebruikt, kan niet in een container worden geplaatst as-is.
Een goed alternatief is echter een hulpprogramma voor extern beheer, zoals Het Windows-beheercentrum. U kunt Het Windows-beheercentrum gebruiken om Windows-containershosts en de containers zelf te beheren, zonder dat u RDP hiervoor hoeft in te voeren. U kunt ook een externe PowerShell-sessie openen voor de host en/of containers om deze te beheren.
Stateful toepassingen
Toepassingen die statusgegevens moeten behouden, kunnen alleen in een container worden geplaatst als u de benodigde gegevens van de ene sessie naar de andere isoleert en opslaat in permanente opslag. Dit vereist mogelijk een herstructurering, die al dan niet triviaal kan zijn, maar door het te doen, zal deze barrière voor containerisatie worden weggenomen.
Een voorbeeld van de status is een webtoepassing waarmee afbeeldingen of muziekbestanden worden opgeslagen in een lokale map. In een traditionele Windows-omgeving wordt een bestand opgeslagen op schijf op het moment dat de schrijfbewerking wordt afgesloten, dus als het exemplaar (in dit geval een VIRTUELE machine) mislukt, brengt u het bestand gewoon terug en is het bestand er nog steeds. Als een containerinstantie die een schrijfbewerking uitvoert mislukt, zal het nieuwe containerexemplaar het bestand niet bevatten. Daarom moet u overwegen permanente opslag te gebruiken, zodat alle containerinstanties statusgegevens of bestanden kunnen opslaan op een gecentraliseerde, duurzame locatie. Voor dit type herarchitecteren hoeft u niet de code van de toepassing te wijzigen, alleen het type opslag dat door het Windows-exemplaar wordt gebruikt. Raadpleeg de Windows-container documentatie over opslagvoor meer informatie.
Dit brengt echter een ander gerelateerd onderwerp met zich mee...
Databasetoepassingen
Databasetoepassingen zijn doorgaans geen goede kandidaten voor containerisatie. Hoewel u een database in een container kunt uitvoeren, is het containeriseren van een bestaande database meestal niet ideaal, om twee redenen.
Ten eerste vereist de prestaties die nodig zijn voor een database mogelijk de volledige hardwarebronnen die beschikbaar zijn voor de host, waardoor het voordeel van consolidatie wordt gedevalueerd. Ten tweede hebben meerdere exemplaren van één databaselaag coördinatie nodig voor de schrijfbewerkingen. Containerorkestratie kan dit oplossen, maar voor bestaande databases kan orkestratie een extra belasting vormen. De meeste databases, zoals Microsoft SQL Server, hebben een ingebouwde load balance en een mechanisme voor hoge beschikbaarheid.
Infrastructuurfuncties op Windows Server
Windows Server-infrastructuurrollen verwerken voornamelijk functies dichter bij het besturingssysteem (bijvoorbeeld AD, DHCP en Bestandsserver). Daardoor zijn ze niet beschikbaar voor draaiende containers. Daarom zijn toepassingen die deze rollen nodig hebben, altijd moeilijk te containeriseren.
Er zijn enkele grijze gebieden. Sommige functies zoals DNS kunnen bijvoorbeeld in Windows-containers werken, ook al zijn ze niet echt bedoeld voor gebruik in containers. Andere infrastructuurrollen worden gewoon verwijderd uit de basiscontainerinstallatiekopieën en kunnen niet worden geïnstalleerd, zoals Active Directory, DHCP en andere.
Active Directory (AD)
Active Directory is meer dan twintig jaar geleden uitgebracht op Windows 2000 Server. Het maakt gebruik van een mechanisme waarin elk apparaat of elke gebruiker wordt vertegenwoordigd door een object dat is opgeslagen in de database. Deze relatie is nauw gekoppeld en objecten worden bewaard in de database, zelfs als de werkelijke gebruiker of het apparaat niet meer in gebruik is. Deze aanpak voor Active Directory is rechtstreeks in strijd met de tijdelijke aard van containers, die naar verwachting kortstondig of verwijderd zijn wanneer ze zijn uitgeschakeld. Het onderhouden van deze een-op-een-relatie met Active Directory is niet ideaal voor deze scenario's.
Daarom kunnen Windows-containers niet lid zijn van een domein. Als gevolg hiervan kunt u Active Directory Domain Services niet uitvoeren als infrastructuurrol voor Windows-containers. U kunt de PowerShell-module uitvoeren voor het extern beheren van domeincontrollers in een Windows-container.
Voor toepassingen die worden uitgevoerd in Windows-containers die afhankelijk zijn van Active Directory, gebruikt u GMSA (Group Managed Service Accounts), wat verder wordt uitgelegd.
Apps met .NET Framework versie 2.0 of ouder
Als voor uw toepassing .NET is vereist, is uw mogelijkheid om containers te maken volledig afhankelijk van de versie van .NET Framework die wordt gebruikt. Elke versie vóór .NET Framework 2.0 wordt helemaal niet ondersteund; voor hogere versies is het gebruik van specifieke installatiekopieën vereist, zoals later wordt beschreven.
Apps die gebruikmaken van frameworks van derden (niet van Microsoft)
Over het algemeen kan Microsoft frameworks of toepassingen van derden niet certificeren of ze ondersteunen die worden uitgevoerd op Windows-containers, of fysieke en virtuele machines. Microsoft voert echter zijn eigen interne tests uit voor de bruikbaarheid van meerdere frameworks en hulpprogramma's van derden, waaronder Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat en vele andere.
Voor elk framework of software van derden valideert u de ondersteuning voor Windows-containers met de leverancier die dit levert.
Ideale kandidaten voor containeriseren
Nu we de harde beperkingen voor het containeriseren van apps hebben overwogen, is het eenvoudiger om te zien welke typen apps zich gemakkelijker lenen voor Windows-containers. De ideale kandidaten voor Windows-containers en eventuele speciale overwegingen voor het containeriseren ervan staan in de volgende tabel.
Type van toepassing | Waarom dit goede kandidaten zijn | Speciale overwegingen |
---|---|---|
Consoletoepassingen | Zonder GUI-beperkingen zijn console-apps ideale kandidaten voor containers. | Gebruik de juiste basiscontainerafbeelding, afhankelijk van de behoeften van de applicatie. |
Windows-diensten | Omdat dit achtergrondprocessen zijn die geen directe gebruikersinteractie vereisen | Gebruik de juiste basiscontainerafbeelding, afhankelijk van de behoeften van de applicatie. U moet een voorgrondproces maken om een achtergrondproces in een container te laten draaien. Zie de sectie over achtergrondservices hieronder. |
WCF-services (Windows Communication Foundation) | Omdat het servicegeoriënteerde apps zijn die ook op de achtergrond worden uitgevoerd | Gebruik de juiste basiscontainerafbeelding, afhankelijk van de behoeften van de applicatie. Mogelijk moet u een voorgrondproces maken om een achtergrondproces in een container actief te houden. Zie de sectie over achtergrondservices hieronder. |
Web-apps | Webtoepassingen zijn in wezen achtergrondservices die luisteren naar een specifieke poort en zijn daarom geweldige kandidaten voor containerisatie, omdat ze gebruikmaken van de schaalbaarheid die wordt aangeboden door containers | Gebruik de juiste basiscontainerafbeelding, afhankelijk van de behoeften van de applicatie. |
Opmerking: zelfs deze ideale kandidaten voor containerisatie kunnen afhankelijk zijn van de belangrijkste Windows-functies en -onderdelen die anders moeten worden verwerkt in Windows-containers. In de volgende sectie, die meer informatie over dergelijke praktische overwegingen bevat, kunt u zich beter voorbereiden op het gebruik van de functionaliteit van Windows-containers.
Praktische overwegingen voor toepassingen die in een container kunnen worden geplaatst
Bij app-renovatieprojecten wordt meestal rekening gehouden met de vraag of een bepaalde app kan worden in een container geplaatst via het perspectief van de bedrijfsfunctie van de app. Maar de bedrijfsfunctionaliteit is niet de factor die bepaalt of het technisch mogelijk is. Wat belangrijk is, is de architectuur van de app, oftewel welke technische onderdelen er afhankelijk van zijn. Daarom is er geen eenvoudig antwoord op een vraag zoals 'Kan ik mijn HR-toepassing containeriseren?' omdat het niet is wat de toepassing doet, hoe (en welke Windows-onderdelen/-services het gebruikt) dat het verschil maakt.
Dit is een belangrijk onderscheid, omdat als uw toepassing niet is gebouwd met een microservicesarchitectuur om mee te beginnen, het waarschijnlijk moeilijker is om een container te maken. Wanneer u doorgaat met containeriseren, hebben bepaalde functies mogelijk speciale verwerking nodig. Sommige kunnen worden veroorzaakt door het gebruik van kernonderdelen en frameworks van Windows die niet worden ondersteund in Windows-containers. Andere, zoals gebeurtenislogboeken en bewaking, zijn te wijten aan inherente verschillen tussen Linux en Windows die alleen zichtbaar worden wanneer u de app in een container opzet. Nog andere, zoals geplande taken en achtergrondservices, moeten vanuit het perspectief worden begrepen dat een container geen VIRTUELE machine is, maar kortstondig is en daarom speciale verwerking nodig heeft.
De volgende tabel bevat een kort overzicht van de onderdelen/functies van toepassingen waarvoor speciale overwegingen nodig zijn wanneer u denkt aan containerisatie. De volgende subsecties geven u meer details, inclusief voorbeelden die technieken illustreren voor het afhandelen van elk scenario. Hoewel de onderstaande lijst betrekking heeft op scenario's die worden ondersteund in Windows-containers, moeten deze scenario's nog steeds de richtlijnen van het vorige hoofdstuk respecteren. Als achtergrondservices bijvoorbeeld worden ondersteund, wordt het uitvoeren van een achtergrondservice op .NET Framework 1.1 niet ondersteund.
Windows-functie/onderdeel waarvoor speciale verwerking is vereist | Reden |
---|---|
Microsoft Messaging Queueing (MSMQ) | MSMQ is lang voordat containers zijn ontstaan en niet alle implementatiemodellen voor berichtenwachtrijen zijn compatibel met containerarchitectuur. |
Microsoft Distributed Transaction Coordinator (MSDTC) | Voor naamomzetting tussen MSDTC en de container is speciale aandacht benodigd. |
IIS | IIS is hetzelfde als in een virtuele machine, maar er zijn belangrijke overwegingen bij het uitvoeren ervan in een containeromgeving, zoals certificaatbeheer, databaseverbindingstekenreeksen en meer. |
Geplande taken | Windows-containers kunnen geplande taken uitvoeren, net zoals elke Windows-instantie. Mogelijk moet u echter een voorgrondtaak uitvoeren om de containerinstantie actief te houden. Afhankelijk van de toepassing kunt u overwegen om een gebeurtenisgestuurde benadering te overwegen. |
Achtergrondservices | Omdat containers worden uitgevoerd als tijdelijke processen, hebt u extra maatregelen nodig om de container draaiende te houden. |
.NET Framework en .NET (voorheen .Net Core) | Zorg ervoor dat u de juiste image gebruikt om compatibiliteit te garanderen, zoals wordt uitgelegd in de onderstaande subsectie. |
Andere ondersteunende onderdelen
Onderdeel waarvoor speciale verwerking is vereist | Reden | Alternatieve benadering |
---|---|---|
Logboekregistratie/bewaking van gebeurtenissen | Omdat de manier waarop Windows gebeurtenissen en logboeken schrijft, inherent verschilt van Linux stdout | Gebruik het nieuwe hulpprogramma Log Monitor om de gegevens te normaliseren en te combineren vanuit Linux en Windows. |
Beveiliging van Windows-containers | Hoewel veel beveiligingsprocedures hetzelfde blijven, vereisen containers aanvullende beveiligingsmaatregelen. | Gebruik een speciaal ontworpen hulpprogramma voor het scannen van registers en software-images. Meer informatie volgt later. |
Back-up van Windows-containers | Containers mogen geen gegevens of statussen bevatten | Maak een back-up van de persistente opslag die door containers wordt gebruikt, evenals de containerimages. |
Windows-onderdelen/-functies
Laten we nu ingaan op de details van toepassingen en onderdelen die in een container kunnen worden geplaatst, maar waarvoor extra verwerking is vereist.
MSMQ
Als uw toepassing afhankelijk is van MSMQ, of u deze kunt containeriseren, is afhankelijk van het MSMQ-implementatiescenario. MSMQ bevat meerdere implementatieopties. De factoren van persoonlijke versus openbare wachtrijen, transactionele of niet- en verificatietype vormen een matrix met scenario's die MSMQ oorspronkelijk heeft ontworpen ter ondersteuning. Niet al deze kunnen eenvoudig worden verplaatst naar Windows-containers. De volgende tabel bevat de scenario's die worden ondersteund:
Draagwijdte | Transactionele? | Wachtrijlocatie | Verificatietype | Verzenden en ontvangen? |
---|---|---|---|---|
Privé | Ja | Dezelfde container (één container) | Anoniem | Ja |
Privé | Ja | Permanent volume | Anoniem | Ja |
Privé | Ja | Domeincontroller | Anoniem | Ja |
Privé | Ja | Eén host (twee containers) | Anoniem | Ja |
Publiek | Nee | Twee hosts | Anoniem | Ja |
Publiek | Ja | Twee hosts | Anoniem | Ja |
Enkele opmerkingen over deze ondersteunde scenario's, die zijn gevalideerd door de interne ontwikkelteams van Microsoft:
- Isolatiemodus: zowel de procesmodus als de Hyper-V modus voor isolatie werken met de bovenstaande scenario's.
- Minimale besturingssysteem- en containerinstallatiekopieën: de minimale versie van het besturingssysteem die wordt aanbevolen voor gebruik met MSMQ is Windows Server 2019.
- Permanente volumes: de bovenstaande scenario's zijn gevalideerd met MSMQ in Azure Kubernetes Service (AKS) met behulp van Azure-bestanden voor permanente opslag.
Wanneer u deze overwegingen samen met de bovenstaande tabel opstelt, kunt u zien dat het enige scenario dat niet wordt ondersteund voor wachtrijen waarvoor verificatie met Active Directory is vereist. De integratie van gMSA's (door groepen beheerde serviceaccounts) met MSMQ wordt momenteel niet ondersteund omdat MSMQ afhankelijkheden heeft van Active Directory die nog niet aanwezig zijn.
U kunt ook Azure Service Bus gebruiken in plaats van MSMQ. Azure Service Bus is een volledig beheerde enterprise-berichtenbroker met berichtenwachtrijen en onderwerpen over publiceren/abonneren (in een naamruimte). Als u overstapt van MSMQ naar Azure Service Bus, zijn codewijzigingen en toepassingsherarchitectuur vereist, maar hebt u de flexibiliteit om over te stappen op een modern platform.
MSDTC
Microsoft Distributed Transaction Coordinator (MSDTC) wordt sterk gebruikt in oudere Windows-toepassingen onder grote ondernemingen. MSDTC kan worden geïnstalleerd in Windows-containers, maar er zijn bepaalde scenario's die niet werken en die niet kunnen worden gereproduceerd in Windows-containers.
- Zorg ervoor dat u bij het maken van de container de parameter --name doorgeeft aan de opdracht docker-run. Met deze naamparameter kunnen de containers communiceren via het docker-netwerk. Als u gMSA gebruikt, moet de naam overeenkomen met de hostnaam die moet overeenkomen met de naam van het gMSA-account.
- Hier volgt een voorbeeld van de run-opdracht met gMSA:
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
- Containers moeten elkaar kunnen vinden met de NETBIOS-naam. Als er problemen zijn met dit probleem, kunt u dit het beste oplossen door de naam en het IP-adres van de containers toe te voegen aan elkaar hostbestanden.
- De uuid voor msdtc op beide containers moet uniek zijn. De UUID vindt u door 'Get-Dtc' uit te voeren in PowerShell voor de containers. Als ze niet uniek zijn, kunt u dit oplossen door msdtc te verwijderen en opnieuw te installeren op een van de containers. Deze powershelll-opdrachten kunnen worden gebruikt: 'uninstall-dtc', 'install-dtc'.
- Op dit moment wordt MSDTC niet ondersteund in Azure Kubernetes Services. Als u een specifieke behoefte heeft om MSDTC op AKS uit te voeren, laat dit dan aan het team van Windows-containers weten door een probleem te openen in de Windows-containers-repo op GitHub.
Hoe IIS werkt in een container versus een VM
IIS werkt hetzelfde in een Windows-container als in een VIRTUELE machine. Er zijn echter enkele aspecten van het uitvoeren van een IIS-exemplaar dat moet worden overwogen bij het uitvoeren van een containeromgeving:
- Permanente opslag voor lokale gegevens: Mappen waarin de app bestanden naar/van schrijft/leest, zijn een goed voorbeeld van iets dat u in een VIRTUELE machine voor een IIS-exemplaar zou bewaren. Met containers wilt u niet dat gegevens rechtstreeks in de container worden geschreven. Containers gebruiken een 'scratchruimte' voor lokale opslag en wanneer er een nieuwe container voor dezelfde toepassing wordt gestart, heeft deze geen toegang tot dat gebied van een vorige container. Gebruik daarom permanente opslag voor gegevens die toegankelijk moeten zijn voor de webtoepassing, zodat elke containerinstantie toegang heeft tot die opslag.
- Certificaten: Hoewel u lokale certificaten op containerinstanties kunt hebben, wordt dit afgeraden, omdat u de containerbeelden opnieuw moet bouwen als een certificaat moet worden bijgewerkt. U kunt ook een containerorkestrator gebruiken met een Ingress-controller. Ingress controllers kunnen netwerkbeleid toepassen en ook het certificaatbeheer afhandelen voor de website die erdoor wordt gehost. Het voordeel is dat u het levenscyclusbeheer van het certificaat loskoppelt van het websitebeheer.
- Databaseverbindingsreeksen: voor traditionele IIS-implementatie kunt u de DB-verbindingsreeks doorgeven als onderdeel van uw toepassingsimplementatie. Hoewel u met Windows-containers dit model kunt volgen, kunt u overwegen om de DB-verbindingsreeks van de container te ontkoppelen naar een gecentraliseerde configuratie die wordt geleverd door de containerorchestrator, waaruit de toepassing kan lezen. Hiermee kunt u de DB-verbindingsreeks onafhankelijk van de toepassing beheren en bijwerken. Als de DB verandert (bijvoorbeeld voor lift-and-shift naar de cloud), kunt u de verbindingsreeks eenvoudig wijzigen zonder de containerimage opnieuw op te bouwen. Met deze methode kunt u ook geheimen (zoals gebruikersnaam en wachtwoord voor het maken van verbinding met de database) bewaren in een geheimarchief.
- Horizontaal automatisch schalen: wanneer de belasting toeneemt, vertragen rekensystemen de waargenomen prestaties tijdens het verwerken van de gelijktijdige aanvragen. Over het algemeen zijn er twee manieren om prestatie-impact te voorkomen: verticaal of horizontaal schalen. Verticale schaal verhoogt de resources die beschikbaar zijn voor de bestaande rekeninstanties (meer CPU, geheugen, enzovoort). Horizontale schaal verhoogt het aantal instanties dat de aanvragen ondersteunt (meer fysieke hosts, of VM's, of containers). Voor weblagen zoals IIS is horizontale schaal meestal efficiënter dan verticaal, maar on-premises omgevingen kunnen resourcebeperkingen en taakverdelingsproblemen ondervinden. Met cloudomgevingen is horizontale schaal veel eenvoudiger omdat resources direct beschikbaar zijn (voor extra kosten) en de cloudprovider ontwerpt doorgaans het taakverdelingsmechanisme met horizontale schaal in gedachten. Windows-containers kunnen gebruikmaken van horizontale schaal voor IIS, maar het tijdelijke aspect van containers speelt een belangrijke rol. Het is belangrijk dat uw containers dezelfde configuratie hebben en dat er geen status of gegevens worden opgeslagen om het aantal exemplaren dat uw webtoepassing ondersteunt, omhoog of omlaag te schalen.
Geplande taken
Geplande taken worden gebruikt om op elk moment in een Windows-omgeving een programma, service of script aan te roepen. Normaal gesproken hebt u altijd een Windows-exemplaar actief en wanneer aan een trigger wordt voldaan, wordt de taak uitgevoerd. Dit is mogelijk met Windows-containers en, afgezien van het feit dat u geplande taken moet configureren en beheren via Azure PowerShell, werken ze precies hetzelfde.
Met een microservicesbenadering hebt u echter een paar opties om te voorkomen dat een container actief blijft om op een trigger te wachten:
- Gebruik een gebeurtenisgestuurde PaaS (Platform as a Service) zoals Azure Function om uw code op te slaan en een trigger voor die app te definiëren. Azure Functions biedt zelfs ondersteuning voor Windows-containerafbeeldingen die kunnen worden uitgevoerd wanneer een trigger wordt geactiveerd.
- Windows-containers gebruiken in combinatie met een containerorchestrator. De container kan alleen worden uitgevoerd wanneer aan de trigger wordt voldaan en aangeroepen vanuit andere onderdelen van de toepassing. In dit geval verwerkt de containerorchestrator de planning en trigger voor de toepassing.
- Houd ten slotte een Windows-container actief om een geplande taak uit te voeren. U hebt een voorgrondservice (zoals Service Monitor) nodig om de container actief te houden.
Achtergrondservices
Hoewel containers over het algemeen bedoeld zijn voor tijdelijke processen, kunt u een achtergrondtoepassing in een container plaatsen, mits u een voorgrondproces maakt om het proces te starten en actief te houden.
Een goed voorbeeld hiervan is ServiceMonitor, een uitvoerbaar Windows-bestand dat is ontworpen om te worden gebruikt als een invoerpuntproces bij het uitvoeren van IIS in containers. Hoewel het is gebouwd voor IIS, biedt het hulpprogramma ServiceMonitor een model dat ook kan worden gebruikt voor het bewaken van andere services, met enkele beperkingen.
Raadpleeg de documentatie op Githubvoor meer informatie over ServiceMonitor.
.NET Framework en .NET
Windows-containers ondersteunen zowel .NET Framework als .NET (voorheen .NET Core). Het .NET-team maakt hun eigen officiële afbeeldingen voor beide frameworks boven op de Windows-basiscontainerafbeeldingen. Het kiezen van de juiste afbeelding is van cruciaal belang om de compatibiliteit te garanderen. Het .NET-team biedt .Net Framework-installatiekopieën boven op de Server Core-basiscontainerinstallatiekopieën en .NET-installatiekopieën boven op zowel server core- als Nano Server-basiscontainerinstallatiekopieën. Server Core heeft een grotere API-set dan Nano Server, die meer compatibiliteit mogelijk maakt, maar ook een grotere afbeeldingsgrootte. Nano Server heeft een sterk verminderd API-oppervlak, maar een veel kleinere afbeeldingsgrootte.
In sommige gevallen moet u mogelijk uw eigen .NET Framework- of .NET-installatiekopieën bouwen boven op de Windows- of Server-basiscontainerinstallatiekopieën. Dit kan nodig zijn als uw toepassing niet alleen een frameworkafhankelijkheid heeft, maar ook een afhankelijkheid van het besturingssysteem. U kunt dergelijke afhankelijkheden detecteren door uw toepassing te testen met een bepaalde basiscontainerafbeelding.
De basiscontainer-installatiekopieën van de Server Core en Nano Server hebben bijvoorbeeld slechts één lettertype beschikbaar om de grootte van de installatiekopieën te verkleinen. Als voor uw toepassing een ander lettertype is vereist, moet u dat lettertype installeren of de Server- of Windows-installatiekopieën gebruiken, die een grotere API-set hebben en alle standaardlettertypen van Windows bevatten. Vanuit het oogpunt van compatibiliteit kan hierdoor vrijwel elke app (zolang ze de aard van containers respecteren, zoals geen GUI) in een container worden geplaatst. Het nadeel is dat ze veel groter zijn, wat de prestaties kan beïnvloeden.
Wanneer u valideert of de toepassing werkt in Windows-containers, raadt Microsoft het volgende aan:
Voor dit framework | Eerst testen met deze containerafbeelding | Terugvallen op deze containerimage als de eerste niet werkt | Basisafbeelding |
---|---|---|---|
.NET Framework-versies 2.X en 3.X | .NET Framework 4.x | .NET Framework 3.5 | Windows Server Core |
.NET Framework 4.x-versies | .NET Framework 4.x | Uw .NET Framework-containerinstallatiekopieën bouwen met Server- of Windows-installatiekopieën | Windows Server Core |
.NET 6 of 7 | .NET 6 of 7 respectievelijk | Uw .NET-containerafbeelding bouwen met basisinstallatiekopieën van Windows of Server | Windows Nano Server of Server Core |
Andere ondersteunende onderdelen
De onderstaande onderdelen en onderwerpen bevatten aanvullende richtlijnen voor items die naast elkaar staan of die een betere duidelijkheid bieden in Windows-containers.
Gebeurtenisregistratie
Windows en Linux gebruiken verschillende methoden om logboeken en gebeurtenissen voor de gebruikers op te slaan en weer te geven. Normaal gesproken heeft Windows de EVT-indeling gebruikt, die op een gestructureerde manier in Event Viewer kan worden bekeken. Linux biedt daarentegen een gestroomlijnde benadering met Standard Output (stdout) waarop andere hulpprogramma's, zoals Docker, vertrouwen.
Docker heeft altijd een mechanisme voor het extraheren van logboeken uit Linux-containers. Met behulp van de opdracht docker logs met een standaard stdout-configuratie brengt Docker toepassingslogboeken uit de container zonder de container interactief te openen. Totdat het hulpprogramma Log Monitor werd gestart, werkte dezelfde techniek echter niet in Windows.
Het hulpprogramma Logboekcontrole presenteert de Windows-logboeken in de stdout-indeling, zodat andere hulpprogramma's, zoals Docker, de benodigde informatie kunnen verzamelen om deze weer te geven. Aanvullende voordelen voor het gebruik van Log Monitor zijn onder andere:
- U kunt filteren welke typen gebeurtenissen/logboeken u wilt weergeven op stdout. U kunt bijvoorbeeld het toepassingslogboek alleen filteren op foutberichten en waarschuwingsberichten als u niet geïnteresseerd bent in 'informatie'-gebeurtenissen.
- De mogelijkheid om te kiezen uit gebeurtenislogboeken, aangepaste logboekbestanden of gebeurtenistracering voor Windows (ETW). Dit is met name handig als uw toepassing op een andere logboekbron schrijft. Een voorbeeld hiervan zijn de IIS-logboeken in de map C:\inetpub.
- Het feit dat Log Monitor ervoor zorgt dat Windows-containers zich nagenoeg hetzelfde gedragen als Linux-containers, betekent dat hulpprogramma's die naar stdout zoeken en interacteren met de containerruntime, functioneren zoals verwacht. Als u bijvoorbeeld overstapt van Docker naar ContainerD als containerruntime, moeten de logboeken nog steeds zichtbaar zijn vanaf de containerhost via (bijvoorbeeld) 'crictl logs'.
Meer informatie over het hulpprogramma Logboekcontrole vindt u in dit blogbericht.
Beveiliging van Windows-containers
Windows-containers zijn gebouwd op dezelfde basis als Windows-exemplaren die worden uitgevoerd op fysieke of virtuele machines. Inzicht in de specifieke kenmerken van hoe containers worden geïmplementeerd, met name wat de aard van de gedeelde kernel is, helpt u bij het beveiligen van een containertoepassing:
- Gedeelde onderdelen. Windows-containers delen enkele onderdelen van de host voor beveiligingsdoeleinden. Dit geldt ook voor Windows Firewall, Windows Defender (Antivirus) en andere beperkingen voor toegang tot resources. U hoeft deze onderdelen niet rechtstreeks in uw container te configureren omdat de containerhost de benodigde aanpassingen aanbrengt op basis van uw containerworkload. Als de container bijvoorbeeld een webaanvraag indient, stuurt de containerhost het benodigde verkeer door via de firewall, zodat de container toegang heeft tot het web.
- Isolatiemodus. Zoals besproken, kunnen Windows-containers worden geïmplementeerd in proces- of Hyper-V isolatiemodus, met Hyper-V de veiligste isolatie te bieden. In procesisolatie deelt de container de kernel, het bestandssysteem en het register met de host, waardoor een proces met verhoogde bevoegdheden (admin) kan communiceren met de containerprocessen en -services. Het kiezen van de juiste isolatiemodus voor uw toepassing is belangrijk om het juiste beveiligingsmodel te garanderen.
- Windowsupdates. Omdat de onderhoudsstack niet aanwezig is in Windows-containers, ontvangen Windows-containers geen updates zoals algemene Windows-exemplaren. In plaats daarvan moet u Windows-containers opnieuw bouwen met behulp van de meest recente basiscontainerinstallatiekopieën. Klanten kunnen hiervoor gebruikmaken van DevOps-pijplijnen. Microsoft werkt de basiscontainerafbeeldingen elke maand bij voor alle officiële afbeeldingen volgens het Patch Tuesday-schema.
- Containergebruikersaccount. Toepassingen in Windows-containers worden standaard uitgevoerd met verhoogde bevoegdheden onder het ContainerAdmin-gebruikersaccount. Dit is handig voor het installeren en configureren van de benodigde componenten in de containerimage. U moet echter overwegen om het gebruikersaccount te wijzigen in ContainerUser bij het uitvoeren van een toepassing waarvoor geen verhoogde bevoegdheden zijn vereist. Voor specifieke scenario's kunt u ook een nieuw account maken met de juiste bevoegdheden.
- Scannen van afbeeldingen en runtimes. Containers vereisen dat images op repositories en containerinstellingen veilig zijn. Microsoft raadt u aan Microsoft Defender for Containers te gebruiken voor het scannen van images en runtime scans. Defender for Containers ondersteunt Windows-containers voor evaluatie van beveiligingsproblemen met registerscans en runtimebeveiliging met detectie van bedreigingen.
Meer informatie over de bovenstaande onderwerpen vindt u op de documentatiepagina van Windows-containers .
Back-up van Windows-containers
U moet anders nadenken over back-ups bij het gebruik van containers. Zoals eerder is besproken, mag een container niet worden gebruikt voor het opslaan van status of gegevens op basis van de tijdelijke aard ervan. Als u de status en gegevens van de containerinstantie scheidt, vallen uw back-upzorgen buiten de runtime van de containerinstantie, die kan worden vervangen door een nieuwe instantie waarbij alle benodigde permanente opslag nog steeds beschikbaar is.
Er zijn nog steeds onderdelen waarvoor u verantwoordelijk bent om back-ups te maken; inclusief de toepassing, de containerafbeelding en het dockerfile dat de containerafbeelding bouwt. De meeste van deze bewerkingen worden verwerkt door het platform waarop u uw productie- en ontwikkelingsworkloads uitvoert. Houd rekening met de meest voorkomende gevallen bij het aannemen van een DevOps-benadering:
- Toepassing: Uw toepassing bevindt zich waarschijnlijk in een bronopslagplaats, zoals GitHub of Azure DevOps. Deze opslagplaatsen bieden versiebeheer, waarmee u kunt terugkeren naar een specifieke versie van de toepassing. Als u eigenaar bent van de bronopslagplaats, moet u de aanbevelingen voor back-up en beheer volgen.
- Containerafbeelding: Voor productieomgevingen moet uw containerafbeelding zich in een gecentraliseerde opslagplaats bevinden, zoals Azure Container Registry (ACR). U kunt uw containerinstallatiekopieën pushen naar ACR, zodat deze beschikbaar is voor andere hosts om deze op te halen. ACR verzorgt de beschikbaarheid van de containerafbeeldingen en fungeert als back-upoptie. Houd er echter rekening mee dat hoewel ACR de beschikbaarheid van de afbeeldingen afhandelt, dit niet voorkomt dat een afbeelding wordt verwijderd of overschreven. Voor elke andere lokale of on-premises image-opslagplaats volgt u de aanbeveling van de leverancier voor het maken van back-ups van bestaande registers.
- Dockerfile: Dockerfiles bouwen nieuwe containerinstallatiekopieën en worden meestal samen met de toepassingsbron opgeslagen. Omdat het dockerfile mogelijk niet is gemaakt met de toepassing, met name als het een bestaande toepassing is die in een container wordt geplaatst, bent u verantwoordelijk voor het controleren of het dockerfile wordt opgeslagen op een veilige en back-uplocatie. U moet er ook voor zorgen dat er een back-up wordt gemaakt van alle andere assets die nodig zijn om uw toepassing in een container te laten werken; Bijvoorbeeld: YAML- en JSON-bestanden voor Kubernetes-, Docker Swarm- en Azure ARM-sjablonen volgen dezelfde richtlijnen als hierboven.
Het lift-and-shift-proces plannen
Nadat u de gereedheid van uw toepassing voor containerisatie hebt beoordeeld, gebruikt u de volgende algemene richtlijnen om het proces te plannen:
- Bepaal de basisinstallatiekopieën van het Windows-besturingssysteem die u nodig hebt: Windows Server Core, Nano Server, Windowsof Server-installatiekopieën.
- Bepaal het type isolatiemodus voor de container: kies tussen proces- of Hyper-V isolatiemodi. Opmerking: Momenteel ondersteunen AKS en AKS in Azure Stack HCI alleen proces-geïsoleerde containers. In een toekomstige release bieden zowel AKS als AKS in Azure Stack HCI ook ondersteuning voor Hyper-V-geïsoleerde containers. Zie Isolatiemodivoor meer informatie.
- Kies de juiste Windows Server-versie voor uw toepassing voor toepassingscompatibile doeleinden. De minimale Versie van Windows Server voor containers is Windows Server 2016, maar Windows Server 2019 en Windows Server 2022 zijn de enige containerhostbesturingssystemen die worden ondersteund op AKS en AKS in Azure Stack HCI.
- Zorg ervoor dat het beveiligingsbeleid van uw bedrijf is ingesteld voor de containeromgeving. Dit omvat het aanpassen van specifieke vereisten voor containers, zoals registerscans en detectie van bedreigingen.
- Overweeg taakverdelingsbehoeften. Containers zelf worden niet verplaatst; U kunt in plaats daarvan een orchestrator gebruiken om containers op clusterknooppunten automatisch te starten of te stoppen, of om wijzigingen in belasting en beschikbaarheid te beheren met automatische horizontale schaal.
- Overweeg orchestratiebehoeften. Zodra uw toepassing is gecontaineriseerd, heeft uw toepassing waarschijnlijk geautomatiseerd beheer nodig dat beschikbaar is met hulpprogramma's zoals Kubernetes, AKS of AKS in Azure Stack HCI. Zie Overzicht van Windows-containerindeling voor een volledige discussie en handleiding voor het kiezen van de hulpprogramma's.
- Plaats de app in een container.
- Upload de app naar een image repository. Hierdoor kunnen de containerhosts de image downloaden in elke omgeving, waaronder ontwikkeling, testen en productie.
Azure Migrate kan een begeleid proces bieden voor het detecteren, beoordelen en migreren van uw bestaande Windows-toepassing naar Azure Kubernetes Service. Raadpleeg de documentatiepagina van Azure Migrate voor meer informatie.