Почему выбрали Alpine образы для контейнеров вместо Slim?

Что проверяют

Понимаете ли вы, чем Alpine отличается от Debian-образа на деле, а не по строчке про размер. Для Python это прежде всего вопрос про бинарные колёса: смотрят, знаете ли вы про musl и manylinux и умеете ли считать итоговый образ, а не базовый слой.

Как отвечать

Разложите различие честно. Alpine собран на musl libc и BusyBox, базовый слой весит единицы мегабайт. Slim это обрезанный Debian с обычной glibc.

Ключевое следствие для Python: готовые колёса в PyPI собираются под тег manylinux, то есть под glibc. На Alpine pip такое колесо не подходит и начинает собирать пакет из исходников. В образе появляются компилятор и заголовки, минуты вместо секунд в сборке, а результат с научным или криптографическим стеком выходит крупнее, чем на slim. Колёса musllinux существуют, но публикуют их далеко не все проекты.

Разумная позиция звучит так: по умолчанию slim, Alpine осознанно, когда зависимости чистые или собираются быстро, а размер действительно критичен. Размер лучше сбивать другим: многостадийная сборка, установка зависимостей отдельным слоем ради кэша, --no-cache-dir у pip, аккуратный .dockerignore.

Где спотыкаются

Называют вес голого Alpine как размер питоновского образа. Сравнивать нужно финальные образы после установки зависимостей, и там разрыв часто оказывается в обратную сторону.

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

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