У вас нет причин использовать alpine для python-проектов

[shpaker]

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

[TyVik]

Да, сборка на базе debian более предсказуемая что ли.

На alpine у меня крутятся совсем уж простые приложения типа notifier (данные из http перекладывает в telegram). Там кода совсем немного и будет легко отдебажить если что. Вот для него экономия в размере получилась больше, чем в 2 раза. Это, как по мне, уже существенно.

[Johan_Palych]

Не пробовали 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/*

[TyVik]

Нет, с btrfs не пробовал экспериментировать, так что спасибо за наводку.

[dolfinus]

А чем здесь поможет btrfs?

В целом, можно взять образ на основе Debian slim, применить скрипт выше, и с помощью multistage скопировать все файлы в новый stage на базе scratch. По сути это будет тоже самое, что слить все правки в один слой. А поверх него уже собирать образ с приложением.

[Johan_Palych]

Используется сжатие на уровне файловой системы btrfs с zstd компрессией.(Use the BTRFS storage driver)

sudo apt install btrfs-progs btrfs-compsiz

Скрин для примера

[Johan_Palych]

Для экономии места можно схлопнуть все промежуточные слои в один финальный слой так: sudo docker build --squash -t
Параметр squash (Squash an image’s layers (--squash) experimental).

[dolfinus]

Не, squash всех слоев в образе с приложением полностью ломает кэширование.

А squash только одного слоя (который к тому же можно сделать отдельным образом) все ещё даёт возможность использовать кэш, правда только при сборке на том же хосте, где собиралась предыдущая версия образа

[Supervadim]

"применить скрипт выше" это какой?

[dolfinus]

https://habr.com/ru/post/707858/comments/#comment_25052380

[not-allowed-here]

а можно сложный вопрос - Работает ли в докере компрессия памяти? те имея 100500 запущенных "контейнеров" на сервере жмется ли память для них? дедупликация?

[dolfinus]

Речь об оперативной памяти?

[not-allowed-here]

да, именно про нее - тк кпд использования при существенных количествах мелких контейнеров становится критичным

[dolfinus]

Я просто не совсем понимаю, о какой компрессии и дедупликации идёт речь. zram? KSM+copy-on-write?

Контейнеры - это обычные процессы, запущенные в своих изолированных namespace (pid, network, fs, etc). Все, что работает для процессов на хосте, работает и для процессов в контейнерах.

[TyVik]

Насколько я понимаю, контейнер - такой же процесс ОС, как и любой другой, но с выделенной cgroups (namespaces и layerfs). Т.е. если в целом компрессия памяти на хостовой ОС включена, то она будет работать и для контейнера.

[slisli]

У альпайна еще были проблемы с резолвингом ДНС. Незнаю как сейчас правда.

[Roman_Cherkasov]

Не понимаю зачем вообще использовать Alpine образы. В debian есть куча мусора, но кому до неё есть дело, если кроме места на диске, она ни как негативно не влияет на производительность и скорость разработки? 100мб лишнего занятого пространства, как мне кажется наименьшая из проблем, даже если образов десятки

[nkokarovtsev]

Не знаю как это применить, но оч интересно!

[B7W]

Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.

При этом совершенно не понятны плюсы, кроме размера одного базового образа.

[gudvinr]

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