У вас нет причин использовать Alpine для python проектов
Dec 14, 2022 13:02 · 2018 words · 10 minute read
По мотивам моего доклада на PyCon “Контейнеризация Python без боли”. На своей практике я постоянно сталкиваюсь со спорами какой базовый образ лучше использовать для проектов: alpine или debian. Аргументы есть и у той, и у другой стороны, но мне это настолько надоело, что я решил сам разобраться и наконец-то поставить точку. В конце концов “В наше время верить нельзя никому, даже себе. Но мне - можно.” (с)
Сравниваем базовые образы alpine и debian
Перед тем, как мы перейдём к специфике запуска python-проектов под alpine, давайте заглянем под капот базовых образов и сравним что они нам предлагают.
FROM scratch
ADD rootfs.tar.xz /
CMD ["bash"]
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 раза! Серьёзно? Чувствую в этом какой-то подвох, так что посмотрим что действительно содержится в образе (прошу прощения за стаю шакалов):
Разница в 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
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
WARNING: You are using pip version 21.2.4; however, version 22.3.1 is available.
You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
/ # 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. Так что приходится учитывать эту специфику.