Месяц назад компания Docker на конференции DockerCon 2017 официально представила свой новый Open Source-проект — Moby. Если это просто ещё один дополнительный проект, нужный кому-то, кто работает с Docker… то почему, как заметили внимательные пользователи, основной репозиторий компании в GitHub — docker/docker — стал пересылать на moby/moby?



Забегая вперёд и заранее отвечая на вопросы разработчиков, использующих Docker как простой способ запуска приложений в контейнерах: Moby — проект не для вас. Несмотря на его появление и происходящие внутри перестановки, «внешне» (для пользователей Docker как готового продукта) ничего не изменится. А для тех, кто настроен более глубоко разобраться в этих перестановках (весьма значимых!) и, возможно, даже воспользоваться ими для решения своих задач… начну с краткого экскурса в новейшую историю развития Docker.

Docker и «соединительный» софт: runC, containerd

Docker как платформа для запуска контейнеров использует множество вспомогательных компонентов, которые компания-разработчик называет «соединительными» (plumbing, что дословно переводится с английского как «сантехника, водопровод»). Уже не первый год инженеры Docker стараются сделать свою платформу более модульной, выделив отдельные её части в самостоятельные Open Source-проекты.

Когда в 2015 году было анонсировано первое такое крупное «отделение» — утилиты runC для запуска контейнеров, — компания опубликовала свой «Манифест соединения инфраструктуры» (Infrastructure Plumbing Manifesto), в котором зафиксировала главные принципы:

1. Всегда, когда это возможно, повторно используйте существующие соединительные решения и возвращайте свои улучшения в их кодовую базу.
2. Когда требуется создать новый соединительный инструмент, сделайте его простым для повторного использования и внесения улучшений. Это позволит увеличивать количество общедоступных компонентов, от которых выигрывают все.
3. Следуйте UNIX-принципу: несколько отдельных компонентов лучше, чем один, но сложный.
4. Определяйте стандартные интерфейсы, которые могут использоваться для сборки множества простых компонентов в более сложную систему. (Аналогия с выстраиванием в одну цепочку-команду множества консольных утилит через конвейеры в Bash.)

Отделённая тогда утилита runC выполняла одну функцию платформы Docker — запуск контейнеров. Она требовала для этого корневую файловую систему и конфигурацию, предоставляя решение всех сопутствующих задач (получение образа, его распаковку…) другим инструментам.

Весной этого года схожая участь постигла containerd — компонент, выделенный из Docker и реализующий исполняемую среду для контейнеров. Подробно о нём мы рассказывали в этой статье. Оба эти проекта (runC и containerd) не только получили свои отдельные Git-репозитории, но и независимый «дом» в виде организации CNCF (Cloud Native Computing Foundation).

И вот с недавним анонсом Moby компания пошла ещё дальше, обобщив и систематизировав свой подход к модульной архитектуре Docker.

Что такое Moby?

Изначальный анонс Moby сравнивал его с набором для конструкторов Лего из десятков компонентов и фреймворка для их сборки в комплекты (assemblies). Поясняя свои намерения, авторы говорили о стремлении «развить движение контейнеризации программного обеспечения и способствовать тому, чтобы экосистема приняла контейнеры как мейнстрим».

В более прагматичном смысле Moby оказался фреймворком, который предоставляет:

1. библиотеку контейнеризированных компонентов для всех жизненно важных аспектов контейнерной системы: операционной системы, исполняемой среды контейнера (по умолчанию это уже упомянутый containerd), оркестровки, управления инфраструктурой, поддержки сети, хранилища данных, безопасности, сборки, распространения образов и т.п.;
2. инструменты для сборки компонентов в запускаемые артефакты для всего поддерживаемого множества платформ и архитектур, т.е. bare metal для x86 и ARM, исполняемых файлов для Linux, Mac OS и Windows, образов виртуальных машин для популярных облачных сервисов и средств виртуализации;
3. набор эталонных комплектов (сборок) под названием Moby Origin, которые можно использовать или как есть, или модифицируя, или как пример для создания своих версий.

Как и в случае с самим Docker, проект Moby задаётся целью предоставить гибкое решение, при разработке которого следуют строгим руководящим принципам. Заключаются же они в следующем:

1. Все компоненты, необходимые для создания полноценной контейнерной системы, доступны, но являются заменяемыми (другими реализациями) благодаря модульной архитектуре. Кстати, вот таким примером-заменой для упомянутого containerd может являться проект rkt от авторов CoreOS.
2. Безопасность обеспечивается по умолчанию без ущерба удобству использования.
3. Ориентированность на контейнеры: «Moby создаётся с контейнерами и для запуска контейнеров».

Как Moby соотносится с Docker

С появлением Moby платформа Docker окончательно перестаёт быть «монолитом», превращаясь в продукт сборки компонентов из Moby:

Проект Moby предоставляет консольную утилиту moby, которая собирает компоненты. На данный момент она собирает загружаемые образы операционной системы, но в скором временем будет использоваться в Docker для его сборки из компонентов, многие из которых станут независимыми проектами.

Это объясняет и причину исчезновения Git-репозитория docker/docker как такового (и его пересылки на moby/moby): разработчикам теперь предлагают не единый продукт (уже собранную систему), а фреймворк для сборки такого продукта в соответствии со своими потребностями (т.е. тот самый конструктор). Одним из таких продуктов будет Docker CE (и Docker EE), а другим — может стать ваша разработка.

С помощью Moby собирается платформа Docker… и ваша контейнерная система

Поскольку появление Moby (и перенос основного репозитория) спровоцировало понятные вопросы у большого числа конечных пользователей Docker, основатель компании Соломон Хайкс (Solomon Hykes) был вынужден публично пояснить, что «пользователей [появление Moby] не затронет; бинарные файлы останутся прежними».

Для кого же тогда это?

На сайте Moby предлагается следующий список потенциальных пользователей проекта:

• хакеры, желающие подготовить или пропатчить свою сборку Docker;
• системные инженеры или интеграторы, создающие контейнерную систему;
• поставщики инфраструктурных решений, намеревающиеся адаптировать существующие контейнерные системы под своё окружение;
• энтузиасты из мира контейнеров, желающие поэкспериментировать с последними технологиями;
• Open Source-разработчики, собирающиеся протестировать свои проекты на множестве систем;
• все любопытствующие, как устроен внутри и собирается Docker.

Отдельным перечнем идёт список, кому Moby не нужен: разработчикам приложений (индивидуальным и компаниям), которые ищут простой способ запуска приложений в контейнерах (для них советуют Docker CE и Docker EE соответственно), а также любопытствующим узнать о контейнерах и найти лёгкий путь освоить их (для этого, по мнению авторов, достаточно сайта docker.com, с чем трудно спорить).

В самой компании Docker используют Moby «как научно-исследовательскую лабораторию для экспериментов, разработки новых компонентов и совместной работы над экосистемой для будущего контейнерных технологий».

Перспективы

В ближайшее время благодаря Moby можно ожидать появления дополнительных отделённых от Docker компонентов, как это произошло с runC и containerd, а также вспомогательных инструментов, альтернативных реализаций тех или иных функций от энтузиастов и компаний, новых Docker-подобных платформ, ориентированных на особые случаи применения контейнеров.

Первым проектом, условно связанным с Moby, стал анонсированный одновременно с ним LinuxKit — набор утилит для сборки своих компактных, безопасных, портируемых Linux-дистрибутивов для контейнеров. Он использует Moby для сборки образов дистрибутива. Простую практическую демонстрацию того, как Moby и LinuxKit работают в связке, можно найти в этой статье (англ. яз.).



С момента анонса Moby прошёл всего месяц, а ещё через месяц (19 июня 2017 г.) состоится первое посвящённое ему и ориентированное на «продвинутых пользователей контейнеров» мероприятие — Moby Summit, — которое должно стать ежегодным.

P.S. Читайте также «Зачем нужен containerd и почему его отделили от Docker?» и подписывайтесь на наш хаб для обновлений!