Месяц назад компания 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?» и подписывайтесь на наш хаб для обновлений!
Поделиться с друзьями
-->

Комментарии (7)


  1. Akuma
    22.05.2017 10:35
    +4

    Краткий ответ на вопрос:

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


    Без шуток, это стоило выделить в начале статьи, т.к. очень много «просто разработчков» использует Докер лишь для запуска микросервисов без особого вникания во внутреннюю систему.


    1. shurup
      22.05.2017 12:06
      +3

      Почему бы и нет — перенёс это замечание в начало статьи (до ката), спасибо!


      1. Akuma
        22.05.2017 13:32
        +1

        Спасибо :) Я как раз тоже задавался этим вопросом и вот нашел ответ для себя в вашей статье.


  1. drinkius
    22.05.2017 14:13
    +1

    По-моему перевод «plumbing» как «сантехника» — очень плохой, в русском языке звучит отрицательно и даже не передаёт смысл. Более правильный прямой перевод — «водопровод», по факту это о соединении частей между собой, значит «Infrastructure Plumbing Manifesto» можно перевести как «Манифест о соединении инфраструктуры»


    1. shurup
      22.05.2017 14:27

      Я, признаюсь, долго выбирал между «водопроводом» и «сантехникой», но остановился на последнем как более обширном термине, т.е. включающим в себя великое множество изделий (актуально и в случае компонентов для Docker). Отрицательного я в нём не почувствовал, но сильно спорить не буду :-)

      Найти какого-либо устоявшегося перевода не смог. Однако после вашего комментария откопал такое развёрнутое определение, в результате чего переделал в статье перевод на «соединительный» [софт, инструмент, etc] и заодно добавил эту ссылку.

      Спасибо!



  1. tru_pablo
    24.05.2017 17:59

    > your product here
    Вы свой какой-то будете выпускать, например?