Файл описания связки сервисов ценен не тем, что экономит длинные команды запуска. Его главная польза в другом: он превращает устное знание о среде в текст — какие сервисы нужны, какие версии, какие переменные, где лежат данные, кто с кем общается.
Именно поэтому его стоит держать рядом с кодом и обновлять вместе с ним. Как только описание расходится с реальностью, оно превращается во вредный документ: новый человек поднимает окружение, получает непонятную ошибку и делает вывод, что проще настроить всё руками.
Практичный приём — разделять базовое описание и надстройки для разных условий. Общая часть содержит сервисы и связи, а отдельный файл добавляет то, что нужно только для разработки: подключение исходников, открытые наружу порты, отладочные инструменты. Тогда рабочая конфигурация не обрастает костылями для локальной машины.
И маленькая, но спасительная деталь: фиксировать версии образов явно. Плавающая метка означает, что через полгода из того же файла соберётся другое окружение ⚙️
Docker на Практике
@docker_practice_ru_n1k
Файл описания связки сервисов ценен не тем, что экономит длинные команды запуска. Его главная польза в другом:
Этот пост опубликован в Telegram-канале Docker на Практике. Подписаться можно по ссылке: @docker_practice_ru_n1k.