Контейнери в Windows Server 2016: Какво трябва да знаете

В история, която написах за Computerworld през януари, която беше преглед на техническия преглед на Windows Server 2016 4, споменах новата поддръжка на Windows Server за Hyper-V контейнери, която беше добавена към нейната поддръжка за контейнери в стил Docker (присъства в рамките на бета версия продукт от предишната бета версия).

Наличието на две опции за контейнери обаче доведе до много въпроси. Каква е разликата между контейнер на Docker и нов контейнер Hyper-V? В кои сценарии бихте искали да използвате едно решение за контейнери над другото? Има ли отделни методи за разполагане на всеки от тях?

Microsoft не е свършила чудесна работа с документирането на тези две опции за контейнери, а самите контейнери са нови за платформата Windows Server. Като се имат предвид тези два фактора, искам да посветя цяла история на това, какви конкретни решения за контейнери Windows Server 2016 или предлага сега във вид на визуализация в наличните версии, или обещава да предостави преди датата на пускане на софтуера до производството (RTM), най-вероятно в втората половина на 2016г.

Общ преглед

Понастоящем в Windows Server 2016 има два типа контейнери: Windows Server контейнери и Hyper-V контейнери. И двете поддържат само Windows Server; нито може да смесва и съчетава Linux и / или Unix, например.

За мързеливи администратори като мен, нека махнем важния въпрос отпред: Дали един от двата типа контейнери е по-труден за разгръщане от другия? Отговорът е категорично не.

[Допълнително четене: Първи поглед: Стартирайте виртуални машини във виртуални машини с Hyper-V контейнери]

Типовете контейнери се изпълняват по различен начин и имат различни нива на изолация и доверие в хипервизора. Но в основата си това е решение за време на разгръщане, взето от собственика на физическата машина - собственика на хоста - за това кой тип контейнер ще бъде използван и е толкова просто, колкото да проверите правилния бутон в съветника . Просто избирате между двете по време на създаването. Решението засяга как Windows Server 2016 - самата операционна система (хипервизорът, седнал в дъното на всички тези неща, работещ върху силиций и физическо желязо) - изолира и изпълнява работните натоварвания във всеки контейнер.

Така че сега, след като знаете, че и двата варианта на контейнера са еднакво много работа за вас, как интелигентно да решите между двете? По същество се свежда до доверие: Ако имате доверие на кода, изпълняващ се в контейнера, тогава бихте избрали контейнер на Windows Server (четете: традиционен, в стил Docker). Ако нямате доверие на кода или не можете да го потвърдите, или той не е дошъл от вашите вътрешни разработчици във вашата собствена организация, тогава Hyper-V контейнерът е пътят. Нека разгледаме подробно всяка опция.

Windows Server контейнери

Контейнерите на Windows Server всъщност са само част от проекта за контейнери с отворен код на Docker, така че ако мислите за контейнер в стил Docker, ще мислите за контейнер на Windows Server. Тези контейнери са по същество нов тип виртуална машина, която по някакъв начин има по-малка изолация от традиционната виртуална машина - а именно защото в много случаи се споделят неща, общи за всички контейнери, работещи на хост. Сред тези споделени елементи са файлове на операционната система, директории и работещи услуги. Това се прави за по-голяма ефективност, защото ако използвате три различни контейнера на хост, всички с една и съща версия на Windows Server като гости, имате нужда от само едно копие на директорията C: \ Windows по всяко време.

Това споделяне все още отделя контейнери от всяко дадено приложение, което може да се изпълнява на хост, но също така намалява режийните разходи и прави контейнерите по-леки. Имате повече пространство за всеки сървър, работещ контейнери, поради това споделяне, за разлика от традиционните виртуални машини, които са по-изолирани и не споделят нищо - и по този начин са склонни да имат много повече дублиране. Обикновено бихте използвали и Windows Server контейнери, когато вашият хост и гост работят с една и съща операционна система, за да се възползват от това споделяне; в резултат на това не можете да стартирате контейнер с Ubuntu Server, работещ на хост на Windows Server 2016. (За този тип натоварване бихте използвали традиционни виртуални машини. Контейнерите не биха били подходящи за това. Просто бихте използвали виртуални машини, които се поддържат в Windows от 2008 г.)

За това, което си струва, в момента двете операционни системи с изображения на контейнери, поддържани от контейнери на Windows Server, са Server Core (Windows без графичния потребителски интерфейс) и Windows Nano Server, радикално реконструираният микросервър, подходящ за малки роли, ориентирани към микроуслуги. (Повече за микроуслугите след малко.)

И така, как Docker се вписва във всичко това? Docker предоставя "ниво на управление", на API и двигатели за управление на контейнери - такъв, който бързо се превърна в индустриален стандарт, много вероятно, защото самият Docker е с отворен код и широко използван. Docker Hub, достъпен за използване от всеки в Интернет, е истинско хранилище на приложения в стил пазар, което се изпълнява в контейнери в стил Docker.

Docker също така предоставя ментална рамка, която разработчиците могат да използват, за да се доближат до действителната работа на техния код и да изградят цели контейнери от средите, които техният код изисква да стартира. Разработчиците по същество изграждат образи на контейнери, които след това се прехвърлят към операции доста лесно и се изпълняват по същество като гости на този хост. Актуализациите и корекциите на кода могат да се обработват бързо и лесно по същия начин.

Всяко от тези изображения на контейнери може дори да работи върху много малка част от цялостното приложение, което композира решението и улеснява работата в среда, ориентирана към микроуслуги. От гледна точка на широката картина, работата с контейнери увеличава отговорността на разработчиците да пишат добър код, който работи точно в тяхната среда. Разработчиците вече не могат да пишат код, който работи перфектно на машините им за разработка, но пада при внедряване на производствен софтуер - тъй като те са едно и също, кодът трябва да работи и на двете места. Това също намалява триенето между операциите и ИТ - ИТ със своите девствени сървърни среди и разработчици, които очакват определени конфигурации, но често нямат способността или обосновката да променят производствената среда, за да отговарят на техните очаквания.

Тези контейнери на Windows Server в стил Docker предполагат някакво доверие - или че сте изтеглили доверено приложение от Docker Hub, или че вашите вътрешни разработчици или разработчици по договор са ви предоставили контейнер с работещ код, на който имате доверие. За приложения в контейнери, които имат надежден код в себе си, Windows Server контейнерите са препоръчителни и подходящи. Споделянето и прожектирането на файлове на операционната система не трябва да е проблем за надежден код.

Но какво се случва, когато има нужда от малко повече сигурност, малко повече изолация, с по-малко надежден код или приложения?

Контейнери Hyper-V

Тогава започвате да разглеждате Hyper-V контейнери, които се оженват за модела на изолация и абстракция от традиционните виртуални машини с гъвкавостта, образите и лесните формати за преразпределяне на контейнери за Windows Server в стил Docker, заедно с API на Docker и инструменти за управление, които Обсъдих в предишния раздел.

Марк Русинович, главен технически директор на Microsoft Azure, каза по този начин в запис в блог миналата година: Hyper-V контейнерите "изолират приложения с гаранциите, свързани с традиционната виртуализация, но с лекотата, формата на изображението и модела за управление на Windows Server Containers, включително подкрепата на Docker Engine. " Разликата тук е в нивото на изолация: Hyper-V контейнерите не споделят директно файлове, процеси и услуги на операционната система с хоста. По-скоро Windows Server обгръща всяко изображение на малък контейнер във виртуална машина с много ниски разходи, което постига границите на абстракция и доверие, които контейнерът на Windows Server в стил Docker не прави.

Тази виртуална машина обаче е прозрачна за администратора за всички намерения и цели. Самите изображения на контейнери, които изпълняват Windows Server, разбират, че всъщност са изображения на контейнери и не се изпълняват на обикновен неограничен силиций, и по този начин са в състояние да се възползват от оптимизациите на операционната система, които идват от това осъзнаване. Но въпреки че тези изображения на контейнери са по-изолирани, те не са разположени по различен начин от контейнерите на Windows Server. Все още използвате API на Docker. Все още използвате клиента на Docker. Просто поставяте отметка в различно квадратче, но самите изображения на контейнера се изграждат и доставят по един и същи начин, независимо кой изолационен модел искате да използвате, за да ги изпълните.

Недостатъкът на този подход: има повече режийни. Поради допълнителната изолация се дублират повече код и процеси. Съществува и фактът, че макар леката обвивка на виртуална машина за контейнер Hyper-V да е малка, тя наистина добавя "данък" към разходите за стартиране на изображение на контейнер. Така че, докато можете да напълните мощен хост, пълен с контейнери за Windows Server в стил Docker, контейнерите Hyper-V ще бъдат ограничени до определен по-малък брой контейнери, като всички останали са еднакво хардуерно.

Отново, тези изображения на контейнери биха поддържали само Windows Server. Въпреки че има изолация, все още има общо между изображенията на контейнера и операционната система на хоста. Така че, ако вашите изображения на контейнери работят с Linux, друг вкус на Unix, BSD или друга алтернативна операционна система, никоя от тези нови функции на Windows Server 2016 няма да има значение за вас.

Долният ред: Код на трета страна, код на пазара или код, който иначе не е напълно доверен от която и да е част от вашата организация, трябва да се изпълнява в контейнери Hyper-V. Това са и най-добрият избор за многобройни публични облаци и други подобни среди. Не губите нищо освен капацитет и получавате ползите за сигурността, като сте по-изолирани.

Докер контейнери

Сега, за да докажа, че брандирането винаги е най-трудната част от всяка технология, позволете ми да представя контейнери на Docker. По-горе споменах, че контейнерите на Windows Server са част от проекта с отворен код на Docker. Контейнерите на Docker се различават от контейнерите на Windows Server. Контейнерите на Windows Server могат да използват цялата основна технология на Docker, но съществуващият набор от инструменти на Docker за управление на контейнери на Docker не работи (поне в тази версия) с контейнери на Windows Server. Нито пък инструментите за управление на контейнери на Windows Server - в този момент куп команди PowerShell - могат да направят нещо ценно със самите контейнери на Docker.

Контейнерите на Docker са тяхно специфично нещо и докато контейнерите на Windows Server действат като контейнери на Docker в способността си да споделят, но изолират - поради което ги наричам контейнери на Windows Server в стил Docker - те сами по себе си не са контейнери на Docker . Това може да се промени в бъдеще, особено в сервизен пакет или следващата версия на Windows Server, но засега тези три типа контейнери, въпреки че всички те могат да си приличат, остават различни концепции. Понастоящем само два се поддържат от Windows Server.

Къде е технологията днес

В момента поддръжката на контейнери в Windows Server 2016 е много в процес на работа. Има много движещи се части в контейнери: Премахване на зависимости от хост и файлове на операционната система, както и конкретни версии и нива на кръпка; постигане на правилната изолация и гарантиране, че нито един код не може да наруши тази граница на сигурност и доверие; оправяне на историята на разработчиците с инструменти и автоматизация, които позволяват на разработчиците да работят с контейнери в предпочитаната интегрирана среда за разработка (IDE) и да „експортират“ своите приложения директно в контейнера; гарантиране, че контейнерите могат да се движат безпроблемно нагоре и надолу в публичния облак; и още.

Във всички тези случаи все още има фатални грешки и грешки, с които да се работи. Ако контейнерите са от решаващо значение за вашата пътна карта на предлаганите услуги в магазина ви, тогава може да започнете да тествате възможностите на Windows Server контейнери и Hyper-V контейнери сега и особено да проверите наличните команди PowerShell, за да активирате контейнери и да ги управлявате на хост на Windows Server 2016.

Ако обаче контейнерите са добра опция, но не са задължителни за вашата организация, тогава моята информирана препоръка ще бъде да спрете да правите каквото и да било, освен най-елементарното проучване, използвайки Технически преглед 4 бита. Все още има твърде много брадавици - включително онези фатални грешки и грешки, споменати по-рано - за да получите наистина сплотено усещане за случващото се.

Поддръжката на контейнери ще бъде вълнуващо допълнение към платформата Windows. Има много от тази история, която остава да бъде написана и разказана.

Тази история „Контейнери в Windows Server 2016: Какво трябва да знаете“ първоначално е публикувана от Computerworld.