Блог компании Southbridge
Системное администрирование
Серверное администрирование
DevOps
Комментарии 15
0

Особенно удобным в этом случае выглядит инвентаризация установленных зависимостей — сторонних библиотек, в которых так же могут быть уязвимости и от которых [вынужденно] зависит "основной" пакет...

+3
Обсуждая размеры докер-образов все рекомендуют использовать Alpine Linux. А как в этих образах обстоят дела с производительностью? Читал в интернете отзывы, и сам проверял, что, например Python, там работает заметно медленнее, чем в образе на базе Ubuntu. В качестве объяснения этого приводились такие варианты:
— все пакеты в Alpine Linux компилируются с оптимизацией по памяти и размеру, а не по скорости;
— в библиотеке musl методы для работы с памятью (выделение и освобождение) работают медленнее чем в glibc.

Ну и в контексте питона, кроме скорости, есть ещё одна заморочка — нет возможности устанавливать бинарные сборки питонячих пакетов из PyPi, т.к. они все собраны под glibc. Приходится их собирать самому из исходников.
+1
Что интересно, для Раста дела обстоят немного по другому. В общем большое спасибо за наводку, есть куда покопать.
+5
насколько можно уменьшить образ Docker, так чтобы при этом приложение работало?

Эмм… Минимальный образ состоит из статически слинкованного бинаря приложения и более ничего. Я чего-то недопонимаю?

НЛО прилетело и опубликовало эту надпись здесь
+1

Зачастую во всяких scratch образах потом тяжело с отладкой, когда надо зайти в shell поковырять там.
И если несколько приложений используют скажем один общий python образ, то ведь он кешируется, а место занимают только само приложение и его зависимости.
И всё это стоит за каким-нибудь балансером или гейтвеем, что усложняет использование уязвимостей самого образа.
Зато проблем со сборкой и компиляцией на том же python alpine based добавляется много.


Тонкий образ имеет смысл для для приложений на go, там один бинарник и ковырять из shell нечего.

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

Ура, циклическому «развитию» ИТ.
+2

Люди фигнёй занимаются. Преждевременной оптимизацией. Внезапно выясняется, что уменьшение размера образа не проходит бесследно. Например, ffmpeg под alpine частично работоспособен. И крашится при определенном наборе аргументов. Есть нюансы со средой выполнения. Ну, там всякие TZDATA, LOCALE. И время разработчика, который делает эту микрооптимизацию существенно дороже, чем выгоды от нее. Конечно, речь не идёт прр кейсы, когда у вас образы по 5ГиБ и вы их удали до 500 мб и сэкономили терабайты трафика.


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

Только полноправные пользователи могут оставлять комментарии., пожалуйста.