company_banner

В чём суть проекта Moby и почему главным репозиторием Docker вдруг стал moby/moby?

    Месяц назад компания 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?» и подписывайтесь на наш хаб для обновлений!
    • +31
    • 18.5k
    • 7
    Флант
    336.61
    Специалисты по DevOps и Kubernetes
    Support the author
    Share post

    Comments 7

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

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


      Без шуток, это стоило выделить в начале статьи, т.к. очень много «просто разработчков» использует Докер лишь для запуска микросервисов без особого вникания во внутреннюю систему.
        +3
        Почему бы и нет — перенёс это замечание в начало статьи (до ката), спасибо!
          +1
          Спасибо :) Я как раз тоже задавался этим вопросом и вот нашел ответ для себя в вашей статье.
        +1
        По-моему перевод «plumbing» как «сантехника» — очень плохой, в русском языке звучит отрицательно и даже не передаёт смысл. Более правильный прямой перевод — «водопровод», по факту это о соединении частей между собой, значит «Infrastructure Plumbing Manifesto» можно перевести как «Манифест о соединении инфраструктуры»
          0
          Я, признаюсь, долго выбирал между «водопроводом» и «сантехникой», но остановился на последнем как более обширном термине, т.е. включающим в себя великое множество изделий (актуально и в случае компонентов для Docker). Отрицательного я в нём не почувствовал, но сильно спорить не буду :-)

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

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

            Only users with full accounts can post comments. Log in, please.