Как стать автором
Обновить

«Восстание машин» часть 1: continuous delivery для базовых Docker образов

Время на прочтение 9 мин
Количество просмотров 9.1K
Всего голосов 32: ↑31 и ↓1 +30
Комментарии 26

Комментарии 26

Работа колоссальная. Сначала принесли Докер, потом оказалось, что нужно здравый смысл, и теперь здравый смысл хаками патчится в Докер.


У вас получилась обычная ОС, в которой операторы следят за ОС, а приложение деплоится поверх.


… Интересно, а можно ли убедить докер, использовать rootfs сервера в качестве basic layer?


Пройтись по всем серверам и сделать apt upgrade.

А почему тут заминусован коммент? Мог бы кто-нибудь аргументированно возразить? Кажется, важный вопрос поднят.

Докерфаны не любят, когда их макают в суровую реальность.

возможно потому что в комментарии нет вопроса?
Кажется вы купили билет на автобус и пошли пешком. Что мешает собрать новый образ, а потом сделать везде docker pull?
так вам ж написали — время меньше, сборку приложения не надо делать. Не надо делать — не сломаешь. Вообще есть уже готовые иммутабельные сборки (дистры) линукс, что как раз и обеспечивают базовый обновляемый слой… и собственно они в будущем как я понимаю движ и будут решать туже самую задачу.

Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть) — стейдж сборки приложения кеширован будет, а база+копирование из стейджа сборки результата, динамически слинкованного на «базовые либы» пересобирается. При этом, конечно, нельзя забывать про то что ABI базы должен не ломаться…
Мне сказали, а (неожиданно) не верю на слово… 20 секуд выигрыша на сборке контейнера ценой адовых извращений, с перспективой получить сторонние эффекты.
у меня в докере собирается chromium (да ещё и в куче вариаций). Соберёте его за 20 сек не имея нехилого такого облака, с кешированием артефактов сборки (промежуточных) и т.п.? Если ваши проекты собираются за 20 сек, то это, круто, честно. И если пересборка не ломает выхлоп (вы же вкурсе что, например, комиляторы тоже имеют баги оптимизаторов и даже результат одного компилера от раза к разу может быть разный ?)
Готовы рисковать — ну ок, а ребята поступили в целом правильно и здраво — нет смысла пересобирать что уже собрано, если ABI «базы» не сломан.
Еще можно вспомнить про различные репозитории артефактов, которые имеют свойство меняться при повторных сборках, даже если вы не используете открытые зависимости, а прописываете везде точные версии.
Мульти-стейдж сборку мы не рассматривали, потому что это бы потребовало переделывания механизма сборок всех наших сервисов, а их несколько сотен. И это все-таки — сборка: с запуском Docker, загрузкой слоев из реестра, их распаковкой, т.д. Намного более долгий и сложный для автоматизации процесс, чем отправка нескольких JSON по HTTP, которую можно делать in-process, в тот момент, когда это потребуется.
докер для сборки докер образов (если вы, конечно, хотите докер формат образов) не обязателен. и, более того: сейчас как раз все уходят от подобной практики.

Ну переделка оно «такое», я не знаю ваших деталей в части объемом — не могу и судить что выйгрышнее — свой велик или «студент на переделку». Вам де-факто и пришлось распортрошить докер файл на «стейджи».
Можете пояснить, почему сейчас все уходят от использования докера для сборки образов? И что используется вместо?
Потому что неудобно собирать докер, когда сборщик сам в докере.
Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть)


Не совсем так.
multistage-build — часть процесса сборки образа.
В описанном же в статье методе — image rebase сборки образа как такового нет.
Изменяеются только ссылки на слои в манифесте образа, что и даёт существенный выигрыш.

ну вот у меня два стейджа: build и out.
Пусть build юзает ubuntu:18-04, и out его же.
Я меняю out в части FROM ubuntu:18-10.
У меня НЕ будет пересборки build, а будет взят кеш и out будет на него «ссылаться».

И чем это отличается от «я сам руками правлю манифест» по-факту?

UPD: а ну ок, вы ведёте речь про то что ковыряете сам registry, без условного 'docker build...'.
Отличается временем, необходимым на создание образа. В нашем случае это существенная экономия, так как образов много, и изменения в базовые образы вносятся регулярно. Но да, это нестандартный подход, который подойдет скорее крупным сервисам. Например, перед публикацией статьи я узнал, что Google есть библиотека для манипуляции образами, в том числе с возможностью делать rebase.

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

И этим решением вы полностью ломаете концепцию идемпотентности докер образов.

Если речь про immutability, то мы ее не ломаем, потому что это невозможно: изменить существующий образ в реестре нельзя, это гарантируется уникальностью его digest-а, который есть sha256 от содержимого. Можно только переставить тег на новый образ, что мы и делаем. Но старый образ можно запросить по digest-у. Или вы что-то другое имели в виду под идемпотентностью?
Вам б расшифровать CD в заголовке, статью открыл только для того, чтоб понять, зачем вы докер образы на болванки нарезаете.
Спасибо за отзыв, поменяли название на более понятное
Есть сервисы, не содержащие бизнес-логики (например, хранилища): их написали один раз, они работают, и лишь изредка в них вносят какие-то фиксы. Ждать планового апдейта для них очень долго.

… которые были скомпилированы под старые версии библиотек. Будут веселые поиски багов, когда однажды обновится библиотека с потерей бинарной совместимости.

Промазал кнопкой – ответил вам ниже
У нас 99% Java, поэтому сказанное не столь актуально для нас. Но проблемы обновления, разумеется, возможны. Новый базовый образ сначала тестируется на небольшом числе контейнеров, прежде чем применяться ко всем остальным. И это происходит осторожно, так, как описано в разделе «Защитные меры». За 2 года помню только несколько проблем с раскаткой нового базового образа, которые были быстро обнаружены и устранены. На доступность сервисов это не повлияло, т.к. они у нас все резервированы.

Спасибо большое за статью, я выполнял другую задачу, но в процессе наткнулся на вашу статью и она очень помогла разобраться в устройстве Container Registry.

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий