Een veel voorkomende vraag wanneer iemand op zoek is naar het transformeren/containeriseren van zijn oplossing is; ‘ik draai nu op een Windows systeem: moet ik Windows containers gebruiken of moet ik kiezen voor Linux containers? En dit is inderdaad een hele terechte vraag. Een lang verhaal kort: Ga voor Linux containers als je kunt. Maar dat is niet altijd een realistische keuze. Wat als je al jaren bezig bent met het ontwikkelen van je huidige oplossing en de softwarestack die je gebruikt wordt niet ondersteund of werkt niet zo goed op een Linux gebaseerd systeem? Dan zijn Windows containers misschien wel dé oplossing voor jou.
Windows containers in het container ecoysysteem.
Windows containers hebben veel commentaar gekregen en worden zelfs belachelijk gemaakt (zelfs door mij), maar het is geen eerlijke vergelijking. Linux containers bestaan al veel langer en zijn meestal de standaard die je zou gebruiken als je vanaf nul zou beginnen. Met de release van cross platforn .Net versies, is de Linux use case voor bedrijven nog groter geworden. Doordat .Net cross-platform is, is het eenvoudig geworden om je oplossing op basis van Linux in containers te containeriseren. Zoals vermeld in de inleiding, hebben veel bedrijven legacy code op basis van verschillende stacks. Neem bijvoorbeeld .Net Framework. Als je jaren ontwikkelt in .Net Framework en je migratie pad naar.Net Core maandenlang ontwikkeling-inspanningen vragen, dan is het onwaarschijnlijk dat je dit gaat doen. Als je jouw oplossing nog steeds wil containeriseren om meer schaalbaarheid toe te voegen en standaardisatie af te dwingen (hierover later meer), dan zijn Windows Containers een interessante oplossing voor jou.
Hoe Windows Containers verschillen van Linux Containers
Je zou het niet geraden hebben, maar ze verschillen nogal. Ja, je bent nog steeds bezig met het schrijven van een Dockerfile, het bouwen ervan en het runnen van je container, maar daar houdt het dan ook wel een beetje op. Voordat je aan de slag gaat met Windows containers raad ik je aan om de concepten, de beperkingen en de mogelijkheden hier te lezen.
Het besturingssysteem
Nou, ten eerste … Het besturingssysteem is anders. Waar we gewend zijn aan een grote verscheidenheid aan opties van afbeeldingen als het gaat om Linux Containers gaat is dit bij Windows Containers een ander verhaal. Er is een sterke link tussen het container OS en het Host OS en je wordt geadviseerd op ze op elkaar af te stemmen, zodat er er geen onverwachte problemen ontstaan. Deze eisen worden nog belangrijker wanneer je gebruikt maakt van proces isolatie. Microsoft heeft deze richtlijnen vrijgegeven om te bepalen welke image het beste past voor welk scenario.
Waar is mijn grafische interface gebleven?
Ja, het is niet echt een verschil, maar het is het vermelden waard als je gewend bent om je oplossing op Windows te draaien. Als het om containers gaat, is er geen GUI. Nu denk je misschien ‘’Ja, natuurlijk weten we dat’’, maar wacht even! In een Linux ecosysteem zijn we gewend om te werken vanuit de command line, maar vanuit Windows … Niet echt. Ja, we gebruiken Powershell, maar hoeveel van je applicaties installeer je eigenlijk vanaf de command line? Precies.
Als je je Windows toepassing zou containeriseren, betekent dit dat je alles vanaf de command line en via het Dockerfile moet worden uitgevoerd. Dit klinkt misschien als een beperking, maar het tegenovergestelde is waar. Je gaat de implementaties standaardiseren en scripten! Soms betekent dat dat je sommige dingen in je iinstaller moet veranderen en soms ben je al klaar om te containeriseren.
Image sizes
Ik ga niet zeggen dat Windows containers ‘langzamer’ zijn, want als het gaat om de runtime zelf hoeft dat niet zo te zijn. Het grootste verschil is de image van de container. Windows images zijn grote dan Linux images. Wanneer je je container draait wordt de Docker image gedownload en dat duurt iets langer dan het downloaden van een Docker image op basis van Linux. Als je daar rekening mee houdt en de juiste image voor jouw werklast kiest, zou dit geen probleem moeten zijn.
Dan zijn er ook nog recente ontwikkelingen die dit verschil kunnen wegnemen of minimaliseren tot een punt waarop het geen issue meer voor je is. Kijk maar eens naar Artifact Streaming. In de wereld van Windows containers zal dit een grote verbetering zijn.
Ik maak gebruik van Azure Kubernetes Services, wat nu?
Goede vraag! Gemakkelijk en eerlijk antwoord: Kubernetes ondersteunt het gebruik van Windows node pools. Dat betekent dat wanneer je AKS uitrolt je één of meerdere node pools kunt hebben. Die node pools kunnen Windows zijn. Bedenk wel dat je altijd een Linux node Pool nodig hebt. De standaard node pool is ook de plek waar de services die nodig zijn voor het functioneren van het cluster worden gehost, deze zijn gebaseerd op Linux.
Dat betekent dat als je voor een Windows container gaat, je minimaal twee node pools hebt. Net als bij Linux node pools worden deze beheerd door AKS zelf en hoe je je daar geen zorgen over te maken. Als je de nodes wel wilttroubleshooten, dan kun je ze benaderen via RDP (let op; de node, niet de container!). Echter, we kunnen tegenwoordig ook gebruik maken van SSH, wat de nieuwe best practice zal zijn.
Je hoeft de nodes niet te openen om Windows updates te installeren of goed te keuren. Op node pools is Windows update uitgeschakeld. In plaats daarvan kun je je Windows-nodepool net als elke andere nodepool upgraden.
Daarnaast worden de meeste functies ondersteund door Windows Containers. Dingen zoals persistent storage networking (CNI) zijn er die je zo kunt gebruiken.
Als je meer wilt weten over de technische aspecten van wat er anders is en wat eventuele beperkingen zijn, kijk dan naar de officiële Kubernetes project documentatie.
De use Case voor Windows Containers
Terug naar het begin. Wat is eigenlijk het nut van Windows Containers? Ik zie verschillende scenario’s gebeuren in de praktijk. Eén daarvan is waar schaalvergroting en de standaardisatie een grote vraag is. Als jouw legacy-applicatie op basis van Windows draait en je wilt echt graag meer schaalbaarheid en standaardisatie toevoegen, dan zijn containers over het algemeen een goede manier om je app te distribueren (let wel op dat als je all-in op containers gaat, dit niet je enige motivatie moet zijn). Als je graag af wilt van de IIS-app op een virtuele machine die je voor elke nieuwe klant moet inzetten, dan zijn Windows Containers misschien wel het antwoord waar je naar op zoek bent.
Dan zie ik ook een veelvoorkomend scenario waarbij klanten overstappen op containers, maar nog niet alles geoptimaliseerd hebben voor gebruik op Linux-containers. Dit is waar de use case van de multiple node pools erg handig is. Laten we zeggen dat je aan het transformeren bent naar containers en een moderne versie van .Net (als je toch bezig bent). Misschien dat sommige delen van je oplossing wat meer werk vereisen om te transformeren (laten we aannemen dat die delen afhankelijk zijn van Windows). Je hoeft niet langer te wachten en je kunt nu beginnen met het gebruik van AKS. Die Windows containers zullen uiteindelijk getransformeerd/rebuild worden naar Linux Containers, maar de ontwikkeling investering hoeft nu niet plaats te vinden. Misschien ben je wel blij met het hybride Windows/Linux scenario en laat je het nog een geruime tijd zo draaien .. Of niet. Beide zijn een optie, maar het hebben van de mogelijkheid om te kiezen tussen de soorten besturingssystemen is echt een game-changer als het gaat om het container systeem. Ja, ze zijn verschillend, maar als je de regels (beperkingen) en use cases volt kan dit echt goed voor je uitpakken.
