I en historie jeg skrev for Computerworld i januar, som var en gjennomgang av Windows Server 2016 Technical Preview 4, nevnte jeg Windows Servers nye støtte for Hyper-V-containere som hadde blitt lagt til sin støtte for Docker-stil containere (til stede i beta-produktet siden forrige beta milepælutgivelse ).
Tilstedeværelsen av to containeralternativer har imidlertid ført til mange spørsmål. Hva er forskjellen mellom en Docker-container og en ny Hyper-V-container? I hvilke scenarier vil du bruke den ene containerløsningen fremfor den andre? Er det separate metoder for å distribuere hver av disse?
Microsoft har ikke gjort en god jobb med å dokumentere disse to containeralternativene, og containere i seg selv er nye for Windows Server-plattformen. Gitt disse to faktorene, vil jeg vie en hel historie til hvilke spesifikke containerløsninger Windows Server 2016 enten gir nå i forhåndsvisning i tilgjengelige utgivelser, eller lover å gi før programvarens utgivelse til produksjonsdato (RTM), sannsynligvis i andre halvdel av 2016.
Oversikt
Det er to typer containere tilstede i Windows Server 2016 på dette tidspunktet: Windows Server-containere og Hyper-V-containere. Begge støtter bare Windows Server; ingen kan for eksempel mikse og matche Linux og / eller Unix.
For lat administratorer som meg, la oss få det viktige spørsmålet ut av veien foran: Er en av de to containertypene vanskeligere å distribuere enn den andre? Svaret er et ettertrykkelig nei.
[Videre lesing: Første titt: Kjør virtuelle maskiner i virtuelle maskiner med Hyper-V-containere]
Containertypene kjøres annerledes og har forskjellige nivåer av isolasjon og tillit til hypervisoren. Men i kjernen er dette en distribusjonstidsbeslutning tatt av eieren av den fysiske maskinen - vertseieren - om hvilken type container som skal brukes, og det er så enkelt som å sjekke riktig alternativknapp i en veiviser . Du velger ganske enkelt mellom de to ved opprettelsestiden. Avgjørelsen påvirker hvordan Windows Server 2016 - selve operativsystemet (hypervisor, som sitter nederst på alt dette, kjører på silisium og fysisk jern) - isolerer og utfører arbeidsbelastningen i hver container.
Så nå som du vet at containeralternativet er like mye arbeid for deg, hvordan bestemmer du intelligent mellom de to? I hovedsak kommer det ned til tillit: Hvis du stoler på koden som kjører i containeren, vil du velge en Windows Server (les: tradisjonell, Docker-stil) container. Hvis du ikke stoler på koden, eller ikke kan bekrefte den, eller hvis den ikke kom fra dine interne utviklere i din egen organisasjon, er en Hyper-V-container veien å gå. La oss se på hvert alternativ i detalj.
Windows Server-containere
Windows Server-containere er egentlig bare en del av Docker-prosjektet med åpen kildekode-container, så hvis du tenker på en Docker-stil container, vil du tenke på en Windows Server-container. Disse containerne er egentlig en ny type virtuell maskin som på noen måter har mindre isolasjon enn en tradisjonell virtuell maskin - nemlig fordi det i mange tilfeller deles ting som er felles for alle containere som kjører på en vert. Blant disse delte elementene er operativsystemfiler, kataloger og tjenester som kjører. Dette gjøres for større effektivitet, for hvis du kjører tre forskjellige containere på en vert, alle med samme versjon av Windows Server som gjester, trenger du bare en kopi av C: \ Windows-katalogen til enhver tid.
Denne delingen skiller fortsatt containere fra en hvilken som helst applikasjon som kan kjøre på en vert - men det reduserer også overhead og gjør containere lettere. Du har mer takhøyde per server som kjører containere på grunn av denne delingen, i motsetning til å kjøre tradisjonelle virtuelle maskiner, som er mer isolerte og ikke deler noe - og dermed har en tendens til å ha mye mer duplisering. Du vil også vanligvis bruke Windows Server-containere når verten og gjesten alle kjører det samme operativsystemet for å dra nytte av denne delingen; Som et resultat kan du ikke kjøre en container med Ubuntu Server som kjører på en Windows Server 2016-vert. (For den typen arbeidsmengde vil du bruke tradisjonelle virtuelle maskiner. Beholdere vil ikke være passende for dette. Du vil bare bruke virtuelle maskiner, som har blitt støttet i Windows siden 2008.)
For hva det er verdt, akkurat nå er de to container-image-operativsystemene som støttes av Windows Server-containere Server Core (Windows uten det grafiske brukergrensesnittet) og Windows Nano Server, den radikalt ombygde mikroserveren som passer for små mikroservicerienterte roller. (Mer om mikrotjenester litt.)
Så hvordan passer Docker inn i alt dette? Docker gir et "administrasjonslag", hvis du vil, av APIer og motorer for å administrere containere - en som raskt har blitt en industristandard, muligens fordi Docker selv er åpen kildekode og mye brukt. Docker Hub, tilgjengelig for bruk av alle på Internett, er et ekte lagerplass-lager av applikasjoner som alle kjører i Docker-stil containere.
Docker gir også et mentalt rammeverk som utviklere kan bruke for å komme nærmere den faktiske driften av koden sin og for å bygge hele containere av miljøene koden krever for å kjøre. Utviklere bygger i hovedsak containerbilder, som deretter sendes over til operasjoner ganske enkelt, og kjører i det vesentlige som de er som gjester på verten. Oppdateringer og kodefikser kan håndteres raskt og enkelt på samme måte.
Hver av disse containerbildene kan til og med fungere på en veldig liten del av den samlede applikasjonen, noe som komponerer løsningen og gjør det lettere å jobbe i et mikrotjenesterorientert miljø. Fra et stort perspektiv øker arbeidet med containere ansvarligheten for utviklere å skrive god kode som fungerer nøyaktig innenfor deres miljø. Utviklere kan ikke lenger skrive kode som fungerer perfekt på utviklingsmaskiner, men faller over når de brukes på produksjonsprogramvare - siden de er den samme, må koden fungere begge steder. Dette reduserer også friksjonen mellom drift og IT - IT med sine uberørte servermiljøer og utviklere som forventer visse konfigurasjoner, men ofte mangler evnen eller begrunnelsen til å endre produksjonsmiljøer for å imøtekomme deres forventninger.
Disse Windows Server-containerne i Docker-stil innebærer en viss tillit - enten at du har lastet ned en pålitelig applikasjon fra Docker Hub, eller at dine interne utviklere eller kontraktutviklere har gitt deg en container som kjører kode som du stoler på. For applikasjoner i containere som har klarert kode i seg, anbefales og anbefales Windows Server-containere. Deling og projeksjon av operativsystemfiler bør ikke være et problem for klarert kode.
Men hva skjer når det er behov for litt mer sikkerhet, litt mer isolasjon, med mindre enn fullstendig klarert kode eller apper?
Hyper-V-containere
Det er når du begynner å se på Hyper-V-containere, som gifter seg med modellen for isolasjon og abstraksjon fra tradisjonelle virtuelle maskiner med fleksibilitet, bilde og enkle omplasseringsformater av Docker-stil Windows Server-containere, sammen med Docker API og administrasjonsverktøy som Jeg diskuterte i forrige avsnitt.
Mark Russinovich, CTO for Microsoft Azure, sa det slik i et blogginnlegg i fjor: Hyper-V-containere "isolerer applikasjoner med garantiene knyttet til tradisjonell virtualisering, men med den enkle, bildeformatet og administrasjonsmodellen til Windows Server Containers, inkludert støtten fra Docker Engine. " Forskjellen her er isolasjonsnivået: Hyper-V-containere deler ikke direkte operativsystemfiler, prosesser og tjenester med verten. Snarere pakker Windows Server hvert lite containerbilde i en virtuell maskin med veldig lav overhead, noe som oppnår grensen for abstraksjon og tillit som en Windows Server-container i Docker-stil ikke gjør.
Imidlertid er denne virtuelle maskinen, for all del, gjennomsiktig for administratoren. Containerbildene selv som kjører Windows Server forstår at de faktisk er containerbilder og ikke kjører på vanlig uhemmet silisium, og dermed er i stand til å dra nytte av optimaliseringer til operativsystemet som kommer fra den bevisstheten. Men selv om disse containerbildene er mer isolerte, distribueres de ikke annerledes enn Windows Server-containere. Du bruker fortsatt Docker APIer. Du bruker fortsatt Docker-klienten. Du merker bare av for en annen rute, men selve containerbildene er bygget og levert på samme måte uavhengig av hvilken isolasjonsmodell du vil bruke til å kjøre dem.
Ulempen med denne tilnærmingen: Det er mer overhead. På grunn av den ekstra isolasjonen dupliseres mer kode og prosesser. Det er også det faktum at selv om den lette virtuelle maskininnpakningen for en Hyper-V-container er liten, tilfører den faktisk en "avgift" til kostnadene ved å kjøre et containerbilde. Så mens du kan fylle en kraftig vert full av Docker-stil Windows Server-containere, vil Hyper-V-containere være begrenset til et bestemt mindre antall containere, alt annet er like maskinvaremessig.
Igjen, disse containerbildene støtter bare Windows Server. Selv om det er isolasjon, er det likevel felles fellesskap mellom containerbildene og vertsoperativsystemet. Så hvis containerbildene dine kjører Linux, en annen smak av Unix, BSD eller et annet alternativt operativsystem, vil ingen av disse nye Windows Server 2016-funksjonene ha betydning for deg.
Poenget: Tredjepartskode, markedskode eller kode som ellers ikke er helt klarert av noen del av organisasjonen din, skal kjøres i Hyper-V-containere. Dette er også det beste valget for offentlige skyer og andre lignende miljøer. Du mister bare kapasitet, og du får sikkerhetsfordelene ved å være mer isolert.
Docker-containere
Nå for å bevise at merkevarebygging alltid er den vanskeligste delen av enhver teknologi, la meg introdusere Docker-containere. Ovenfor nevnte jeg at Windows Server-containere er en del av Docker open source-prosjektet. Docker-containere er forskjellige fra Windows Server-containere. Windows Server-containere kan bruke all Docker-underliggende teknologi, men det eksisterende Docker-verktøysettet for å administrere Docker-containere fungerer ikke (i det minste i denne versjonen) med Windows Server-containere. Heller ikke Windows Server-verktøy for administrering av containere - på dette punktet, en haug med PowerShell-kommandoer - kan gjøre noe av verdi med Docker-containere selv.
Docker-containere er deres egen spesifikke ting, og mens Windows Server-containere fungerer som Docker-containere i deres evne til å dele, men isolere - det er derfor jeg har referert til dem som Docker-stil Windows Server-containere - de er ikke Docker-containere per se. Dette kan endre seg i fremtiden, spesielt i en oppdateringspakke eller neste utgivelse av Windows Server, men foreløpig forblir disse tre containertypene, selv om de alle kan være like, forskjellige konsepter. Bare to støttes for øyeblikket av Windows Server.
Hvor teknologien er i dag
Akkurat nå er containerstøtte i Windows Server 2016 veldig i gang. Det er mange bevegelige deler til containere: Fjerne avhengigheter av verts- og operativsystemfiler, og spesifikke versjoner og oppdateringsnivåer; å oppnå riktig isolasjon og sikre at ingen kode kan bryte grensen for sikkerhet og tillit; gjøre utviklerhistorien riktig med verktøy og automatisering som lar utviklere jobbe med containere i deres foretrukne integrerte utviklingsmiljø (IDE) og "eksportere" applikasjonene sine direkte til containeren; sørge for at containere kan bevege seg opp og ned i den offentlige skyen sømløst; og mer.
I alle disse tilfellene er det fortsatt fatale feil og feil å jobbe gjennom. Hvis containere er avgjørende for veikartet ditt for tjenestetilbud i butikken din, kan det være lurt å begynne å teste ut funksjonene til Windows Server-containere og Hyper-V-containere nå, og spesielt sjekke de tilgjengelige PowerShell-kommandoene for å aktivere containere og for å administrere dem. på en Windows Server 2016-vert.
Imidlertid, hvis containere er et fint alternativ, men ikke et must-have for organisasjonen din, så vil min informerte anbefaling være å holde ut med å prøve alt annet enn den mest rudimentære letingen ved hjelp av Technical Preview 4 bits. Det er fortsatt for mange vorter - inkludert de fatale feilene og feilene som er nevnt tidligere - for å virkelig få en sammenhengende følelse av hva som skjer.
Containerstøtte vil være et spennende tillegg til Windows-plattformen. Det er mye av den historien som gjenstår å bli skrevet og fortalt.
Denne historien, "Containers in Windows Server 2016: What you need to know" ble opprinnelig utgitt av Computerworld.
