Каждый сеньор, у которого я спрашивал, отвечал одно и то же: Docker Compose не для прода, бери Kubernetes, Compose — это для ноутбука. А я взял и выкатил Docker Compose в прод — реальное приложение, живые пользователи, настоящая нагрузка. И оно просто работало. Не «еле выжило», а спокойно и надёжно — месяцами.
Это история про то решение, про цифры за ним и про то, почему самым тяжёлым оказалась совсем не техника.
Три дня, которые перепрошили мне мозг
Мой самый первый docker-compose.yml — это WordPress и MySQL. И я провозился с ним три дня.
Три дня конфликтов портов. Три дня я смотрел на базу, которая наотрез отказывалась принимать подключения. Три дня я не понимал разницу между контейнером и образом — честно думал, что это одно и то же. Добил меня порт 3306: он был уже занят, потому что MySQL крутился прямо на машине, а я даже не подозревал, что когда-то его поставил. Целый вечер ушёл на одну строчку.
Сегодня тот же стек я поднимаю за три минуты. Но о тех трёх днях не жалею ни секунды — они навсегда изменили то, как я думаю про инфраструктуру. Потому что внутри крошечного compose-файла были все настоящие проблемы прода в миниатюре: service discovery, сеть, volumes, конфиги, порядок запуска зависимостей. Compose — это уменьшенная модель любого сложного инфраструктурного вопроса, который тебе когда-либо зададут.
Как «прод» выглядел на самом деле
Промотаем вперёд. Приложение: web-сервис с базой, кэшем и фоновыми воркерами. Умеренный, предсказуемый трафик. Около 500 пользователей.
Вот и вся конструкция:
- Docker Compose на одной VM
- Nginx как reverse proxy с SSL
- Health-check'и и авто-рестарт
- Blue-green деплой через один скучный bash-скрипт
- Мониторинг на Prometheus + Grafana
- Автоматические бэкапы, наружу с машины
Итоговая стоимость инфраструктуры — $40 в месяц.
Эквивалент на Kubernetes — managed control plane плюс ноды — я оценил в $200–400 в месяц, и это ещё не считая часов моей жизни на его обслуживание. Аптайм за полгода — 99.9%. Ни одного подъёма в три ночи. Ни загадочных evictions. Ни отладки service mesh, которую потом пришлось бы кому-то объяснять.
Урок из того первого файла всё ещё в силе
- Инфраструктура как код. Всё окружение — в файле, который можно прочитать, сравнить и откатить.
- Воспроизводимость.
docker compose upдаёт один и тот же результат каждый раз. - Изолированные, композируемые сервисы. Каждый делает своё дело и общается по описанной сети.
Приложению на 500 пользователей не нужна оркестрация контейнеров. Ему нужна VM, compose-файл и инженер, который реально понимает trade-off'ы. Over-engineering — это не про «продвинутость». Это тот же инженерный провал, просто дороже и выглядит солиднее.
Самым сложным была не техника
Скажу честно про то, о чём не предупреждают: техника была лёгкой частью. Войной было — отстоять решение.
На каждом код-ревью кто-нибудь спрашивал про Kubernetes. На каждой встрече по архитектуре кто-нибудь поднимал вопрос масштабирования — под трафик, которого не было и по любым честным прогнозам ещё долго не предвиделось. У индустрии настоящая зависимость от сложности, и «а вдруг однажды придётся масштабироваться» — её любимая фраза.
Поэтому я завёл один предельно простой документ: текущие пользователи, текущая нагрузка, прогноз роста. Каждый раз, когда всплывал вопрос про Kubernetes, я показывал на цифры. Цифры ни разу не оправдали сложность. Не оправдывают до сих пор.
Подгоняй сложность под задачу, а не под резюме
Мораль тут не «никогда не бери Kubernetes». Kubernetes прекрасен, когда твоя задача действительно имеет форму Kubernetes. Мораль уже и полезнее: подгоняй сложность инфраструктуры под сложность задачи.
Лучшее инфраструктурное решение того года — это когда я выбрал НЕ строить что-то впечатляющее. Скучная технология, тихо работающая в проде, обошла все умные альтернативы на столе — по деньгам, по аптайму и по моему собственному сну.
И вот вопрос к тебе, тот же, что я задал своей ленте: какое самое скучное техническое решение сэкономило тебе больше всего нервов? Потому что по моему опыту скучный, очевидный выбор чаще всего и есть самый профессиональный в комнате.