Контейнеры и Windows. От Hello World до Kubernetes. Часть первая, вводная

Когда я разговариваю с Linux инженерами и говорю им о проблемах Kubernetes кластера на Windows, на меня смотрят очень подозрительно. Некоторые даже не верят что это законно такое бывает. Контейнеры на Windows не так распространены и востребованы, как на Linux. Но я думаю, что поговорить об этой теме стоит, хотя бы для того, что бы понимать общую концепцию и основные отличия контейнеров Windows и Linux. Первой записью я пройдусь по полотну широкой кистью, а затем, в последующих постах, попробую постепенно углубиться в нюансы.

Контейнеры в Windows

Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux

Действительно, контейнеры в Windows до недавнего времени были экзотикой. А хуже всего то, что документацию приходилось собирать по крохам, на каждом ресурсе будь то официальный сайт Docker или Microsoft, всё представлялось в обзорном виде без описания «как и почему», а через месяц-два и существующая информация устаревала. И в этом нет ничего сверхъестественного – контейнеры и технологии с ними связанные развиваются с какой-то нереальной скоростью.

В настоящий момент с документацией все стало лучше и что бы погрузится в мир контейнеров для Windows достаточно почитать официальную документацию от Microsoft и следить за её изменениями. Что интересно, документация написана хорошо и на русском языке, хотя при глубоком изучении вам не избежать переходов по ссылкам на различные ресурсы по типу https://www.docker.com/ или https://kubernetes.io/ где всё написано на старом добром английском языке.

Сейчас ответы на любые вопросы можно найти в официальной документации, но есть некоторые нюансы, которые лучше знать заранее. Возможно вам это будет полезно и сэкономит время при погружении в контейнерные технологии под флагом Microsoft.

Вы не можете запускать контейнеры Windows на Linux и на Windows*

Контейнерные технологии позволяют легко обращаться с окружением благодаря наличию переконфигурированных образов приложений. Это как Apple Appstore или Google Play, но только для инженеров и разработчиков. Как и в магазинах для мобильных приложений вы не можете поставить приложение из Google Play на iOS. Так и на Docker хосте с операционной системой Linux вы не можете запустить контейнер с операционной Windows. Верно и обратное утверждение, правда с некоторыми «но», так как Docker хост с Windows всё же может предоставить Linux окружение для запуска контейнеров.

Так же вы не можете запустить контейнер Windows в среде Windows не убедившись в совместимости версий операционной системы. Работая с контейнерами от Microsoft вам придется оглядываться на Windows Container Version Compatibility и периодически открывать данный документ.

Говоря о версионности — Microsoft с приходом контейнеров приняла решение о выпуске новых полугодовых версий Windows semi-annual. Это такие версии как windows server 1703, 1709, 1803, 1809, 1903. Цифры означают год и месяц выхода, а поддерживаются они по 18 месяцев. Первые две уже покоятся с миром и находятся в end of service. Кроме того, существуют версии LTS такие как Windows Server 2016 и Windows Server 2019. Список версий.

Так вот, если вы собрали контейнер на хосте с версией Windows 1803, то и запустить данный контейнер вы можете только на хостах с Windows 1803. Соответственно, чтобы не пересобирать каждый раз сам контейнер вам придется использовать LTS версию Windows, что при современных скоростях развития технологий не всегда оправдано. Либо всё же думать о версионности и таки постоянно пересобирать контейнеры следуя шаг в шаг за программой semi-annual.

Тэг latest в Dokerfile для Windows контейнеров присутствует не всегда и вообще он deprecated. По-хорошему вам всегда надо знать, что у вас за версия Windows и вносить соответствующие правки в Dockerfile.

Контейнеры — это часть подхода «Инфраструктура как код». Пересобирать контейнеры нужно постоянно, это не только просто и весело, но в этом и заключается основная магия, которая позволяет приложениям всегда работать на свежем улучшенном софте. Но в нашем случае мы сталкиваемся с ограничением: не получится держать универсальный Dockerfile под все системы Windows. Это необходимо учитывать.

Всё вышесказанное справедливо для контейнеров, запущенных в режиме process isolation. В режиме Hyper-V isolation действует обратная совместимость – вы можете запускать все контейнеры, которые собраны на текущей и предыдущей версиях. В общем-то с помощью Hyper-V isolation можно на хосте Windows запускать и Linux контейнеры. Но такой режим пока что поддерживает меньше плюшек, чего только стоит отсутствие Kubernetes.

Отличие process isolation и Hyper-V isolation это тема отдельной статьи. Сейчас скажу только то, что сценарии с Hyper-V isolation мне не совсем очевидны, а по умолчанию в Windows используется process isolation.

Отдельной головной болью является поиск правильных по версии образов на Docker Hub. Некоторые образы вообще отсутствуют для Windows. Например, официальной сборки Nginx, MySQL, Nodejs, как и сотни других приложений под Windows вы не найдете и вам придется собирать контейнеры самостоятельно либо использовать контейнеры, собранные и предоставленные участниками сообщества.

Windows стоит денег.

Не стоит забывать и о том, что Windows это по-прежнему платная штука. К примеру, Semi-annual версии доступны по подписке Visual Studio или при наличии Software Assurance в действующем лицензионном контракте Microsoft. Ссылка.

Но у Microsoft есть большое количество способов получит платное за бесплатно. Это и программа BizSpark и всякие trial версии Windows Server 2019 на 180 дней и прочее и прочее.

Контейнеры Windows не легковесны.

Принято считать, что контейнеры легковесны, но что правда для Linux не всегда правда для Windows. Подавляющее большинство контейнеров Windows, на первый взгляд весит непозволительно много. Да и на второй взгляд впечатление не меняется. Например, базовый образ aspnet:4.8 весит порядка 7.5 Гб.

Даже если вы будете размещать базовые образы в локальном репозитории, первоначальная загрузка образа на хост будет занимать довольно продолжительное время, что уж говорить про удаленные репозиторий типа Docker Hub.

Да вы можете в некоторых сценариях использовать легковесный Windows Nano Server, но увы он имеет кучу ограничений. И тем более вам не по пути с Windows Nano Server если вы разрабатываете под .Net Framework.

Для управления надо хорошо знать CMD и Powershell.

Скорее всего работать вам придется с core версией Windows Server на Docker хостах. Windows Server имеет огромное количество возможностей по удаленному управлению. Общий подход такой, что имея Windows Server с графическим интерфейсом вы можете подключатся всеми графическими оснастками к любому core серверу.

Данный подход не работает в сценариях с контейнерами, хотя в контейнере и находится полноценная версия Windows Server. Внутрь контейнера Windows теоретически можно подключится по WMI, но это не так просто, хотя бы потому что хостовая ОС будет перехватывать данный трафик на себя. Контейнеров на хосте может быть несколько десятков и сотен, и в таком случае направлять трафик в нужный контейнер это целое дело.

CMD и Powershell понадобятся как для администрирования контейнеров так и самого хоста на котором установлен Docker. Так же знание данных оболочек необходимо для написания Dockerfile, так как все инструкции RUN будут выполнятся в вышеупомянутых командных оболочках.

Запомнить все длинные командлеты Powershell довольно сложно. Это вам не лаконичные команды bash. Хотя сейчас большинство командлетов имеет понятные любому Linux инженеру алиасы. В powershell можно использовать:

Из крайне полезных вещей, это то, что с помощью Powershell можно запустить в контейнере простой веб сервер для целей тестирования. В Powershell всё представляется в виде объектов. Если вы сторонник ООП, то вы быстро оцените преимущества этой командной оболочки.

В качестве заключения вводной статьи хочу сказать что я нарочно не касался вопроса оркестрации и управления кластерам. Docker на Windows находится в роли догоняющего и приложения по оркестрации такие как Swarm и Kubernetes на Windows реализуют не полный свой функционал.

Так же на текущий момент если вы хотите поднять кластер Docker, то он скорее всего будет мульти платформенный. То есть вам придется иметь в кластере один или более хостов с операционной системой Linux. Например, для Kubernetes, мастер ноды обязаны быть на Linux. А в Swarm, Linux контейнеры понадобятся, например, для реализации балансировщика на Nginx или запуска других популярных приложений для кластера, которые доступны только для Linux.

P.S. Использование Windows в контейнерах имеет весьма ограниченный набор сценариев для применения. Тем не менее эти сценарии могут оказаться крайне продуктивными. Конечно, первое что приходит на ум это web приложения на IIS, но мой опыт показывает, что в контейнерах хорошо изолируются самописные службы Windows и некоторые сервисы такие как MSMQ.

UPD. В статье есть небольшая неточность, кластер Docker на одних только Windows хостах собрать можно. Причем, это не только Swarm, но и развиваемый самим Micrisoft продукт для оркестрации кластера Service Fabric

UPD2. Docker контейнеры для Windows 10 доступны только в режиме Hyper-V isolation и используют отличные от Windows Server базовые образы.

Глава 11. Контейнеры и Нано сервер

Содержание

Многие из новых технологий, включённых в Windows Server 2019, разработаны для отражения возможностей, предоставляемых облачными вычислениями, привнося ваши частные облачные решения в жизнь и предоставляя вам отличную возможность производить те же самые решения, которые дают вам поставщики общедоступных облачных решений внутри своей собственной физической инфраструктуры. Ряд самых последних итераций операционной системы Сервера также вращались вокруг виртуализации, а основная идея контейнерных приложений это нечто такое, что касается обоих данных подходов. Приложения в контейнерах намерены сделать развёртывание приложений более упорядоченным, более безопасным и более эффективным. Контейнеры- относительно новая идея в мире Microsoft, и я пока не слышал чтобы о них разговаривало много ИТ- администраторов, но в скором времени это изменится. Именно они уже давно улучшают вычислительные возможности Linux, а именно данная новейшая операционная система Windows Server привносит их слегка ближе для наших сосредоточенных вокруг Microsoft продаж.

Разработчики приложений будут крайне заинтересованы в тех контейнерах, которые производятся Windows Server 2019 и, по правде говоря, скорее всего осознают концепции контейнеров гораздо лучше чем традиционные администраторы сервера. Хотя исходные задачи данной книги не сосредоточены на возможностях разработки и уж точно не ориентированы на Linux, мы намерены обсудить контейнеры по той причине, что предоставляемые ими преимущества предназначены не только для разработчиков. Нам, системным операторам, также предоставляется выигрыш от использования контейнеров и для нас будет важно знать и понимать как разрабатывать концепцию и как раскручивать контейнеры с тем, чтобы вы могли предоставлять инфраструктуру, которую намерены потребовать для своего применения наши разработчики.

В данной главе мы рассмотрим некие темы, имеющие дело с приложениями контейнеров, в частности, те новые возможности, которые доступны в Windows Server 2019 для привнесения этой технологии в наши центры обработки данных:

Общее представление о контейнерных приложениях

Контейнеры и нано серверы

Сопоставление контейнеров Windows Server и Hyper-V контейнеров

Docker и Kubernetes

Работу с контейнерами

< Прим. пер.: работа с контейнерами требует переосмысления многих парадигм программирования, которыми вы пользовались в традиционной разработке приложений. Если у вас есть острый интерес к тому чтобы понять зачем они нужны и в чём причины их популярности, советуем ознакомиться с великолепным руководством по приобретению навыков работы с контейнерами Docker в нашем переводе вышедшей в феврале 2019 книги Docker для разработчиков Rails Роба Айзенберга. Не стоит пугаться указания Rails в заголовке. Даже если вы не знакомы с Rails и не собираетесь разрабатывать с его помощью приложения, это руководство снабдит вас пониманием ключевых особенностей сборки прикладных приложений со множеством пакетов программного обеспечения промежуточного уровня — баз данных, веб- серверов, средств аутентификации, служб ключ- значение, средств обмена сообщениями, балансировщиков нагрузки и т.п. — в единое целое приложение на основе контейнеров. Вооружившись пониманием того из- за чего весь сыр- бор, знакомство с Kubernetes пойдёт значительно быстрее. У вас появится цельная картина обсуждаемой предметной области, которую может быть сложно уловить если начинать знакомство сразу с этой книги, практически, претендующей на роль монографии. >

< Прим. пер.: одной из самых необычных сторон контейнеров является их уровень абстракции относительно операционной системы, под которой они исполняются. Это, естественно, требует больших усилий от самих разработчиков операционных систем, но в конечном итоге приводит к тому, что очень примечательно отметил с своей вышедшей в октябре 2018 автор книги Профессиональный SQL Server поверх Linux, Боб Вордс, приведя свой диалог: «Я вспоминаю как не так давно спросил своего коллегу, Трэвиса Райта, одного из ключевых руководителей программ по выпуску SQL Server Linux, относительно поддержки SQL Server для контейнеров Windows. Его первый ответ озадачил меня. Он сказал: ‘Боб, почему это тебя волнует?’ Его мысль состояла в том, что было бы неплохо попасть в тот мир, в котором основное внимание уделяется контейнеру базы данных, в том числе SQl Server, саму базу данных и все фрагменты зависимостей вместо того чтобы беспокоиться о самой операционной системе в таком образе контейнера. Я никогда не думал об этом таким образом, и скорее всего мы пока не готовы к этому, но его идея очевидна. Это одна из перспектив контейнеров.». Конкретно это обсуждение касалось именно баз данных, но в большой степени относится и к прочему программному обеспечению промежуточного уровня, на основе которого и собираются в конечном счёте приложения в контейнерах. >

Понимание контейнерных приложений

Означают ли они то, что они содержат некое приложение? У нас на сегодняшний день уже имеется хорошая концепция вместительных серверов посредством виртуализации. Формой включения в себя таких ВМ является применение физического оборудования для его превращения в хост виртуализации наподобие Hyper-V и запуск поверх него множества виртуальных машин. По существу мы заставляем их полагать что они являются самостоятельным логически завершённым объектом, совершенно не подозревая, что они разделяют ресурсы и оборудование с прочими виртуальными машинами, исполняющимися в том же самом хосте. В то же время, когда мы совместно применяем аппаратные ресурсы, мы способны обеспечить строгие уровни изоляции между ВМ, так как нам требуется гарантировать что доступ и полномочия не могут перекрываться между ВМ — в особенности при ситуации с поставщиком облачных ресурсов, так как это могло бы означать катастрофу.

Приложения контейнеров эта та же самая идея, но на ином уровне. В то время как ВМ относятся к виртуализации оборудования, контейнеры больше походят на виртуализацию самой операционной системы. Вместо того чтобы создавать ВМ для размещения наших приложений, мы можем создавать контейнеры, которые имеют гораздо меньшие размеры. Затем мы запускаем приложения внутри этих контейнеров и наши приложения обманываются в том, что они запущены поверх некого выделенного экземпляра своей операционной системы.

Гигантским преимуществом применения контейнеров является та универсальность, которую они привносят в команды разработчиков и операторов. На протяжении всего последнего времени мы постоянно слышим этот термин DevOps, который означает сочетание процессов разработки и выполнения операций с тем, чтобы сделать более действенным весь процесс раскрутки приложения. Само использование контейнеров призвано оказать гигантское воздействие на образ мыслей DevOps, так как разработчики могут теперь выполнять своё задание (разработку приложения) без необходимости сосредотачиваться на стороне частностей самих операций и инфраструктуры. Когда ваше приложение собрано, операции могут брать контейнер, внутри которого расположено данное приложение и просто раскрутить его внутри имеющейся инфраструктуры контейнеров не заботясь о том, что данное приложение намерено прерывать работу сервера или иметь проблемы совместимости.

Я с очевидностью предвижу что контейнеры займут место большого числа виртуальных машин, но это произойдёт только в том случае, если администраторы вскочат на подножку разгоняющегося поезда и попробуют их сами. Давайте обсудим ряд конкретных преимуществ, которые приносят к нам на поверхность контейнеры.

Совместно используемые ресурсы

В точности как и в том случае, когда мы обсуждали расщеплению оборудования по ВМ, контейнерные приложения означают, что они берут фрагменты физического оборудования и разделяют их по множеству контейнеров. Это позволяет нам запускать множество контейнеров в одном и том же сервере — будь то физический или виртуальный сервер.

Однако, взятыми по отдельности, ВМ не дают никаких преимуществ, так как они просто разделяют само оборудование. Мы на самом деле начинаем ощущать преимущества применения контейнеров, а не виртуальных машин по отдельности для всех ваших приложений именно тогда, когда все наши контейнеры могут применять одну и ту же базовую операционную систему. Они не просто связаны с одним и тем же базовым набором, что позволяет очень быстро выводить новые контейнеры в рабочий режим, но это также означает и то, что они совместно используют одни и те же ресурсы ядра. Каждый экземпляр операционной системы имеет свой собственный набор пользовательских процессов и зачастую бывает сложно запускать несколько приложений совместно в серверах, так как эти приложения традиционно имеют доступ к одному и тому же набору процессов и могут подвергаться негативному воздействию со стороны таких процессов. Иными словами, именно в этом состоит та причина, по которой мы склонны раскручивать в наши дни так много серверов, сохраняя под каждое из приложений его собственный сервер, с тем чтобы они не оказывали негативного воздействия друг на друга. Порой приложения просто не любят смешиваться. Само ядро в Windows Server 2019 подверглось расширениям с тем, чтобы оно было способно обрабатывать множество копий определённых процессов пользовательского режима. Это означает, что у вас имеется возможность не только экземпляры одного и того же приложения в разных серверах, но также подразумевает что вы можете исполнять множество различных приложений, даже если им обычно не нравится сосуществовать в одном и том же сервере.

Изоляция

Одним из гигантских преимуществ контейнерных приложений является то, что разработчики способны собирать свои приложения внутри некоторого контейнера, запуская это на своём собственном рабочем месте! Машиной хоста для размещения контейнеров может быть Windows Server, либо это может быть рабочая станция Windows 10. < Прим. пер.: или даже macOS либо Linux! > При сборке внутри песочницы такого контейнера, разработчики будут знать, что их приложение содержит все требующиеся ему необходимые пути, части и зависимости для надлежащей работы и что оно запускается таким образом, что не требует никаких дополнительных компонентов от лежащей в основе операционной системы. Это означает, что разработчик может собирать данное приложение, убедившись что оно работает в его локальной среде и затем легко передвинув этот контейнер приложения в серверы хостинга, где оно будет раскручено и готово к промышленному применению. Такой промышленный сервер может быть даже неким ресурсом облачного решения, но само приложение это никак не затрагивает. Такая изолированность контейнера от операционной системы помогает поддерживать данное приложение стандартным образом с тем, чтобы оно обладало простой мобильностью и перемещаемостью и сберегало время и головную боль своего разработчика, так как ему не приходится сосредотачиваться на отличиях в лежащих в основе операционных системах на протяжении всего процесса разработки.

Другой стороной изолированности являются вопросы безопасности. Это в точности та же самая история, что и относительно множества исполняющихся в одном и том же хосте виртуальных машин, в особенности в некоей облачной среде. Вы бы желали чтобы между такими машинами имелись некие границы безопасности, на практике по большей части чтобы они даже и не были бы осведомлены друг о друге. Вы даже хотите изолированности и разъединённости между самими виртуальными машинами и самой операционной системой хоста, так как вы уж точно не желаете чтобы ваш поставщик общедоступных облачных служб слонялся по вашим виртуальным машинам. В точности та же самая идея применяется к контейнерным приложениям.

Сами процессы, запускаемые внутри некого контейнера не видны для имеющейся операционной системы хоста, даже несмотря на то, что вы потребляете из этой операционной системы её ресурсы. Контейнеры поддерживают два различных вида изоляции. Это изоляция пространства имён, которая подразумевает что сами контейнеры ограничены своей собственной файловой системой и реестром. Затем, существует также и изоляция ресурсов, которая означает что мы можем определять какие именно конкретные аппаратные ресурсы доступны различным контейнерам и их невозможно уводить друг от друга. Короче говоря, мы обсудим две различные категории контейнеров, контейнеры Windows Server и Hyper-V контейнеры. Эти два типа контейнеров обрабатывают изоляцию двумя разными способами, поэтому следите за получением дальнейшей информации по этой теме.

Нам известно что контейнеры совместно используют ресурсы и раскручивались из одного и того же базового образа и в то же самое время сохраняют свои процессы обособленными с тем, чтобы сама лежащая в основе операционная система не смогла оказывать отрицательного воздействия, а также чтобы само приложение не иссушало бы саму операционную систему хоста. Но как такая изолированность обрабатывает вопросы сетевой среды? Да, контейнерные приложения используют технологии виртуальной коммутации из своего Hyper-V с тем чтобы сохранять всё прямо на стороне самой сетевой среды. Фактически, по мере того как вы начинаете применять контейнеры, вы быстро обнаружите, что каждый контейнер имеет некий выделенный ему уникальный IP адрес для сопровождения изолированности на этом уровне.

Масштабируемость

Сочетание раскрутки одного и того же самого базового образа при изоляции самого контейнера делает очень привлекательным сценарий масштабируемости и роста. Задумайтесь о неком размещаемом вами веб- приложении, которое день ото дня испытывает значительные колебания в своём применении. Предоставление достаточного объёма ресурсов для сопровождения такого приложения в напряжённое время обычно означало что мы переплачиваем за вычислительные ресурсы в то время когда такое приложение не применяется интенсивно. Облачные технологии предоставляют динамическое масштабирование для таких современных видов приложений, но они обычно выполняют это зачастую раскручивая или останавливая виртуальные машины целиком. Существует три основных трудности для динамично масштабируемых приложений. Во- первых, это то время, которое требуется для воспроизводства дополнительных виртуальных машин, даже в случае автоматизации данного процесса, ваше приложение может оставаться перегруженным на протяжении того времени, пока не будут введены в строй дополнительные ресурсы. Наш второй вызов состоит в тех трудностях, которые требуется преодолеть самому разработчику чтобы сделать своё приложение настолько независимым, чтобы его не беспокоило имеются ли какие бы то ни было несоответствия между теми машинами, в которых будет исполняться его приложение. В- третьих это цена. Причём не только сам стоимость оборудования, так как новые вступающие в строй ВМ будут по отдельности потреблять целиком весь набор ресурсов ядра, но также и денежные затраты. Раскрутка и останов виртуальных машин в вашей облачной среде быстро могут стать весьма затратными. Всех этих препятствий нет в том случае когда вы применяете контейнеры в качестве своего метода развёртывания приложений.

Поскольку контейнерные приложения применяют одно и то же лежащее в их основе ядро, а также тот же самый базовый образ, время их приведения в жизнеспособное состояние чрезвычайно краткое. Новые контейнеры очень быстро запускаются и останавливаются, причём пачками и без необходимости дожидаться загрузки и запуска процессов режима ядра. Кроме того, поскольку мы предоставляем самим разработчикам такую структуру изоляции контейнера, в рамках которой и собирается данное приложение, мы знаем что наше приложение предназначено быть способным запускаться везде где только мы можем раскручивать эти контейнеры. Не стоит больше беспокоиться будет ли новая приходящая в рабочее состояние ВМ верно стандартизована, ибо контейнеры для некого приложения всегда одни и те же и содержат все необходимые приложению важные зависимости, причём непосредственно в самом этом контейнере.

Контейнеры и Нано сервер

Данная тема вновь возвращает нас обратно к нашему обсуждению относительно Нано сервера и того почему он в частности исчез в качестве варианта установки Windows Server. Прежде чем обсуждать те цели, которые теперь обслуживает Нано сервер, давайте по- быстрому рассмотрим структуру контейнера на основе Windows. Вот некое графическое представление, позаимствованное из колоды общедоступных слайдов, которые являются частью презентации Microsoft Ignite:

Рисунок 1

Самый нижний уровень контейнера — это его базовая операционная система. При раскрутке некого контейнера вам требуется некий базовый набор кода и ядро, из которого происходит сборка. Такой базовой операционной системой может быть либо Server Core, либо Nano Server < Прим. пер.: либо Linux, например, привычный Ubuntu 16.04, и это будет тот же самый Docker внутри Windows — здесь не без волшебства! Вы теперь имеете возможность размещать контейнеры Linux поверх Windows Server 2019. >.

Следующим уровнем контейнера является уровень персонализации. Именно здесь сосредоточены те технологии, которые в конечном итоге будут расположены применяемые вашим приложением. Например, наши контейнеры могут содержать IIS для размещения некого вебсайта, PowerShell, или даже нечто подобное .NET. Все эти наборы инструментов располагаются на этом уровне.

Наконец, самым верхним слоем в этом торте контейнера является уровень приложения. Это, естественно, то конкретное приложение, которое вы планируете размещать внутри данного контейнера, к которому и будут осуществлять доступ ваши пользователи.

Хотя Сервер ядра является великолепной операционной системой для построения небольших и действенных серверов, он всё ещё тяжеловсен по сравнению с Нано сервером. Нано настолько потрясающе отличается и настолько невероятно крошечный, что их на самом деле нельзя сравнивать. Вы скорее всего помните, что когда ранее мы устанавливали Сервер ядра, мы выдавали некий жёсткий диск порядка 6 ГБ. Хотя это и намного меньше чем версия Windows Server с Рабочим столом, задумайтесь над этим. Базовый образ Нано сервера может составлять менее 500 МБ!

Он ошеломляюще мал. Кроме того, ожидается, что обновления для Нано сервера будут реже и между ними будет больший промежуток. Это означает, что вам не придётся иметь ежемесячные дела с исправлениями ошибок и обновлениями в своих контейнерах приложений. На самом деле, так как контейнеры содержат всё что им требуется для исполнения размещающегося в них приложения, вам просто требуется продвигаться далее и собирать некий новый образ контейнера, вместо того чтобы обновлять уже имеющиеся. Если Нано сервер получает некое обновление, просто соберите новый контейнер, установите и проверьте своё приложение в нём, и раскатайте его. Вам требуются некие обновления в самом приложении? Вместо того чтобы определять как обновлять некий имеющийся образ, будет гораздо быстрее собрать некий новый, проверить его вне вашей промышленной среды и когда оно будет готово, просто запустить развёртывание и раскрутить вновь полученный контейнер в промышленной среде, позволяя своей старой версии уйти прочь.

Нано сервер теперь применяется исключительно в качестве базовой операционной системы для контейнеров. В этом основное отличие от выпуска Сервера 2016, в котором ожидалась гораздо более широкая сфера применения Нано. Если вы применяете Нано сервер для своих рабочих потоков за пределами образов контейнеров, вам потребуется начать работу по переносу этих рабочих потоков в более традиционные серверы, такие как Сервер ядра.

Вы можете быть удивлены: «Почему кто- то будет применять Сервер ядра в качестве основы для некого контейнера, когда в доступности имеется Нано сервер?» Самый простой ответ на этот вопрос состоит в совместимости приложения. Нано сервер невероятно мал, а раз так, он очевидно утратил большую часть кода, которая имеется внутри Сервера ядра. Когда вы начинаете рассматривать применение контейнера для размещения своих приложений, великолепной мыслью будет воспользоваться самым маленьким Нано сервером, если это возможно , но часто ваше приложение просто будет не способно исполняться на этой платформе и в таких случаях вы будете применять в качестве базовой операционной системы Сервер ядра.

Сопоставление контейнеров Windows Server и контейнеров Hyper-V

Когда вы раскручиваете свои контейнеры, важно знать что существует две категории контейнеров, которые вы можете запускать в Windows Server 2019. Все стороны контейнерных приложений, которые мы до сих пор обсуждали, применяются либо к контейнерам Windows Server, либо к контейнерам Hyper-V. Как и контейнеры Windows Server, контейнеры Hyper-V могут исполнять внутри себя тот же самый код или те же самые образы, в то же время продолжая обеспечивать те же самые строгие гарантии изоляции чтобы поддерживать уверенность сопровождения обособленности начинки. Решение между использованием контейнеров Windows Server или контейнеров Hyper-V, скорее всего, будет зависеть от того, какой уровень безопасности требуется вам для поддержки своих контейнеров. Давайте обсудим различия между ними, чтобы вы могли лучше понять, с каким именно выбором вы столкнулись.

Контейнеры Windows Server

Также как контейнеры Linux разделяют файлы ядра операционной системы, контейнеры Windows Server также используют такой совместный доступ для повышения эффективности контейнеров. Однако это означает, что хотя для отделения контейнеров друг от друга существуют пространство имён, файловая система и сетевая изоляция, всё же существует некая вероятность уязвимости между различными запущенными в некотором сервере хоста контейнерами Windows Server. Например, если вы зарегистрируетесь в самой операционной системе хоста со своего контейнерного сервера, вы будете иметь возможность видеть все запущенные процессы всех контейнеров. Сам контейнер не способен видеть свой хост или прочие контейнеры и всё ещё остаётся изолированным от самого хоста различными способами, но знание того что хост способен просматривать имеющиеся в его контейнерах запущенные процессы, демонстрирует нам что в этом уровне совместного использования всё же существует некое взаимодействие. Контейнеры Windows Server будут более всего полезны когда ваши контейнеры расположены в пределах одного и того же ограничения доверенности . Для большинства случаев это означает, что контейнеры Windows Server будут более всего подходящими для принадлежащей определённой компании серверов. Если вы доверяете как самому хост- серверу, так и своим контейнерам и и считаете допустимым то что эти логические элементы доверяют друг другу, развёртывание обычных контейнеров Windows Server будет самым действенным применением ваших аппаратных ресурсов.

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

Если вы заинтересованы в неком увеличении изолированности и более строгих границах, тогда вам самая дорога в контейнеры Hyper-V. Контейнеры Hyper-V больше похожи на супер оптимизированную версию виртуальной машины. Несмотря на то, что ресурсы ядра по- прежнему совместно применяются контейнерами Hyprer-V, а следовательно они по- прежнему намного более производительны нежели полноценные виртуальные машины, каждый контейнер Hyper-V получает свою собственную выделенную оболочку Windows, в рамках которой может запускаться некий обособленный контейнер. Это означает, что вы обладаете изоляцией контейнера, которая больше напоминает изоляцию между виртуальными машинами и, тем не менее, вы всё равно можете раскручивать свои новые контейнеры по собственному желанию, причём очень быстро, поскольку сама инфраструктура контейнеров всё ещё расположена в их основе. Контейнеры Hyper-V будут более подходящими в в инфраструктурах со множеством арендаторов, когда вы желаете быть уверенными в том, что никакие код или активность не способны перетекать между самим контейнером и его хостом, либо между различными контейнерами, которые могут принадлежать различным логическим объектам. Ранее мы обсуждали, что операционная система хоста может отслеживать процессы, исполняющиеся в контейнере Windows Server, но это не относится к контейнерам Hyper-V. Операционная система хоста абсолютно ничего не знает о тех службах, которые исполняются внутри самих контейнеров Hyper-V и никак не может их применять. Эти процессы теперь невидимы.

Доступность контейнеров Hyper-V означает, что даже если у вас имеется некое приложение, которое должно быть строго изолированным, вам больше не требуется посвящать этому приложению целую ВМ Hyper-V. Теперь у вас имеется возможность раскрутить некий контейнер Hyper-V, запустить в этом контейнере своё приложение и получить полную изоляцию для данного приложения и при этом продолжать совместно использовать ресурсы и предоставлять лучшую практику масштабирования для данного приложения.

Docker и Kubernetes

Докер является неким проектом с открытым исходным кодом — некий инструментарий, на самом деле — который изначально разрабатывался в помощь с запуском контейнеров в операционных системах Linux. Постойте минутку, что-а? Эти слова Linux и открытый исходный код вновь появились внутри книги про Microsoft! Куда катится мир? Видите ли, контейнеры быстро превращаются в крупным бизнес, и это на самом деле так. В 2016 Сервере Microsoft предпринял некие шаги для того чтобы начать изобретать своё колесо контейнеров, включая cmdlet PowerShell, которые можно применять для ускорения и управления контейнерами, работающими в вашем Windows Server, но платформа Docker росла настолько быстрыми темпами, что Microsoft на самом деле ожидает что всякий кто пожелает запускать контейнеры в своих машинах Windows намерен делать это посредством инструментария Docker. Если вы желаете применять или даже просто попробовать контейнеры в своих машинах Windows, для начала вам потребуется получить Docker для Windows.

Docker — это контейнерная платформа . Это означает, что она предоставляет соответствующие команды и инструменты, необходимые для выгрузки, создания, упаковки, распространения и запуска контейнеров. Docker для Windows полностью поддерживается для работы как в Windows 10, так и в Windows Server 2019. Устанавливая Docker для Windows вы получаете все те инструменты, которые требуются для начала использования контейнеров для расширения изоляции и масштабирвоания ваших контейнеров.

Разработчики имеют возможность применять Docker для создания некой среды на своих рабочих местах, которые отражают среду времени исполнения сервера, с тем чтобы они имели возможность разрабатывать приложения внутри контейнеров и при этом быть уверенными, что они на самом деле запустятся после того как эти приложения будут перемещены на сам сервер. Docker является платформой, которая предоставляет вашим разработчикам возможности упаковки, отправки и запуска. После завершения разработки, такой контейнерный пакет может быть передан имеющемуся системному администратору, который раскрутит этот контейнер (эти контейнеры) с исполняемым приложением и развернётся как положено. Сам разработчик не знает и не беспокоится о самой инфраструктуре размещения контейнеров, а её администратор не знает и не заботится о процессе разработки или совместимости со своими серверами.

< Прим. пер.: работа с контейнерами требует переосмысления многих парадигм программирования, которыми вы пользовались при традиционной разработке приложений. Если у вас есть острый интерес к тому чтобы понять зачем они нужны и в чём причины их популярности, советуем ознакомиться с великолепным руководством по приобретению навыков работы с контейнерами Docker в нашем переводе вышедшей в феврале 2019 книги Docker для разработчиков Rails Роба Айзенберга. Не стоит пугаться указания Rails в заголовке. Даже если вы не знакомы с Rails и не собираетесь разрабатывать с его помощью приложения, это руководство снабдит вас пониманием ключевых особенностей сборки прикладных приложений со множеством пакетов программного обеспечения промежуточного уровня — баз данных, веб- серверов, средств аутентификации, служб ключ- значение, средств обмена сообщениями, балансировщиков нагрузки и т.п. — в единое целое приложение на основе контейнеров. Вооружившись пониманием того из- за чего весь сыр- бор, знакомство с Kubernetes пойдёт значительно быстрее. У вас появится цельная картина обсуждаемой предметной области, которую может быть сложно уловить если начинать знакомство сразу с этой книги, практически, претендующей на роль монографии. >

< Прим. пер.: одной из самых необычных сторон контейнеров является их уровень абстракции относительно операционной системы под которой они исполняются. Это, естественно, требует больших усилий от самих разработчиков операционных систем, но в конечном итоге приводит к тому, что очень примечательно отметил с своей вышедшей в октябре 2018 автор книги Профессиональный SQL Server поверх Linux, Боб Вордс, приведя свой диалог: «Я вспоминаю как не так давно спросил своего коллегу, Трэвиса Райта, одного из ключевых руководителей программ по выпуску SQL Server Linux, относительно поддержки SQL Server для контейнеров Windows. Его первый ответ озадачил меня. Он сказал: ‘Боб, почему это тебя волнует?’ Его мысль состояла в том, что было бы неплохо попасть в тот мир, в котором основное внимание уделяется контейнеру базы данных, в том числе SQl Server, саму базу данных и все фрагменты зависимостей вместо того чтобы беспокоиться о самой операционной системе в таком образе контейнера. Я никогда не думал об этом таким образом, и скорее всего мы пока не готовы к этому, но его идея очевидна. Это одна из перспектив контейнеров.». Конкретно это обсуждение касалось именно баз данных, но в большой степени относится и к прочему программному обеспечению промежуточного уровня, на основе которого и собираются в конечном счёте приложения в контейнерах. >

Контейнеры Linux

Имеется некое важное обновление, которое находится в продолжающейся стадии разработки что касается возможностей, которыми обладает Windows Server 2019 для взаимодействия с различными типами контейнеров. Ранее в Сервере 2016 сервер размещения контейнеров Windows мог исполнять только контейнеры на основе Windows, так как контейнеры Windows Server разделяли своё ядро с самой операционной системой хоста, поэтому не было способа которым вы бы могли раскручивать некий контейнер Linux в хосте Windows. < Прим. пер.: не совсем так, имелась возможность устанавливать Docker для Windows, который как и Docker для macOS, применял возможности имеющегося гипервизора хоста для запуска ядра Linux подробнее. . Впрочем, никто не отменял эту способность самого Docker с поддержкой Linux со стороны какого- то гипервизора, но в таком случае у вас будут исполняться только контейнеры на основе ядра Linux (MobyVM). >

Времена меняются, и теперь у нас имеется несколько созидательных новых способностей в Server 2019 для отработки таких ситуаций как контейнеры Linux. Хотя эти свойства всё ещё шлифуются, существуют некие новые возможности, именуемые как Moby VM и LCOW , которые позволят контейнерам Linux запускаться в неком хосте контейнеров Windows Server, даже исполняясь бок о бок с контейнерами Windows!

Это всё ещё достаточно новые возможности и всё ещё в процессе своего становления чтобы предоставлять дополнительные подробности, но перейдите по этой ссылке и вы получите текущее состояние этих новых возможностей, если вам интересно запускать контейнеры Linux.