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

Часто задаваемые вопросы о контейнерах

Если у вас есть вопрос о контейнерах Windows Server, возможно, ответ на него вы найдете ниже.

В чем отличие контейнеров Linux и контейнеров Windows Server?

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

Каковы предварительные требования для запуска контейнеров в Windows?

Контейнеры были введены для этой платформы начиная с версии Windows Server 2016. Для использования контейнеров требуется Windows Server 2016 или Windows 10 Anniversary update (версия 1607) или более поздней версии. Чтобы узнать больше, ознакомьтесь с системными требованиями.

Какие ОС Windows поддерживаются?

AKS в Azure Stack HCI использует Windows Server 2019 в качестве версии ОС для узла контейнеров и поддерживает только изоляцию процессом. Сведения о совместимости версий контейнеров Windows см. в этой статье.

Как поставить заплаты для моих узлов Windows?

Для узлов Windows Server на AKS в Azure Stack HCI нужно установить обновления, чтобы вы могли получить последние исправления. Центр обновлений Windows не включен на узлах Windows на AKS в Azure Stack HCI. Но AKS в Azure Stack HCI обеспечивает доступ к Центру обновлений Windows, периодически обновляя образы узлов Windows Server.

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

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

Что такое WCOW и LCOW?

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

Как осуществляется лицензирование контейнеров? Существует ли ограничение на количество контейнеров, которые я могу запустить?

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

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

*Использование рабочих контейнеров в выпусках Windows IoT зависит от того, согласились ли вы с коммерческими условиями использования образов среды выполнения Windows 10 Базовая или с лицензией для устройств Windows 10 IoT Корпоративная («коммерческое соглашение Windows IoT»). Дополнительные условия и ограничения для коммерческих соглашений по Windows IoT применяются к использованию образа контейнера в рабочей среде. Ознакомьтесь с лицензионным соглашением для образа контейнера, чтобы точно понимать, что разрешено, а что нет.

Нужно ли разработчику переписывать приложение под каждый тип контейнера?

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

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

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

Можно ли запускать контейнеры Windows в режиме изоляции процессов в Windows 10?

Если вы хотите выполнять контейнеры Windows таким образом, необходимо убедиться, что узел работает под управлением Windows 10 Build 17763+ и у вас установлена версия Docker с ядром версии 18.09 или более поздней.

Эта функция предназначена только для разработки или тестирования, но не на узлах под управлением версий IoT Базовая и IoT Корпоративная (после принятия дополнительных условий и ограничений). Для развертывания в рабочей среде в качестве узла следует продолжать использовать Windows Server. С помощью этой функции необходимо также убедиться, что теги версии узла и контейнера совпадают, в противном случае контейнер может не запуститься или продемонстрировать неожиданное поведение.

Как можно сделать образы контейнеров доступными на территориально разнесенных компьютерах?

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

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

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

Хотите добавить что-нибудь в часто задаваемые вопросы? Создайте новый отзыв в разделе комментариев или подайте запрос на включение внесенных изменений для этой страницы с помощью GitHub.

Источник

Windows контейнеры и Docker

Начиная с 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, но взамен вы получаете более изолированную и безопасную среду.

Источник

Глубокое погружение в контейнеры 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% ошибочно и может сильно запутать. Контейнеры отличаются от виртуальных машин, и поэтому я всегда представляю контейнеры как “что-то, отличное от виртуальных машин” или даже говорю “контейнеры — это НЕ виртуальные машины”. Но в чём же разница? И почему она так важна?

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

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

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

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

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

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

Контейнеры 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. Я напишу об этом интересном типе контейнеров в следующей статье этой серии. Оставайтесь с нами…

Источник

Инструменты платформы контейнеров в Windows

Майкрософт расширяет платформу контейнеров Windows. Работа с Docker была лишь первым этапом на пути к реализации контейнеров. Теперь мы создаем другие инструменты платформы контейнеров.

В этой статье рассматривается платформа контейнеров Windows и Linux, а также все инструменты платформы контейнеров.

Платформа контейнеров Windows и Linux

В средах Linux средства управления контейнерами, такие как Docker, основаны на наборе более специализированных средств для контейнеров: runc и containerd.

runc — это средство командной строки Linux для создания и запуска контейнеров в соответствии со спецификацией для среды выполнения контейнеров OCI.

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

В Windows мы применили другой подход. В начале работы с Docker для поддержки контейнеров Windows мы создавали решения непосредственно на основе HCS (служба вычисления узлов). В этой записи блога подробно объясняется, почему мы создали HCS и использовали такой подход к контейнерам вначале.

Сейчас Docker по-прежнему отправляет вызовы непосредственно в HCS. Но в будущем инструменты управления контейнерами будут включать поддержку контейнеров Windows и узел контейнера Windows сможет выполнять вызовы к containerd и runhcs так же, как это происходит в Linux.

runhcs

Функциональные различия runc и runhcs:

runhcs выполняется в Windows. Этот клиент взаимодействует с HCS для создания контейнеров и управления ими.

runhcs может запускать контейнеры различных типов.

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

— это имя запускаемого экземпляра контейнера. Имя должно быть уникальным в пределах узла контейнеров.

Для правильной работы в файле спецификации OCI (config.json) должно быть два поля:

В runhcs доступны следующие команды для контейнеров:

Инструменты для создания и запуска контейнера:

Инструменты для управления процессами, выполняющимися в контейнере:

Инструменты для управления состоянием контейнера:

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

На сайте GitHub доступны две наши оболочки, которые можно использовать для взаимодействия с HCS. Так как HCS представляет собой API для C, используйте оболочки, чтобы упростить вызов HCS на языках более высокого уровня.

Если вы хотите использовать HCS (напрямую или через оболочку) либо создать программу-оболочку Rust/Haskell/InsertYourLanguage для HCS, оставьте комментарий.

containerd/cri

CRI поддерживают только Windows Server 2019, а также Windows 10 1809 и более поздних версий. Мы все еще активно ведем разработку containerd для Windows. Это средство доступно только для разработки и тестирования.

В спецификациях OCI контейнер определен как отдельный объект. Но в CRI (интерфейс среды выполнения контейнера) контейнеры представлены как рабочие нагрузки в общей изолированной среде (песочнице), называемой pod. Такие объекты pod могут содержать одну или несколько рабочих нагрузок контейнера. Объекты pod позволяют оркестраторам контейнеров, таким как Kubernetes и сетка Service Fabric, работать с группами рабочих нагрузок, которые могут выполняться в одном узле и использовать общие ресурсы, например память и виртуальные сети.

В containerd/cri предоставляется следующая матрица совместимости для объектов pod:

* Узлы Windows 10 поддерживают только изоляцию Hyper-V

Ссылки на спецификацию CRI:

Если инструменты управления runHCS и containerd поддерживает любая система с Windows Server 2016 или более поздней версии, то для поддержки pod (групп контейнеров) потребовалось внести критически важные изменения в инструменты для контейнеров в Windows. CRI поддерживают Windows Server 2019, а также Windows 10 1809 и более поздних версий.

Источник