ней подойти.
Есть docker-compose.yaml, в котором контейнеры разбиты на две группы - сервисы для обеспечения работы бизнес-процесса и контейнеры с сервисами мониторинга всего этого добра.
В compose для разграничения этих контейнеров созданы две bridge сети. Контейнеры с продакшн сервисами находятся в каждой из сетей.
Один из контейнеров в продакшен-группе общается с другим через API, обращаясь к нему по имени контейнера. Проблема возникает в тот момент когда DNS-resolver в Docker'е начинает отдавать IP адрес не из "рабочей" сети, а из сети под мониторинг. Все ломается, эндпоинт в API не отвечает, связность между сервисами нарушается и все, стенд не работает как надо.
1) Насколько это bad design? Может есть смысл просто перевезти все контейнеры в одну сеть и все проблемы решатся сами по себе?
2) Если это не bad design и так делать можно - нормальное ли это поведение у resolver'а?
3) Если это его нормальное поведение - как лучше сделать так, чтобы обращение по имени контейнера велось только в пределах нужной мне виртуальной сети?
Прошу прощения за сумбур и неточность в формулировках и терминологии. docker-compose.yaml суда скинуть не смогу, но при необходимости смогу воспроизвести простенький пример, который будет иллюстрировать мою проблему.
Вообще компоуз на проде не лучшая идея
Чем больше работаю с Docker'ом - тем больше убеждаюсь в правильности этой мысли. Но вопросы деплоя, как и вопросы продакшена вне моей компетенции.
Можно попробовать явно указывать имена вида имя_сервиса.имя_сети
Это точно должно работать )
Че это, наш стартап со дня на день на композе побежит :)
Сейчас попробую, спасибо за наводку
Ты предлагаешь 4 контейнера в куб?
Отличная идея, мне нравится
Большое спасибо, это сработало в моем случае. Вкину наверх эту мысль + еще одно, вдогонку, о нормальных инструментах для оркестрации.
Обсуждают сегодня