ganjo888, и ещё, /src/database/migrations:/src/database - тут каталоги внутри и снаружи не совпадают. А ещё я подозреваю, что имелось в виду не "/src/... на хосте", а "/src/... в том другом контейнере".
сергей кузьмин, если контейнер что-то делает в базе - то вполне нормально что он удаляется в конце. Но в данном случае похоже это даже не планировалось.
SexyHair, он при этом должен создать отдельную сеть с именем типа ИМЯПРОЕКТА_default (см. в docker network ls). Но если не переопределить DNS, будет использоваться тот же, что и у всей системы, но через собственный resolver в качестве прослойки.
SexyHair, он не игнорируется, просто используется вместо системного как вышестоящий ресолвер.
Тут нюанс в том, что докер позволяет переопределить DNS только в дефолтной сетке (bridge docker0). В остальных эта опция означает DNS-сервер, в который docker resolver пересылает запросы, причём этот resolver нельзя убрать. docker-compose на проекст создаёт собственную отдельную сеть.
127.0.0.11 - это docker resolver, DNS в контейнере, я уже говорил, что он большинство запросов проксирует в следующий DNS
127.0.0.53 - это systemd resolved
В выводе systemd-resolve написано, что реальный DNS - 192.168.1.1. Если это дома, то скорее всего DNS в роутере, такой тоже может работать как-нибудь странно.
Предлагаю для сравнения создать контейнер с DNS например от гугла (docker run --dns 8.8.8.8) и проверить, будет ли разница. В общем, попытаться как-то локализовать источник.
SexyHair, я бы проверил что все указанные в resolv.conf (или в resolved) DNS-сервера нормально работают.
Система использует /etc/resolv.conf. Если там указан 127.0.0.53 - это systemd-resolved, нужно смотреть реальные DNS в выводе команды systemd-resolve --status. Ещё можно переопределить DNS в конфигурации докера, в том числе через параметры docker run или в файле для docker-compose, но это вряд ли.
Можно попробовать оставлять один-единственный DNS в /etc/resolv.conf и проверять скриптом на хосте, так выявить, действительно ли конкретный DNS тормозит (а может и вообще не работает?).
MTU тут ни при чём, докеру хватает такого же MTU, как на выходном интерфейсе хоста, а там скорее всего обычные 1500. Более того, при нехватке MTU были бы не редкие задержки, а частые фрагментации пакетов в любых коннектах вне зависимости от использования/неиспользования session.
Скорее проблема в DNS. Если попробовать тестовые запросы делать по IP - проблема уйдёт?
В докере DNS работает так: есть собственный ресолвер, который ресолвит контейнеры по именам, а весь остальной трафик пересылает в штатные DNS, указанные в /etc/resolv.conf, либо в явно указанные в конфигурации контейнера. Если, например, с каким-то из вышестоящих DNS бывают проблемы, когда на него попадаешь, то таймауты вполне объяснимы.
