Comments 20
Мне кажется, что заголовок слишком категоричен, хотя очевидно, что проблемы и вправду есть. Я правда тоже сталкивался с некоторыми проблемами, при использовании альпайна, но они тоже все были связаны с переходом на поетрю и пайдантик в проектах. С тех пор, когда это зависит от меня, использую двухэтапную сборку на базе slim контейнеров.
Да, сборка на базе debian более предсказуемая что ли.
На alpine у меня крутятся совсем уж простые приложения типа notifier (данные из http перекладывает в telegram). Там кода совсем немного и будет легко отдебажить если что. Вот для него экономия в размере получилась больше, чем в 2 раза. Это, как по мне, уже существенно.
Не пробовали Configuring Docker with Btrfs ну и Use the BTRFS storage driver?
Ну и так, например:
find /usr/share/doc -depth -type f | xargs rm || true
rm -rf /usr/share/man/* /usr/share/groff/* /usr/share/info/* /usr/share/lintian/* /usr/share/linda/* /var/cache/man/*Нет, с btrfs не пробовал экспериментировать, так что спасибо за наводку.
А чем здесь поможет btrfs?
В целом, можно взять образ на основе Debian slim, применить скрипт выше, и с помощью multistage скопировать все файлы в новый stage на базе scratch. По сути это будет тоже самое, что слить все правки в один слой. А поверх него уже собирать образ с приложением.
Используется сжатие на уровне файловой системы btrfs с zstd компрессией.(Use the BTRFS storage driver)
sudo apt install btrfs-progs btrfs-compsizСкрин для примера
Для экономии места можно схлопнуть все промежуточные слои в один финальный слой так: sudo docker build --squash -t
Параметр squash (Squash an image’s layers (--squash) experimental).
"применить скрипт выше" это какой?
а можно сложный вопрос - Работает ли в докере компрессия памяти? те имея 100500 запущенных "контейнеров" на сервере жмется ли память для них? дедупликация?
Речь об оперативной памяти?
Насколько я понимаю, контейнер - такой же процесс ОС, как и любой другой, но с выделенной cgroups (namespaces и layerfs). Т.е. если в целом компрессия памяти на хостовой ОС включена, то она будет работать и для контейнера.
У альпайна еще были проблемы с резолвингом ДНС. Незнаю как сейчас правда.
Не понимаю зачем вообще использовать Alpine образы. В debian есть куча мусора, но кому до неё есть дело, если кроме места на диске, она ни как негативно не влияет на производительность и скорость разработки? 100мб лишнего занятого пространства, как мне кажется наименьшая из проблем, даже если образов десятки
Не знаю как это применить, но оч интересно!
Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.
При этом совершенно не понятны плюсы, кроме размера одного базового образа.
Размер образа перестаёт иметь значение когда у вас больше одного контейнера.
Нижние слои переиспользуются, можно даже собрать базовый контейнер с основными зависимостями для вашего стека и переиспользовать его во всех контейнерах.
У вас нет причин использовать alpine для python-проектов