По мотивам моего доклада на PyCon "Контейнеризация Python без боли". На своей практике я постоянно сталкиваюсь со спорами какой базовый образ лучше использовать для проектов: alpine или debian. Аргументы есть и у той, и у другой стороны, но мне это настолько надоело, что я решил сам разобраться и наконец-то поставить точку. В конце концов "В наше время верить нельзя никому, даже себе. Но мне - можно." (с) Перед тем, как мы перейдём к специфике запуска python-проектов под alpine, давайте посмотрим на код базовых образов и сравним что они нам предлагают. Debian: Alpine Т.е. что alpine, что debian, состоят по сути из одного слоя куда распаковывается файловая система. Давайте заглянем что же там находится. Кстати, alpine-minirootfs-3.17.0-x86_64.tar.gz весит всего 3 Mb, а rootfs.tar.xz аж 31 Mb. В распакованном виде 6.7 Mb и 122 Mb соответственно. Внушительная разница, не правда ли? За счёт чего? Сравним 2 каталога: Разница примерно везде. Но бросается в глаза размер каталога usr - аж 100 Mb! Заглянем в него (я игнорирую все каталоги меньше 100k иначе список получится очень большой): Т.е. погодите - 31 Mb под локали? 13 Mb - под документацию? там ещё gconv на 7.6 Mb? Разработчики образа debian, вы вообще там место не считаете?! Как часто программистам нужен man внутри контейнера? Лично мне примерно никогда. Аналогично в /bin и /sbin есть утилиты, которые пригождаются крайне редко (при работе контейнера): lsblk, df, debugfs, swapon/swapoff... Выглядит как мусор, но кто я такой, чтобы спорить с авторами настолько популярного базового образа. В любом случае, если основательно почистить образ, то можно ужать если не до 7 Mb, то хотя бы в 2 раза - до 50 Mb. Но всё это, как не странно, мелочи. Основное отличие alpine от debian в бинарниках. Если сравнить каталог /bin, то в debian лежат полноценные бинарники, в то время как у alpine ссылки на /bin/busybox. И тут мы переходим к вопросу "а что же такое дистрибутив alpine linux?". "Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox." - цитата с официального сайта, которая целиком и полностью описывает суть дистрибутива. Проект, кстати, достаточно старый - выпускается с 2005 года, и изначально делал упор на нетребовательность к ресурсам и отсекании всего лишнего. Т.е. это был обычный дистрибутив linux но без systemd (заменили на openrc), с загрузчиком extlinux, собственным пакетным менеджером apk и busybox как замена GNU coreutils. Собственно, поэтому все утилиты в /bin и ссылаются на один и тот же файл /bin/busybox. Но самая интересная замена - GNU libc на более легковесную musl libc. К glibc были некоторые вопросы насчёт переусложнённости и расширений. Например, isalnum() мог кинуть сегфолт. Так что alpine хорошо должен подойти под всякий embedded (поправьте, если не так). Как вы понимаете, бинарно они не совместимы, и отсюда столько боли. Но вернёмся к python. Спулим 2 образа, и разница уже не столь существенна, правда? Давайте соберём небольшое django-приложение. Зависимости взяты как пример из моего пет-проекта: И получилось: Разница всё та же в 70Mb - предсказуемо. И если экстраполировать на какой-нибудь реальный проект, в котором docker-образ будет весить ~600Mb, то так ли важны эти 70Mb? Ok, с простым django-приложением более-менее всё понятно. Так что я возьму другой свой пет-проект на FastAPI со следующими зависимостями: Заменю в Dockerfile python:3.8-slim на python:3.8-alpine ииии... Ладно, поставлю gcc, хотя под debian никакой компиляции не требовалось... ok, сам дурак - заголовочные файлы забыл. К слову установку я обернул в чтобы как можно честнее подсчитывать место. Но после этого меня ждало: `Something went wrong bootstrapping makefile fragments` вселил в меня ужас. Ковыряться в Makefile мне совсем не улыбалось, а uvicorn больше опциональная зависимость, которую для тестов можно опустить. Так что я решил просто исключить его. Образ собрался, но осадочек-то остался... Кстати, из-за всех этих скачиваний, установок и компиляций образ собирался почти в 2 раза медленнее, чем под python:3.8-slim. Оно и логично, но ради чего? Вернёмся к этому позже. Сейчас проверим размеры собраных образов с одинаковыми зависимостями. Разница больше, чем в 2 раза! Серьёзно? Чувствую в этом какой-то подвох, так что посмотрим что действительно содержится в образе (прошу прощения за стаю шакалов): Основное различие в библиотеке pydantic. Разница в 2 порядка - это уже перебор, здесь точно что-то не так! Идём в каталог и видим, что в случае debian там бинарники, а под alpine - python код. Т.е. погодите - при такой установке pydantic под alpine будет работать гораздо медленнее, чем под debain. Но, собственно, почему такое отличие вообще имеет место быть? Посмотрим на его сборку и установку. Установка любого пакета python начинается с его сборки в wheel. Если он поставляется в исходниках (.tar.gz), то выполняется setup.py, потом будет сборка пакета, который уже в свою очередь и будет установлен. Так что хорошей практикой будет заливать в pypi не только исходники, но и собранные на CI/CD wheel-пакеты. Благо, это делается буквально в 2 строчки (на примере моей библиотеки для работы с Yandex Disk): Ещё пара слов об именовании пакетов. Описан он в PEP 440 и представляет собой такую конструкцию: {dist}-{version}-{python}-{abi}-{platform}.whl (на самом деле там гораздо больше вариаций, но они нам не интересны). Что тут происходит: dist - название пакета version - версия пакета (обычно используется semver) python - для какого python abi - бинарный интерфейс (обычно abi3, повторяет python или опускается) platform - платформа, под которую собраны бинарники Т.е. один и тот же пакет poetry-1.1.14-py2.py3-none-any.whl будет использоваться и для python2, и для python3, причём для любой платформы. А вот cffi-1.15.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl будет установлен только на CPython 3.9 под Linux x86_64 с более-менее современными библиотеками. Обратим внимание на manylinux_2_17_x86_64 - это строка говорит о том, что бинарники внутри скомпилированы glibc версии 2.17 под архитектуру x86_64. Важный момент! Потому что под alpine будет ставиться другой пакет - cffi-1.15.1-cp39-cp39-musllinux_1_1_x86_64.whl. Скомпилирован он musl версии 1.1 и бинарно не совместим с manylinux. Т.е. под разные системы могут быть скачаны и распакованы разные архивы. Хорошо, если они созданы из одних исходников. Подробнее можно почитать на realpython. Собственно, поэтому uvloop под alpine требовал компиляции - wheel под alpine просто нет на pypi. Для новых версий эту проблему починили. Т.е. теперь пакет будет скачан и распакован, компиляции не потребуется. Аналогичная проблема была и с psycopg2-binary. Но мы возвращаемся к pydantic-1.9.1. Этот пакет собран под всё, что только можно. И при установке обычным pip выглядит нормально: Как видно из куска файла с зависимостями, я использовал poetry. Вероятно, проблема в нём... Действительно! К моменту выхода статьи проблему уже пофиксили в версии 1.2.0. Заключалась она в том, что poetry просто игнорировал пакеты с тегом musllinux_1_1_x86_64 и всегда собирал из исходников. А у pydantic в setup.py: Т.е. если не установлен Cython, то компиляции пропускается - будет работать код на python. Да-да, python-код можно компилировать в бинарник. Правда, не любой, с некоторыми ограничениями, но всё же. Так что казалось бы популярный сетап alpine + poetry + FastAPI, а работать будет совсем по-другому. Вернее, дико тормозить. Да, именно эта проблема уже исправлена, но если вы взяли стандартный python:3.x-slim, вы бы о ней и не узнали, т.к. использовали те же самые пакеты, что и при разработке. Часто ли мы проверям docker-образ на то, что в действительности туда поставилось? Со следующей проблемой я столкнулся на препроде. Баг был в библиотеке aiohttp==3.6.2 и python==3.7. Да, давно это было, но пример показательный - поведение библиотеки под alpine и debian различалось. Один сервер конкатенировал куки не через \r\n как по стандарту, а через \n. Казалось бы мелочь, но: Исходники для проверки можно взять с github. Баг проявился потому что работал разный код. Под debian куки парсились с помощью конечного автомата, реализованного в бинарнике; под alpine работал фолбек-код на python, который парсил регуляркой. Случилось это потому что в pypi проник файл aiohttp-3.6.2-py3-none-any.whl, который подходит под все архитектуры и который был установлен как наиболее подходящий под alpine. Там исключительно python код. Под debian был установлен другой - aiohttp-3.6.2-cp37-cp37m-manylinux1_x86_64.whl вместе с бинарниками. Казалось бы да, баги - с кем не бывает. Но я хочу обратить внимание, что они связаны с использованием нестандартного окружения. Не того, на котором происходит разработка. И хорошо, если это просто отнимает время на дебаг Dockerfile и установку зависимостей при сборке. Хуже, когда проблема внезапно возникает на проде, или вы вдруг узнаёте, что установилось не то, что должно было. И стоит ли сэкономленные 80Mb таких заморочек? Alpine не плохой и не хороший. Это просто инструмент. У меня самого пара сервисов крутятся на нём, но они предельно простые. Там буквально 2 зависимости, и поэтому что-то необычное сразу бросится в глаза (например, установка из исходников). Для себя я выработал правило: в подавляющем большинстве случаев бери debian; alpine - только если действительно знаешь что делаешь. Прошу прощения за кликбейтный заголовок. Мне хочется, чтобы к выбору базового образа подходили чуть более осознанно, учитывая как плюсы, так и минусы. Я знаю, что фронты, гошники и др. часто используют alpine в качестве базового образа. Там это вполне уместно, т.к. слабо связано с окружающей системой. И я сам беру nginx:alpine, postgres:alpine, redis:alpine в качестве сервисов... В python-мире же очень сильно взаимодействие с бинарными файлами, которые были получены в том числе и с помощью musl. Так что приходится учитывать эту специфику.  Full-stack developer