Проблемы и решения
Хотя Docker можно смело назвать первопроходцем в новой области, он недолго оставался единственным игроком на этом поле. Почувствовав перспективу данного направления, многие компании поспешили так или иначе выразить поддержку Docker, в то время как другие пошли альтернативным путем и стали предлагать свои решения.nnОдним из наиболее заметных игроков стал проект CoreOS – легковесная система на основе ядра Linux, в которой каждое приложение запускается внутри отдельного контейнера. Изначально для управления контейнерами в CoreOS использовался Docker, однако вскоре разработчики представили свою альтернативу под названием Rocket (или сокращенно rkt). Причина создания Rocket – недовольство путем, которым пошло развитие Docker. По мнению создателей CoreOS , Docker вышел далеко за рамки начальной идеи разработки контейнера для запуска приложений, и инструментарий проекта обрастает все новым и новым функционалом. Рисунок 1.nn
nnСписок организаций, поддерживающих OCI, внушает уважение.nnКак известно, отличное от единицы количество поставщиков порождает конкуренцию и в целом приводит к положительным последствиям для конечного пользователя, не давая технологиям застыть в стагнации. С другой стороны, если альтернативные решения не совместимы друг с другом и переход с одного на другое по стоимости сравним с запуском нового проекта, то пользователи оказываются перед непростой дилеммой и риском оказаться привязанным к одному конкретному инструментарию.nnВ случае с контейнерами приложений пользователей можно разделить на несколько категорий.n
- Во-первых, это разработчики ПО, желающие использовать контейнеры для распространения своих продуктов. Идея избавиться от возни с каждой целевой системой заманчива, но не придется ли вместо этого возиться с разными форматами контейнеров?
- Во-вторых, на рынке присутствуют независимые от разработчиков распространители и магазины приложений (такие как Quay или Bitnami), для которых также привлекательна идея предоставлять различные продукты, упаковав их в контейнеры, и также не очень привлекательна перспектива подготавливать один и тот же контейнер в разных форматах.
Наконец, есть собственно пользователи, желающие скачать контейнер и запустить находящуюся в нем программу на своих машинах. Чтобы иметь возможность запускать контейнеры разных форматов, им придется устанавливать соответствующий инструментарий. Это, конечно, возможно (например, на машине под управлением Virtuozzo можно без проблем установить Docker и запускать его контейнеры наравне с «родными»), но необходимость держать зоопарк альтернативных технологий вряд ли обрадует системных администраторов.nnОтметим, что всем категориям пользователей по большому счету безразличны детали реализации того или иного инструментария – им достаточно иметь возможность подготовить один-единственный контейнер с приложением и запустить его на машине пользователя. А для этого прежде всего необходимы унифицированный формат распространения контейнеров и унифицированный способ их запуска. Именно стандартизацией этих аспектов и решили озаботиться создатели Docker, по чьей инициативе в июне 2015 года был организован проект Open Container Project, впоследствии трансформировавшийся в организацию Open Containers Initiative (OCI). Инициатива была поддержана не только разработчиками CoreOS, но и многими другими заметными участниками рынка виртуализации и облачных технологий – Amazon, Google, EMC, Red Hat, Virtuozzo и многими другими (на момент написания статьи на сайте организации было указано 46 компаний-участников, см. рис. 1). Целью OCI объявлена разработка стандартов для работы с контейнерами в Linux.n
Структура OCI
OCI создана «под крылом» The Linux Foundation, и стать членом этой ассоциации может любой член Linux Foundation, выразивший такое желание (и подписавший соответствующий документ).nnОрганизационная структура OCI подразумевает наличие в ней нескольких рабочих групп (Technical Developer Community, TDC) и одного «надзорного» комитета (Technical Oversight Board, TOB). Разработчики в группах TDC собственно и занимаются созданием стандартов, а роль TOB – чисто административная, его члены призваны разрешать возможные конфликты внутри рабочих групп, координировать их действия, а также решать, каких еще стандартов не хватает отрасли и какие группы надо создать для их разработки.nnВступить в тот или иной TDC может любой желающий и один человек может участвовать сразу в нескольких рабочих группах. В каждой группе выбираются ключевые разработчики – мейнтейнеры. Критерии, на основе которых производится выбор, должны определяться каждой группой с учетом ее реалий. В целом можно сказать, что TDC напоминают обычные свободные проекты с той разницей, что занимаются разработкой стандартов, а не ПО. При этом вся разработка ведется на GitHub – благо все файлы, кроме картинок, текстовые. Так что можно использовать все преимущества системы контроля версий, обмена изменениями, отслеживания задач и прочих сервисов.nnВыборы в TOB производятся на индивидуальной основе. При этом четыре человека в TOB выбираются мейнтейнерами рабочих групп сроком на год, а еще пять человек – организациями – членами OCI и уже сроком на два года (впрочем, они не обязаны представлять интересы компаний, в которых они работают). Отметим, что в TOB вошел и наш соотечественник Павел Емельянов, архитектор Virtuozzo.n
Спецификации и реализации
В настоящее время в рамках OCI действуют два TDC, работающих над спецификациями формата распространения контейнеров и формата запуска. Под последним понимается интерфейс взаимодействия контейнера и платформы, которая должна его запустить. Ознакомиться с результатами деятельности этих групп можно на GitHub – Image Format Specification и Runtime Specification.nnВ соответствии с духом контейнеризации сборка документации происходит внутри отдельного контейнера с утилитой pandoc. Так что для получения спецификаций в форматах PDF или HTML вам не нужно устанавливать в своей системе какие-либо инструменты обработки документов, но надо иметь возможность запустить docker-контейнер.nnЧто касается содержательного наполнения, то разработчики взяли за основу существующие решения. В качестве формата распространения выступает формат Docker Image Manifest V2, подразумевающий построение контейнера из нескольких слоев (физически представляющих собой архивы с файлами), накладывающихся друг на друга посредством каскадно-объединенного монтирования – детали этой реализации мы рассматривали в статье.nnОтметим, что формально спецификация не затрагивает вопроса хранения контейнеров. Однако на практике инструментарию удобно хранить контейнеры в таком же либо близком формате, поскольку конвертация во что-то принципиально иное может потребовать заметного количества ресурсов. Одним же из «близких» форматов является формат контейнеров в CoreOS, описанный в спецификации App Container. Конвертация образов docker/OCI в формат AppC – прямолинейный процесс, который может быть выполнен с помощью соответствующих утилит. Инструментарий rkt, используемый в CoreOS для управления контейнерами, выполняет такие преобразования автоматически.nnСпецификация формата запуска OCI основана на формате, используемом в CoreOS, и подразумевает запуск приложения на основе готового образа файловой системы. Этот образ должен сопровождаться конфигурационным файлом в формате JSON с базовыми сведениями о контейнере, включающими в себя путь к образу файловой системы, монтируемые внешние директории, команда для запуска, ее аргументы и переменные среды и тому подобное. Предусмотрена возможность вставки «хуков» – выполнения заданных команд на определенных стадиях запуска контейнера. В настоящее время поддерживается запуск команд перед стартом контейнера непосредственно после запуска его основного процесса, а также после его остановки.nnПоскольку спецификации OCI основаны на существующих решениях, которые уже поддерживались в Docker и CoreOS, то проблем с поддержкой этих спецификаций ни у того, ни у другого инструментария нет. Неудивительно, что при выходе версии 1.11 разработчики Docker смело заявили, что их продукт теперь базируется на форматах OCI. При этом созданная разработчиками Docker утилита runC, служащая для запуска контейнеров, является эталонной реализацией стандарта запуска OCI и также размещена в репозитории OCI на GitHub. Заинтересованность во взаимодействии с OCI выразили и разработчики flatpak (ранее известного как xdg-app) – инструментария запуска приложений в изолированной среде, нацеленного прежде всего на программы с графическим интерфейсом.nnНачальный этап становления той или иной отрасли – удачное время для создания стандартов. Различные реализации еще не успели удалиться друг от друга на критическое расстояние, а пользователи еще не успели крепко привязаться к одной из них. Есть все шансы, что совместные усилия разработчиков Docker и CoreOS, поддержанные большим пулом компаний, приведут к созданию спецификаций, которые станут реальными работающими стандартами.nnСпецификации OCI охватывают контейнеры как механизм распространения и запуска приложений, но не как механизм виртуализации. Тем не менее интерес к OCI проявляют и разработчики виртуализационных технологий (в частности, Virtuozzo) – ведь логично предположить, что у этих двух областей в дальнейшем будет очень много пересечений.nnНа данный момент в OCI не замечено представителей LXC, но можно предположить, что стоящая за его разработкой Canonical в настоящее время сосредоточена на своем формате распространения изолированных приложений – snap. Разрабатывать свои собственные альтернативы имеющимся решениям для Canonical не впервой, но большинство из них не выходит за пределы мира Ubuntu. Предпочтут ли в Canonical сотрудничать с остальным миром на этот раз – время покажет, но думается, что такое сотрудничество пошло бы всем на пользу.n
Внедрение и поддержка контейнерных технологий в том числе docker, подробности.