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

Установка контейнеров

Чтобы использовать контейнеры Windows Server, сначала вы должны установить функцию «Containers». Кроме того, если вы хотите использовать контейнеры Hyper-V, вам также будет необходимо установить функцию Hyper-V.

Затем, вам нужно будет установить и настроить Docker, который не поставляется с Windows Server 2016.

Дополнительная информация. Чтобы узнать, как настроить эту функцию и как установить и настроить Docker, перейдите на https://aka.ms/windowscontainers и прочитайте руководства по быстрому запуску.

Правила для контейнеров

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

Таблица: Поддерживаемые на хостах образы контейнеров

Для исправления хоста контейнера потребуется патч образа контейнера и для обеспечения нормальной работы — фиксация.

Microsoft будет предоставлять обновлённый образ Windows Docker на ежемесячной основе. Его вы можете использовать для восстановления образа контейнера.

Если вы планируете использовать контейнеры Hyper-V внутри гостевой виртуальной машины, необходимо обеспечить следующее:

• Для хоста контейнера включена вложенная виртуализация
• На хосте имеется не менее 4 ГБ ОЗУ
• Для операционной системы хоста вы используете Windows Server 2016 или Windows 10
• В гостевой виртуальной машине хоста требуется, по меньшей мере, два виртуальных процессора

В репозитории Docker есть дополнительные образы, которые соответствуют тем же правилам.

Подробнее. Для получения большей информации о развёртывании контейнеров Windows Server перейдите на https://msdn.microsoft.com/virtualization/windowscontainers/ quick_start/manage_docker.

Related posts:

1. Контейнеры в Windows Server 2016
2. Hyper-V в Windows Server 2016
3. Microsoft Windows Server 2016
4. VM группы в Windows Server 2016

«Пакуем окна»: изучаем технологию контейнеров от Microsoft

В *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.

В качестве ОС в контейнере может использоваться Server Core или Nano Server. Первый, в общем-то, давно не новинка и обеспечивает высокий уровень совместимости с имеющимися приложениями. Второй — еще более урезанная версия для работы без монитора, позволяющая запускать сервер в минимально возможной конфигурации для использования с Hyper-V, файловым сервером (SOFS) и облачными службами. Графический интерфейс, естественно, отсутствует. Содержит только самые необходимые компоненты (.NET с CoreCLR, Hyper-V, Clustering и так далее). Но в итоге занимает на 93% меньше места, требует меньше критических исправлений.

Еще интересный момент. Для управления контейнерами, кроме традиционного 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, даем команду

PS> Install-WindowsFeature Containers

Другие статьи в выпуске:

Xakep #206. Ключ от всех дверей

• Содержание выпуска
• Подписка на «Хакер» -60%

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

PS> Get-NetAdapter

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

PS> New-VMSwitch -Name External -NetAdapterName Ethernet0

PS> Get-VMSwitch | where

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

PS> New-NetFirewallRule -Name "TCP80" -DisplayName "HTTP on TCP/80" -Protocol tcp -LocalPort 80 -Action Allow -Enabled True PS> Add-NetNatStaticMapping -NatName "ContainerNat" -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.1.2 -InternalPort 80 -ExternalPort 80

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

PS> https://aka.ms/tp4/Install-ContainerHost -OutFile C:\Install-ContainerHost.ps1 PS> C:\Install-ContainerHost.ps1

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

PS> wget -uri https://aka.ms/tp4/New-ContainerHost -OutFile c:\New-ContainerHost.ps1 PS> C:\New-ContainerHost.ps1 –VmName WinContainer -WindowsImage ServerDatacenterCore

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

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

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

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

PS> Get-Command -module Containers

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

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

PS> Install-PackageProvider ContainerProvider -Force

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

PS> Find-ContainerImage

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

PS> Install-ContainerImage -Name WindowsServerCore

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

PS> Get-ContainerImage Name Publisher Version IsOSImage ---- --------- ------- --------- WindowsServerCore CN=Microsoft 10.0.10586.0 True

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

PS> New-Container -Name "WindowsCore" -ContainerImageName "WindowsServerCore" -SwitchName External

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

PS> Start-Container "WindowsCore"

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

PS> Enter-PSSession -ContainerName WindowsCore -RunAsAdministrator

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

PS> Install-WindowsFeature web-server

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

PS> New-ContainerImage -Name "WindowsIIS" -ContainerImageName "WindowsCore"

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

PS> Get-ContainerImage | select Name, ParentImage

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

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

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

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

PS> Add-ContainerNetworkAdapter -ContainerName "WindowsIIS" -SwitchName "External" PS> Connect-ContainerNetworkAdapter -ContainerName "WindowsIIS" -SwitchName "External"

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

PS> New-Item -Type Directory С:\share

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

PS> Add-ContainerSharedFolder -ContainerName "WindowsIIS" -SourcePath c:\share -DestinationPath c:\share\WindowsIIS

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

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

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

PS> Install-Module -Name posh-docker

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

PS> wget https://aka.ms/tp4/docker -OutFile $env:SystemRoot\system32\docker.exe

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

PS> Start-Process cmd "/k docker daemon -D -b External -H 0.0.0.0:2375”

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

PS> docker images

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

PS> docker search microsoft

PS> docker run -it --name demo microsoft/nano-iis cmd

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

C:\> exit PS> docker commit demo windowsiis

Вывод

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

Глубокое погружение в контейнеры Windows Server и Docker — Часть 2 — Реализация контейнеров 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 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.

Разница между контейнерами Windows и Linux

Одинаковые утилиты и команды 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

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

Не только в способе предоставления функциональности уровня ядра, но также и на уровне архитектуры существует важная разница в том, как обе операционные системы предоставляют функциональность контейнера клиентским утилитам Docker. В текущей реализации контейнеров в Windows Server 2016 представлен слой абстракции, называемый Compute Services, который абстрагирует низкоуровневые возможности контейнера извне. Причина этого в том, что Microsoft может менять низкоуровневый API контейнера без необходимости менять публичный API, вызываемый Docker Engine и другими клиентскими утилитами контейнеров. Кроме этого API Compute Services, вы можете написать свой собственный инструментарий управления контейнерами, используя биндинг языков C# или Go, которые доступны по адресам https://github.com/Microsoft/dotnet-computevirtualization и https://github.com/Microsoft/hcsshim.

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

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

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

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