Istorijoje, kuriai parašiau Kompiuterių pasaulis sausio mėnesį, kai buvo peržiūrėta „Windows Server 2016“ techninė peržiūra 4, paminėjau naują „Windows Server“ palaikymą „Hyper-V“ talpykloms, kuris buvo pridėtas prie „Docker“ stiliaus talpyklų palaikymo (esančių beta produkte nuo ankstesnio beta versijos leidimo) ).
Tačiau dėl dviejų konteinerių variantų kilo daug klausimų. Kuo skiriasi „Docker“ konteineris nuo naujo „Hyper-V“ konteinerio? Kuriais atvejais norėtumėte naudoti vieną sudėtinio rodinio sprendimą, o ne kitą? Ar yra atskiri kiekvieno iš jų diegimo metodai?
„Microsoft“ nepadarė didelio darbo užfiksuodama šias dvi talpyklų parinktis ir patys konteineriai yra naujiena „Windows Server“ platformoje. Atsižvelgdamas į šiuos du veiksnius, noriu skirti visą istoriją apie tai, kokius konkrečius konteinerių sprendimus „Windows Server 2016“ dabar pateikia peržiūros forma esamuose leidimuose, arba žada pateikti iki programinės įrangos išleidimo į gamybos (RTM) datą, greičiausiai antrosios pusės 2016 m.
Apžvalga
Šiuo metu „Windows Server 2016“ yra dviejų tipų sudėtiniai rodiniai: „Windows Server“ ir „Hyper-V“ sudėtiniai rodiniai. Abi palaiko tik „Windows Server“; taip pat negali derinti ir derinti, pavyzdžiui, „Linux“ ir (arba) „Unix“.
Tingiems administratoriams, tokiems kaip aš, leiskite mums iš anksto paimti svarbų klausimą: ar vieną iš dviejų konteinerių tipų yra sunkiau pritaikyti nei kitus? Atsakymas yra pabrėžtinas ne.
[Tolesnis skaitymas: Pirmoji išvaizda: paleiskite VM VM su „Hyper-V“ konteineriais]
Konteinerių tipai nevienodai vykdomi, jų hipervizorius izoliuoja ir pasitiki skirtingai. Tačiau iš esmės tai yra diegimo laiko sprendimas, kurį fizinės mašinos savininkas - pagrindinio kompiuterio savininkas - priima dėl to, kokio tipo konteineriai bus naudojami, ir tai yra taip paprasta, kaip patikrinti teisingą vedlio radijo mygtuką. . Kūrimo metu paprasčiausiai renkatės tarp dviejų. Šis sprendimas turi įtakos tam, kaip „Windows Server 2016“ - pati operacinė sistema (hipervizorius, sėdintis visų šių daiktų apačioje, veikiantis siliciu ir fizine geležimi) - izoliuoja ir vykdo kiekvieno konteinerio darbo krūvius.
Taigi dabar, kai žinote, kad bet kuris konteinerio variantas jums yra toks pats darbas, kaip protingai apsispręsti tarp judviejų? Iš esmės tai susiję su pasitikėjimu: jei pasitikite kodu, veikiančiu sudėtiniame rodinyje, pasirinktumėte „Windows Server“ (skaitykite: tradicinis, „Docker“ stiliaus) konteinerį. Jei nepasitikite kodu arba negalite jo patvirtinti, arba jei jis atsirado ne iš jūsų vidinių kūrėjų jūsų pačių organizacijoje, tai „Hyper-V“ konteineris yra kelias. Pažvelkime į kiekvieną variantą išsamiai.
„Windows Server“ sudėtiniai rodiniai
„Windows Server“ konteineriai iš tikrųjų yra tik „Docker“ atvirojo kodo konteinerių projekto dalis, taigi, jei galvojate apie „Docker“ stiliaus talpyklą, galvosite apie „Windows Server“ konteinerį. Šie konteineriai iš esmės yra naujo tipo virtuali mašina, kuri tam tikrais būdais yra mažiau izoliuota nei tradicinė virtuali mašina, būtent todėl, kad daugeliu atvejų visiems visiems pagrindiniame kompiuteryje veikiantiems konteineriams yra bendri dalykai. Tarp šių bendrinamų elementų yra operacinės sistemos failai, katalogai ir vykdomos paslaugos. Tai daroma siekiant didesnio efektyvumo, nes jei pagrindiniame kompiuteryje naudojate tris skirtingus sudėtinius rodinius su visais, turinčiais tą pačią „Windows Server“ versiją kaip svečiai, jums bet kuriuo metu reikia tik vienos katalogo „C: \ Windows“ kopijos.
Šis bendrinimas vis dar atskiria konteinerius nuo bet kurios programos, kuri gali veikti pagrindiniame kompiuteryje, tačiau taip pat sumažėja pridėtinės išlaidos ir konteineriai tampa lengvesni. Turite daugiau vietos vienam serveriui, kuriame veikia konteineriai dėl šio bendrinimo, o ne tradicinių virtualių mašinų, kurios yra labiau izoliuotos ir nieko nesidalija, vadinasi, yra daug daugiau dubliavimosi. Jūs taip pat paprastai naudosite „Windows Server“ sudėtinius rodinius, kai visi pagrindiniai kompiuteriai ir svečiai naudoja tą pačią operacinę sistemą, kad galėtų pasinaudoti šiuo bendrinimu; todėl negalite paleisti konteinerio su „Ubuntu Server“, veikiančiu „Windows Server 2016“ pagrindiniame kompiuteryje. (Tokio tipo darbo krūviui turėtumėte naudoti tradicines virtualias mašinas. Konteineriai tam netinka. Tiesiog naudokite VM, kuriuos „Windows“ palaiko nuo 2008 m.)
Dėl ko verta, šiuo metu dvi „Windows Server“ talpyklų palaikomos talpyklinio vaizdo operacinės sistemos yra „Server Core“ („Windows“ be jos grafinės vartotojo sąsajos) ir „Windows Nano Server“ - radikaliai pertvarkytas mikropaklauslis, tinkantis mažoms į mikropaslaugas orientuotoms funkcijoms. (Daugiau apie mikropaslaugas.)
Taigi, kaip „Docker“ telpa į visa tai? Jei norite, „Docker“ teikia API ir variklių, skirtų konteineriams tvarkyti, valdymo sluoksnį - tokį, kuris greitai tapo pramonės standartu, greičiausiai todėl, kad pats „Docker“ yra atviro kodo ir plačiai naudojamas. „Docker Hub“, kurį gali naudoti visi internete, yra tikra „Marketplace“ stiliaus programų, kurios visos veikia „Docker“ stiliaus talpyklose, saugykla.
„Docker“ taip pat pateikia mentalinę sistemą, kurią kūrėjai gali naudoti, kad priartėtų prie faktinio savo kodo veikimo ir sukonstruotų ištisus konteinerius aplinkos, kuriai reikia jų kodo paleisti. Kūrėjai iš esmės kuria talpyklų vaizdus, kurie tada gana lengvai perduodami operacijoms, ir paleidžiami iš esmės tokie, kokie yra svečiai tame šeimininke. Atnaujinimus ir kodo taisymus galima greitai ir lengvai tvarkyti tuo pačiu būdu.
Kiekvienas iš šių talpyklų vaizdų gali veikti net labai mažoje visos programos dalyje, kuri sudaro komponentą ir palengvina darbą į mikropaslaugas orientuotoje aplinkoje. Žiūrint iš bendro požiūrio, darbas su konteineriais padidina kūrėjų atskaitomybę rašyti gerą kodą, kuris veikia tiksliai jų aplinkoje. Kūrėjai nebegali rašyti kodo, puikiai veikiančio jų kūrimo mašinose, bet nukrentančio juos įdiegus gamybos programinėje įrangoje - kadangi jie yra tas pats, kodas turi veikti abiejose vietose. Tai taip pat sumažina trintį tarp operacijų ir IT - IT su savo nesugadinta serverio aplinka ir kūrėjais, kurie tikisi tam tikrų konfigūracijų, tačiau dažnai neturi galimybių ar pagrindo pakeisti gamybos aplinką, kad atitiktų jų lūkesčius.
Šie „Docker“ stiliaus „Windows Server“ sudėtiniai rodikliai reiškia tam tikrą pasitikėjimą - arba tai, kad atsisiuntėte patikimą programą iš „Docker Hub“, arba tai, kad jūsų vidiniai kūrėjai ar sutarčių kūrėjai pateikė jums konteinerio, kuriame veikia patikimas kodas. Programoms sudėtiniuose rodiniuose, kuriuose yra patikimas kodas, rekomenduojami ir tinkami „Windows Server“ sudėtiniai rodiniai. Operacinės sistemos failų bendrinimas ir projektavimas neturėtų būti patikimo kodo problema.
Bet kas nutinka, kai reikia šiek tiek daugiau saugumo, šiek tiek daugiau izoliacijos, naudojant mažiau nei visiškai patikimą kodą ar programas?
„Hyper-V“ konteineriai
Tai yra tada, kai pradedate žiūrėti į „Hyper-V“ talpyklas, kurios susituokia su tradicinių virtualių mašinų izoliacijos ir abstrakcijos modeliu, naudojant „Docker“ stiliaus „Windows Server“ talpyklų lankstumą, vaizdą ir lengvą perkėlimo formatą, taip pat „Docker“ API ir valdymo įrankius, kurie Aptariau ankstesniame skyriuje.
Markas Russinovičius, „Microsoft Azure“ CTO, pernai parašė savo tinklaraščio įrašą taip: „Hyper-V“ konteineriai „išskiria programas su garantijomis, susijusiomis su tradicine virtualizacija, tačiau naudodamiesi„ Windows Server Containers “patogumu, vaizdų formatu ir valdymo modeliu, įskaitant: „Docker Engine“ palaikymas “. Čia skiriasi izoliacijos lygis: „Hyper-V“ konteineriai tiesiogiai nesidalija operacinės sistemos failais, procesais ir paslaugomis su pagrindiniu kompiuteriu. Atvirkščiai, „Windows Server“ kiekvieną mažą konteinerio vaizdą suvynioja į labai mažą pridėtinę virtualią mašiną, kuri pasiekia abstrakcijos ir pasitikėjimo ribą, kurios ne „Docker“ stiliaus „Windows Server“ konteineris.
Tačiau ši virtuali mašina administratoriui yra skaidri ir neskaidri. Patys konteinerių vaizdai, kuriuose veikia „Windows Server“, supranta, kad iš tikrųjų jie yra konteinerių vaizdai ir neveikia naudojant įprastą nevaržomą silicį, todėl gali pasinaudoti OS optimizavimu, kuris gaunamas iš šio supratimo. Nors šie talpyklų vaizdai yra labiau izoliuoti, jie nėra išdėstyti kitaip nei „Windows Server“ sudėtiniai rodiniai. Jūs vis dar naudojate „Docker“ API. Jūs vis dar naudojate „Docker“ klientą. Jūs tiesiog pažymite kitą laukelį, tačiau patys konteinerio vaizdai yra kuriami ir pateikiami tuo pačiu būdu, neatsižvelgiant į tai, kurį izoliacijos modelį norite naudoti jiems paleisti.
Šio požiūrio trūkumas: yra daugiau pridėtinių išlaidų. Dėl papildomos izoliacijos daugiau kodų ir procesų yra dubliuojami. Taip pat yra tai, kad, nors „Hyper-V“ konteineriui skirtas lengvas virtualių mašinų įvyniojimas yra nedidelis, jis iš tikrųjų prideda „mokestį“ prie konteinerio atvaizdo paleidimo išlaidų. Taigi, nors jūs galite įdaryti galingą pagrindinį kompiuterį, kuriame yra daug „Docker“ stiliaus „Windows Server“ konteinerių, „Hyper-V“ konteineriai būtų apriboti tam tikru mažesniu konteinerių skaičiumi, visa kita būtų vienoda aparatine prasme.
Vėlgi, šie talpyklų vaizdai palaikytų tik „Windows Server“. Nors yra izoliacija, vis dar yra bendras konteinerio vaizdų ir pagrindinės kompiuterio operacinės sistemos bendrumas. Taigi, jei jūsų konteinerio vaizduose veikia „Linux“, kitas „Unix“, BSD ar kitos alternatyvios operacinės sistemos skonis, nė viena iš šių naujų „Windows Server 2016“ funkcijų jums nebus svarbi.
Apatinė eilutė: trečiosios šalies kodas, prekyvietės kodas arba kodas, kuriuo kitu atveju visiškai nepasitiki jokia jūsų organizacijos dalis, turėtų būti paleisti „Hyper-V“ konteineriuose. Tai taip pat yra geriausias pasirinkimas daugialypiams viešiesiems debesims ir kitoms panašioms aplinkoms. Jūs neprarandate nieko kito, tik pajėgumų ir gaunate daugiau saugumo privalumų, nes esate labiau izoliuotas.
Docker konteineriai
Dabar norėdamas įrodyti, kad prekės ženklo naudojimas yra sunkiausia bet kurios technologijos dalis, leiskite man pristatyti „Docker“ konteinerius. Pirmiau minėjau, kad „Windows Server“ konteineriai yra „Docker“ atvirojo kodo projekto dalis. „Docker“ talpyklos skiriasi nuo „Windows Server“ talpyklų. „Windows Server“ sudėtiniuose rodiniuose gali būti naudojama visa pagrindinė „Docker“ technologija, tačiau esamas „Docker“ įrankių rinkinys, skirtas „Docker“ talpykloms tvarkyti, neveikia (bent jau šiame leidime) su „Windows Server“ sudėtiniais rodiniais. „Windows Server“ konteinerių valdymo įrankiai - šiuo metu krūva „PowerShell“ komandų - taip pat negali padaryti nieko vertingo su pačiais „Docker“ konteineriais.
„Docker“ konteineriai yra jų pačių konkretus dalykas, o „Windows Server“ konteineriai veikia kaip „Docker“ konteineriai, nes jie gali dalintis, bet izoliuoti, todėl aš juos vadinau „Docker“.stiliaus „Windows Server“ konteineriai - tai nėra „Docker“ konteineriai per se. Tai gali pasikeisti ateityje, ypač pakeitimų pakete ar kitame „Windows Server“ leidime, tačiau kol kas šie trys sudėtinių rodinių tipai, nors ir visi gali būti panašūs, išlieka skirtingos sąvokos. Šiuo metu „Windows Server“ palaiko tik du.
Kur šiandien yra technologija
Šiuo metu „Windows Server 2016“ talpyklų palaikymas yra labai nebaigtas darbas. Į konteinerius yra daug judančių dalių: pašalinama priklausomybė nuo pagrindinės ir operacinės sistemos failų bei konkrečių versijų ir pataisų lygių; tinkama izoliacija ir užtikrinimas, kad nėra jokio kodo, gali pažeisti tą saugumo ir pasitikėjimo ribą; tobulinti kūrėjo istoriją naudojant įrankius ir automatiką, leidžiančius kūrėjams dirbti su konteineriais jų pageidaujamoje integruotoje kūrimo aplinkoje (IDE) ir „eksportuoti“ savo programas tiesiai į konteinerį; užtikrinti, kad konteineriai galėtų sklandžiai judėti aukštyn ir žemyn į viešąjį debesį; ir dar.
Visais šiais atvejais vis dar yra lemtingų klaidų ir klaidų, kurias reikia pašalinti. Jei konteineriai yra labai svarbūs planuojant paslaugų pasiūlą parduotuvėje, galite pradėti išbandyti „Windows Server“ konteinerių ir „Hyper-V“ konteinerių galimybes jau dabar, ypač patikrinkite galimas „PowerShell“ komandas, kad įgalintumėte konteinerius ir juos tvarkytumėte „Windows Server 2016“ pagrindiniame kompiuteryje.
Tačiau, jei konteineriai yra puikus pasirinkimas, bet jūsų organizacijai jų neprivaloma turėti, mano informuota rekomendacija būtų susilaikyti nuo bandymų, išskyrus pačius elementariausius tyrimus, naudojant 4 techninės peržiūros bitus. Karpų vis dar yra per daug, įskaitant tas mirtinas klaidas ir klaidas, kurios buvo minėtos anksčiau, kad iš tikrųjų suprastumėte, kas vyksta.
Konteinerių palaikymas bus įdomus „Windows“ platformos papildymas. Tą istoriją liko daug parašyti ir papasakoti.
Šią istoriją „Konteineriai„ Windows Server 2016 “: ką reikia žinoti“ iš pradžių paskelbė „Computerworld“.
