Маршрут развития проекта Moby

Как мне использовать этот документ?

Данный документ предоставляет описание элементов, которые проект решил приоритизировать. Это должно служить отправной точкой для участников проекта Moby для понимания направлений его развития и помощи в определении того, будет ли ваш вклад конфликтовать с какими-либо долгосрочными планами.

Отсутствие какой-либо функциональности в данном списке не означает, что патч для её реализации автоматически будет отклонён! Мы всегда рады принимать патчи для новых интересных функций, которые мы ещё не успели рассмотреть или которые пока не были признаны приоритетными. Однако, пожалуйста, учтите, что такие патчи могут требовать больше времени для проверки со стороны команды.

Как я могу помочь?

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

Как я могу добавить что-то в маршрут развития?Процесс маршрута развития для проекта Moby новый: мы только начинаем структурировать и документировать наши цели. Наши ближайшие цели — сделать нас более прозрачными и работать вместе с нашим сообществом для сосредоточения наших усилий на меньшем количестве приоритетных тем.

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

1. Улучшение функциональности и рефакторинг

1.1 Улучшение среды выполнения

Со временем мы накопили множество функциональностей в части контейнерной среды выполнения Moby, а также развивались в других областях. Многие компоненты контейнерной среды выполнения теперь являются дублированным трудом, доступным в других, более низкоуровневых компонентах, таких как containerd. На данный момент Moby использует только containerd для базового управления состоянием среды выполнения, например, для запуска и остановки контейнеров, что ранее предоставлялось демоном до версии containerd 1.0.Теперь, когда containerd стал полноценной средой выполнения контейнеров, поддерживающей весь цикл жизненного цикла контейнеров, мы хотели бы больше полагаться на containerd и удалить те части в Moby, которые теперь дублируются. Это потребует значительных усилий по рефакторингу и даже удалению крупных частей кодовой базы Moby. Отслеживание проблем:- #38043 Предложение: интеграция образов в containerd

1.2 Построение образов

Работа продолжается над интеграцией BuildKit в Moby и заменой реализации сборки версии "v0". BuildKit предлагает лучшее управление кэшем, параллелизуемые шаги сборки и большую гибкость при этом сохраняя портабельность сборки, что является одним из главных принципов Moby.

По завершении этой работы пользователи получат более производительный и гибкий инструмент сборки, который позволит пользователям предоставлять свои собственные персонализированные синтаксисы, которые могут быть похожими на Dockerfile или чем-то полностью другим.

Смотрите buildpacks в BuildKit как пример этой гибкости.

Новые возможности для построителя и Dockerfile должны быть реализованы сначала в Backend BuildKit с использованием внешней реализации Dockerfile из контейнерных образов. Это позволяет всем тестировать и оценивать новые возможности без необходимости обновления демона. Новые возможности следует внедрять сначала в экспериментальный канал, они могут быть частью образа docker/dockerfile:experimental. Оттуда они переходят в docker/dockerfile:latest и бинарные выпуски. Исходный код фронтенда Dockerfile временно находится по адресу https://github.com/moby/buildkit/tree/master/frontend/dockerfile, с новыми возможностями, определяемыми с помощью тегов сборки Go.Отслеживание проблем:

• #32925 Обсуждение: будущее построителя: BuildKit

1.3 Безпривилегиный режим

Запуск демона требует повышения привилегий для выполнения многих задач. Мы хотели бы поддерживать запуск демона обычным, безпривилегиным пользователем без использования двоичных файлов с повышенными правами доступа (suid).

Отслеживание проблем:

• #37375 Предложение: возможность запуска dockerd без привилегий (также известно как безпривилегиный режим)

1.4 Тестирование

У Moby много тестов, как единичных, так и интеграционных. Moby нуждается в большем количестве тестов, которые могли бы охватывать весь спектр функциональности и граничных случаев.

Тесты в папке integration-cli также следует переместить в (по расположению и стилю) папку integration. Эти новые тесты проще запускать отдельно, проще читать, проще писать и более полно тестируют API. В то же время тесты командной строки Docker CLI обычно находятся в папке docker/cli. Отслеживание проблем:

• #32866 Замена набора тестов integration-cli на набор тестов API

1.5 Внутреннее декомпозированиеБольшая работа была проделана в попытках разделить внутренние компоненты Moby. Этот процесс создания отдельных проектов с четко определённой функцией, привлекающих специализированное сообщество, следует продолжать. К тому же, помимо интеграции containerd, мы хотели бы интегрировать BuildKit как следующий автономный компонент.

Мы видим gRPC как естественный уровень связи между декомпозированными компонентами.Кроме того, выталкивая большие компоненты в другие проекты, большую часть внутренней структуры кода, а также в частности объект "Daemon", следует разделить на более мелкие, управляемые и проверяемые компоненты.