Stāstā, par kuru es rakstīju Datoru pasaule janvārī, kas bija Windows Server 2016 tehniskā priekšskatījuma 4 pārskats, es pieminēju jauno Windows servera atbalstu Hyper-V konteineriem, kas tika pievienots tā atbalstam Docker stila konteineriem (kas atrodas beta produktā kopš iepriekšējās beta versijas izlaišanas) ).
Tomēr divu konteineru iespēju klātbūtne ir radījusi daudz jautājumu. Kāda ir atšķirība starp Docker konteineru un jaunu Hyper-V konteineru? Kādos gadījumos jūs vēlaties izmantot vienu konteinera risinājumu virs otra? Vai ir atsevišķas metodes, kā izvietot katru no šiem?
Microsoft nav paveicis lielisku darbu, dokumentējot šīs divas konteineru opcijas, un paši konteineri ir jauni Windows Server platformā. Ņemot vērā šos divus faktorus, es vēlos veltīt visu stāstu par to, kādus konkrētus konteineru risinājumus Windows Server 2016 vai nu piedāvā priekšskatījuma formā pieejamajos laidienos, vai arī sola sniegt pirms programmatūras izlaišanas līdz ražošanas (RTM) datumam, visticamāk, 2016. gada otrajā pusē.
Pārskats
Pašlaik sistēmā Windows Server 2016 ir divu veidu konteineri: Windows Server konteineri un Hyper-V konteineri. Abi atbalsta tikai Windows Server; tāpat nevar sajaukt un saskaņot, piemēram, Linux un / vai Unix.
Tādiem slinkiem administratoriem kā es ļaujiet mums paņemt priekšā svarīgo jautājumu: vai vienu no diviem konteineru veidiem ir grūtāk izvietot nekā otru? Atbilde ir uzsvērta nē.
[Papildu lasījums: Pirmais skatījums: VM palaišana VM ar Hyper-V konteineriem]
Konteineru veidi tiek izpildīti atšķirīgi, un tiem ir atšķirīgs izolācijas līmenis un uzticēšanās hipervizoram. Bet būtībā tas ir izvietošanas laika lēmums, ko fiziskās mašīnas īpašnieks - resursdatora īpašnieks - pieņem par to, kāda veida konteineri tiks izmantoti, un tas ir tikpat vienkārši, kā pārbaudīt pareizo vedņa pogu . Izveides laikā jūs vienkārši izvēlaties starp abiem. Lēmums ietekmē to, kā Windows Server 2016 - pati operētājsistēma (hipervizors, kas sēž visu šo lietu apakšā, darbojas ar silīciju un fizisko dzelzi) - izolē un izpilda katra konteinera darba slodzes.
Tātad, tagad, kad zināt, ka jebkura no konteinera iespējām jums ir vienāds darbs, kā jūs saprātīgi izlemjat starp abiem? Būtībā tas attiecas uz uzticēšanos: ja jūs uzticaties kodam, kas darbojas konteinerā, jūs izvēlaties Windows Server (lasīt: tradicionālo, Docker stila) konteineru. Ja jūs neuzticaties kodam vai nevarat to pārbaudīt, vai arī tas nenāca no iekšējiem izstrādātājiem jūsu pašu organizācijā, tad pareizais ceļš ir Hyper-V konteiners. Apskatīsim katru variantu detalizēti.
Windows Server konteineri
Windows Server konteineri faktiski ir tikai daļa no Docker atvērtā koda konteineru projekta, tāpēc, ja domājat par Docker stila konteineru, jūs domājat par Windows Server konteineru. Šie konteineri būtībā ir jauna veida virtuālā mašīna, kurai dažos veidos ir mazāka izolācija nekā tradicionālajai virtuālajai mašīnai - proti, tāpēc, ka daudzos gadījumos visiem kopīgajiem visiem konteineriem, kas darbojas resursdatorā, ir kopīgas lietas. Starp šiem kopīgotajiem vienumiem ir operētājsistēmas faili, direktoriji un palaišanas pakalpojumi. Tas tiek darīts, lai panāktu lielāku efektivitāti, jo, ja resursdatorā palaižat trīs dažādus konteinerus, kuriem visiem viesiem ir viena un tā pati Windows Server versija, jums jebkurā brīdī ir nepieciešama tikai viena direktorija C: \ Windows kopija.
Šī koplietošana joprojām atdala konteinerus no jebkuras lietojumprogrammas, kas varētu darboties resursdatorā, taču tas arī samazina pieskaitāmās izmaksas un padara konteinerus vieglākus. Šīs koplietošanas dēļ jums ir vairāk vietas vienā serverī, kurā darbojas konteineri, atšķirībā no tradicionālo virtuālo mašīnu palaišanas, kuras ir izolētākas un neko nedala - un tādējādi tām parasti ir daudz vairāk dublēšanās. Jūs arī parasti izmantojat Windows Server konteinerus, kad visi jūsu resursdators un viesis darbojas vienā operētājsistēmā, lai izmantotu šīs koplietošanas priekšrocības; Rezultātā jūs nevarat palaist konteineru ar Ubuntu Server, kas darbojas Windows Server 2016 resursdatorā. (Šāda veida slodzei jūs izmantojat tradicionālās virtuālās mašīnas. Konteineri tam nebūtu piemēroti. Jūs vienkārši izmantojat VM, kuras Windows atbalsta kopš 2008. gada.)
Kas ir tā vērts, šobrīd abas konteinera attēla operētājsistēmas, kuras atbalsta Windows Server konteineri, ir Server Core (Windows bez tā grafiskā lietotāja saskarnes) un Windows Nano Server, radikāli pārstrādāts mikroserveris, kas piemērots mazām uz mikropakalpojumiem orientētām lomām. (Vairāk par mikropakalpojumiem.)
Tātad, kā Dokers iekļaujas šajā visā? Ja vēlaties, Docker nodrošina API un dzinēju "pārvaldības slāni" konteineru pārvaldībai - tādu, kas ātri ir kļuvis par nozares standartu, iespējams, tāpēc, ka pats Docker ir atvērtā koda un plaši izmantots. Docker centrmezgls, kuru ikviens var izmantot internetā, ir īsts tirgus laukuma stila lietojumprogrammu krātuve, kas visas darbojas Docker stila konteineros.
Docker nodrošina arī mentālo ietvaru, kuru izstrādātāji var izmantot, lai tuvotos sava koda faktiskajai darbībai un izveidotu veselus konteinerus vidēs, kuru darbībai nepieciešams kods. Izstrādātāji būtībā izveido konteineru attēlus, kurus pēc tam diezgan viegli pārsūta uz darbībām, un tos palaiž kā tādus, kādi viņi ir viesos šajā resursdatorā. Atjauninājumus un koda labojumus var ātri un ērti apstrādāt vienādi.
Katrs no šiem konteinera attēliem var pat darboties ļoti mazā kopējā lietojuma daļā, kas komponē risinājumu un atvieglo darbu uz mikropakalpojumiem orientētā vidē. Raugoties no liela attēla viedokļa, darbs ar konteineriem palielina izstrādātāju atbildību rakstīt labu kodu, kas darbojas tieši viņu vidē. Izstrādātāji vairs nevar rakstīt kodu, kas perfekti darbojas viņu izstrādes mašīnās, bet nokrīt, kad tos izvieto ražošanas programmatūrā - tā kā viņi ir viens un tas pats, kodam ir jādarbojas abās vietās. Tas arī samazina berzi starp operācijām un IT - IT ar neskartajām serveru vidēm un izstrādātājiem, kuri sagaida noteiktas konfigurācijas, bet bieži trūkst iespēju vai pamatojuma mainīt ražošanas vidi, lai tas atbilstu viņu cerībām.
Šie Docker stila Windows Server konteineri nozīmē zināmu uzticamību - vai nu esat lejupielādējis uzticamu lietojumprogrammu no Docker Hub, vai arī jūsu iekšējie izstrādātāji vai līgumu izstrādātāji jums ir piegādājuši uzticamu konteinera darbības kodu. Lietotnēm konteineros, kuros ir uzticams kods, ieteicams un piemēroti ir Windows Server konteineri. Uzticama koda problēma nedrīkst būt operētājsistēmas failu koplietošana un projicēšana.
Bet kas notiek, ja ir nepieciešama nedaudz lielāka drošība, nedaudz lielāka izolācija, izmantojot mazāk uzticamu kodu vai lietotnes?
Hyper-V konteineri
Tas ir tad, kad jūs sākat apskatīt Hyper-V konteinerus, kas apprecas ar tradicionālo virtuālo mašīnu izolācijas un abstrakcijas modeli, izmantojot Docker stila Windows Server konteineru elastību, attēlu un ērtus pārdales formātus, kā arī Docker API un pārvaldības rīkus, kas Es apspriedu iepriekšējā sadaļā.
Marks Russinovičs, Microsoft Azure CTO, pagājušā gada emuāra ierakstā izteicās šādi: Hyper-V konteineri "izolē lietojumprogrammas ar garantijām, kas saistītas ar tradicionālo virtualizāciju, bet ar Windows Server Containers vieglumu, attēlu formātu un pārvaldības modeli, ieskaitot Docker Engine atbalstu. " Atšķirība šeit ir izolācijas līmenis: Hyper-V konteineri tieši nedala operētājsistēmas failus, procesus un pakalpojumus ar resursdatoru. Drīzāk Windows Server aptin katru mazo konteinera attēlu ļoti zemā virtuālajā mašīnā, kas nodrošina abstrakcijas un uzticības robežu, kāda nav Docker stila Windows Server konteineram.
Tomēr šī virtuālā mašīna administratoram ir pilnīgi pārskatāma. Paši konteineru attēli, kuros darbojas sistēma Windows Server, saprot, ka faktiski tie ir konteinera attēli un nedarbojas ar parastu neierobežotu silīciju, un tādējādi viņi var izmantot OS optimizācijas priekšrocības, kas rodas no šīs izpratnes. Lai gan šie konteineru attēli ir vairāk izolēti, tie netiek izvietoti citādi nekā Windows Server konteineri. Jūs joprojām izmantojat Docker API. Jūs joprojām izmantojat Docker klientu. Jūs vienkārši atzīmējat citu izvēles rūtiņu, bet paši konteinera attēli tiek veidoti un piegādāti vienādi neatkarīgi no tā, kuru izolācijas modeli vēlaties izmantot, lai tos palaistu.
Šīs pieejas negatīvie aspekti: ir vairāk papildu izmaksu. Papildu izolācijas dēļ vairāk kodu un procesu tiek dublēti. Ir arī fakts, ka, kaut arī Hyper-V konteinera vieglais virtuālās mašīnas iesaiņojums ir mazs, tas patiešām pievieno "nodokli" konteinera attēla palaišanas izmaksām. Tātad, lai arī jūs varat aizpildīt jaudīgu resursdatoru, kas pilns ar Docker stila Windows Server konteineriem, Hyper-V konteineri būtu ierobežoti ar noteiktu mazāku konteineru skaitu, visi pārējie būtu vienādi aparatūras ziņā.
Arī šie konteinera attēli atbalstīs tikai Windows Server. Lai gan pastāv izolācija, konteinera attēlos un resursdatora operētājsistēmā joprojām ir kopīga. Tātad, ja jūsu konteinera attēlos darbojas Linux, cits Unix, BSD vai jebkuras citas alternatīvas operētājsistēmas aromāts, neviena no šīm jaunajām Windows Server 2016 funkcijām jums nebūs svarīga.
Apakšējā līnija: trešās puses kods, tirgus laukuma kods vai kods, kam citādi neuzticas neviena jūsu organizācijas daļa, būtu jādarbina Hyper-V konteineros. Šīs ir arī labākā izvēle daudzdimensiju publiskiem mākoņiem un citās līdzīgās vidēs. Jūs nezaudējat neko citu kā tikai spēju un iegūstat drošības priekšrocības, ja esat izolētāks.
Dokeru konteineri
Tagad, lai pierādītu, ka zīmola veidošana vienmēr ir vissarežģītākā tehnoloģija, ļaujiet man iepazīstināt ar Docker konteineriem. Iepriekš es minēju, ka Windows Server konteineri ir daļa no Docker atvērtā pirmkoda projekta. Docker konteineri atšķiras no Windows Server konteineriem. Windows Server konteineros var izmantot visu Docker pamatā esošo tehnoloģiju, taču esošais Docker rīkkopa Docker konteineru pārvaldībai nedarbojas (vismaz šajā laidienā) ar Windows Server konteineriem. Tāpat Windows Server konteineru pārvaldības rīki - šajā brīdī virkne PowerShell komandu - neko pašu vērtīgu nevar paveikt ar pašiem Docker konteineriem.
Docker konteineri ir viņu pašu īpašā lieta, un, lai gan Windows Server konteineri darbojas kā Docker konteineri, spējot tos koplietot, bet izolēt - tāpēc es tos saucu par Docker-stils Windows Server konteineri - tie paši par sevi nav Docker konteineri. Tas var mainīties nākotnē, it īpaši servisa pakotnē vai nākamajā Windows Server laidienā, taču pagaidām šie trīs konteineru veidi, kaut arī tie visi var būt līdzīgi, joprojām ir atšķirīgi jēdzieni. Pašlaik Windows Server atbalsta tikai divus.
Kur tehnoloģija ir šodien
Pašlaik konteineru atbalsts sistēmā Windows Server 2016 ir ļoti gatavs darbs. Konteineros ir daudz kustīgu daļu: atkarību noņemšana no resursdatora un operētājsistēmas failiem, kā arī īpašas versijas un ielāpu līmeņi; pareizas izolācijas panākšana un koda nodrošināšana nevar pārkāpt šo drošības un uzticības robežu; izstrādāt izstrādātāja stāstu pareizi ar rīkiem un automatizāciju, kas ļauj izstrādātājiem strādāt ar konteineriem vēlamajā integrētajā izstrādes vidē (IDE) un "eksportēt" savas lietojumprogrammas tieši uz konteineru; pārliecinoties, ka konteineri var nemanāmi pārvietoties augšup un lejup publiskajā mākonī; un vēl.
Visos šajos gadījumos joprojām ir jāizdara liktenīgas kļūdas un kļūdas. Ja konteineriem ir izšķiroša nozīme pakalpojumu sniegšanas ceļvedī jūsu veikalā, iespējams, vēlēsities sākt pārbaudīt Windows Server konteineru un Hyper-V konteineru iespējas jau tagad, īpaši pārbaudot pieejamās PowerShell komandas, lai iespējotu konteinerus un tos pārvaldītu Windows Server 2016 resursdatorā.
Tomēr, ja konteineri ir jauka iespēja, bet jūsu organizācijai tas nav obligāti nepieciešams, tad mans informētais ieteikums būtu apturēt mēģinājumus kaut ko darīt, izņemot visbūtiskāko izpēti, izmantojot 4 tehniskā priekšskatījuma bitus. Kārpu joprojām ir pārāk daudz - ieskaitot iepriekš minētās liktenīgās kļūdas un kļūdas -, lai patiešām saprastu notiekošo vienoti.
Konteineru atbalsts būs aizraujošs papildinājums Windows platformai. Šis stāsts vēl ir daudz uzrakstāms un izstāstāms.
Šo stāstu “Konteineri sistēmā Windows Server 2016: kas jums jāzina” sākotnēji publicēja kompānija Computerworld.
