контейнеры windows server 2019
Как запустить Docker контейнеры на Windows Server 2019
В этом руководстве мы рассмотрим, как настроить сервер Windows 2019 для запуска контейнеров Docker.
Docker изменил правила работы с контейнерами приложений и проектированием и развертыванием микросервисов.
Docker позволяет легко создавать, отправлять и запускать образы, содержащие приложения с их зависимостями, и избегать сумасшедших проблем с зависимостями, характерных для виртуальных машин.
Docker engine – это то, что заставляет работать контейнеры.
Первоначально он был написан для Linux, но была проделана большая работа, чтобы позволить пользователям Windows и macOS запускать контейнеры Docker.
Как запустить Docker контейнеры на Windows Server 2019
Прежде чем вы сможете использовать контейнеры Windows для запуска нескольких изолированных приложений вашей системы, вам нужно включить функцию контейнеров и установить Docker на Windows Server 2019.
Шаг 1. Включите функцию контейнеров в Windows Server 2019
Первый шаг – включить функцию контейнеров Windows Server 2019. Откройте PowerShell от имени администратора.
Запустите следующие команды.
Это установит Docker-Microsoft PackageManagement Provider из галереи PowerShell.
Пример вывода, как показано ниже:
Шаг 2. Установите Docker на Windows Server 2019
как только функция «Контейнеры» будет включена в Windows Server 2019, установите последнюю версию Docker Engine и Client, выполнив следующую команду в сеансе PowerShell.
Согласитесь на установку, используя «yes», «Y» или «А», чтобы согласиться со всеми.
После завершения установки перезагрузите компьютер.
Установленную версию Docker можно проверить с помощью:
Обновление можно выполнить в любое время, выполнив следующие команды в PowerShell.
Шаг 3: Запустите Docker контейнер
Запустить Docker Daemon
Контейнер запустится, напечатает сообщение hello world и завершится.
Запуск контейнеров Linux на Windows Server 2019
Из коробки Docker в Windows запускает только контейнер Windows.
Чтобы использовать контейнеры Linux на Windows Server, вам нужно использовать Docker Enterprise Edition Preview, который включает в себя полную систему LinuxKit для запуска контейнеров Docker Linux.
Удалите ваш текущий Docker CE.
Включите вложенную виртуализацию, если вы используете Docker Containers с использованием виртуальной машины Linux, работающей в Hyper-V.
Затем установите текущую предварительную сборку Docker EE.
Включить систему LinuxKit для запуска контейнеров Linux
Перезапустите Docker Service после изменения.
Вытащите образ тестового докера.
Чтобы вернуться к работе с контейнерами Windows, выполните:
Наслаждайтесь работой контейнеров Linux и Windows на Windows Server 2019. Оставьте нам комментарий в случае каких-либо проблем.
2 thoughts on “ Как запустить Docker контейнеры на Windows Server 2019 ”
Вот эта команда дает ошибку
+ CategoryInfo : InvalidArgument: (WinContainerHost:String) [Get-VM], VirtualizationException
+ FullyQualifiedErrorId : InvalidParameter,Microsoft.HyperV.PowerShell.Commands.GetVM
Очевидно же WinContainerHost необходимо заменить на имя вашего сервера, на котором запускается контейнер.
Начало работы. Подготовка Windows для контейнеров
Из этого руководства вы узнаете, как выполнить следующие задачи:
Предварительные требования
Windows Server
Для запуска контейнеров на Windows Server вам понадобится физический сервер или виртуальная машина под управлением Windows Server 2022, Windows Server (Semi-Annual Channel), Windows Server 2019 или Windows Server 2016.
Windows 10
Для запуска контейнеров в Windows 10 необходимо следующее:
Начиная с Windows 10 с обновлением за октябрь 2018 г., корпорация Майкрософт не запрещает пользователям запускать контейнер Windows в режиме изоляции процессов в Windows 10 Корпоративная или Профессиональная для разработки и тестирования. Дополнительные сведения см. в разделе вопросов и ответов.
Контейнеры Windows Server по умолчанию используют изоляцию Hyper-V в Windows 10, чтобы разработчики получили ту же версию ядра и ту же конфигурацию, что и в рабочей среде. Дополнительные сведения об изоляции Hyper-V см. в статье Режимы изоляции.
Установка Docker
В конце сентября 2022 г. корпорация Майкрософт объявила об обновлении поддержки среды выполнения контейнеров Windows, чтобы уведомить клиентов о том, что мы больше не будем производить сборки Docker EE для API DockerMsftProvider. Клиентам, которые хотят установить среду выполнения контейнера в экземпляре Windows Server, рекомендуется перейти на containerd, Moby или Mirantis Container Runtime. К сентябрю 2022 года эти документы по установке будут обновлены в соответствии с процессом установки, рекомендуемым корпорацией Майкрософт.
Первым шагом станет установка Docker. Это нужно для работы с контейнерами Windows. Docker предоставляет стандартную среду выполнения для контейнеров, а также популярный API и интерфейс командной строки (CLI).
Дополнительные сведения о конфигурации см. в статье Подсистема Docker в Windows.
Чтобы установить Docker в Windows Server, можно использовать модуль PowerShell поставщика OneGet, который опубликован корпорацией Майкрософт, под именем DockerMicrosoftProvider. Этот поставщик включает поддержку контейнеров в Windows, а также устанавливает подсистему и клиент Docker. Вот как это сделать.
Откройте сеанс PowerShell с повышенными привилегиями и установите поставщик Docker-Microsoft PackageManagement из коллекции PowerShell.
Если будет предложено установить поставщик NuGet, введите Y и установите его.
С помощью модуля PackageManagement PowerShell установите последнюю версию Docker.
После установки перезагрузите компьютер.
Если позже вам потребуется обновить Docker, выполните следующие действия:
Windows Admin Center;
Вы можете использовать Windows Admin Center для корректной настройки компьютера Windows Server в качестве узла контейнера. Чтобы начать работу, убедитесь, что в вашем экземпляре Windows Admin Center установлена последняя версия расширения «Контейнеры». Дополнительные сведения об установке и настройке расширений см. в документации по Windows Admin Center. Установив расширение «Контейнеры», выберите компьютер Windows Server, который нужно настроить, и выберите вариант «Контейнеры»:
Нажмите кнопку Установить. Windows Admin Center запустит настройку Windows Server и Docker в фоновом режиме. После завершения процесса можно обновить страницу и просмотреть другие функции расширения «Контейнеры».
Вы можете установить Docker в Windows 10 Профессиональная и Корпоративная, выполнив описанные ниже действия.
Загрузите и установите Docker Desktop и создайте учетную запись Docker, если у вас ее еще нет. Вы можете создать бесплатную учетную запись Docker для частных пользователей или пользователей малого бизнеса, однако для крупных предприятий взимается ежемесячная плата. Дополнительные сведения см. в документации по Docker.
Во время установки выберите контейнеры Windows в качестве типа контейнеров по умолчанию. Чтобы переключиться после установки, можно использовать элемент Docker в области уведомлений Windows (как показано ниже) либо следующую команду в командной строке PowerShell:
Дальнейшие действия
Теперь, когда ваша среда полностью настроена, перейдите по приведенной ниже ссылке, чтобы узнать, как запустить контейнер.
Инструменты платформы контейнеров в 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 и более поздних версий.
Глубокое погружение в контейнеры 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 Server 2022, Windows Server 2019, Windows Server 2016
Контейнеры — это технология упаковки и запуска приложений 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 или других облаках:
Развертывайте контейнеры локально с помощью 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. Ниже приведены варианты, предоставляемые корпорацией Майкрософт.
Попробуйте контейнеры в Windows
Чтобы приступить к работе с контейнерами в Windows Server или Windows 10, см. следующие сведения:
Дополнительные сведения о том, какие службы Azure доступны для вашего сценария, см. в статьях Службы контейнеров Azure и Выбор служб Azure, которые будут использоваться для размещения приложений.
Ресурсы
Ознакомьтесь со следующими ресурсами по использованию контейнеров Windows Server:
Сведения о текущих проблемах и запланированных обновлениях функций см. на страницеСтратегия развития контейнеров Windows Server.
Чтобы связаться с командой по контейнерам Windows Server отправьте сообщение электронной почты в отдел обслуживания с клиентов, работающих с контейнерами Windows.