Свершилось! То ли молитвы помогли, то ли жертвоприношения, но теперь можно запускать Docker контейнеры с Windows внутри. Прекрасная новость пришла одновременно с релизом Windows Server 2016. И речь не идёт о какой-нибудь хитро-спрятанной виртуальной машине, или эмуляции Windows на Linux ядре — запускается настоящая Windows в настоящем Docker, с работающими Dockerfile, docker-compose и прочими docker-приблудами.
Ограничения
Но это не значит, что теперь можно запускать любой контейнер где угодно. Из-за того, что Docker контейнеры «отдалживают» ядро операционной системы у своего хоста (а иначе им пришлось бы иметь свою ОС и превращаться в виртуальную машину), Windows контейнеры можно запускать только на свежих Windows 10 Pro Anniversary Update и Windows Server 2016 .
Второй момент, запустить нативно Linux контейнер на Windows всё еще нельзя. В Anniversary Update есть собственная Linux подсистема (с помощью которой можно запустить настоящий Bash, например), но она не дотягивает для полноценного Linux-ядра, так что для того же контейнера с Убунтой на Windows всё еще нужна спрятанная виртуальная машина.
Наконец, одновременно запускать те и другие контейнеры на Windows машине можно, но с танцем. Если выполнить такую команду в Windows Server 2016 с установленным Docker (год назад я бы обозвал такое колдовством), оно сработает:
Но если после этой команды попробовать запустить Ubuntu контейнер, Docker взгрустнёт:
Проблема в том, что Windows и Linux контейнера обслуживаются разными Docker-демонами, которые, тем не менее, используют один и тот же канал для общения с командной строкой. То есть в каждый момент времени только один демон может быть активным. На официальном Докер-сайте есть бета «Docker for Windows «, которая пытается справиться проблемой (пока только на Windows 10 Pro и Enterprise). Но даже с ней, чтобы переключиться с Windows на Linux контейнеры, нужно либо лезть в меню настроек, либо общаться с командной строкой:
PowerShell
& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon
& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon |
Образы с Windows
Пока есть только два базовых образа с контейнерной Windows:
Сделать свой базовый образ (scratch image) — нельзя.
Образ Windows Server Core весит аж 10 гигов и в целом ведёт себя как полноценная Windows Server 2016. Например, MS SQL и полноценный.NET Framework устанавливаются там без проблем. Если ваше приложение не сильно зависит от UI, то установится и оно.
Nano Server слегка интереснее. Это очень оптимизированная и урезанная Windows Server, которая весит меньше гига. Но и ограничений хватает: нет 32-битных приложений, UI, RDP, порезаный PowerShell, и т.д. Но это не мешает поставить на Nano Server тот же IIS, .NET Core, и даже какой-нибудь MySQL.
И кто-нибудь мог представить пару лет назад, что в Dockerfile можно будет встретить сразу «Microsoft», «Windows» и «PowerShell»?
FROM microsoft/windowsservercore RUN powershell -Command....
FROM microsoft / windowsservercore RUN powershell - Command . . . . |
Это же Windows в Докере! До сих пор звучит абсурдно.
Степени изоляции
Windows контейнера можно запускать в двух режимах изоляции:
- Windows Server Containers
- Hyper-V Containers
В первом режиме Windows контейнера ведут себя так же, как и все остальные контейнера в Docker: делят общее ядро с операционной системой, контейнерные процессы изолированы, но всё еще видны в хостовом дереве процессов, и т. п. Это дефолтный и самый быстрый способ запустить контейнер в Windows.
Во втором случае контейнера попадают особую Hyper-V виртуальную машину. Это, конечно, плохо сказывается на скорости запуска, но зато и изоляция полная.
Заключение
Windows в Докере — это просто отличные новости. Даже если не бросаться упаковывать свои продукты по контейнерам, это прекрасный инструмент для того, чтобы изолировать свои юнит-тесты, рабочие машины, сервера для демонстраций, песочницы — всё то, для чего раньше приходилось создавать виртуальную машину. Если Microsoft еще умудрится запустить nanoserver на Linux, то я им прощу недавнее снятие с производства Microsoft Band 2, неосмотрительно купленный за два месяца до этого.
В *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
В процессе установится и сетевой контроллер Virtual Switch, его сразу необходимо настроить, иначе дальнейшие действия будут выдавать ошибку. Смотрим названия сетевых адаптеров:
PS> Get-NetAdapter
Для работы нам нужен контроллер с типом External. У командлета New-VMSwitch много параметров, но для примера обойдемся минимальными установками:
PS> New-VMSwitch -Name External -NetAdapterName Ethernet0
Проверяем:
PS> Get-VMSwitch | where {$_.SwitchType –eq "External"}
Файрвол 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.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
У меня есть приложение, написанное на NodeJS. Как я могу упаковать его в образ Docker, чтобы запускать как контейнер?
Docker - система управления контейнерами в POSIX-совместимых операционных системах (на данный момент поддерживается Linux). Особенностью Docker является возможность упаковать приложение со всем необходимым окружением таким образом, чтобы запускать его на другой системе без долгих и сложных процедур установки зависимостей или сборки из исходников. Запакованное приложение, готовое к развёртыванию, называется "образом". Образы Docker основываются на "шаблонах" - предварительно настроенных рабочих окружениях. Можно рассматривать это как дистрибутивы операционной системы, хотя это и не совсем так. Кроме того, изучив документацию на Docker, вы сможете создать собственный шаблон. Преимуществом такого подхода является то, что образ вашего приложения будет содержать только само приложение, а необходимое для него окружение будет скачиваться автоматически из репозитория шаблонов. Docker слегка напоминает chroot или bsd jail, но работает иначе.
Важно различать для себя понятия "контейнер" и "образ". Контейнер - это выполняющаяся копия вашего приложения, а образ - это файл, в котором хранится приложение, и из которого и создаётся контейнер.
Предположим, что у вас есть приложение на NodeJS, которое вы хотите упаковать в контейнер. Предположим, что файл, который запускает ваше приложение называется server.js, а для работы приложение слушает порт 8000. В качестве шаблона мы будем использовать "node:carbon". Для контейнеризации приложения вам нужно создать в каталоге, где расположены файлы вашего приложения, файл "Dockerfile", в котором будут описаны параметры подготовки образа:
$ touch Dockerfile
Содержимое файла может быть примерно таким:
# Указываем используемый шаблон FROM node:carbon # Создаём рабочий каталог приложения внутри контейнера WORKDIR /usr/src/app # Устанавливаем зависимости приложения с помощью npm # Копируются оба файла package.json И package-lock.json, если они присутствуют COPY package*.json ./ RUN npm install # Копируем в образ файлы вашего приложения COPY . . # Открываем порт 8000 чтобы он был доступен снаружи контейнера EXPOSE 8000 # Выполняем команду для запуска приложения внутри контейнера CMD [ "npm", "start" ]
Чтобы исключить ненужные файлы из образа, вы можете перечислить их имена в файле ".dockerignore". Допускается использование маски (*.log).
Сборка образа осуществляется следующей командой:
$ docker build -t username/node-web-app .
$ docker images # Example REPOSITORY TAG ID CREATED node carbon 1934b0b038d1 5 days ago username/node-web-app latest d64d3505b0d2 1 minute ago
Запуск контейнера из образа производится следующей командой:
$ docker run -p 49160:8000 -d username/node-web-app
В этом примере создаётся контейнер из образа "username/node-web-app" и сразу запускается. Порт приложения 8000 доступен на локальной машине (localhost) и для того, чтобы он был доступен "снаружи", он "пробрасывается" на порт 49160. Можно выбрать любой свободный порт, кроме того возможно пробросить порт приложения "как есть", указав опцию "-p 8000:8000".
Вы можете увидеть что ваш контейнер выполняется, введя команду:
$ docker ps # Example ID IMAGE COMMAND ... PORTS ecce33b30ebf username/node-web-app:latest npm start ... 49160->8000
Управление контейнером можно осуществлять различными командами, указывая ID этого контейнера:
$ docker pause ecce33b30ebf - приостановить работу контейнера с ID ecce33b30ebf
$ docker resume ecce33b30ebf - возобновить работу контейнера с ID ecce33b30ebf
$ docker stop ecce33b30ebf - остановить контейнер c ID ecce33b30ebf
$ docker rm ecce33b30ebf - удалить контейнер (при этом удаляются все данные, созданные приложением внутри контейнера)
Контейнеры в Microsoft Windows Server 2016 стали расширением возможностей технологии для клиентов. Microsoft планирует разработки клиентов, развертывания и теперь хостинг приложений в контейнерах как часть их процессов развития.
По мере того как темпы развертывания приложений продолжают увеличиваться и клиенты используют развертывания версий приложений ежедневно или даже ежечасно, возможность быстрого развертывания приложений валидацию с клавиатуры разработчика для производства определяет решающее значение для успеха бизнеса. Этот процесс ускоряется контейнерами.
В то время как виртуальные машины имеют функцию переноса приложений в центрах обработки данных и в облако и за его пределы, ресурсы виртуализации дополнительно разблокированы контейнерами с помощью виртуализации ОС (Системный софт). Данное решение, благодаря виртуализации, позволит осуществить быструю доставку приложений.
Технология Windows Контейнер включает в себя два различных типа контейнеров, Windows Server Контейнер и Hyper-V Контейнеры. Оба типа контейнеров создаются, управляются и функционируют одинаково. Они даже производят и потребляют тот же образ контейнера. Отличается они между собой уровнем изоляции, созданного между контейнером, операционной системы хоста и всех других контейнеров, запущенных на хосте.
Windows Server Контейнеры : Несколько экземпляров контейнеров могут работать одновременно на хосте с изоляцией, предоставляемой через пространство имен, управления ресурсами и изоляции процессов технологий. Windows Server Контейнеры имеют одно и то же ядро, расположенное на хосте.
Hyper-V Контейнеры : Несколько экземпляров контейнеров могут работать одновременно на хосте. Тем не менее, каждый контейнер реализован внутри специальной виртуальной машины. Это обеспечивает изоляцию уровня ядра между каждым Hyper-V контейнером и контейнером хоста.
Microsoft включил в функцию контейнера набор инструментов Docker по управлению не только контейнерами Linux, но и контейнерами Windows Server и Hyper-V. В рамках сотрудничества в сообществах Linux и Windows , был расширен опыт Docker путем создания модуля PowerShell для Docker , который представлен теперь с открытым исходным кодом для. Модуль PowerShell может управлять Linux и Windows Sever контейнерами локально или удаленно с помощью REST API Docker технологии. Разработчики удовлетворены внедрением инноваций для клиентов с помощью открытого исходного кода для развитием нашей платформы. В дальнейшем планируется принести технологии для наших клиентов наряду с инновациями, как Hyper-V.
