Небольшое уточнение, 1) текущая stable версия Version 17.09.0-ce-win33 (13620), 17.10.0-ce (13788) — это edge версия 2) сейчас при включение этой возможности невозможно однвременно работать с Windows контейнерами.
Не знаю. Это раняя бета, что будет в релизе, неизвестно, но теоретически, вопросы взаимодействия с хотовой системы — важно для тех сценариев, где это может найти применение.
Там идея работы — прозрачная работа с контейнерами, соответсвенно, предположу, что ограничения на память должны буду задаваться ограничениями на память контейнера.
Пока что это очень раняя бета и сейчас этого там точно нет. Но, я рассчитваю, что интеграция будет прозрачной и можно будет делать подключение на уровне директорий.
Да, моя вина. Поскольку для меня это "горячая" тема, пропустил "очевидные" вещи.
Как работает Docker for Windows с Linux контейнерами? Он поднимает виртуалку с Linux, поднимает на ней Docker Engine, пробрасывет порт на Windows хост. В этом случае, реальным хостом для запуска контейнера является для Docker Linux виртуалка и, например, все COW файлы пишутся именно туда.
Теперь делаем шаг назад. Под Windows есть 2 типа контейнеров: Windows Containers и Hyper-V Windows Containers. Windows Containers устроены аналогично Linux контейнерам, а вот Hyper-V — нет. Hyper-V контейнеры запскаются каждый, как контейнер в специальной Windows виртуалке, оптимизированной под запуск контейнеров, но при этом они прозрачны для Docker Engine и на самой виртуалке незапускется Docker Engine, COW файлы пишутся на основной хост и т.д.
Так вот. То, о чём я рассказывал в этой и предыдущей статье — Hyper-V Linux контейнеры. Т.е. прозрачно для Docker Engine в специализированной виртуалке запускается Linux контенер, в самой виртуалке не запускается Docker Engine, COW файлы пишутся на Windows хост и т.д. А так как Linux дистрибутивов больше одно, то вариантов этой специализированной виртуалки может быть больше одного. В прошлый раз это была виртуалка от Docker, в этой статье — Ubuntu.
Что это означает для администратора и разработчика? Возможность прозрачного запуска, без какого-либо переключения, одновременно, всех типов Windows контейнеров, Hyper-V Linux контейнеров на одном Windows хосте, который будет для Docker Engine хостом на котором запускаются контейнеры со всеми вытекающими плюсами, вроде прозрачной интеграции networks и т.д.
Сможете использовать любые контейнеры. Идея данной реализации Hyper-V Linux контейнеры под Windows, когда прозрачно для вас на специально собраном ядре в виртуалке запускаются линукс контейнеры, но внути самой Linuх виртуалки _незапускается Docker Engine, COW файлы пишутся на Windows хост и т.д. Т.е. выглядит это, как Linix контейнер под Windows :)
Для того, чтобы организовать такую штуку, вам нужны специальные оптимизировванные образы для этих виртуалок, внутри которых запускаются контейенры. Эта статья про такой образ от Ubuntu, на которм запускается Ubuntu :) Прошлая статья про такой образ от Docker.
Это обычная hyper-v виртуалка, но с очень специальным образом, которая очень специальным образом управляется, что существенно уменьшает вермя запуска и оверхед на процессор и память.
Оверхед по памяти есть, но он невелик (в %) даже для Windows контейнера, надо будет посмотреть, когда технология отрелизится, сейчас это пока первью.
Там запускается виртуалка на Linux alpine на которой и вертится ваши все контейнеры. Просто это сделано для вас прозрачно. Запускается джокер энжин, от него побрасывется вам на виндоус машину соединение. Здесь по другому. Минимальная виртуалка на Linuxkit прозрачно для вас запускается для каждого контейнера, аналогично hyper-v контейнерам Windows. И управляется всё сразу из джокера.
Копеечные контроллеры в критических системах используют редко, если они критичные, конечно. Windows IoT нельзя использовать в критических системах — это напрямую запрещает лицензия.
Схема контроллеры-концентраторы достаточно популярная и рабочая. Никто не предлагает делать оконечные устройства на Windows IoT, в данном случае речь о концентраторах.
Каждая система подходит хорошо для своего решения/ниши. Пример, так не появилось массовых ТВ-приставок на Windows, но терминалы оплаты (типа QIWI) на Linux я вживую перестал наблюдать. Так что, я за выбор исходя из объективных критериев, куда, например, может входить наличе команды разработчиков, которая умеет на QNХ и не умеет на Windows. Хотя, мне всегда казалось, что QNХ стоит существенно дороже ...
На текущий момент эта технология не предназначена для контейнеров "непрерывного" использования, а цена больше, так как здесь уровень сервиса выше. VM — IaaS, а контейнеры ближе к SaaS, так как от вас скрыта оркестрация.
Небольшое уточнение, 1) текущая stable версия Version 17.09.0-ce-win33 (13620), 17.10.0-ce (13788) — это edge версия 2) сейчас при включение этой возможности невозможно однвременно работать с Windows контейнерами.
Не знаю. Это раняя бета, что будет в релизе, неизвестно, но теоретически, вопросы взаимодействия с хотовой системы — важно для тех сценариев, где это может найти применение.
Через некоторое время получится. Сейчас в превью
https://habrahabr.ru/company/microsoft/blog/339214/
https://habrahabr.ru/company/microsoft/blog/339746/
Взял инструкцию отсюда для LinuxKit, добавил в окружение $env:LCOW_API_PLATFORM_IF_OMITTED="linux" для запуска сервиса.
Без переменной окружения $env:LCOW_API_PLATFORM_IF_OMITTED="linux" не работало, с ней запустилось. Windows 10 Version 1709 — это как раз Update.
Запускал всё из PowerShell (Admin)
Ну, это же preview, где-то ещё не синхронизировалась кодова база. Я тоже обновился, сейчас попробую сам ещё раз и если что-то получится, отпишусь.
Не нужно будет никакого переключения, Docker network между Windows и Linux на одной машине, созданный и управляемый средствами Docker
В официальном репощитории Ubuntu образ из которого используется в этом руководстве
Там идея работы — прозрачная работа с контейнерами, соответсвенно, предположу, что ограничения на память должны буду задаваться ограничениями на память контейнера.
Пока что это очень раняя бета и сейчас этого там точно нет. Но, я рассчитваю, что интеграция будет прозрачной и можно будет делать подключение на уровне директорий.
В Linux Sub Docker не работает. Клиент — работает, engine — нет. Здесь речь о запуске контейнеров.
Вот здесь описал разницу между docker for windows и этим. Технологически, почти то же самое, но есть ньюансы: https://habrahabr.ru/company/microsoft/blog/339746/#comment_10467902
там же везде оптимизированные Docker образы без UI
Да, моя вина. Поскольку для меня это "горячая" тема, пропустил "очевидные" вещи.
Как работает Docker for Windows с Linux контейнерами? Он поднимает виртуалку с Linux, поднимает на ней Docker Engine, пробрасывет порт на Windows хост. В этом случае, реальным хостом для запуска контейнера является для Docker Linux виртуалка и, например, все COW файлы пишутся именно туда.
Теперь делаем шаг назад. Под Windows есть 2 типа контейнеров: Windows Containers и Hyper-V Windows Containers. Windows Containers устроены аналогично Linux контейнерам, а вот Hyper-V — нет. Hyper-V контейнеры запскаются каждый, как контейнер в специальной Windows виртуалке, оптимизированной под запуск контейнеров, но при этом они прозрачны для Docker Engine и на самой виртуалке не запускется Docker Engine, COW файлы пишутся на основной хост и т.д.
Так вот. То, о чём я рассказывал в этой и предыдущей статье — Hyper-V Linux контейнеры. Т.е. прозрачно для Docker Engine в специализированной виртуалке запускается Linux контенер, в самой виртуалке не запускается Docker Engine, COW файлы пишутся на Windows хост и т.д. А так как Linux дистрибутивов больше одно, то вариантов этой специализированной виртуалки может быть больше одного. В прошлый раз это была виртуалка от Docker, в этой статье — Ubuntu.
Что это означает для администратора и разработчика? Возможность прозрачного запуска, без какого-либо переключения, одновременно, всех типов Windows контейнеров, Hyper-V Linux контейнеров на одном Windows хосте, который будет для Docker Engine хостом на котором запускаются контейнеры со всеми вытекающими плюсами, вроде прозрачной интеграции networks и т.д.
Сможете использовать любые контейнеры. Идея данной реализации Hyper-V Linux контейнеры под Windows, когда прозрачно для вас на специально собраном ядре в виртуалке запускаются линукс контейнеры, но внути самой Linuх виртуалки _незапускается Docker Engine, COW файлы пишутся на Windows хост и т.д. Т.е. выглядит это, как Linix контейнер под Windows :)
Для того, чтобы организовать такую штуку, вам нужны специальные оптимизировванные образы для этих виртуалок, внутри которых запускаются контейенры. Эта статья про такой образ от Ubuntu, на которм запускается Ubuntu :) Прошлая статья про такой образ от Docker.
Это обычная hyper-v виртуалка, но с очень специальным образом, которая очень специальным образом управляется, что существенно уменьшает вермя запуска и оверхед на процессор и память.
Оверхед по памяти есть, но он невелик (в %) даже для Windows контейнера, надо будет посмотреть, когда технология отрелизится, сейчас это пока первью.
Это другая технология, но, безусловно, похожая. Смысл здесь в прозрачной интеграции Docker engine + минимальный Linux Kit + специальная виртуалка.
Идея здесь в прозрачной интеграции Docker engine + минимальный Linux Kit.
Там запускается виртуалка на Linux alpine на которой и вертится ваши все контейнеры. Просто это сделано для вас прозрачно. Запускается джокер энжин, от него побрасывется вам на виндоус машину соединение. Здесь по другому. Минимальная виртуалка на Linuxkit прозрачно для вас запускается для каждого контейнера, аналогично hyper-v контейнерам Windows. И управляется всё сразу из джокера.
Расписание доступно по ссылке https://events.techdays.ru/Microsoft-Developer-School/2017-09/schedule
Копеечные контроллеры в критических системах используют редко, если они критичные, конечно. Windows IoT нельзя использовать в критических системах — это напрямую запрещает лицензия.
Схема контроллеры-концентраторы достаточно популярная и рабочая. Никто не предлагает делать оконечные устройства на Windows IoT, в данном случае речь о концентраторах.
Каждая система подходит хорошо для своего решения/ниши. Пример, так не появилось массовых ТВ-приставок на Windows, но терминалы оплаты (типа QIWI) на Linux я вживую перестал наблюдать. Так что, я за выбор исходя из объективных критериев, куда, например, может входить наличе команды разработчиков, которая умеет на QNХ и не умеет на Windows. Хотя, мне всегда казалось, что QNХ стоит существенно дороже ...
На текущий момент эта технология не предназначена для контейнеров "непрерывного" использования, а цена больше, так как здесь уровень сервиса выше. VM — IaaS, а контейнеры ближе к SaaS, так как от вас скрыта оркестрация.