Docker: зачем нужны контейнеры

«У меня всё работает» — фраза, которая стоила тысячам команд часов отладки, сорванных дедлайнов и ночных звонков от клиентов. Приложение работает на ноутбуке разработчика. Падает на сервере. Потому что у разработчика Python 3.10, на сервере 3.8. Или другая версия библиотеки. Или отсутствующая переменная окружения. Docker решает этот класс проблем — и заодно открывает несколько других важных возможностей.

Что такое контейнер и чем он отличается от виртуальной машины

Виртуальная машина (VM) — это полноценный компьютер внутри компьютера: своё ядро операционной системы, полный стек ОС, собственная файловая система. Мощно, но тяжело: VM весит гигабайты, запускается минуты, потребляет значительные ресурсы.

Контейнер разделяет ядро ОС с хостом, но изолирует файловую систему, сетевые интерфейсы и процессы. Он содержит ровно то, что нужно для запуска приложения: код, зависимости, конфигурацию. Весит мегабайты, запускается секунды. Принцип простой: всё, что нужно приложению для работы, упаковано вместе с ним.

Dockerfile — рецепт сборки

Dockerfile — это инструкция по созданию образа контейнера. Текстовый файл с последовательностью команд: «возьми базовый образ Python 3.11, скопируй код, установи зависимости, запусти приложение». Один раз написанный Dockerfile гарантирует: где бы вы ни запустили этот образ — среда будет идентичной. На MacBook разработчика, на Ubuntu-сервере, в облаке AWS или в CI/CD пайплайне.

Образ — это результат сборки Dockerfile, готовый к запуску. Контейнер — это запущенный экземпляр образа. Один образ можно запустить сотни раз в виде отдельных контейнеров.

Docker Compose — оркестрация нескольких сервисов

Большинство реальных приложений состоят из нескольких частей: веб-сервер, база данных, кэш (Redis), очередь задач (Celery). Docker Compose позволяет описать все эти сервисы в одном YAML-файле и запустить всё командой docker-compose up. Разработчик, только что склонировавший репозиторий, получает полностью работающую среду разработки за две минуты — без ручной установки PostgreSQL, Redis и настройки конфигов.

Это решает одну из самых болезненных проблем командной разработки: «onboarding новичка». Вместо многостраничного гайда «как настроить локальную среду» — один файл и одна команда.

Как это меняет деплой

Традиционный деплой: SSH на сервер, обновить зависимости, перезапустить сервис, надеяться что всё совпадает. Деплой с Docker: собрать образ, отправить в registry, запустить новую версию на сервере. Откат: запустить предыдущую версию образа. Это занимает секунды и не требует ручного вмешательства на сервере.

Kubernetes — следующий шаг: оркестрация контейнеров в кластере серверов с автомасштабированием, балансировкой нагрузки и самовосстановлением. Это уже уровень сложнее, но базовое понимание Docker — обязательная предпосылка.

Три практических случая, когда Docker помогает прямо сейчас

Первый: вы хотите запустить чужой проект из GitHub и не хотите ставить все его зависимости на свою машину. docker-compose up — и всё работает в изолированной среде, которую легко удалить.

Второй: вы разрабатываете с коллегами и хотите гарантировать, что у всех одинаковая среда. Dockerfile в репозитории — это описание среды как код, которое хранится в системе контроля версий и меняется вместе с кодом.

Третий: вы хотите запустить несколько версий Python или Node одновременно на одном компьютере без конфликтов. Разные контейнеры — разные версии, полная изоляция.

С чего начать

Docker Desktop для Mac или Windows, Docker Engine для Linux. Официальный туториал «Get Started» занимает час и даёт базовое понимание. После него — попробуйте «докеризовать» любой свой проект: написать Dockerfile, собрать образ, запустить контейнер. Это лучший способ понять механику на практике.

«Работает у меня» больше не норма. «Работает в контейнере» — это «работает везде». Разница принципиальная.