Представители Docker на своем стенде на прошедшем недавно Red Hat Summit раздавали футболки с провокационным текстом:



Ушлые журналисты из TheRegister заметили, и постепенно начал разгораться скандал. Как многим показалось, таким образом представители Docker Inc. выражали неприязнь к тому, что Red Hat в проекте Atomic используют патченную версию Docker. Наш коллега, Dan Walsh, был вынужден написать пост с разъяснениями:

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

В этой заметке мы постараемся описать все патчи, которые у нас есть:

• Объясним типы патчей.
• Опишем сами патчи.
• Приведем ссылки на обсуждения на GitHub и на PR.

Кое кто утверждает, что наш репозиторий Docker, это форк репозитория апстрим.

Что это значит - форк?

Я занимаюсь открытым ПО уже очень давно, и мое определение форка может быть устаревшим. Я полагаю, что форк, это враждебное действие, совершенное одной группой, чтобы заставить людей использовать и развивать их версию проекта, и игнорировать оригинальную. Например, LibreOffice форкнулся от OpenOffice, или ранее Xorg форкнулся от Xfree86.

Сейчас GitHub изменил значение форка. Если ПО разрабатывается на GitHub или аналогичной платформе, то каждый, кто хочет внести вклад, должен нажать кнопку fork и начать писать свои патчи. На момент написания этой заметки у Docker на GitHub есть 9860 форков, включая наш. Однако, по определению все пакеты в дистрибутиве, которые собраны с патчами, это форки. Red Hat поставляет ядро Linux, и я пока не слышал, чтобы это называли форком. Но если вы считаете, что любой проект, который поставляется с дистроспецифичными патчами, это форк, то и оно тоже форк.

Апстрим Docker даже основывается на том, что Ubuntu пропатчила AUFS патчами, которые никогда не были включены в апстрим. Т.к. RHEL и производные дистрибутивы не содержат этих патчей, то мы добавили поддержку бэкендов для Devicemapper, OverlayFS, и Btrfs, которые полностью поддерживаются апстримом ядра. Вот так должны работают дистрибутивы для серьезных задач: поставлять пакеты, собранные и сконфигурированные так, чтобы их можно было поддерживать долго.

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

Как я могу узнать подробности о патчах к конкретной версии Docker?

Все наши патчи описаны в файле README.md в соответствующем бранче нашего репозитория Docker. Например, если вы хотите посмотреть на патчи к docker-1.12, то обратите внимание на бранч docker-1.12.

Затем вы можете посмотреть на страницу со списком патчей к Docker, где есть информация про эти патчи.

Какие типы патчей включает Project Atomic?

Вот краткое описание типов патчей, которые мы используем, и инструкция по поиску информации про конкретный патч.

Бэкпорты из апстрима

Апстрим Docker Project, как правило, исправляет ошибки в следующей версии Docker. Это значит, что если пользователь столкнулся с ошибкой в docker-1.11, и мы предложили исправление в апстрим, то патч будет включен лишь в бранч master, и скорее всего никогда не будет бэкпортирован в docker-1.11.

Т.к. Docker выпускается с бешеной скоростью, то они будут предлагать пользователям обновиться до docker-1.12, когда он выйдет. Это хорошо, если пользователь хочет быть на острие разработки, но в ряде случаев новая версия приносит новые ошибки.

Например, в docker-1.11 сервис docker был разделен на три части: демон docker, containerd, и runc. Мы не считаем, что это изменение стабильно, чтобы поставлять его корпоративным пользователям сразу, как оно выйдет, хотя в этой версии и было множество исправлений для ошибок в версии docker-1.10. Много пользователей желают лишь получать обновления с исправлением ошибок, и не хотят тестировать все ПО снова каждые пару месяцев.

Другая проблема с поддержкой стабильной ветки ПО с быстро изменяющимися зависимостями, это что разработчики стабильной ветки вынуждены тратить время на проверку того, что их продукт остается стабильным каждый раз при обновлении зависимости. Это дорогостоящий процесс, и как результат зависимости обновляются нечасто. Это приводит к тому, что мы выбираем (cherry-pick) изменения из апстрима Docker и поставляем эти изменения со старыми версиями, чтобы исправлять ошибки, не обновляя или добавляя зависимости. Тот же подход мы применили, чтобы добавить capabilities в ядро Linux, подход, доказавший свою ценность для пользователей.

Патчи предложенные в апстрим

Мы также добавляем патчи, которые, как мы знаем, пользователи требуют прямо сейчас, но они еще не были включены в апстрим. Каждый патч, который мы добавляем в репозиторий Project Atomic, также предлагается на включение в апстрим-репозиторий Docker.

Эти типы патчей остаются в репозитории Project Atomic либо недолго, пока их рассматривают в апстриме на включение, либо навсегда, если апстрим отвергает их. Если мы не согласны с апстримом Docker и полагаем, что наши пользователи нуждаются в этих патчах, мы продолжаем применять их. В некоторых случаях, мы разрабатываем альтернативные подходы, например плагины для авторизации.

Например, пользователи образов RHEL, не публикуют образы Docker на публичных сайтах. Мы хотим, чтобы был возможность защитить пользователей от случайного выкладывания образа на базе RHEL на Docker Hub, и поэтому мы сначала сделали патч, которые блокирует выкладывание образа. А когда появились плагины авторизации , то мы создали плагин для защиты пользователя от публикации контента из RHEL на публичных сайтах, типа Docker Hub, и нам перестал быть нужным тот наш патч.

Подробный список патчей

Хотите знать больше о конкретном патче? Вы можете найти список патчей на нашей странице патчей к Docker.