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

По мотивам моего доклада на PyCon «Контейнеризация Python без боли». На своей практике я постоянно сталкиваюсь со спорами какой базовый образ лучше использовать для проектов: alpine или debian. Аргументы есть и у той, и у другой стороны, но мне это настолько надоело, что я решил сам разобраться и наконец-то поставить точку. В конце концов «В наше время верить нельзя никому, даже себе. Но мне — можно.» (с)

Сравниваем базовые образы alpine и debian

Перед тем, как мы перейдём к специфике запуска python-проектов под alpine, давайте посмотрим на код базовых образов и сравним что они нам предлагают.

Debian:

FROM scratch ADD rootfs.tar.xz / CMD ["bash"]

Alpine

FROM scratch ADD alpine-minirootfs-3.17.0-x86_64.tar.gz / CMD ["/bin/sh"]

Т.е. что 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 иначе список получится очень большой):

➜  /opt/debain/usr du -h -d 2 -t 100k . 14M   ./bin 532K  ./share/info 31M   ./share/locale 168K  ./share/keyrings 128K  ./share/gcc 5,3M  ./share/man 13M   ./share/doc 264K  ./share/common-licenses 536K  ./share/perl5 344K  ./share/bash-completion 124K  ./share/lintian 5,0M  ./share/zoneinfo 56M   ./share 1,9M  ./lib/locale 1,1M  ./lib/apt 36M   ./lib/x86_64-linux-gnu 39M   ./lib 2,2M  ./sbin 111M  .

Т.е. погодите — 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?».

Ремарка про alpine

«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 образа, и разница уже не столь существенна, правда?

➜  /opt docker images REPOSITORY            TAG               IMAGE ID       CREATED         SIZE python                3.10-slim         dae00c0316e5   12 hours ago    126MB python                3.10-alpine       2527f31628e7   13 days ago     50.1MB

Давайте соберём небольшое django-приложение. Зависимости взяты как пример из моего пет-проекта:

[tool.poetry.dependencies] python = "^3.10" Django = "~3.2" django-elasticsearch-dsl = "^7.2.0" django-enumfields = "^2.1.1" djangorestframework = "^3.12.4" django-elasticsearch-dsl-drf = "^0.22.1" django-filter = "^2.4.0" django-cors-headers = "^3.7.0" drf-nested-routers = "^0.93.4" gunicorn = "^20.1.0"

И получилось:

➜  /opt docker images REPOSITORY              TAG               IMAGE ID       CREATED         SIZE django                  debian            3e9fef9d8b54   2 seconds ago   201MB django                  alpine            2f27ca4a1588   16 seconds ago  125MB python                  3.10-slim         dae00c0316e5   12 hours ago    126MB python                  3.10-alpine       2527f31628e7   13 days ago     50.1MB

Разница всё та же в 70Mb — предсказуемо. И если экстраполировать на какой-нибудь реальный проект, в котором docker-образ будет весить ~600Mb, то так ли важны эти 70Mb?

Ok, с простым django-приложением более-менее всё понятно. Так что я возьму другой свой пет-проект на FastAPI со следующими зависимостями:

[tool.poetry.dependencies] python = "^3.8" pycairo = "^1.19.1" fastapi = "^0.54.1" uvicorn = "^0.11.3" aiofiles = "^0.5.0" SQLAlchemy = {extras = ["asyncio"], version = "^1.4.29"} alembic = "^1.7.5" asyncpg = "^0.25.0" elasticsearch = {extras = ["async"], version = "^7.16.2"}

Заменю в Dockerfile python:3.8-slim на python:3.8-alpine ииии…

Ладно, поставлю gcc, хотя под debian никакой компиляции не требовалось…

ok, сам дурак — заголовочные файлы забыл. К слову установку я обернул в

RUN apk add g++ musl-dev --virtual dev \   && poetry config virtualenvs.create false \   ...   && apk del dev

чтобы как можно честнее подсчитывать место. Но после этого меня ждало:

`Something went wrong bootstrapping makefile fragments` вселил в меня ужас. Ковыряться в Makefile мне совсем не улыбалось, а uvicorn больше опциональная зависимость, которую для тестов можно опустить. Так что я решил просто исключить его. Образ собрался, но осадочек-то остался… Кстати, из-за всех этих скачиваний, установок и компиляций образ собирался почти в 2 раза медленнее, чем под python:3.8-slim. Оно и логично, но ради чего? Вернёмся к этому позже. Сейчас проверим размеры собраных образов с одинаковыми зависимостями.

➜  /opt docker images REPOSITORY                TAG               IMAGE ID       CREATED         SIZE fastapi                   debian            b939da63315f   14 minutes ago  244MB fastapi                   alpine            6f210c82554e   14 minutes ago  111MB

Разница больше, чем в 2 раза! Серьёзно? Чувствую в этом какой-то подвох, так что посмотрим что действительно содержится в образе (прошу прощения за стаю шакалов):

Основное различие в библиотеке pydantic. Разница в 2 порядка — это уже перебор, здесь точно что-то не так! Идём в каталог и видим, что в случае debian там бинарники, а под alpine — python код. Т.е. погодите — при такой установке pydantic под alpine будет работать гораздо медленнее, чем под debain. Но, собственно, почему такое отличие вообще имеет место быть? Посмотрим на его сборку и установку.

Сборка и установка python пакетов

Установка любого пакета python начинается с его сборки в wheel. Если он поставляется в исходниках (.tar.gz), то выполняется setup.py, потом будет сборка пакета, который уже в свою очередь и будет установлен. Так что хорошей практикой будет заливать в pypi не только исходники, но и собранные на CI/CD wheel-пакеты. Благо, это делается буквально в 2 строчки (на примере моей библиотеки для работы с Yandex Disk):

$ pip wheel --no-deps . -w dist Processing /opt/app/YaDiskClient   Preparing metadata (setup.py) ... done Building wheels for collected packages: YaDiskClient   Building wheel for YaDiskClient (setup.py) ... done   Created wheel for YaDiskClient: filename=YaDiskClient-0.5.1-py3-none-any.whl size=5238 Successfully built YaDiskClient  $ twine upload dist/* Uploading distributions to https://upload.pypi.org/legacy/ Uploading YaDiskClient-0.5.1-py3-none-any.whl 100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 11.8/11.8 kB • 00:00 • 9.3 MB/s View at: https://pypi.org/project/YaDiskClient/0.5.1/

Ещё пара слов об именовании пакетов. Описан он в 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 выглядит нормально:

➜  ~ docker run -it python:3.9-alpine3.13 sh / # pip install pydantic==1.9.1 Collecting pydantic==1.9.1   Downloading pydantic-1.9.1-cp39-cp39-musllinux_1_1_x86_64.whl (12.5 MB) |████████████████████████████████| 12.5 MB 2.1 MB/s Collecting typing-extensions>=3.7.4.3   Downloading typing_extensions-4.4.0-py3-none-any.whl (26 kB) Installing collected packages: typing-extensions, pydantic Successfully installed pydantic-1.9.1 typing-extensions-4.4.0  / # du -d 1 -h /usr/local/lib/python3.9/site-packages/ 72.0K /usr/local/lib/python3.9/site-packages/__pycache__ 49.5M /usr/local/lib/python3.9/site-packages/pydantic ...

Баги всюду

Как видно из куска файла с зависимостями, я использовал poetry. Вероятно, проблема в нём…

# poetry add pydantic@1.9.1 Updating dependencies Resolving dependencies... (1.2s) Writing lock file Package operations: 2 installs, 0 updates, 0 removals   • Installing typing-extensions (4.4.0)   • Installing pydantic (1.9.1)  # du -d 1 -h /root/.cache/pypoetry/virtualenvs/-il7asoJj-py3.9/lib/python3.9/site-packages/ 1.7M  /root/.cache/pypoetry/virtualenvs/-il7asoJj-py3.9/lib/python3.9/site-packages/pkg_resources 876.0K  /root/.cache/pypoetry/virtualenvs/-il7asoJj-py3.9/lib/python3.9/site-packages/pydantic ...

Действительно! К моменту выхода статьи проблему уже пофиксили в версии 1.2.0. Заключалась она в том, что poetry просто игнорировал пакеты с тегом musllinux_1_1_x86_64 и всегда собирал из исходников. А у pydantic в setup.py:

if not any(arg in sys.argv for arg in ['clean', 'check']) and 'SKIP_CYTHON' not in os.environ:     try:         from Cython.Build import cythonize     except ImportError:         pass     else:         # For cython test coverage install with `make build-trace`         compiler_directives = {}         if 'CYTHON_TRACE' in sys.argv:             compiler_directives['linetrace'] = True         # Set CFLAG to all optimizations (-O3)         # Any additional CFLAGS will be appended. Only the last optimization flag will have effect         os.environ['CFLAGS'] = '-O3 ' + os.environ.get('CFLAGS', '')         ext_modules = cythonize('pydantic/*.py', exclude=['pydantic/generics.py'], …)  setup(     … 

Т.е. если не установлен Cython, то компиляции пропускается — будет работать код на python. Да-да, python-код можно компилировать в бинарник. Правда, не любой, с некоторыми ограничениями, но всё же.

Так что казалось бы популярный сетап alpine + poetry + FastAPI, а работать будет совсем по-другому. Вернее, дико тормозить. Да, именно эта проблема уже исправлена, но если вы взяли стандартный python:3.x-slim, вы бы о ней и не узнали, т.к. использовали те же самые пакеты, что и при разработке. Часто ли мы проверям docker-образ на то, что в действительности туда поставилось?

Взрываемся в препроде

Со следующей проблемой я столкнулся на препроде. Баг был в библиотеке aiohttp==3.6.2 и python==3.7. Да, давно это было, но пример показательный — поведение библиотеки под alpine и debian различалось. Один сервер конкатенировал куки не через \r\n как по стандарту, а через \n. Казалось бы мелочь, но:

➜  ~ docker run --rm --net=host tyvik/py-alpine [] <html><body><h1>hi!</h1></body></html>  ➜  ~ docker run --rm --net=host tyvik/py-debian ['uid', 'session'] <html><body><h1>hi!</h1></body></html>

Исходники для проверки можно взять с 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. Так что приходится учитывать эту специфику.