Контейнеры windows server что это

Обновлено: 06.07.2024

В эпоху развития облачных и мобильных технологий приложения задают ритм для инноваций. Контейнеры и связанная с ними экосистема позволяют создавать сервисы нового поколения. До недавнего времени контейнеры были вещью из мира Linux. Но с выходом Windows Server 2016 ситуация изменилась — технологии контейнеризации стремительно ворвались в мир Windows.

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

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

Контейнеры как технология существуют еще с 80-х годов, то есть они возникли еще до привычных нам виртуальных машин. В 2000-е появились первые коммерческие продукты для организации контейнеров на Linux и Unix (Virtuozzo, HP-UX Containers), а в 2008 году появилась нативная поддержка контейнеризации в ядре Linux (LXC).

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

Год назад компания Microsoft сделала первый серьёзный шаг в мир контейнеров, запустив Azure Container Service — облачный сервис контейнеризации на базе Docker Swarm и DC/OS (Apache Mesos). Этот сервис позволяет тысячам заказчиков по всему миру эффективно развёртывать масштабные решения с использованием контейнеров популярных форматов Docker и Mesos на базе ОС Linux.

Кстати, Microsoft идёт по пути скрещивания этих двух по сути параллельных продуктов — Azure Container Service и Windows Server Containers (и да, прошу их не путать). В данный момент идёт раннее тестирование Windows Server Containers в Azure Container Service, записаться можно вот здесь. Так что в будущем Azure Container Service сможет работать не только с контейнерами Linux, но и с контейнерами на базе Windows Server.

Типы контейнеров Windows

Контейнеры в Windows Server 2016 создаются из специальных шаблонов в формате Docker. Вы можете создавать свои шаблоны или воспользоваться богатым выбором из библиотеки Docker Hub. Подключение к контейнеру производится через командную строку, так как собственной графической оболочки контейнер не имеет. Контейнер не нужно патчить или обслуживать — вы просто создаёте новый шаблон контейнера и разворачиваете из него новые контейнеры вместо старого за секунды.

Контейнеры в Windows Server 2016 делятся на два типа:

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

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

Принципы работы контейнера Windows

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

При создании контейнеров Windows и последующей работе с ними пригодятся перечисленные ниже основные понятия.

Узел контейнера. Физический или виртуальный компьютер под управлением Windows Server 2016, настроенный для работы с контейнерами Windows. На хосте работают один или несколько контейнеров Windows.

Образ контейнера. По мере того как в файловую систему или реестр контейнера вносятся изменения (например, при установке программного обеспечения), они регистрируются в «песочнице». Во многих случаях может потребоваться зарегистрировать это состояние, чтобы применить внесенные изменения при создании новых контейнеров. В этом и заключается суть образа: после остановки работы контейнера можно либо отключить «песочницу», либо преобразовать ее в новый образ контейнера. Предположим, вы развернули контейнер в образе Windows Server Core. Затем вы устанавливаете в этот контейнер MySQL. Создание нового образа на базе этого контейнера будет происходить аналогично его развертыванию. Этот образ будет содержать только внесенные изменения (MySQL) и при этом работать в виде слоя поверх образа ОС контейнера.

«Песочница». После запуска контейнера все операции записи (изменения файловой системы и реестра либо установка программного обеспечения) регистрируются на уровне «песочницы».

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

Репозиторий контейнера. При каждом создании образа контейнера этот образ и его зависимости сохраняются в локальном репозитории. Эти образы можно использовать повторно много раз на узле контейнера. Образы контейнеров также можно хранить в открытом или закрытом реестре (например, Docker Hub), чтобы использовать на многих других узлах контейнеров.

Использование контейнеров Windows

Образ Docker можно создать где угодно, начиная с компьютера разработчика и заканчивая тестовыми и рабочими компьютерами. К тому же его развертывание в любой среде будет выполнено одинаково и за считанные секунды. Благодаря этому появилась развитая и расширяющаяся экосистема приложений, запакованных в контейнеры Docker. При этом в общедоступных репозиториях Docker Hub открытого реестра контейнерных приложений, который Docker обслуживает, в настоящее время опубликовано более 180 000 приложений.

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

Так как контейнер содержит все необходимое для запуска приложения, он отличается высокой переносимостью и может запускаться на любом компьютере под управлением Windows Server 2016. Можно создать и протестировать контейнер локально, а затем развернуть его образ на сервере поставщика услуг, а также в частном или общедоступном облаке компании. Адаптивность контейнеров позволяет использовать современные модели разработки приложений в крупномасштабных виртуализированных и облачных средах.

Контейнеры позволяют масштабировать веб-сервисы эффективнее, так как новые экземпляры стартуют в разы быстрее, чем виртуальные машины (плюс виртуальной машине, в отличие от контейнера, еще нужно время на provisioning).

Также контейнеры значительно менее требовательны к оперативной памяти, нежели виртуальные машины.

С помощью контейнеров разработчики могут создать приложение на любом языке. Такие полностью переносимые приложения можно запускать где угодно (на ноутбуке, настольном компьютере, сервере, в частном или публичном облаке) без необходимости изменения кода.

Если вам интересна тема контейнеров в Windows Server 2016, рекомендуем прочитать официальную документацию, статью Марка Руссиновича и посмотреть доклад по теме с конференции Microsoft Ignite.

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

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

Экосистема контейнеров Майкрософт

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

Запускайте контейнеры под управлением Windows или Linux в среде Windows 10 для разработки и тестирования с помощью Docker Desktop, который использует встроенные функции контейнеров Windows. Можно также выполнять контейнеры с помощью встроенных подсистем Windows Server.

Разрабатывайте, тестируйте, публикуйте и развертывайте контейнеры на основе Windows используя комплексную поддержку контейнеров в Visual Studio и Visual Studio Code, которые включают поддержку Docker, Docker Compose, Kubernetes, Helm и других полезных технологий.

Публикуйте свои приложения как образы контейнеров, сделав их общедоступными на DockerHub для использования другими пользователями или в частном реестре контейнеров Azure для собственной разработки и развертывания вашей организации, отправляя и получая их непосредственно в Visual Studio и Visual Studio Code.

Развертывание контейнеров в Azure или других облаках:

Извлекайте свое приложение (образ контейнера) из реестра контейнеров, например Реестра контейнеров Azure, а затем развертывайте его и управляйте им с помощью оркестратора, например Azure Kubernetes Service (AKS) или Azure Service Fabric.
Служба Azure Kubernetes развертывает контейнеры на виртуальных машинах Azure и управляет ими при любом масштабе, будь то десятки контейнеров, сотни или даже тысячи. Виртуальные машины Azure запускают настроенный образ Windows Server (при развертывании приложения на основе Windows) или настраиваемый образ Ubuntu Linux (при развертывании приложения на основе Linux).

Развертывайте контейнеры локально с помощью AKS в Azure Stack HCI, Azure Stack с обработчиком AKS или Azure Stack с OpenShift. Вы также можете самостоятельно настроить Kubernetes в Windows Server (см. Kubernetes в Windows); мы работаем над поддержкой запуска контейнеров Windows на платформе контейнеров RedHat OpenShift.

Как работают контейнеры

Контейнер — это изолированный, нетребовательный к ресурсам пакет, предназначенный для запуска приложения в операционной системе сервера. Контейнеры создаются на основе ядра операционной системы сервера (скрытые процессы операционной системы), как показано на схеме ниже.

Хотя контейнер использует ядро операционной системы сервера, контейнер не получает неограниченный доступ к ядру. Вместо этого контейнер получает изолированное, а в некоторых случаях виртуализированное, представление системы. Например, контейнер может обращаться к виртуализированной версии файловой системы и реестра, но любые изменения затрагивают только контейнер и удаляются при его остановке. Чтобы сохранить данные, контейнер может подключить постоянное хранилище, например диск Azure или общую папку (в том числе файлы Azure).

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

Контейнеры и виртуальные машины

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

Контейнеры и виртуальные машины имеют свои преимущества: на самом деле многие среды контейнеров используют виртуальные машины в качестве операционной системы сервера, а не работают непосредственно на оборудовании, в частности при работе с контейнерами в облаке.

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

Образы контейнеров

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

Корпорация Майкрософт предлагает несколько образов (называемых основными образами), которые можно использовать в качестве отправной точки при создании собственного образа контейнера.

Дополнительные сведения см. в разделе Базовые образы контейнеров.

Пользователи контейнеров

Контейнеры для разработчиков

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

Контейнеры являются переносимыми и универсальными, позволяют запускать приложения, написанные на любом языке, и совместимы с любыми компьютерами под управлением Windows 10 версии 1607 или более поздней, или Windows Server 2016 или более поздней версии. Разработчики могут создать и протестировать контейнер локально на своем ноутбуке или настольном компьютере, а затем развернуть этот образ контейнера в частном или общедоступном облаке или у поставщика услуг. Адаптивность контейнеров позволяет использовать современные модели разработки приложений в крупномасштабных, виртуализированных и облачных средах. Наиболее важное преимущество для разработчиков — возможность изолировать среду таким образом, чтобы приложение всегда получало указанную вами версию библиотек, избегая конфликтов с зависимостями.

Контейнеры для ИТ-специалистов

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

Кроме того, вы можете запустить конфликтующие экземпляры программы командной строки в той же системе, используя интерактивный режим контейнеров.

Оркестрация контейнеров

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

Оркестраторы контейнеров созданы для упрощения управления контейнерами при изменении масштаба и в рабочей среде. Оркестрация предоставляет следующие функциональные возможности:

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

развертывание при любом масштабе;
планирование рабочей нагрузки;
наблюдение за работоспособностью;
отработка отказов при сбое сервера;
увеличение или уменьшение масштаба;
сеть;
обнаружение служб;
координирование обновления приложений;
единообразие узлов кластера.

Существует множество различных оркестраторов, которые можно использовать с контейнерами Windows. Ниже приведены варианты, предоставляемые корпорацией Майкрософт.

— использование управляемой службы Azure Kubernetes — использование Службы Azure Kubernetes в локальной среде

Попробуйте контейнеры в Windows

Чтобы приступить к работе с контейнерами в Windows Server или Windows 10, см. следующие сведения:

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

Ресурсы

Ознакомьтесь со следующими ресурсами по использованию контейнеров Windows Server:

Сведения о текущих проблемах и запланированных обновлениях функций см. на страницеСтратегия развития контейнеров Windows Server.

В данной статье рассказывается об особенностях реализации Docker в Windows, а также об отличиях в реализации контейнеров между Windows и Linux.

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

Представив 3 августа 2015 года Windows Server 2016 Technical Preview 3, Microsoft внедрила технологию контейнеров в платформу Windows. В то время, как на Linux технология контейнеров появилась в августе 2008 года, подобная функциональность прежде не поддерживалась операционными системами Microsoft. Благодаря успеху Docker на Linux, Microsoft решила почти 3 года назад (оригинальная статья опубликована 6 мая 2017 — прим. перев.) начать работу над реализацией контейнеров для Windows. С сентября 2016 года мы смогли поработать с публично доступной версией этой новой технологии контейнеров в Windows Server 2016 и Windows 10. Но в чём разница между контейнерами и виртуальными машинами? И как внутренне реализованы контейнеры Windows? В этой статье мы погрузимся в реализацию контейнеров на Windows.

Часто с контейнерами начинают знакомить с фразы “Контейнеры — это облегчённые виртуальные машины”. Хотя это может помочь людям дать фундаментальное понимание, что такое контейнеры, важно отметить, что это утверждение на 100% ошибочно и может сильно запутать. Контейнеры отличаются от виртуальных машин, и поэтому я всегда представляю контейнеры как “что-то, отличное от виртуальных машин” или даже говорю “контейнеры — это НЕ виртуальные машины”. Но в чём же разница? И почему она так важна?

Что общего между контейнерами и виртуальными машинами

Хотя контейнеры НЕ виртуальные машины, у них обоих есть три важные характеристики:

Что общего между контейнерами и виртуальными машинами:

Изолированное окружение: как и виртуальные машины, контейнеры гарантируют изоляцию файловой системы, переменных окружения, реестра и процессов между приложениями. Это значит, что, как и виртуальная машина, каждый контейнер создаёт изолированное окружение для всех приложений внутри себя. При миграции и контейнеры, и виртуальные машины сохраняют не только приложения внутри, но также и контекст этих приложений.
Миграция между хостами: большое преимущество работы с виртуальными машинами в том, что можно перемещать слепки виртуальных машин между гипервизорами, при этом не нужно изменять их содержимое. Это справедливо и для контейнеров. Там, где виртуальные машины можно “перемещать” между разными гипервизорами, контейнеры можно “перемещать” между разными хостами контейнеров. При “перемещении” обоих видов артефактов между разными хостами содержимое виртуальной машины/контейнера остаётся точно таким же, как и на предыдущих хостах.
Управление ресурсами: другая общая черта — это то, что доступные ресурсы (ЦП, ОЗУ, пропускная способность сети) как контейнеров, так и виртуальных машин могут быть ограничены до заданных значений. В обоих случаях это управление ресурсами может осуществляться только на стороне хоста контейнера или гипервизора. Управление ресурсами гарантирует, что контейнер получает ограниченные ресурсы, чтобы свести к минимуму риск того, что он повлияет на производительность других контейнеров, запущенных на том же самом хосте. К примеру, контейнеру можно задать ограничение, что он не может использовать больше 10% ЦП.

Разница между контейнерами и виртуальными машинами

Хотя между контейнерами и виртуальными машинами есть общие черты, также между ними есть некоторые важные различия.

Разница между контейнерами и виртуальными машинами:

Уровень виртуализации: контейнеры — это новый уровень виртуализации. Если взглянуть на историю виртуализации, то она началась с таких понятий, как виртуальная память и виртуальные машины. Контейнеры — это новый уровень этой тенденции виртуализации. Там, где виртуальные машины обеспечивают виртуализацию аппаратного обеспечения, контейнеры обеспечивают виртуализацию ОС. Это значит, что если виртуализация аппаратного обеспечения позволяет виртуальной машине верить, что её аппаратные ресурсы принадлежат только ей, виртуализация ОС позволяет контейнеру верить, что вся ОС принадлежит только ему. Важно отметить эту разницу в виртуализации. У контейнеров, к примеру, нет собственного режима ядра. По этой причине контейнеры не видны как виртуальные машины и они также не распознаются, как виртуальные машины внутри операционной системы (можете попробовать самостоятельно выполнить команду PowerShell Get-VM). Хорошая аналогия для того, чтобы объяснить эту разницу — это дома (виртуальные машины) и квартиры (контейнеры). Дома (виртуальные машины) полностью самодостаточны и предоставляют защиту от непрошенных гостей. У каждого дома также есть собственная инфраструктура — водопровод, отопление, электричество и т. д. Квартиры (контейнеры) тоже предоставляют защиту от непрошенных гостей, но они строятся на основе общей инфраструктуры. В многоквартирном доме (Docker Host) водопровод, отопление, электричество и т. д являются общими. Хотя у них обоих могут быть общие характеристики, это разные сущности.
Взаимодействие с ОС: другое важное отличие между контейнерами и виртуальными машинами заключается в способе, которым они взаимодействуют с режимом ядра. Тогда как у виртуальных машин есть полноценная ОС (и выделенный режим ядра), контейнеры разделяют “ОС (точнее, режим ядра)” с другими контейнерами и с хостом контейнеров. В результате контейнеры должны ориентироваться на ОС хоста контейнеров, в то время, как виртуальная машина может выбрать любую ОС (версию и тип), какую пожелает. Там, где виртуальные машины могут запускать ОС Linux на гипервизоре Windows, с технологией контейнеров невозможно запустить контейнер Linux на хосте контейнеров Windows, и наоборот. (В Windows 10 можно запускать контейнеры Linux, но они запускаются внутри виртуальной машины Linux — прим. перев.)
Модель роста: контейнеры разделяют ресурсы хоста контейнера, и создаются на основе образа, который содержит ровно то, что нужно для запуска вашего приложения. Вы начинаете с основ и добавляете то, что необходимо. Виртуальные машины создаются в обратном порядке. Чаще всего мы начинаем с полной операционной системы и, в зависимости от приложения, убираем вещи, которые не нужны.

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

Режим ядра

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

Режим пользователя

В режиме пользователя код всегда выполняется в отдельном процессе (пользовательском пространстве), у которого есть свой собственный набор областей памяти (собственное виртуальное адресное пространство). Так как виртуальное адресное пространство каждого приложения является собственным, одно приложение не может изменить данные, принадлежащие другому приложению. Каждое приложение выполняется в изоляции, и если приложение падает, то падение ограничено только этим приложением. В дополнение к тому, что виртуальное адресное пространство является собственным, в режиме пользователя оно ограничено. Процессор, работающий в режиме пользователя, не может получить доступ к виртуальным адресам, зарезервированным для операционной системы. Ограничение виртуального адресного пространства приложения в режиме пользователя не позволяет ему изменять, и, возможно, повреждать, критические данные операционной системы.

Техническая реализация контейнеров Windows

Но что всем этим режимам процессора делать с контейнерами? Каждый контейнер — это всего лишь “режим пользователя” процессора с парой дополнительных возможностей, таких, как изоляция пространства имён, управление ресурсами и понятием каскадно-объединённой файловой системы. Это значит, что Microsoft нужно было адаптировать операционную систему Windows, чтобы она позволяла поддерживать множественные режимы пользователя. Что-то, что было очень трудно сделать, принимая во внимание высокий уровень интеграции между обоими режимами в предыдущих версиях Windows.

До выпуска Windows Server 2016 каждая операционная система Windows, которой мы пользовались, состояла из единственного “режима пользователя” и “режима ядра”. С появлением Windows Server 2016 стало возможным иметь несколько режимов пользователя, выполняющихся в одной операционной системе. Следующая диаграмма даёт общее представление об этой новой архитектуре мульти-режимов пользователя.

Взглянув на режимы пользователя в Windows Server 2016, можно выявить два различных типа: режим пользователя хоста и режимы пользователя контейнера (зелёные блоки на диаграмме). Режим пользователя хоста идентичен обычному режиму пользователя, с которым мы знакомы по предыдущим версиям Windows. Цель этого режима пользователя — размещать основные службы Windows и процессы, такие, как Session Manager, Event Manager и сеть. Более того, этот режим пользователя облегчает, в случае реализации Windows Server Core, взаимодействие пользователя с Windows Server 2016 при помощи пользовательского интерфейса.

Новая возможность Windows Server 2016 заключается в том, что как только вы включили компонент “Контейнеры”, этот режим пользователя хоста будет содержать некоторые дополнительные технологии управления контейнерами, которые гарантируют, что контейнеры будут работать в Windows. Основа этой технологии контейнеров — абстракция Compute Services (оранжевый блок), которая даёт доступ через публичный API к низкоуровневым возможностям контейнера, предоставляемым ядром. На самом деле, эти службы содержат лишь функциональность, чтобы запускать контейнеры Windows, отслеживать, запущены ли они, и управлять функциональностью, необходимой для их перезапуска. Остальные функции управления контейнером, такие, как отслеживание всех контейнеров, хранение образов контейнеров, томов и т. д., реализованы в Docker Engine. Этот движок напрямую общается с API контейнеров Compute Services и использует для этого “биндинг языка Go”, предложенный Microsoft.

Одинаковые утилиты и команды Docker в контейнерах Windows и Linux

Хотя те же самые клиентские утилиты Docker (Docker Compose, Docker Swarm) могут управлять как контейнерами Windows, так и Linux, существуют некоторые важные отличия между реализациями контейнеров в Windows и в Linux.

Системные процессы

Там, где Linux предоставляет свою функциональность уровня ядра через системные вызовы, Microsoft решила контролировать доступную функциональность ядра при помощи DLL (это также является причиной того, почему Microsoft на самом деле не документировала свои системные вызовы). Хотя этот способ абстракции системных вызовов имеет свои преимущества, он привёл к сильно интегрированной операционной системе Windows со множеством взаимозависимостей между разными DLL Win32 и ожиданию от многих DLL, что будут запущены некоторые системные службы, на которые они (не)явно ссылаются. В результате запускать только процессы приложений, указанных в Dockerfile, внутри контейнера Windows не очень реалистично. Поэтому внутри контейнера Windows вы увидите кучу запущенных дополнительных системных процессов, в то время, как контейнерам Linux нужно запускать только указанные процессы приложений. Чтобы гарантировать, что необходимые системные процессы и службы выполняются внутри контейнера Windows, внутри каждого контейнера запускается так называемый процесс smss. Цель процесса smss — запустить нужные системные процессы и службы.

Процесс SMSS

Архитектура ОС

Каскадно-объединённая файловая система?

Третье важное отличие между реализациями контейнеров Linux и Windows заключается в способе, которым обе операционные системы используют технологию Docker “копирование-при-записи”. Так как множество приложений Windows полагается на семантику NTFS, для команды Microsoft было сложно создать полноценную реализацию каскадно-объединённой файловой системы в Windows. Для таких функций, как журналы USN и транзакции, это, к примеру, потребовало бы совершенно новой реализации. Поэтому в текущей версии контейнеров в Windows Server 2016 нет настоящей каскадно-объединённой файловой системы. Вместо этого текущая реализация создаёт новый виртуальный диск NTFS для каждого контейнера. Чтобы эти виртуальные диски оставались небольшими, различные объекты файловой системы на этом виртуальном NTFS диске на самом деле являются символическими ссылками на настоящие файлы файловой системы хоста. Как только вы изменяете файлы внутри контейнера, эти файлы сохраняются на виртуальное блочное устройство, а в момент, когда вы хотите зафиксировать этот слой изменений, изменения забираются из виртуального блочного устройства и сохраняются в нужном месте файловой системы хоста контейнера.

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

Последнее различие в реализации контейнеров Linux и Windows состоит в понятии контейнеров Hyper-V. Я напишу об этом интересном типе контейнеров в следующей статье этой серии. Оставайтесь с нами…

В *nix-системах изначально реализована многозадачность и предлагаются средства, позволяющие изолировать и контролировать процессы. Такие технологии, как chroot(), обеспечивающая изоляцию на уровне файловой системы, FreeBSD Jail, ограничивающая доступ к структурам ядра, LXC и OpenVZ, давно известны и широко используются. Но импульсом в развитии технологии стал Docker, позволивший удобно распространять приложения. Теперь подобное добралось и до Windows.

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

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

Контейнеры — это иной тип виртуализации, предоставляющий обособленную среду для выполнения приложений, называемую OS Virtualization. Реализуются контейнеры за счет использования изолированного пространства имен, включающего все необходимые для работы ресурсы (виртуализированные имена), с которыми можно взаимодействовать (файлы, сетевые порты, процессы и прочее) и выйти за которые нельзя. То есть ОС показывает контейнеру только то, что выделено. Приложение внутри контейнера считает, что оно единственное, и работает в полноценной ОС без каких-либо ограничений. Если необходимо изменить существующий файл или создать новый, контейнер получает копии с основной ОС хоста, сохраняя только измененные участки. Поэтому развертывание нескольких контейнеров на одном хосте очень эффективно.

Отличие контейнеров от виртуальных машин заключается в том, что контейнеры не загружают собственные копии ОС, библиотеки, системные файлы и прочее. Операционная система как бы делится с контейнером. Единственное, что дополнительно требуется, — это ресурсы, необходимые для запуска приложения в контейнере. В результате контейнер стартует в считаные секунды и меньше нагружает систему, чем в случае применения виртуальных машин. Docker в настоящее время предлагает 180 тысяч приложений в репозитории, а формат унифицирован в Open Container Initiative (OCI). Но зависимость от ядра подразумевает, что в другой ОС контейнеры не будут работать. Контейнеры Linux требуют Linux API, соответственно Windows в Linux работать не станет.

Разработчики Windows до недавнего времени предлагали две технологии виртуализации: виртуальные машины и виртуальные приложения Server App-V. Каждая имеет свою нишу применения, свои плюсы и минусы. Теперь ассортимент стал шире — в Windows Server 2016 анонсированы контейнеры (Windows Server Containers). И хотя на момент TP4 разработка еще не была завершена, уже вполне можно посмотреть новую технологию в действии и сделать выводы. Нужно отметить, что, догоняя и имея на руках готовые технологии, разработчики MS пошли в некоторых вопросах чуть дальше, так что использование контейнеров стало проще и более универсальным. Главное отличие в том, что предложены два вида контейнеров: контейнеры Windows и контейнеры Hyper-V. В TP3 были доступны только первые.

Контейнеры Windows используют одно ядро с ОС, которое динамично разделяют между собой. Процесс распределения (CPU, ОЗУ, сеть) берет на себя ОС. При необходимости можно ограничить максимально доступные ресурсы, выделяемые контейнеру. Файлы ОС и запущенные службы проецируются в пространство имен каждого контейнера. Такой тип контейнера эффективно использует ресурсы, уменьшая накладные расходы, а значит, позволяет более плотно размещать приложения. Этот режим в чем-то напоминает FreeBSD Jail или Linux OpenVZ.

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

Важная особенность контейнеров в Win 2016 состоит в том, что тип выбирается не в момент создания, а в момент деплоя. То есть любой контейнер может быть запущен и как Windows, и как Hyper-V.

В Win 2016 за контейнеры отвечает слой абстракции Contаiner Management stack, реализующий все нужные функции. Для хранения используется формат образа жесткого диска VHDX. Контейнеры, как и в случае с Docker, сохраняются в образы в репозитории. Причем каждый сохраняет не полный набор данных, а только отличия создаваемого образа от базового, и в момент запуска все нужные данные проецируются в память. Для управления сетевым трафиком между контейнером и физической сетью служит Virtual Switch.

Еще интересный момент. Для управления контейнерами, кроме традиционного PowerShell, можно использовать и Docker. И чтобы обеспечить возможность запуска неродных утилит на Win, MS заключила партнерское соглашение для расширения API Docker и набора инструментов. Все разработки открыты и доступны в официальном GitHub проекта Docker. Команды управления Docker применимы ко всем контейнерам как Win, так и Linux. Хотя, естественно, контейнер, созданный на Linux, запустить в Windows невозможно (как и наоборот). В настоящий момент PowerShell по функциям ограничен и позволяет работать только с локальным репозиторием.

Установка Containers

В Azure есть необходимый образ Windows Server 2016 Core with Containers Tech Preview 4, который можно развернуть и использовать для изучения контейнеров. Иначе необходимо все настроить самому. Для локальной установки нужен Win 2016, причем, так как Hyper-V в Win 2016 поддерживает вложенную виртуализацию (Nested virtualization), это может быть как физический, так и виртуальный сервер. Сам процесс установки компонента стандартен. Выбираем соответствующий пункт в мастере добавления ролей и компонентов или, используя PowerShell, даем команду

Установка компонента Containers в диспетчере серверов

В процессе установится и сетевой контроллер Virtual Switch, его сразу необходимо настроить, иначе дальнейшие действия будут выдавать ошибку. Смотрим названия сетевых адаптеров:

Для работы нам нужен контроллер с типом External. У командлета New-VMSwitch много параметров, но для примера обойдемся минимальными установками:

Настройка Virtual Switch

Файрвол Windows будет блокировать соединения к контейнеру. Поэтому необходимо создать разрешающее правило, как минимум для возможности подключаться удаленно при помощи PowerShell remoting, для этого разрешим TCP/80 и создадим правило NAT:

Есть еще один вариант простого развертывания. Разработчики приготовили скрипт, позволяющий установить все зависимости автоматически и настроить хост. При желании можно воспользоваться им. Параметры внутри скрипта помогут понять все механизмы:

Есть еще один вариант — развернуть готовую виртуальную машину с поддержкой контейнера. Для этого на том же ресурсе есть скрипт, автоматически производящий все нужные операции. Подробная инструкция приведена на MSDN. Скачиваем и запускаем скрипт:

Готовим контейнер

Имя задаем произвольное, а -WindowsImage говорит о типе собираемого образа. Вариантами могут быть NanoServer, ServerDatacenter. Сразу ставится и Docker, за его отсутствие или наличие отвечает параметр SkipDocker и IncludeDocker. После запуска начнется загрузка и преобразование образа, в процессе нужно будет указать пароль для входа в VM. Сам ISO-файл достаточно большой, почти 5 Гбайт. Если канал медленный, файл можно скачать на другом компьютере, после чего переименовать в WindowsServerTP4 и скопировать в С:\Users\Public\Documents\Hyper-V\Virtual Hard Disks . Можем залогиниться в установленную виртуальную машину, указав пароль, заданный при сборке, и работать.

Теперь можно переходить непосредственно к использованию контейнеров.

Использование контейнеров с PowerShell

Модуль Containers содержит 32 командлета PowerShell, документация по некоторым еще неполная, хотя, в общем, чтобы заставить все работать, достаточная. Перечень вывести просто:

Список командлетов модуля Containers

Получить список доступных образов можно при помощи командлета Get-ContainerImage, контейнеров — Get-Container. В случае с контейнером в колонке Status будет показан его текущий статус: остановлен или запущен. Но пока технология находится в стадии разработки, MS не представила репозиторий, да и, как говорилось, пока PowerShell работает с локальным репозиторием, поэтому для экспериментов его придется создать самому.

Итак, сервер с поддержкой у нас есть, теперь нужны сами контейнеры. Для этого ставим провайдер пакетов ContainerProvider.

Смотрим список доступных в OneGet образов.

Выбираем и ставим нужный.

Устанавливаем контейнер на локальный сервер

Проверяем, что образ действительно находится в локальном репозитории:

Для создания контейнера из образа нужно указать его имя, исходный образ и имя Virtual Switch:

В результате в ОС появляются файлы, содержащие описание нового контейнера. Дополнительно можно указать максимальный размер памяти, аккаунт для доступа, версию, издателя, путь, где создать контейнер, и так далее. Можем проверить его наличие при помощи Get-Container. И запускаем:

В этот момент контейнеру выделяются ресурсы, и, в отличие от виртуальной машины, контейнер стартует практически мгновенно. Остановка производится при помощи командлета Stop-Container.
Подключаемся при помощи PowerShell remoting:

Теперь можем выполнить любые действия как с обычной виртуальной машиной. Например, установить новую роль:

Чтобы сохранить установки, на основе контейнера можем создать образ. При этом система автоматически регистрирует зависимости между новым и базовым образом:

Можем проверить данные об образе — имя и родительский образ:

Если теперь запустить образ WindowsIIS и проверить установленные службы, то увидим наличие IIS.

Дополнительные операции

Для изменения настроек параметров контейнера предложен целый набор командлетов Add-Container и Set-Container, назначение большинства понятно из названия.

Добавим сетевой адаптер внутрь контейнера, подключим его к созданному ранее Virtual Switch и активируем соединение:

Так же просто создаются общие папки между контейнером и сервером. Добавим в контейнере новый каталог:

Затем создаем новую общую папку, выполнив на сервере

После этого необходимо перезапустить контейнер.

Использование Docker

Как уже говорилось, кроме PowerShell, для управления контейнерами могут быть использованы утилиты Docker. С точки зрения унификации это большой плюс: тем, кто раньше работал с Docker, не нужно изучать новые инструменты. Docker не устанавливается при развертывании на хосте контейнеров, это нужно сделать самому или использовать скрипты New-ContainerHost или Install-ContainerHost, о которых говорилось выше. В процессе потребуется установить клиент и запустить демон Docker с нужными параметрами. Возможно, в будущем процесс упростится и нужный пакет появится в OneGet. Пока в нем находится лишь пакет posh-docker, реализующий автодополнение команд Docker в командной строке PowerShell:

Разработчики предлагают свой вариант установки и настройки Docker, предполагающий использование NSSM, по ссылке есть все команды и скрипт. Для тестирования можно поступить проще. Скачиваем docker.exe и помещаем в каталог system32:

Запускаем службу Docker, не забыв открыть в файрволе стандартный для Docker 2375-й порт:

Теперь можем работать как с обычным Docker, только в Windows. Смотрим список доступных локальных образов:

Должны увидеть установленные при помощи PowerShell образы, можем их использовать. Но также есть готовые образы и в репозитории Docker:

Получаем в результате доступ к командной строке. Выполняем все настройки, выходим и сохраняем результат в образ:

Ищем образ в репозитории Docker

Вывод

Возможность запускать приложения в безопасной изолированной среде без увеличения нагрузки на ОС — несомненно, большой плюс новой версии Windows Server 2016. Поэтому новая фича будет востребована при развертывании и масштабировании сервисов среди разработчиков. Остается дождаться окончательного релиза.

Начиная с Windows Server 2016 в операционной системе от Microsoft включена нативная поддержка контейнеров. Это не Linux контейнеры, это контейнеры, которые работают на Windows, и запускают Windows внутри себя.

Данный факт является результатом присоединения Microsoft к Open Container Initiative (OCI). Контейнеры в Windows позволяют запускать приложения, которые изолированы от остальной части системы в переносимых контейнерах. Эти контейнеры включают в себя все, чтобы ваше приложение было полностью функциональным. Так же как это произошло с Linux, Microsoft надеется, что контейнеры изменят характер поставки программного обеспечения для пользователей и в Windows.

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

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

Docker революция стала настолько значительной, что даже Microsoft присоединился к этой инициативе в первую очередь за счет поддержки Docker и Linux в Azure, а теперь и за счет интеграции этой технологии в Windows Server 2016. Самое интересное это то, что контейнеры Windows Server не основаны на Linux, это нечто совершенно новое. Windows контейнеры — это контейнеры, которые работают в Windows и запускают Windows внутри себя.

Причем Microsoft настолько серьезно стала относится к контейнерам, что сейчас активно участвует в Open Container Initiative (OCI), пытаясь перетягивать одеяло на себя так, как будто бы она сама придумала эту технологию.

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

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

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

Microsoft планирует предложить два типа контейнеров в Windows Server 2016: контейнер Windows Server и Hyper-V контейнер. Оба типа функционируют одинаковым образом, и могут быть созданы и управляются одинаково. Там, где они различаются — это в уровне изоляции, который каждый из них обеспечивает.

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

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

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

Читайте также: