docker-иризированные приложения и вопросы по ним

как обновлять библиотеки внутри docker-контейнера?

В концепции Докера — никак. Докер-контейнер — законченное приложение. Обновлять нужно целиком контейнер.

А если в библиотеке критическая уязвимость, которую нужно было устранить день назад, то что делать с 2137-ю контейнерами, в которых библиотека (положим, openssl) используется?

Обновить все контейнеры :)

А что мешает разработчикам всё-таки собирать бинарные пакеты? Что принципиально мешает?

Зависимость бинарного пакета от конфигурации системы и взаимные конфликты таких пакетов.

Коллеги объяснили, что многие (мягко говоря) используют докер совсем не так, как задумано - в частности да, пакуют зависимости приложения вместе с самим приложением.

И проблема именно в том, что докер вообще не про это, а про доставку настраиваемого приложения-сервиса с обёртками конфигов, скриптов запуска, тюнингом параметров при запуске докер-контейнера.

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

Зависимость бинарного пакета от конфигурации системы и взаимные конфликты таких пакетов.

Предположим, я устанавливаю один из нескольких десятков тысяч пакетов для Debian. Он зависит от конфигурации и взаимных конфликтов. Но при этом после установки - работает. ЧЯДНТ?

пакуют зависимости приложения вместе с самим приложением.

А как по-другому? Вот моя прога зависит от boost. Как по мнению твоих товарищей мне её правильно(с)(тм) упаковать в контейнер?

1) 2) 3) 4) решаются созданием централизованного registry из базовых контейнеров. Разработчик при работе с контейнером не с докерхаба его должен брать, а из твоего поддерживаемого репозитория, где ты управляешь централизованным обновлением базовых слоев.

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

5) Ничего (ну кроме того что deb-формат сильно перегружен и переусложнен). Просто отсутствие квалификации.

Дело в том что докер продает иллюзию возможности использования абы чего в продакшене. И первое время это срабатывает а к моменту осознания проблем 1), 2), 3) и 4) и того что классическая пакетная схема была придумана не для усложнения жизни, а для решения именно этих проблем, оказывается уже поздно что-то менять, докер уже везде и из ушей лезет.

К тому же многие стартаперские проекты до фазы осознания просто не доживают. Они рапортуют об успехе, пишут статью об успешном внедрении докера и ускорении разработки на 1000% и тут же прыгают на другой проект оставляя после себя разруху и бардак, с которыми разбираться приходится уже old-school админам и «скучным» разработчикам «не знающим» современных подходов и технологий.

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

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

1) 2) 3) 4) решаются созданием централизованного registry из базовых контейнеров. Разработчик при работе с контейнером не с докерхаба его должен брать, а из твоего поддерживаемого репозитория, где ты управляешь централизованным обновлением базовых слоев.

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

Очень жаль, что LOR - не StackOverflow, нельзя репутацию плюсануть :)

Спасибо, отличное описание! Буду смотреть в сторону базовых слоёв.

К тому же многие стартаперские проекты до фазы осознания просто не доживают. Они рапортуют об успехе, пишут статью об успешном внедрении докера и ускорении разработки на 1000% и тут же прыгают на другой проект оставляя после себя разруху и бардак, с которыми разбираться приходится уже old-school админам и «скучным» разработчикам «не знающим» современных подходов и технологий.

причем один из этих проектов - docker.com

boost в любом дистрибутиве есть и к твоему приложению никакого отношения даже близко не имеет.

Предположим, я устанавливаю один из нескольких десятков тысяч пакетов для Debian. Он зависит от конфигурации и взаимных конфликтов. Но при этом после установки - работает. ЧЯДНТ?

Попробуйте написать пакет для дебиана, который так же работает на другой версии дебиана, центоси, арче, убунте с неопределённым количеством ppa, генте и сборке lfs от господина saahriktu.

Если вы не работаете в маргинальной конторе Рога и Копыта (просто не работайте там), то у вашего софта есть требования, в том числе к версии дистрибутива.

Если кому-то нужна кастомная сборка - за кастомные деньги делаете оную, это не так уж и сложно.

то у вашего софта есть требования, в том числе к версии дистрибутива.

Не являюсь сторонником решения технических проблем административными мерами.

который так же работает на другой версии дебиана, центоси, арче, убунте с неопределённым количеством ppa, генте и сборке lfs от господина saahriktu.

Во-первых докер так не работает. В каждой из этих систем будет своя версия докера, своё ядро, и своя fs. Того же docker для mac например два разных, при этом ещё разных версий, так что они по разному работают с сетью, volumes и по-разному интегрируются в IDE. Поэтому заявленная кроссплатформенность - миф.

Во-вторых, сама озвученная цель - совершенно искуственна и не имеет никакого отношения к реальным задачам разработки.

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

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

А ты под каждую заявленную поддерживаемую платформу будешь тестирование делать?

Или ты считаешь, что заявлять поддержку софта на платформе без тестирования - это ок, просто потому что докер?

Во-первых докер так не работает. В каждой из этих систем будет своя версия докера, своё ядро, и своя fs. Того же docker для mac например два разных, при этом ещё разных версий, так что они по разному работают с сетью, volumes и по-разному интегрируются в IDE. Поэтому заявленная кроссплатформенность - миф.

Давайте не будем бросаться столь серьёзными утверждениями. Да, докер не является абсолютно переносимым. Ну и что? По сравнению с традиционными методами развёртывания он позволяет радикально снизить требования к инфраструктуре. И поэтому он популярен и будет оставаться популярным не смотря на всю свою сырость и проблемы с совместимостью.

Во-вторых, сама озвученная цель - совершенно искуственна

А это до первого случая когда нужно будет подружить две софтины с несовместимым набором библиотек.

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

И сражаться с отделом разработки ради каждой библиотеки которую та или иная проектная команда хочет притащить в зависимости. Спасибо, всегда об этом мечтал.

А ты под каждую заявленную поддерживаемую платформу будешь тестирование делать?

Да буду. А вот париться «я тестирован на ubuntu 16.04, а у заказчика ubuntu 16.04 + какие-то программы и библиотеки поэтому мои тесты внезапно не очень релевантные» не буду. Здорово правда?

Во-вторых, сама озвученная цель - совершенно искуственна и не имеет никакого отношения к реальным задачам разработки.

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

полтора месяца прошло. хм, может к февралю допилят.

И сражаться с отделом разработки ради каждой библиотеки которую та или иная проектная команда хочет притащить в зависимости.

Перечитай начальный пост этого треда. Проблемы обновления безопасности от применения докера никуда не делись. Проблемы зоопарка софта - на месте.

При наличии пядитесяти разных версий JVM в инфраструктуре компании необходимо вести 50 разных веток багрепортов и тюнинга. При использовании 150-ти разных js библиотек выполняющих сортировку пузырьком, все 150 надо кешировать и хранить в своей инфраструктуре. И каждого разработчика переучивать каждый раз при его переходе в другую команду.

Да, если ты работаешь в маленькой команде и не заморачиваешься планами дальше чем на два месяца - можно обо всем этом не думать. Не может же твоя js-библиотека в эти два месяца случайно пропасть с npm, да же? И OpenSSL обновлять вам не надо, вы все равно его не используете... красота.

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

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

Но при этом после установки - работает. ЧЯДНТ?

Попробуй регулярно обновлять Redmine и не сломать ничего в Ruby-инфраструктуре :)

1) 2) 3) 4) решаются созданием централизованного registry из базовых контейнеров. Разработчик при работе с контейнером не с докерхаба его должен брать, а из твоего поддерживаемого репозитория, где ты управляешь централизованным обновлением базовых слоев.

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

Ещё раз, прямо по буквам:

решаются созданием централизованного registry из БАЗОВЫХ КОНТЕЙНЕРОВ

По-моему, подход очень логичный и понятный: поставляйте софт вместе с зависимостями из своего registry, но не пихайте тёплое с деревянным и мягким в один контейнер!

Почему-то я уверена что дело там не в rpm :)

пакуют зависимости приложения вместе с самим приложением
докер вообще не про это, а про доставку настраиваемого приложения-сервиса

В чем именно ты видишь противоречие?

Перечитай начальный пост этого треда. Проблемы обновления безопасности от применения докера никуда не делись.

Тоесть если технология не решает все проблемы на свете, то это плохая, негодная технология и использовать её не нужно? При всём уважении мне будет трудно принять столь экстремальный взгляд на вещи.

Да, если ты работаешь в маленькой команде и не заморачиваешься планами дальше чем на два месяца

Т.е. если использовать, то кто-то мешает заниматься планированием, выстраивать отношения, разрабатывать стандарты и т.д. и т.п.? Вот, ей Богу, вас куда-то не в ту степть заносит.

но не пихайте тёплое с деревянным и мягким в один контейнер!

Не уверен, что вполне понимаю вашу метафору. Можно то же самое более техничным языком?

При всём уважении мне будет трудно принять столь экстремальный взгляд на вещи.

Это ЛОР, без некоторой доли экстремальности тут неинтересно.

Разумеется я пользуюсь докером. И я не о технологии докера как namespaced runtime сейчас говорю, а именно о философии разработки «у нас несколько команд, и докер позволяет каждой команде разработчиков делать что угодно в своем проекте и использовать какие угодно зависимости».

Этот подход некорректен не потому что он использует докер, а именно вот этим своим лозунгом: «свободу разработчикам, несправедливо притесняемым необходимостью разговаривать с другими командами и особенно с админами, которые всё время портят нам праздник своими openssl и т.п. скучными вещами».

Проблема в том что Docker как компания выбрал этот лозунг в качестве основы своего маркетинга. И проблема в том что это очень токсичный аргумент сам по себе.

Дело в том что докер продает иллюзию возможности использования абы чего в продакшене. И первое время это срабатывает а к моменту осознания проблем 1), 2), 3) и 4) и того что классическая пакетная схема была придумана не для усложнения жизни, а для решения именно этих проблем, оказывается уже поздно что-то менять, докер уже везде и из ушей лезет.

Можно я это в рамочке на стену повешу? Давно искал эту формулировку, а сам не осилил.

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

+1, просто здорово сказано!

Во-первых докер так не работает. В каждой из этих систем будет своя версия докера, своё ядро, и своя fs

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

Все правильно. Когда вы сделали второе - то докер позволит сделать reproducible build для софта с его зависимостями. Тоесть если вы взяли образ с хешем 1312312312321 и прогнали интеграционные тесты с ним и ничего не упало, то есть основания полагать что он может идти дальше. Вы одними тестами можете покрыть и ваш софт и его environment, при условии что хост более стабилен как вы сказали выше, в рамках организации.

и особенно с админами, которые всё время портят нам праздник своими openssl

Решается всеорганизационным пинком релиза контейнера. Зато всем кто например онкол - им более понятно что новый релиз включает новую версию зависимости, через те же каналы, как он раньше включал новую фичу в коде. Не знаю как у кого нету паранои если под ваш софт кто-то тихонечко на продакшне пропихнет библиотеку новой версии.

Противоречия прямого, может быть, и нет, но есть проблема разумной достаточности. Если твоя компания наклепала 200 приложений, из которых 90 используют boost - нужно либо паковать в rpm/deb, где boost - зависимость, и полагаться на разработчиков дистрибутива, либо заниматься геморроем самостоятельно и делать свой действительно docker-дистрибутив, где boost будет базовым контейнером/базовым слоем, от которого зависят другие контейнеры.

Я не вижу никакой проблемы с дистрибутивами, особенно сейчас, когда они благодаря тому же systemd весьма неплохо унифицированы, но если собрать пакеты аж в 2-х разных форматах столь сложно - делайте свой docker-registry, где приложения всё-таки это приложения, а библиотеки - это библиотеки. С точки зрения разработчиков, они же умные люди, должно быть понятно, что приложения и библиотеки, тем более не свои вообще библиотеки, - это разные множества, и пересекать их можно разве что тогда, когда бизнес имеет сугубо «сиюминутный» характер, а в качестве методологии разработки принят принцип ХХП.

При этом ни один серьёзный заказчик не примет от вас контейнер, в котором упакована библиотека, за обновление которой никто вообще не отвечает.

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

Зачем разработчику ПО подписываться ещё и на то, чтобы содержать стороннее ПО на стороне заказчика в актуальном состоянии? И даже если это так интересно, то почему в случае такой необходимости разработчику должно быть удобнее пересобрать и выложить не один контейнер, а 90 контейнеров? Это такая форма мазохизма или традиционный русский «авось» (сейчас мне вот так по-идиотски сделать удобно - а потом, может, вообще кризис грянет и мы все умрём)?

При этом ни один серьёзный заказчик не примет от вас контейнер, в котором упакована библиотека, за обновление которой никто вообще не отвечает.

Мне кажется те, кто делали докер и активно им пользуются не думают ни о каких «приемах заказчиком». Есть одна компания, есть ее разработчики. У них есть CI и сорцы. Если че надо обновить в зависимостях - пересобрали все контейнейры, протестировали и в продакшн. Кто код пишет, тот и онкол, тот и его фиксит. Никой тебе езды на троллейбусе к какому-то заказчику с бинарями на DVD раз в месяц.

на стороне заказчика

This.

Цитирую тебя

просто не работайте там

... где есть «сторона заказчика», которая не ваша сторона, которую вы контроллируете.

Хотя я понимаю неадекватность подобного совета в общем случае, но ты первый начал )

Не знаю как у кого нету паранои если под ваш софт кто-то тихонечко на продакшне пропихнет библиотеку новой версии.

Вы сами вообще понимаете, что говорите?

Ну и да, есть такое слово, «зависимости» - это не ругательное слово, это очень полезное, важное и нужное слово. А ещё есть замечательное словосочетание «обновление зависимостей».

Кстати, интересно, а какие, собственно, известные разработчики софта сейчас пихают сборки в виде докер-контейнеров с упакованными в них зависимостями? Причём эти контейнеры не обёрнуты в какой-нибудь rpm-пакет, а просто поставляются as is - вот как хочешь, так и пользуйся. Это интересно даже не только в контексте того, как весь такой аутичный эскапизм согласуется с требованиями безопасности, но и в контексте того, что не всякий заказчик в принципе будет рад ставить docker ради того, чтобы запустить ваше чудесное приложение: мало того, что сам docker в той же CentOS приносит с собой немеряно какого-то дико полезного барахла, так ещё и ваше приложение будет за рамками пакетного менеджера. А ведь он не только зависимости отслеживает, но и, например, целостность установленных из пакетов файлов - тоже.

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

Аудиторам не понравилось. Мне, как админу, разработчики, пакующие в контейнеры docker что-то, за что они не отвечают и вообще никто не отвечает, но зато «им удобно» - почему-то тоже не нравятся.

Не докер, но контейнер

Кстати, интересно, а какие, собственно, известные разработчики софта сейчас пихают сборки в виде докер-контейнеров с упакованными в них зависимостями?

https://static.googleusercontent.com/media/research.google.com/en//pubs/archi...

Borg programs are statically linked to reduce
dependencies on their runtime environment

https://static.googleusercontent.com/media/research.google.com/en//pubs/archi...

There are many ways to achieve these hermetic images.
In Borg, program binaries are statically linked at build time to known-good library versions hosted in the company-wide repository. Even so, the Borg container image is not quite as airtight as it could have been: applications share a so-called base image that is installed once on the machine rather than being packaged in each container. This base image contains utilities such as tar and the libc library, so upgrades to the base image can affect running applications and have occasionally been a significant source of trouble.

Тут немного преувеличили, потому что это же надо такой софт написать чтобы тебе все сломала новая версия утилиты (даже не библиотеки) tar

Мне, как админу, разработчики, пакующие в контейнеры docker что-то, за что они не отвечают

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

Не знаю как у кого нету паранои если под ваш софт кто-то тихонечко на продакшне пропихнет библиотеку новой версии.

Так в докер её гораздо легче пропихнуть. Так что как раз паранойя-то у нас в наличии.

Вообще если докер использовать как систему упаковки и деплоя, то собственно проблемы с ним нет. Слои и namespaces - раньше мы их могли реализовать пакетами и зависимостями, но нужны были более строгие guidelines. Red Hat даже надстройку из scl-пакетов сделал для этого. Теперь докер позволяет namespaces зафиксировать уровнем ниже и это в принципе удобно.

Но докер приходит не один. Он приходит с зависимостями на Docker Hub, с CI pipeline управляемым изнутри проекта, с идеей о «полной свободе» разработчика и с devops-культурой в которой несмотря на название от ops не осталось ничего, а есть только dev, который об администрировании знает что там терминал и bash (в большинстве случаев ещё и маковод, то есть про дистрибутивы, пакетные менеджеры, обновления и процесс их релиза не имеет представления).

И никакого «всеорганизационного» пинка ты в такой ситуации не дашь. Организации-то нет.

Вот за организацию и боремся.

той же CentOS приносит с собой немеряно какого-то дико полезного барахла, так ещё и ваше приложение будет за рамками пакетного менеджера

Не зря запилили например CoreOS, где нету никакого пакетного менеджера. Да и софт нельзя поставить кроме как в docker/rkt. Вся ОС обновляется целиком и всегда одинаковая при условии одинаковой версии. Отличается запихнутыми контейнерами и данными.

У coreos, docker images и прочих immutable-систем пакетный менеджер есть. Только он находится не внутри образа, а снаружи.

Без внешней инфраструктуры управляющей версионированием, обновлением и зависимостями такие системы не живут.

И такой внешний пакетный менеджер стоит недешево. Его всегда нужно включать в любое сравнение.

И сражаться с отделом разработки ради каждой библиотеки которую та или иная проектная команда хочет притащить в зависимости.

Это административная проблема. Решать ее техническими средствами (Docker) - затея сомнительная.

Это техническая проблема. Решать ее административными средствами - затея сомнительная.

И сражаться с отделом разработки ради каждой библиотеки которую та или иная проектная команда хочет притащить в зависимости.

Это административная проблема.

Это техническая проблема

Отсутствие принятого в организации стандарта - техническая проблема? Ну тогда окей.

Отстутсвие возможности без боли и страданий добавить библиотеку в проект — административнаая проблема? Ну тогда окей.

о каком стандарте ты говоришь? типа «используйте только этот язык, только этот завизированный набор библиотек, а теперь быстро разошлись по рабочим местам и принесите компании денег»? такое работает?

Отстутсвие возможности без боли и страданий добавить библиотеку в проект — административнаая проблема?

Наличие возможности по желанию добавлять библиотеки в проект - фдминистраивная проблема.

Наличие возможности по желанию добавлять библиотеки в проект

Согласитесь же, что добавлять библиотеки против желания было бы как-то странно.

ЕМНИП апстрим буста приветствует идею статической линковки приложения со своей библиотекой. Ибо они нередко ломают API.

Но сама суть твоего вопроса понятно, речь не конкретно о бусте. И чтобы доставить приложение в контейнере - без накладывания туда зависимостей - никак

Согласитесь же, что добавлять библиотеки против желания было бы как-то странно.

Этот случай мне настолько не интересен, что у меня даже мнения о нем нет.

Ну, прямо скажем, что некоторая толика административного фашизма не помешает.