Каждый разработчик это проходил: запускаешь новый проект — устанавливаешь базу данных (PostgreSQL или MySQL), задаёшь пароль… а через пару минут уже не помнишь, какой придумал. Проходит месяц — для следующего проекта нужна другая версия базы или новый сервис вроде Redis, и вот уже на компьютере десятки старых, забытых программ.
Вариантов решения куча, но для локальной разработки не придумать проще, чем собрать всё нужное в один файл docker-compose.yml.
Как устроить идеальный dev-набор для локальной разработки
Какие сервисы чаще всего нужны для разработки
Когда я работаю с web-проектами, мне обычно требуются одни и те же инструменты. Многие придерживаются похожего набора: база данных (чаще всего PostgreSQL), key-value-хранилище вроде Redis (для кэша или сессий), а если нужны фоновые задачи или события — ещё и очередь RabbitMQ. Для проверки отправки писем беру MailHog — он перехватывает email-уведомления и показывает их прямо в браузере, чтобы реальные пользователи ничего не получили.
Сейчас соберём docker-compose.yml, который поднимает все эти сервисы разом — универсальный dev-набор, который можно таскать между проектами, менять версии и всегда получать знакомое окружение.
Создайте папку для проекта и в ней файл docker-compose.yml — как раз его ищет по умолчанию команда docker compose.
1. Сначала — база данных
Начинаем с PostgreSQL. Вот простой пример настройки этого сервиса:
Давайте быстро разберёмся, что тут происходит. В блоке services перечислены все контейнеры, которые вам нужны, каждый со своим именем — например, postgres.
image указывает, какой образ брать из Docker Hub. Я намеренно фиксирую версию (postgres:18.2): если указать просто "postgres", всегда будет скачиваться свежая версия, которая может внезапно всё сломать из-за изменений внутри.
container_name — опционально, но удобно: контейнер получит понятное, читаемое имя вместо рандомного (типа postgres_1234abcd), так его проще находить и управлять им через docker.
Перед тем как покупать NAS, изучите Docker!
С помощью Docker можно превратить свой NAS в «облачный сервер» — запускать любые приложения и даже автоматизировать умный дом.
Строка ports сопоставляет порт внутри контейнера с портом на вашем компьютере. Формат простой — «хост:контейнер». Обычно Postgres слушает порт 5432; мы пробрасываем его на тот же порт, чтобы можно было подключаться к базе через localhost:5432, как будто она стоит локально.
environment — переменные окружения внутри контейнера. Официальный образ Postgres ждёт логин, пароль и имя базы — для примера можно выставить простые значения.
volumes — очень важный момент: контейнеры по умолчанию "одноразовые". Если вы их удалите — все данные исчезнут. Мы создаём именованный том postgres_data и монтируем его в /var/lib/postgresql/data, чтобы база жила между перезапусками контейнера. В конце файла обязательно опишите раздел volumes.
restart: unless-stopped говорит Docker самостоятельно перезапускать контейнер в случае сбоя, но не трогать, если вы его остановили вручную.
2. Добавляем Redis
С Redis всё просто до безобразия: никаких настроек пользователей и переменных — никакой головной боли.
3. Подключаем RabbitMQ
RabbitMQ немного сложнее, так как у него есть собственная веб-админка. Хочется заходить в неё прямо из браузера.
В этом случае пробрасываем сразу два порта: 5672 — для обмена сообщениями (AMQP), через него работают ваши приложения; 15672 — для интерфейса управления. Заходите на http://localhost:15672, вводите guest/guest и управляйте очередями, обменниками и сообщениями.
4. Перехват писем через MailHog
MailHog — просто находка для локальной разработки. Это «фейковый» SMTP-сервер: перехватывает все письма из вашего приложения и показывает их в браузере. Идеально для тестов регистрации, восстановления пароля и любых уведомлений — никакой реальный пользователь не получит случайное письмо.
В самом низу docker-compose.yml обязательно пропишите раздел volumes, чтобы Docker создал тома и хранил в них файлы — искать вручную их не придётся.
Docker сам создаст эти разделы, файлы будут храниться автоматически — вам не придётся заботиться об этом.
5. Собираем всё воедино
Сохраните готовый docker-compose.yml в папке проекта — и всё, dev-стэк готов.
Как мгновенно запустить dev-набор
1. Откройте терминал в папке с docker-compose.yml. Для запуска всех сервисов выполните команду:
Ключ -d запускает контейнеры в фоне — терминал снова свободен, а сервисы продолжают работать.
2. Чтобы убедиться, что всё работает, наберите:
Вы увидите статус, порты и время работы каждого контейнера.
3. Когда закончили работу, остановите контейнеры (данные сохранятся):
Остановятся только контейнеры — и данные, и контейнеры можно будет без проблем поднять заново командой docker compose start или docker compose up.
4. Удалить только контейнеры, но оставить данные можно так:
5. Хотите снести всё подчистую, вместе с томами? Просто добавьте флаг -v:
Чем заменить Docker Compose? Реальные альтернативы
Установка сервисов прямо на компьютер
Конечно, Docker Compose — не единственный путь. Вариантов, как в мире Linux, огромное множество.
Самый «олдскульный» — ставить всё через стандартный пакетный менеджер: PostgreSQL, Redis, RabbitMQ… Иногда этого достаточно, а если понадобился build-essential в Debian — вы уже собираете свою среду: компиляторы, заголовки и всё сопутствующее.
Но чем больше проектов и изменений, тем больше путаницы: одному проекту нужна Postgres 18, другому — 16, приходится прыгать между версиями, менять порты или даже полностью переустанавливать сервисы. Да и удалить их без остатка невозможно — конфиги так и останутся в системе.
Менеджеры версий (например, asdf)
Инструменты вроде asdf отлично справляются с языками программирования: переключайте Python, Node.js, Ruby — какая версия нужна, та и будет. Для кода приложений — просто спасение.
Подпишитесь на рассылку: лучшие Dev-стеки года через Docker Compose!
Но базы данных, очереди и почтовые сервисы — это совсем другая история. Им нужны отдельные папки, свои процессы, ресурсы и куча настроек. Собирать их для каждого проекта вручную — то ещё «удовольствие», а про удобство и повторяемость тут речи нет.
Автоматизация: Ansible, Task и другие
Ещё вариант: автоматизировать всё с помощью Ansible или Task. Это идеальный подход для настройки серверов — можно выполнять целые последовательности команд одной кнопкой.
Но тащить такой арсенал ради локальной установки Postgres, Redis и RabbitMQ — это уж слишком тяжёлая артиллерия.
Вот контейнеры, которые я запускаю каждый день — остальные безжалостно удалил!
Некоторые сервисы реально делают жизнь проще, а другие только мешают. Делюсь списком контейнеров, которые у меня прижились, и тех, от которых с удовольствием отказался.
"docker run" против Compose: где подвох?
Похожая альтернатива Compose — запуск сервисов через docker run. Для одного контейнера — быстро и удобно: одна команда, порт проброшен, сервис работает.
Но стоит добавить второй-третий — и начинаются пляски: прописывать тома, переменные, сети, рестарты руками, да ещё всё это не забыть. А если сервисы должны общаться друг с другом, поддерживать все параметры становится мучительно сложно. Поэтому все быстро начинают копировать команды из доков или оборачивают их в shell-скрипты (я тоже так делал!) — в итоге получается свой «compose-файл», только в виде скрипта.
Почему Compose — выбор большинства разработчиков
Docker Compose избавляет от километровых команд docker run — всё красиво и понятно прописано в одном YAML, а сеть между сервисами появляется сама. Полной тонкой настройки нужно редко, а в 90% случаев всё взлетает «из коробки».
Главное — прозрачность и предсказуемость: можно быстро переносить среду между проектами и не захламлять систему ненужными сервисами.
Проще не бывает: так удобнее всего обновлять ваши Docker-контейнеры!
Обновляете контейнеры вручную? Хватит жить в прошлом!
Почему контейнерный dev-стек экономит кучу времени
Простой docker-compose.yml экономит часы: вы избавляетесь от муторной ручной установки, настройки и бесконечных проблем со «старыми» сервисами. Закончили проект — просто удалили папку, остановили контейнеры, и всё чисто, никаких следов на системе. Не скажу, что это универсальная панацея, но для быстрого старта и продуктивной работы — лучший вариант, особенно если только начинаете разбираться с организацией рабочих окружений.
У меня сейчас часть задач решается через asdf и Podman — где-то нужна тесная интеграция с системой, где-то хочется работать без демона Docker. Главное — группируйте сервисы по задачам, не захламляйте основную ОС, и всё окружение сможете восстановить за пару минут.
Docker
Если вам понравилась эта статья, подпишитесь, чтобы не пропустить еще много полезных статей!
Премиум подписка - это доступ к эксклюзивным материалам, чтение канала без рекламы, возможность предлагать темы для статей и даже заказывать индивидуальные обзоры/исследования по своим запросам!Подробнее о том, какие преимущества вы получите с премиум подпиской, можно узнать здесь
Также подписывайтесь на нас в:
- Telegram: https://t.me/gergenshin
- Youtube: https://www.youtube.com/@gergenshin
- Яндекс Дзен: https://dzen.ru/gergen
- Официальный сайт: https://www-genshin.ru