$ cat post.md
Что начинает раздражать в Docker Compose после десятого сервиса и как я с этим живу
Честный разбор того, где Compose остаётся отличным решением, а где начинает требовать уже не энтузиазма, а дисциплины.
Docker Compose прекрасен, пока система небольшая и держится в голове целиком. Но когда сервисов становится больше, вместе с удобством приходит и новое трение: длинные compose-файлы, пересекающиеся volume, однотипные env-переменные, зависимые контейнеры и всё больше мест, где можно случайно ошибиться.
Проблема не в самом Compose. Проблема в том, что он очень долго остаётся удобным, и из-за этого легко не заметить момент, когда проекту уже нужны правила. Имена сервисов, структура каталогов, шаблон env-файлов, порядок деплоя, единый способ писать healthcheck — всё это становится обязательным чуть раньше, чем хочется.
Сейчас я отношусь к Compose как к хорошему инструменту, который не прощает хаотичный рост. Если заранее договориться о соглашениях, он остаётся отличным решением и после десятого сервиса.
Что помогает не утонуть
- Делить сервисы по понятным каталогам.
- Не складывать всё в один гигантский compose-файл без необходимости.
- Делать одинаковые паттерны для env, volumes и networks.
- Сразу описывать, как сервис поднимается и чем проверяется.