I en historie, jeg skrev for Computerverden i januar, som var en gennemgang af Windows Server 2016 Technical Preview 4, nævnte jeg Windows Servers nye understøttelse af Hyper-V-containere, der var blevet føjet til dens understøttelse af Docker-stilcontainere (til stede inden for betaproduktet siden den forrige beta-milepælsudgivelse ).
Imidlertid har tilstedeværelsen af to containermuligheder ført til mange spørgsmål. Hvad er forskellen mellem en Docker-container og en ny Hyper-V-container? I hvilke scenarier vil du bruge den ene containerløsning over den anden? Er der separate metoder til implementering af hver af disse?
Microsoft har ikke gjort et godt stykke arbejde med at dokumentere disse to containerindstillinger, og containere selv er nye på Windows Server-platformen. I betragtning af disse to faktorer vil jeg dedikere en hel historie til, hvilke specifikke containerløsninger Windows Server 2016 enten leverer nu i forhåndsvisning i de tilgængelige udgivelser eller lover at levere inden softwarens frigivelse til produktionsdato (RTM), sandsynligvis i anden halvdel af 2016.
Oversigt
Der er to typer containere til stede i Windows Server 2016 på dette tidspunkt: Windows Server-containere og Hyper-V-containere. Begge understøtter kun Windows Server; hverken kan f.eks. mix-and-match Linux og / eller Unix.
For dovne administratorer som mig, lad os få det vigtige spørgsmål ude af vejen foran: Er den ene af de to containertyper sværere at implementere end den anden? Svaret er et eftertrykkeligt nej.
[Yderligere læsning: Første kig: Kør VM'er i VM'er med Hyper-V-containere]
Containertyperne udføres forskelligt og har forskellige niveauer af isolation og tillid til hypervisoren. Men i sin kerne er dette en implementeringstidsbeslutning truffet af ejeren af den fysiske maskine - værtsejeren - om hvilken type container der skal bruges, og det er så simpelt som at kontrollere den rigtige radioknap i en guide . Du vælger blot mellem de to ved oprettelsestidspunktet. Beslutningen påvirker, hvordan Windows Server 2016 - selve operativsystemet (hypervisoren, der sidder i bunden af alle disse ting, kører på silicium og fysisk jern) - isolerer og udfører arbejdsbelastningerne i hver container.
Så nu hvor du ved, at begge containermuligheder er den samme mængde arbejde for dig, hvordan beslutter du intelligent mellem de to? I det væsentlige kommer det ned til tillid: Hvis du stoler på koden, der kører i containeren, vælger du en Windows Server (læs: traditionel, Docker-stil) container. Hvis du ikke har tillid til koden eller ikke kan bekræfte den, eller hvis den ikke kom fra dine interne udviklere i din egen organisation, er en Hyper-V-container den rigtige vej. Lad os se på hver mulighed i detaljer.
Windows Server-containere
Windows Server-containere er faktisk kun en del af Docker-open source-containerprojektet, så hvis du tænker på en Docker-stil container, vil du tænke på en Windows Server-container. Disse containere er i det væsentlige en ny type virtuel maskine, der på nogle måder har mindre isolering end en traditionel virtuel maskine - nemlig fordi i mange tilfælde deles ting, der er fælles for alle containere, der kører på en vært. Blandt disse delte emner er operativsystemfiler, kataloger og kørende tjenester. Dette gøres for at opnå større effektivitet, fordi hvis du kører tre forskellige containere på en vært, alle med den samme version af Windows Server som gæster, behøver du kun en kopi af C: \ Windows-biblioteket til enhver tid.
Denne deling adskiller stadig containere fra en given applikation, der muligvis kører på en vært - men det reducerer også omkostninger og gør containere mere lette. Du har mere plads pr. Server, der kører containere på grund af denne deling, i modsætning til at køre traditionelle virtuelle maskiner, som er mere isolerede og ikke deler noget - og derfor har tendens til at have meget mere dobbeltarbejde. Du bruger normalt også Windows Server-containere, når din vært og gæst alle kører det samme operativsystem for at drage fordel af denne deling; som et resultat kan du ikke køre en container med Ubuntu Server, der kører på en Windows Server 2016-vært. (For den type arbejdsbyrde bruger du traditionelle virtuelle maskiner. Containere ville ikke være passende til dette. Du bruger bare VM'er, som har været understøttet i Windows siden 2008.)
For hvad det er værd, lige nu er de to container-image-operativsystemer, der understøttes af Windows Server-containere, Server Core (Windows uden dets grafiske brugergrænseflade) og Windows Nano Server, den radikalt ombyggede mikroserver, der er velegnet til små mikroservicesorienterede roller. (Mere om mikroservices om lidt.)
Så hvordan passer Docker ind i alt dette? Docker giver et "administrationslag", hvis du vil, af API'er og motorer til at styre containere - en, der hurtigt er blevet en industristandard, muligvis fordi Docker selv er open source og udbredt. Docker Hub, der er tilgængelig til brug for alle på Internettet, er et ægte lagerplads-lager af applikationer, der alle kører i Docker-stil containere.
Docker giver også en mental ramme, som udviklere kan bruge til at komme tættere på den faktiske drift af deres kode og til at bygge hele containere af de miljøer, som deres kode kræver for at køre. Udviklere bygger i det væsentlige containerbilleder, som derefter sendes over til operationer ganske let og kører i det væsentlige som de er som gæster på den vært. Opdateringer og kodefixes kan håndteres hurtigt og nemt på samme måde.
Hver af disse containerbilleder fungerer måske endda på en meget lille del af den samlede applikation, som komponerer løsningen og gør det lettere at arbejde i et mikrotjenesteorienteret miljø. Fra et stort billedperspektiv øger arbejdet med containere ansvarligheden for udviklere at skrive god kode, der fungerer nøjagtigt inden for deres miljø. Udviklere kan ikke længere skrive kode, der fungerer perfekt på deres udviklingsmaskiner, men vælter, når de implementeres på produktionssoftware - da de er den samme, skal koden fungere begge steder. Dette mindsker også friktionen mellem operationer og IT - IT med dets uberørte servermiljøer og udviklere, der forventer bestemte konfigurationer, men ofte mangler evnen eller begrundelsen til at ændre produktionsmiljøer, så de passer til deres forventninger.
Disse Windows Server-containere i Docker-stil antyder en vis grad af tillid - enten at du har downloadet en betroet applikation fra Docker Hub, eller at dine interne udviklere eller kontraktudviklere forsynet dig med en containerkørselskode, som du stoler på. For applikationer i containere, der har tillid til kode, anbefales Windows Server-containere og passende. Deling og projektion af operativsystemfiler bør ikke være et problem for betroet kode.
Men hvad sker der, når der er behov for lidt mere sikkerhed, lidt mere isolation med mindre end fuldt pålidelig kode eller apps?
Hyper-V containere
Det er, når du begynder at kigge på Hyper-V-containere, som gifter sig med modellen for isolering og abstraktion fra traditionelle virtuelle maskiner med fleksibilitet, billede og nem omplacering af Docker-stil Windows Server-containere sammen med Docker API og administrationsværktøjer, der Jeg diskuterede i det foregående afsnit.
Mark Russinovich, CTO for Microsoft Azure, sagde det sådan i et blogindlæg sidste år: Hyper-V-containere "isolerer applikationer med garantierne forbundet med traditionel virtualisering, men med lethed, billedformat og styringsmodel for Windows Server Containere, herunder støtte fra Docker Engine. " Forskellen her er isolationsniveauet: Hyper-V-containere deler ikke direkte operativsystemfiler, processer og tjenester med værten. Snarere indpakker Windows Server hvert lille containerbillede i en meget lav overhead virtuel maskine, hvilket opnår den abstraktions- og tillidsgrænse, som en Windows Server-container i Docker-stil ikke gør.
Denne virtuelle maskine er dog i alle henseender gennemsigtig for administratoren. Containerbillederne selv, der kører Windows Server, forstår, at de faktisk er containerbilleder og ikke kører på almindeligt uhindret silicium, og dermed er i stand til at drage fordel af optimeringer til OS, der kommer fra denne bevidsthed. Men selvom disse containerbilleder er mere isolerede, distribueres de ikke anderledes end Windows Server-containere. Du bruger stadig Docker API'er. Du bruger stadig Docker-klienten. Du markerer bare et andet felt, men selve containerbillederne er bygget og leveret på samme måde, uanset hvilken isolationsmodel du vil bruge til at køre dem.
Ulempen ved denne tilgang: Der er mere overhead. På grund af den ekstra isolering duplikeres mere kode og processer. Der er også det faktum, at selvom den lette virtuelle maskineindpakning til en Hyper-V-container er lille, tilføjer den faktisk en "skat" til omkostningerne ved at køre et containerbillede. Så mens du kan fylde en kraftig vært fuld af Windows Server-containere i Docker-stil, ville Hyper-V-containere være begrænset til et bestemt mindre antal containere, alt andet lige hardware-messigt.
Igen understøtter disse containerbilleder kun Windows Server. Selvom der er isolation, er der stadig fællesart mellem containerbillederne og værtsoperativsystemet. Så hvis dine containerbilleder kører Linux, en anden smag af Unix, BSD eller ethvert andet alternativt operativsystem, betyder ingen af disse nye Windows Server 2016-funktioner noget for dig.
Bundlinjen: Tredjepartskode, markedspladskode eller kode, der ellers ikke er fuldstændig betroet af nogen del af din organisation, skal køres i Hyper-V-containere. Disse er også det bedste valg til offentlige skyer i flere enheder og andre lignende miljøer. Du mister kun kapacitet, og du får sikkerhedsfordelene ved at være mere isoleret.
Docker-containere
Lad mig nu introducere Docker-containere for at bevise, at branding altid er den sværeste del af enhver teknologi. Ovenfor nævnte jeg, at Windows Server-containere er en del af Docker open source-projektet. Docker-containere adskiller sig fra Windows Server-containere. Windows Server-containere kan bruge al den underliggende Docker-teknologi, men det eksisterende Docker-værktøjssæt til styring af Docker-containere fungerer ikke (i det mindste i denne udgivelse) med Windows Server-containere. Windows Server-containerstyringsværktøjer kan heller ikke - på dette tidspunkt en masse PowerShell-kommandoer - gøre noget af værdi med Docker-containere selv.
Docker-containere er deres egen specifikke ting, og mens Windows Server-containere fungerer som Docker-containere i deres evne til at dele, men isolere - det er derfor, jeg har henvist til dem som Docker-stil Windows Server-containere - de er ikke Docker-containere i sig selv. Dette kan ændre sig i fremtiden, især i en servicepakke eller den næste udgivelse af Windows Server, men indtil videre forbliver disse tre containertyper, selvom de alle muligvis er ens, forskellige koncepter. Kun to understøttes i øjeblikket af Windows Server.
Hvor teknologien er i dag
Lige nu er containerstøtte i Windows Server 2016 meget i gang. Der er mange bevægelige dele til containere: Fjernelse af afhængigheder af værts- og operativsystemfiler og specifikke versioner og patchniveauer; at opnå den rette isolation og sikre, at ingen kode kan bryde den grænse for sikkerhed og tillid; gøre udviklerhistorien rigtig med værktøjer og automatisering, der giver udviklere mulighed for at arbejde med containere i deres foretrukne integrerede udviklingsmiljø (IDE) og "eksportere" deres applikationer direkte til containeren; sørge for, at containere problemfrit kan bevæge sig op og ned i den offentlige sky og mere.
I alle disse tilfælde er der stadig fatale fejl og fejl at arbejde igennem. Hvis containere er afgørende for din køreplan for servicetilbud i din butik, kan du måske begynde at teste funktionerne i Windows Server-containere og Hyper-V-containere nu og især tjekke de tilgængelige PowerShell-kommandoer for at aktivere containere og administrere dem. på en Windows Server 2016-vært.
Men hvis containere er en god mulighed, men ikke et must-have for din organisation, så ville min informerede anbefaling være at holde ud med at forsøge alt andet end den mest rudimentære udforskning ved hjælp af Technical Preview 4 bits. Der er stadig bare for mange vorter - inklusive de fatale fejl og fejl, der er nævnt tidligere - til virkelig at få en sammenhængende fornemmelse af, hvad der sker.
Containersupport vil være en spændende tilføjelse til Windows-platformen. Der er meget af den historie tilbage, der skal skrives og fortælles.
Denne historie, "Containers in Windows Server 2016: What you need to know" blev oprindeligt udgivet af Computerworld.
