Несколько докер-сервисов с собственными базами данных для Django, похоже, перекрестно соединяются
У нас есть несколько сервисов, и при локальном запуске каждый из них запускает свой собственный контейнер docker для postgres. Отлично.
Также есть репо "admin services" с файлом docker compose для таких вещей, как pgAdmin, который будет подключаться к любым запущенным сервисам для удобства использования. Для каждого сервиса назначены маппинги внешних портов, так что мы можем запускать разные сервисы одновременно локально.
Проблема в том, что для работы репозитория админских сервисов мы добавили "общую" сеть к сервисам, к которым он должен подключаться. Для pgAdmin это нормально, так как он подключается к "db_service1", "db_service2" и т.д., что является значением имени_контейнера.
Однако настройке django DATABASES["default"]["HOST"], похоже, не нравится значение "db_service1", и вместо него требуется фактический идентификатор сервиса из файла compose, который для всех сервисов равен "db".
А поскольку docker использует не внешние IP-адреса, а внутренние, а внутренние адреса все 5432 (postgres по умолчанию), когда я запускаю, например, сервис2, то сервис1 начинает ошибаться с
relation "django_session" does not exist
LINE 1: ...ession_data", "django_session"."expire_date" FROM "django_se...
Единственное объяснение, которое у меня есть для этого, заключается в том, что теперь он внезапно пытается подключиться к базе данных service2, потому что они обе находятся в "общей" сети, чтобы репозиторий служб администратора мог получить доступ к ним.
Если бы я мог задать "db_service1" в качестве HOST для базы данных в settings.py, все было бы хорошо, но django это совсем не нравится.
(я еще не проверял, но предположу, что с redis происходит то же самое...)
То, что я пробовал:
- Измените конфигурацию
DATABASESна подключение через localhost и порт внешнего контейнера. - Изменение
DATABASES["default"]["HOST"]наdb_service1, а не простоdb
Я мог бы попытаться заставить всех изменить настройки compose в каждом репо, чтобы фактические имена сервисов были "db_service1" и т.д., а не "db", но это очень хлопотно с точки зрения координации, и мне кажется, что django должен иметь возможность подключаться по имени контейнера (в конце концов, pgAdmin прекрасно подключается к "db_service1" !!!)