Настройка Python в Docker уже не прихоть.
Это необходимость. Или должна быть. Представьте вашу команду: пинги в Slack в девять утра, ModuleNotFoundError на каждом шагу, и тот коллега на Windows, уверяющий, что его код безупречен. Знакомая картина? У нас так тянулось пять месяцев. Полный провал.
Оригинальный рассказ бьёт в точку. «Пять месяцев «работает у меня на машине». Пять месяцев проблем с онбордингом. Пять месяцев, когда команда теряла часы впустую». Ай-ай-ай. Это не исповедь — это преступление против продуктивности. И да, понимаю: признавать, что дали этому разрастись, не хочется. Но вот горькая правда: если в 2024-м вы всё ещё боретесь с локальным адом, проблема в вас.
Почему локальные Python-сборки — это помойка
Машина каждого разработчика? Франкенштейн из полупотрёпанных pip-установок, хаков с PATH, призрачных пакетов от той утилиты, которую удалили криво. Mac, Windows, Linux — каждый со своей уникальной мукой. requirements.txt? Мило. Virtualenv? Уже лучше, но всё равно хрупко, как стекло. Малейший апдейт Python — с 3.10.4 на 3.10.11 — и привет, апокалипсис устаревших фич.
Мы угробили день на подготовку демо из-за этого. Три часа гонялись за воздухом. Стыдоба.
Docker меняет правила игры. Интерпретатор больше не живёт на вашем ноутбуке. Он в проекте. Dockerfile всё прописывает: версия Python, зависимости, базовый OS. Собери раз — запусти везде. Без отмазок.
А Dev Containers в VS Code? Идеальный ход. Всё туннелируется внутрь: терминал, дебаггер, IntelliSense — контейнеризировано. Ощущается как локально. Не является. Гениально.
У нас был requirements.txt. Были виртуальные среды. Был добросовестный README с инструкциями по настройке, которые уже шесть недель устарели. Чего у нас не было — так это какой-либо гарантии, что Python-интерпретатор на моей Windows-машине видит тот же мир, что и на MacBook коллеги или на Ubuntu-воркстейшне третьего члена команды.
В яблочко. Это привидение преследует каждую команду.
Настройка Docker для Python: Пошаговка без лишнего
Не усложняйте. Вот что мы собрали. Корень проекта:
my-project/ ├── .devcontainer/ │ └── devcontainer.json ├── Dockerfile ├── requirements.txt └── main.py
Сначала Dockerfile. Просто и надёжно:
FROM python:3.14.3-slim
RUN apt-get update && apt-get install -y --no-install-recommends git curl && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
Slim-образ? Умно — без балласта, быстрее тянется даже на слабом интернете. WORKDIR /app? Предсказуемые пути, без головной боли от маппинга. requirements.txt первым? Магия кэширования слоёв. Код поменялся? Pip не пересобирается. Чистый кайф.
Дальше devcontainer.json в .devcontainer/. Это цепляет VS Code:
{
"name": "Python Dev",
"dockerfile": "../Dockerfile",
"workspaceFolder": "/app",
"features": {
"ghcr.io/devcontainers/features/python:1": {
"version": "3.14.3"
}
}
}
Жмём Reopen in Container. VS Code перерождается внутри Docker. Расширения? Живут снаружи. Терминал? Чисто контейнерный. Дебаггер? Оживает мгновенно.
Заняло полдня. Сэкономило месяцы.
Docker для Python-команды — перебор?
Ни в коем случае. Один разработчик? Всё равно внедряйте. Будущий вы скажет спасибо, когда в 2027-м откроете репозиторий. Нанимаете подрядчика? Запустится за минуты, а не дни.
А вот мой эксклюзив: это Python-момент «npm install» из тёмных времён Node. Помните 2010-й? Node-разрабы тонули в аду версий, конфликтах как в плохом разводе. Yarn поправил наполовину; Docker — всё. Войны pipenv-poetry-conda? Закончились. Контейнеры побеждают. Смелый прогноз: к 2026-му GitHub будет предлагать devcontainer.json для каждого Python-репо. Игнорируйте на свой страх.
Корпоративный PR зовёт это «reproducible builds». Чушь — это страховка рассудка.
Критика оригиналу: автор ждал пять месяцев. Почему? Лень? Страх перед репутацией Docker как «тяжёлого»? Docker Desktop жрёт ресурсы на ноутбуках, факт — но slim-образ
