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

В эпоху развития облачных и мобильных технологий приложения задают ритм для инноваций. Контейнеры и связанная с ними экосистема позволяют создавать сервисы нового поколения. До недавнего времени контейнеры были вещью из мира 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.

Концепция контейнеров долгое время оставалась вещью из мира Linux (ну или Unix). Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux, которые могли эффективно использовать контейнеры для целей Dev/Test, а потом так же быстро и эффективно переносить контейнеры в продуктивную среду. Windows Server 2016 меняет эту парадигму: теперь контейнеры доступны и для мира Windows, причём сразу в двух лицах — в виде контейнеров Windows Server и в виде контейнеров Hyper-V. Причём Windows Server для контейнеризации использует одну из самых популярных систем в индустрии — Docker.

Кстати, 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.

Часто задаваемые вопросы о контейнерах Frequently asked questions about containers

Если у вас есть вопрос о контейнерах Windows Server, возможно, ответ на него вы найдете ниже. Have a question about Windows Server containers, see if it’s answered in the list below.

В чем отличие контейнеров Linux и контейнеров Windows Server? What’s the difference between Linux and Windows Server containers?

В ядрах и базовых операционных системах Linux и Windows Server реализованы сходные технологии. Linux and Windows Server both implement similar technologies within their kernel and core operating systems. Отличие заключается в платформе и рабочих нагрузках, выполняющихся в контейнерах. The difference comes from the platform and workloads that run within the containers.

Контейнеры Windows Server можно интегрировать с существующими технологиями Windows, например .NET, ASP.NET, PowerShell. When a customer uses Windows Server containers, they can integrate with existing Windows technologies, such as .NET, ASP.NET, and PowerShell.

Каковы предварительные требования для запуска контейнеров в Windows? What are the prerequisites for running containers on Windows?

Контейнеры были введены для этой платформы начиная с версии Windows Server 2016. Containers were introduced to the platform with Windows Server 2016. Для использования контейнеров требуется Windows Server 2016 или Windows 10 Anniversary update (версия 1607) или более поздней версии. To use containers, you’ll need either Windows Server 2016 or the Windows 10 Anniversary update (version 1607) or newer. Чтобы узнать больше, ознакомьтесь с системными требованиями. Read the System Requirements to learn more.

Какие ОС Windows поддерживаются? What Windows operating systems are supported?

AKS в Azure Stack HCI использует Windows Server 2019 в качестве версии ОС для узла контейнеров и поддерживает только изоляцию процессом. AKS on Azure Stack HCI uses Windows Server 2019 as the container host OS version and only supports process isolation. Сведения о совместимости версий контейнеров Windows см. в этой статье. For Windows container version compatibility, see Windows container version compatibility.

Как поставить заплаты для моих узлов Windows? How do I patch my Windows nodes?

Для узлов Windows Server на AKS в Azure Stack HCI нужно установить обновления, чтобы вы могли получить последние исправления. Windows Server nodes in AKS on Azure Stack HCI must be upgraded to get the latest patch fixes and updates. Центр обновлений Windows не включен на узлах Windows на AKS в Azure Stack HCI. Windows Updates are not enabled on Windows nodes in AKS on Azure Stack HCI. Но AKS в Azure Stack HCI обеспечивает доступ к Центру обновлений Windows, периодически обновляя образы узлов Windows Server. However, AKS on Azure Stack HCI makes Windows Updates available by periodically updating the Windows Server node images.

Могут ли мои контейнеры Windows Server использовать gMSA? Can my Windows Server containers use gMSA?

Да, gMSA поддерживается для подключенных к доменам рабочим узлов Windows. Yes, gMSA is supported with domain-joined Windows worker nodes. Дополнительные сведения об использовании gMSA с контейнерами Windows см. в статье Подготовка узлов Windows для gMSA. To learn more about using gMSA with Windows containers, see Prepare Windows nodes for gMSA.

Что такое WCOW и LCOW? What are WCOW and LCOW?

WCOW — сокращение для «Windows containers on Windows» (контейнеры Windows в Windows). WCOW is short for «Windows containers on Windows.» LCOW — сокращение для «Linux containers on Windows» (контейнеры Linux в Windows). LCOW is short for «Linux containers on Windows.»

Как осуществляется лицензирование контейнеров? How are containers licensed? Существует ли ограничение на количество контейнеров, которые я могу запустить? Is there a limit to the number of containers I can run?

Лицензионное соглашение для образа контейнера Windows описывает использование, которое зависит от наличия у пользователя действительной лицензии на ОС узла. The Windows container image EULA describes a usage that depends on a user having a validly licensed host OS. Количество контейнеров, которые может запустить пользователь, зависит от выпуска ОС узла и режима изоляции, с которым выполняется контейнер, а также от того, запускаются ли эти контейнеры в целях разработки/тестирования или в рабочей среде. The number of containers a user is allowed to run depends upon the host OS edition and the isolation mode a container is being run with, as well as whether these containers are running for dev/test purposes or in production.

ОС узла Host OS	Количество контейнеров при изоляции на уровне процессов Process-isolated container limit	Количество контейнеров при изоляции с помощью Hyper-V Hyper-V-isolated container limit
Windows Server Standard Windows Server Standard	Без ограничений Unlimited	2 2
Windows Server Datacenter Windows Server Datacenter	Без ограничений Unlimited	Без ограничений Unlimited
Windows 10 Профессиональная и Windows 10 Корпоративная Windows 10 Pro and Enterprise	Без ограничений (только для целей тестирования или разработки) Unlimited (for test or development purposes only)	Без ограничений (только для целей тестирования или разработки) Unlimited (for test or development purposes only)
Windows 10 IoT Базовая и Windows 10 Корпоративная Windows 10 IoT Core and Enterprise	Без ограничений Unlimited*	Без ограничений Unlimited*

Использование образа контейнера Windows Server определяется путем считывания количества гостевых виртуальных машин, поддерживаемых в этом выпуске. Windows Server container image usage is determined by reading the number of virtualization guests supported for that edition.

*Использование рабочих контейнеров в выпусках Windows IoT зависит от того, согласились ли вы с коммерческими условиями использования образов среды выполнения Windows 10 Базовая или с лицензией для устройств Windows 10 IoT Корпоративная («коммерческое соглашение Windows IoT»). *Production usage of containers on an IoT edition of Windows depend on if you have agreed to the Microsoft Commercial Terms of Use for Windows 10 Core Runtime Images or the Windows 10 IoT Enterprise Device License (“Windows IoT Commercial Agreement”). Дополнительные условия и ограничения для коммерческих соглашений по Windows IoT применяются к использованию образа контейнера в рабочей среде. Additional terms and restrictions in the Windows IoT Commercial Agreements apply to your use of Container Image in a production environment. Ознакомьтесь с лицензионным соглашением для образа контейнера, чтобы точно понимать, что разрешено, а что нет. Please read the container image EULA to understand exactly what is permitted and what is not.

Нужно ли разработчику переписывать приложение под каждый тип контейнера? As a developer, do I have to rewrite my app for each type of container?

Нет. No. Контейнеры Windows Server и изоляция Hyper-V используют общие образы. Windows container images are common across both Windows Server containers and Hyper-V isolation. Вы выбираете тип при запуске контейнера. The choice of container type is made when you start the container. С точки зрения разработчика между контейнерами Windows Server и изоляцией Hyper-V нет принципиальных различий. From a developer standpoint, Windows Server containers and Hyper-V isolation are two flavors of the same thing. Открытые и расширяемые, они предусматривают одинаковые возможности для разработки, программирования и управления, а также одинаковый уровень интеграции и поддержки с помощью Docker. They offer the same development, programming, and management experience, and are open and extensible and include the same level of integration and support with Docker.

Разработчик может создать образ контейнера с помощью контейнера Windows Server и развернуть его в изоляции Hyper-V, или наоборот, не внося изменений, лишь установив флажок необходимой среды выполнения. A developer can create a container image using a Windows Server container and deploy it in Hyper-V isolation or vice-versa without any changes other than specifying the appropriate runtime flag.

Контейнеры Windows Server обеспечивают более высокую плотность и производительность (меньшее время раскрутки, когда ключевым фактором является скорость, более высокую производительность среды выполнения по сравнению с вложенными конфигурациями). Windows Server containers offer greater density and performance for when speed is key, such as lower spin-up time and faster runtime performance compared to nested configurations. Изоляция Hyper-V, в полном соответствии со своим названием, обеспечивает лучшую изоляцию, чтобы код, выполняющийся в одном контейнере, не мог нарушить безопасность или стабильность операционной системы узла или других запущенных на нем контейнеров. Hyper-V isolation, true to its name, offers greater isolation, ensuring that code running in one container can’t compromise or impact the host operating system or other containers running on the same host. Это удобно при обслуживании одним экземпляром приложения нескольких развертываний (необходимо размещение кода без доверия), в том числе размещении приложений SaaS и среды выполнения приложений. This is useful for multitenant scenarios with requirements for hosting untrusted code, including SaaS applications and compute hosting.

Можно ли запускать контейнеры Windows в режиме изоляции процессов в Windows 10? Can I run Windows containers in process-isolated mode on Windows 10?

Начиная с обновления Windows 10 за октябрь 2018 года можно запустить контейнер Windows в изолированном процессе, но сначала необходимо напрямую запросить изоляцию процесса с помощью флага —isolation=process при запуске контейнеров с docker run . Starting with the Windows 10 October 2018 update, you can run a Windows container with process isolation, but you must first directly request process isolation by using the —isolation=process flag when running your containers with docker run . Изоляция процессов поддерживается в Windows 10 Pro, Windows 10 Корпоративная, Windows 10 IoT Базовая и Windows 10 IoT Корпоративная. Process-isolation is compatible on Windows 10 Pro, Windows 10 Enterprise, Windows 10 IoT Core and Windows 10 IoT Enterprise.

Если вы хотите выполнять контейнеры Windows таким образом, необходимо убедиться, что узел работает под управлением Windows 10 Build 17763+ и у вас установлена версия Docker с ядром версии 18.09 или более поздней. If you want to run your Windows containers this way, you’ll need to make sure your host is running Windows 10 build 17763+ and you have a Docker version with Engine 18.09 or newer.

Эта функция предназначена только для разработки или тестирования, но не на узлах под управлением версий IoT Базовая и IoT Корпоративная (после принятия дополнительных условий и ограничений). Aside from on IoT Core and IoT Enterprise hosts (after accepting additional terms and restrictions), this feature is only meant for development and testing. Для развертывания в рабочей среде в качестве узла следует продолжать использовать Windows Server. You should continue to use Windows Server as the host for production deployments. С помощью этой функции необходимо также убедиться, что теги версии узла и контейнера совпадают, в противном случае контейнер может не запуститься или продемонстрировать неожиданное поведение. By using this feature, you must also ensure that your host and container version tags match, otherwise the container may fail to start or exhibit undefined behavior.

Как можно сделать образы контейнеров доступными на территориально разнесенных компьютерах? How do I make my container images available on air-gapped machines?

Базовые образы контейнера Windows содержат артефакты, разнесение которых ограничено лицензией. Windows container base images contain artifacts whose distribution is restricted by license. Когда вы создадите эти образы и отправите их в закрытый или общедоступный реестр, вы заметите, что базовый уровень никогда не передается. When you build on these images and push them to a private or public registry, you’ll notice the base layer is never pushed. Вместо этого мы используем концепцию внешнего слоя, который ссылается на реальный базовый уровень, находящийся в облачном хранилище Azure. Instead, we use the concept of a foreign layer that points to the real base layer residing in Azure cloud storage.

Это может усложнить работу при наличии территориально удаленного компьютера, который может получать образы только из закрытого реестра контейнеров. This can complicate things when you have an air-gapped machine that can only pull images from the address of your private container registry. В этом случае попытки выполнить внешний слой для получения базового образа не будут работать. In this case, attempts to follow the foreign layer to get the base image won’t work. Чтобы переопределить поведение внешнего слоя, можно использовать флаг —allow-nondistributable-artifacts в управляющей программе Docker. To override the foreign layer behavior, you can use the —allow-nondistributable-artifacts flag in the Docker daemon.

Использование этого флага не исключает обязательства в соответствии с условиями лицензии на базовый образ контейнера Windows; не следует публиковать содержимое Windows для общедоступного распространения или для передачи третьим сторонам. Usage of this flag shall not preclude your obligation to comply with the terms of the Windows container base image license; you must not post Windows content for public or third-party redistribution. Использование в собственной среде разрешено. Usage within your own environment is allowed.

Хотите оставить дополнительный отзыв? Additional feedback

Хотите добавить что-нибудь в часто задаваемые вопросы? Want to add something to the FAQ? Создайте новый отзыв в разделе комментариев или подайте запрос на включение внесенных изменений для этой страницы с помощью GitHub. Open a new feedback issue in the comments section or set up a pull request for this page with GitHub.