Комментарии 15
![](https://habrastorage.org/webt/p5/3_/cr/p53_cridn9dlhfpircfufbmh6g0.gif)
Особенно удобным в этом случае выглядит инвентаризация установленных зависимостей — сторонних библиотек, в которых так же могут быть уязвимости и от которых [вынужденно] зависит "основной" пакет...
— все пакеты в Alpine Linux компилируются с оптимизацией по памяти и размеру, а не по скорости;
— в библиотеке musl методы для работы с памятью (выделение и освобождение) работают медленнее чем в glibc.
Ну и в контексте питона, кроме скорости, есть ещё одна заморочка — нет возможности устанавливать бинарные сборки питонячих пакетов из PyPi, т.к. они все собраны под glibc. Приходится их собирать самому из исходников.
github.com/gliderlabs/docker-alpine/issues/300
superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image
насколько можно уменьшить образ Docker, так чтобы при этом приложение работало?
Эмм… Минимальный образ состоит из статически слинкованного бинаря приложения и более ничего. Я чего-то недопонимаю?
Зачастую во всяких scratch образах потом тяжело с отладкой, когда надо зайти в shell поковырять там.
И если несколько приложений используют скажем один общий python образ, то ведь он кешируется, а место занимают только само приложение и его зависимости.
И всё это стоит за каким-нибудь балансером или гейтвеем, что усложняет использование уязвимостей самого образа.
Зато проблем со сборкой и компиляцией на том же python alpine based добавляется много.
Тонкий образ имеет смысл для для приложений на go, там один бинарник и ковырять из shell нечего.
Спасибо, попробую)
Ура, циклическому «развитию» ИТ.
Люди фигнёй занимаются. Преждевременной оптимизацией. Внезапно выясняется, что уменьшение размера образа не проходит бесследно. Например, ffmpeg под alpine частично работоспособен. И крашится при определенном наборе аргументов. Есть нюансы со средой выполнения. Ну, там всякие TZDATA, LOCALE. И время разработчика, который делает эту микрооптимизацию существенно дороже, чем выгоды от нее. Конечно, речь не идёт прр кейсы, когда у вас образы по 5ГиБ и вы их удали до 500 мб и сэкономили терабайты трафика.
Несомненно — я не спорю с очевидными тезисами. Вроде меньше образ — меньше поверхность атаки и поле для уязвимостей. Я — за здравый и осознанный подход в каждом случае.
Крохотные образы Docker, которые верили в себя*