Windows 10 container image manager что это

Когда я разговариваю с Linux инженерами и говорю им о проблемах Kubernetes кластера на Windows, на меня смотрят очень подозрительно. Некоторые даже не верят что

это законно

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

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

Согласно данной статье:

Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux

Действительно, контейнеры в Windows до недавнего времени были экзотикой. А хуже всего то, что документацию приходилось собирать по крохам, на каждом ресурсе будь то официальный сайт Docker или Microsoft, всё представлялось в обзорном виде без описания «как и почему», а через месяц-два и существующая информация устаревала. И в этом нет ничего сверхъестественного – контейнеры и технологии с ними связанные развиваются с какой-то нереальной скоростью.

В настоящий момент с документацией все стало лучше и что бы погрузится в мир контейнеров для Windows достаточно почитать официальную документацию от Microsoft и следить за её изменениями. Что интересно, документация написана хорошо и на русском языке, хотя при глубоком изучении вам не избежать переходов по ссылкам на различные ресурсы по типу https://www.docker.com/ или https://kubernetes.io/ где всё написано на старом добром английском языке.

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

Вы не можете запускать контейнеры Windows на Linux и на Windows*

Контейнерные технологии позволяют легко обращаться с окружением благодаря наличию переконфигурированных образов приложений. Это как Apple Appstore или Google Play, но только для инженеров и разработчиков. Как и в магазинах для мобильных приложений вы не можете поставить приложение из Google Play на iOS. Так и на Docker хосте с операционной системой Linux вы не можете запустить контейнер с операционной Windows. Верно и обратное утверждение, правда с некоторыми «но», так как Docker хост с Windows всё же может предоставить Linux окружение для запуска контейнеров.

Так же вы не можете запустить контейнер Windows в среде Windows не убедившись в совместимости версий операционной системы. Работая с контейнерами от Microsoft вам придется оглядываться на Windows Container Version Compatibility и периодически открывать данный документ.

Говоря о версионности — Microsoft с приходом контейнеров приняла решение о выпуске новых полугодовых версий Windows semi-annual. Это такие версии как windows server 1703, 1709, 1803, 1809, 1903. Цифры означают год и месяц выхода, а поддерживаются они по 18 месяцев. Первые две уже покоятся с миром и находятся в end of service. Кроме того, существуют версии LTS такие как Windows Server 2016 и Windows Server 2019. Список версий.

Так вот, если вы собрали контейнер на хосте с версией Windows 1803, то и запустить данный контейнер вы можете только на хостах с Windows 1803. Соответственно, чтобы не пересобирать каждый раз сам контейнер вам придется использовать LTS версию Windows, что при современных скоростях развития технологий не всегда оправдано. Либо всё же думать о версионности и таки постоянно пересобирать контейнеры следуя шаг в шаг за программой semi-annual.

Тэг latest в Dokerfile для Windows контейнеров присутствует не всегда и вообще он deprecated. По-хорошему вам всегда надо знать, что у вас за версия Windows и вносить соответствующие правки в Dockerfile.

Контейнеры — это часть подхода «Инфраструктура как код». Пересобирать контейнеры нужно постоянно, это не только просто и весело, но в этом и заключается основная магия, которая позволяет приложениям всегда работать на свежем улучшенном софте. Но в нашем случае мы сталкиваемся с ограничением: не получится держать универсальный Dockerfile под все системы Windows. Это необходимо учитывать.

Всё вышесказанное справедливо для контейнеров, запущенных в режиме process isolation. В режиме Hyper-V isolation действует обратная совместимость – вы можете запускать все контейнеры, которые собраны на текущей и предыдущей версиях. В общем-то с помощью Hyper-V isolation можно на хосте Windows запускать и Linux контейнеры. Но такой режим пока что поддерживает меньше плюшек, чего только стоит отсутствие Kubernetes.

Отличие process isolation и Hyper-V isolation это тема отдельной статьи. Сейчас скажу только то, что сценарии с Hyper-V isolation мне не совсем очевидны, а по умолчанию в Windows используется process isolation.

Отдельной головной болью является поиск правильных по версии образов на Docker Hub. Некоторые образы вообще отсутствуют для Windows. Например, официальной сборки Nginx, MySQL, Nodejs, как и сотни других приложений под Windows вы не найдете и вам придется собирать контейнеры самостоятельно либо использовать контейнеры, собранные и предоставленные участниками сообщества.

Windows стоит денег.

Не стоит забывать и о том, что Windows это по-прежнему платная штука. К примеру, Semi-annual версии доступны по подписке Visual Studio или при наличии Software Assurance в действующем лицензионном контракте Microsoft. Ссылка.

Но у Microsoft есть большое количество способов получит платное за бесплатно. Это и программа BizSpark и всякие trial версии Windows Server 2019 на 180 дней и прочее и прочее.

Контейнеры Windows не легковесны.

Принято считать, что контейнеры легковесны, но что правда для Linux не всегда правда для Windows. Подавляющее большинство контейнеров Windows, на первый взгляд весит непозволительно много. Да и на второй взгляд впечатление не меняется. Например, базовый образ aspnet:4.8 весит порядка 7.5 Гб.

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

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

Для управления надо хорошо знать CMD и Powershell.

Скорее всего работать вам придется с core версией Windows Server на Docker хостах. Windows Server имеет огромное количество возможностей по удаленному управлению. Общий подход такой, что имея Windows Server с графическим интерфейсом вы можете подключатся всеми графическими оснастками к любому core серверу.

Данный подход не работает в сценариях с контейнерами, хотя в контейнере и находится полноценная версия Windows Server. Внутрь контейнера Windows теоретически можно подключится по WMI, но это не так просто, хотя бы потому что хостовая ОС будет перехватывать данный трафик на себя. Контейнеров на хосте может быть несколько десятков и сотен, и в таком случае направлять трафик в нужный контейнер это целое дело.

CMD и Powershell понадобятся как для администрирования контейнеров так и самого хоста на котором установлен Docker. Так же знание данных оболочек необходимо для написания Dockerfile, так как все инструкции RUN будут выполнятся в вышеупомянутых командных оболочках.

Запомнить все длинные командлеты Powershell довольно сложно. Это вам не лаконичные команды bash. Хотя сейчас большинство командлетов имеет понятные любому Linux инженеру алиасы. В powershell можно использовать:

rm вместо Remove-Item
pwd вместо Get-Location.
cat вместо Get-Content 
touch вместо New-Item
etc.
# ключи данных команд из Linux вам тут без пользы. Команда rm –rf не прокатит.
# но в Powershell есть аналог man в котором можно всё посмотреть
Get-Help <командлет>

Из крайне полезных вещей, это то, что с помощью Powershell можно запустить в контейнере простой веб сервер для целей тестирования. В Powershell всё представляется в виде объектов. Если вы сторонник ООП, то вы быстро оцените преимущества этой командной оболочки.

В качестве заключения вводной статьи хочу сказать что я нарочно не касался вопроса оркестрации и управления кластерам. Docker на Windows находится в роли догоняющего и приложения по оркестрации такие как Swarm и Kubernetes на Windows реализуют не полный свой функционал.

Так же на текущий момент если вы хотите поднять кластер Docker, то он скорее всего будет мульти платформенный. То есть вам придется иметь в кластере один или более хостов с операционной системой Linux. Например, для Kubernetes, мастер ноды обязаны быть на Linux. А в Swarm, Linux контейнеры понадобятся, например, для реализации балансировщика на Nginx или запуска других популярных приложений для кластера, которые доступны только для Linux.

P.S. Использование Windows в контейнерах имеет весьма ограниченный набор сценариев для применения. Тем не менее эти сценарии могут оказаться крайне продуктивными. Конечно, первое что приходит на ум это web приложения на IIS, но мой опыт показывает, что в контейнерах хорошо изолируются самописные службы Windows и некоторые сервисы такие как MSMQ.

UPD. В статье есть небольшая неточность, кластер Docker на одних только Windows хостах собрать можно. Причем, это не только Swarm, но и развиваемый самим Micrisoft продукт для оркестрации кластера Service Fabric

UPD2. Docker контейнеры для Windows 10 доступны только в режиме Hyper-V isolation и используют отличные от Windows Server базовые образы.

Свершилось! То ли молитвы помогли, то ли жертвоприношения, но теперь можно запускать 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 контейнеры, нужно либо лезть в меню настроек, либо общаться с командной строкой:

Пока есть только два базовых образа с контейнерной Windows:

• microsoft/windowsservercore
• microsoft/nanoserver

Сделать свой базовый образ (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»?

Это же Windows в Докере! До сих пор звучит абсурдно.

Степени изоляции

Windows контейнера можно запускать в двух режимах изоляции:

• Windows Server Containers
• Hyper-V Containers

В первом режиме Windows контейнера ведут себя так же, как и все остальные контейнера в Docker: делят общее ядро с операционной системой, контейнерные процессы изолированы, но всё еще видны в хостовом дереве процессов, и т. п. Это дефолтный и самый быстрый способ запустить контейнер в Windows.

Во втором случае контейнера попадают особую Hyper-V виртуальную машину. Это, конечно, плохо сказывается на скорости запуска, но зато и изоляция полная.

Заключение

Windows в Докере — это просто отличные новости. Даже если не бросаться упаковывать свои продукты по контейнерам, это прекрасный инструмент для того, чтобы изолировать свои юнит-тесты, рабочие машины, сервера для демонстраций, песочницы — всё то, для чего раньше приходилось создавать виртуальную машину. Если Microsoft еще умудрится запустить nanoserver на Linux, то я им прощу недавнее снятие с производства Microsoft Band 2, неосмотрительно купленный за два месяца до этого.

Привет, Хабр! Представляю вашему вниманию перевод статьи Deep dive into Windows Server Containers and Docker – Part 2 – Underlying implementation of Windows Server Containers от автора Cornell Knulst.

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

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

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

(Изображение Albund | Dreamstime.com)

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

• Изолированное окружение: как и виртуальные машины, контейнеры гарантируют изоляцию файловой системы, переменных окружения, реестра и процессов между приложениями. Это значит, что, как и виртуальная машина, каждый контейнер создаёт изолированное окружение для всех приложений внутри себя. При миграции и контейнеры, и виртуальные машины сохраняют не только приложения внутри, но также и контекст этих приложений.
• Миграция между хостами: большое преимущество работы с виртуальными машинами в том, что можно перемещать слепки виртуальных машин между гипервизорами, при этом не нужно изменять их содержимое. Это справедливо и для контейнеров. Там, где виртуальные машины можно “перемещать” между разными гипервизорами, контейнеры можно “перемещать” между разными хостами контейнеров. При “перемещении” обоих видов артефактов между разными хостами содержимое виртуальной машины/контейнера остаётся точно таким же, как и на предыдущих хостах.
• Управление ресурсами: другая общая черта — это то, что доступные ресурсы (ЦП, ОЗУ, пропускная способность сети) как контейнеров, так и виртуальных машин могут быть ограничены до заданных значений. В обоих случаях это управление ресурсами может осуществляться только на стороне хоста контейнера или гипервизора. Управление ресурсами гарантирует, что контейнер получает ограниченные ресурсы, чтобы свести к минимуму риск того, что он повлияет на производительность других контейнеров, запущенных на том же самом хосте. К примеру, контейнеру можно задать ограничение, что он не может использовать больше 10% ЦП.

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

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

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

• Уровень виртуализации: контейнеры — это новый уровень виртуализации. Если взглянуть на историю виртуализации, то она началась с таких понятий, как виртуальная память и виртуальные машины. Контейнеры — это новый уровень этой тенденции виртуализации. Там, где виртуальные машины обеспечивают виртуализацию аппаратного обеспечения, контейнеры обеспечивают виртуализацию ОС. Это значит, что если виртуализация аппаратного обеспечения позволяет виртуальной машине верить, что её аппаратные ресурсы принадлежат только ей, виртуализация ОС позволяет контейнеру верить, что вся ОС принадлежит только ему. Важно отметить эту разницу в виртуализации. У контейнеров, к примеру, нет собственного режима ядра. По этой причине контейнеры не видны как виртуальные машины и они также не распознаются, как виртуальные машины внутри операционной системы (можете попробовать самостоятельно выполнить команду PowerShell Get-VM). Хорошая аналогия для того, чтобы объяснить эту разницу — это дома (виртуальные машины) и квартиры (контейнеры). Дома (виртуальные машины) полностью самодостаточны и предоставляют защиту от непрошенных гостей. У каждого дома также есть собственная инфраструктура — водопровод, отопление, электричество и т. д. Квартиры (контейнеры) тоже предоставляют защиту от непрошенных гостей, но они строятся на основе общей инфраструктуры. В многоквартирном доме (Docker Host) водопровод, отопление, электричество и т. д являются общими. Хотя у них обоих могут быть общие характеристики, это разные сущности.
• Взаимодействие с ОС: другое важное отличие между контейнерами и виртуальными машинами заключается в способе, которым они взаимодействуют с режимом ядра. Тогда как у виртуальных машин есть полноценная ОС (и выделенный режим ядра), контейнеры разделяют “ОС (точнее, режим ядра)” с другими контейнерами и с хостом контейнеров. В результате контейнеры должны ориентироваться на ОС хоста контейнеров, в то время, как виртуальная машина может выбрать любую ОС (версию и тип), какую пожелает. Там, где виртуальные машины могут запускать ОС Linux на гипервизоре Windows, с технологией контейнеров невозможно запустить контейнер Linux на хосте контейнеров Windows, и наоборот. (В Windows 10 можно запускать контейнеры Linux, но они запускаются внутри виртуальной машины Linux — прим. перев.)
• Модель роста: контейнеры разделяют ресурсы хоста контейнера, и создаются на основе образа, который содержит ровно то, что нужно для запуска вашего приложения. Вы начинаете с основ и добавляете то, что необходимо. Виртуальные машины создаются в обратном порядке. Чаще всего мы начинаем с полной операционной системы и, в зависимости от приложения, убираем вещи, которые не нужны.

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