Pull to refresh

Comments 8

Спасибо, обратили внимание на достаточно важные моменты.

Единственное, заголовок "Практические рекомендации по работе с Docker для Python-разработчиков" можно заменить, например на "Практические рекомендации по работе с Docker на примере с Python".
Т.е. основной текст статьи несет в себе информацию по Docker полезную не только python-разработчикам.

Ещё удобная штука чтобы смотреть сколько и какой слой занимает. Для больших образов не всегда понятно где именно проблема появляется. Можно включать в CI
https://github.com/wagoodman/dive

Спасибо за статью, много полезных рекомендаций.

Однако с одним утверждением я не согласен:

При необходимости используйте в контейнерах виртуальные окружения Python

С одной стороны да, размер образа будет меньше. С другой, внутри контейнера, который и так даёт изоляцию окружения от хоста, зачем-то создаётся виртуальное окружение, которое изолирует зависимости от системного Python.

Плюс, нужно будет собирать stage на одном и том же базовом образе, поскольку по-умолчанию внутри venv пути к интерпретатору python на самом деле являются симлинками на системный python, а в разных дистрибутивах он может быть расположен по разным путям (где-то /usr/bin, где-то /usr/local/bin). А если использовать опцию --copy, то размер образа увеличивается, поскольку в venv создаётся копия файлов интерпретатора.

Плюс новички, увидев что внутри контейнера создаётся venv, могут по незнанию написать в своем Dockerfile что-нибудь вроде COPY venv/ /app/venv/. В таком варианте уже не приходится говорить ни о какой воспроизводимости сборки, как и о ее независимость от хоста, на котором она выполняется.

Так что этот подход я бы не стал рекомендовать.

Если будут силы и идеи на новую статью, было бы интересно прочитать про ускорение Python с помощью различных PyPy, Cython, Nuitka и т.д. в разрезе сборки Docker в Ci/Cd и с результатами, насколько быстрее получились приложения, а так же что удалось/не удалось.

ENV PYTHONDONTWRITEBYTECODE 1 ENV PYTHONUNBUFFERED 1

В примере с многоэтапной сборкой передается в образе билдера, переменные как-нибудь передаются в финальный образ?

А можно подробнее по секретным данным? Предположим, что у меня есть secret.py, где указаны ключики, а запускается контейнер на чуждой мне VPS. Сейчас я просто собираю контейнер сCOPY secret.py /workdir, а после сношу secret.py с хоста, но по сути внутри контейнера он доступен. Есть другое решение?

Sign up to leave a comment.