Comments 11
рано или поздно вам захочется установить инструменты разработки в вашем образе,
Нет, не захочется
Слог статьи создаёт ощущение Google translate или AI-generation.
Подскажите, что навеяло мысли об участии AI? Возможно, нам стоит внимательнее присмотреться к источнику, хотя на первый взгляд он вызывает доверие. Ну а Google translate здесь точно не участвовал
Проблема в том, что ваш перевод сделан в лоб и не скорректирован под русский. Пример.
Потому что это невероятно сложно.
Это сложно сделать.
У вас в 2 абзацах повторяется одна и та же мысль, что странно выглядит. В оригинале так же, но фраза "Это сложно сделать" - ссылка на другую статью, поэтому повторение имеет смысл. Ну и куча других мест, где формально перевод верный, но с точки зрения языка - криво. Прогоняйте хотя бы через редактор Яндекса (а лучше корректора)
Статья из разряда вредных советов, все в точности наоборот
FROM python:3.12.2-slim as builder
WORKDIR /app
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
RUN apt-get update && \
apt-get install -y --no-install-recommends gcc
COPY requirements.txt .
RUN pip wheel --no-cache-dir --no-deps --wheel-dir /app/wheels -r requirements.txt
# final stage
FROM python:3.12.2-slim
WORKDIR /app
COPY --from=builder /app/wheels /wheels
COPY --from=builder /app/requirements.txt .
RUN pip install --no-cache /wheels/*
Действительно минимальные образы встречаются крайне редко и стоят дорого. Если вы не уверены, что у вас именно такой образ, и не готовы поддерживать его в таком состоянии на протяжении всего проекта, независимо от того, кто будет над ним работать, лучше даже не пытаться.
Стремиться к лучшему? Нет. Да и в чем сложность постараться создать минимальный образ для python? Это делается один раз на проект, да и во многих схожих проектах Dockerfile практически одинаковый, никаких трудностей там нет. Куча информации на хабре как создать минимальный и правильный Dockerfile.
С учётом того, что контейнер по своей природе служит для изоляции, может показаться нелогичным добавлять ещё один слой изоляции поверх этого.
Именно так!
venv — это обеспечение однородности: где бы вы ни находились, вы используете venv. Это избавляет вас от необходимости разбираться с вариациями и сложностями, которые они создают.
Контейнер и так обеспечивает однородность, причем чистую, а не то что у вас может быть на рабочем компьютере, даже с venv.
А если вы начнёте устанавливать пакеты через pip без venv, рано или поздно что-то из Pypi и что-то из операционной системы столкнутся.
Образ контейнера для python имеет много разных версий: alpine, slim, bookworm, и т.д. Всегда при сборке контейнера нужно выбирать, какой базовый образ выбрать для проекта. Затем устанавливаются дополнительные библиотеки и потом уже python зависимости. Если что-то когда-то сломается, то это знак, что нужно исправить ошибку в образе контейнера, а не брать самый тяжелый python:latest и добавлять к нему виртуальное окружение отдельной папкой и смотреть на образ в 2 ГБ.
Не говоря уже о том, сколько ресурсов вы готовы потратить на поддержание этого прекрасного чистого состояния установки без venv? На документацию? Обучение? Процессы?
Очень мало по сравнению с необразованностью и попыткой сделать как легче, а не как лучше. Мы же технически грамотные люди, нужно разбираться в том что делаем, тем более это в разы проще написания проекта.
И ради чего? Какая цель? Если вы не можете ответить на этот вопрос мгновенно, просто используйте venv.
Цель обеспечить минимум лишнего окружения для проекта и его прозрачного использования в чистой среде контейнера с конкретными зависимостями. Если это не требуется, то может и docker вовсе лишний. Можно запускать очень хорошо с помощью виртуального окружения python проект на ОС как демон. И это иногда будет даже лучше!
Список зависимостей вашего проекта в продакшене будет легко сравнить с тем, что используется в разработке.
Для этого не нужен venv внутри контейнера.
Нет необходимости в правах администратора, что может усложнить задачу злоумышленнику, пытающемуся проникнуть в ваш контейнер.
Для этого не нужен venv внутри контейнера.
Вы можете легко использовать сторонние инструменты, такие как uv, poetry или anaconda
Для этого не нужен venv внутри контейнера.
Вы можете иметь несколько venv с разными версиями Python или библиотек, чтобы быстро тестировать обновления. Это гораздо легче, чем использовать несколько образов.
А может тогда мы и несколько проектов будем запускать в одном контейнере. Это гораздо легче, чем использовать несколько образов.
Вы можете хранить ваш venv в отдельном томе, что позволяет отделить зависимости Python от самого образа.
Для этого не нужен venv внутри контейнера.
Если где-то и понадобится venv внутри контейнера, то для этого должны быть определенные условия, которые являются частным случаем, а не общим.
Стоит ли использовать Python venv в контейнере, таком как Docker? Определённо