Я исследовал это недавно - это специально - изоляция контейнера . Обычно только главный (сервис httpd
) хост доступен извне , скрывая внутренние соединения (хосты, с которыми он связывается для доставки ответа).
Контейнер, созданный в собственной сети, недоступен с внешних адресов, даже из контейнеров в том же мосту, но из другой сети (172.19.0.0/16).
Ваш контейнер должен быть доступен по docker адресу хоста (127.0. 0.1, если работает локально) и сопоставленный ("-p 3306: 3306") порт - 3306 . Но, конечно, это не сработает, если многие работающие контейнеры БД имеют одинаковое отображение на один и тот же порт хоста.
Изоляция выполняется с помощью брандмауэра - iptables. Вы можете перечислить правила (iptables -L
), чтобы увидеть это с docker уровня хоста.
Вы можете изменить брандмауэр, чтобы разрешить внешний доступ к внутренним сетям. Я использовал это правило:
iptables -A DOCKER -d 172.16.0.0/12 -j ACCEPT
После этого ваш MySQL контейнерный движок должен быть доступен по внутреннему адресу 172.18.0.2 и исходному (не отображенному) порту 3306.
Предупреждения
- отключает всю изоляцию, не используйте ее на производстве;
- вы должны запускать это после каждые docker запуск - правила, созданные / измененные docker на лету
- не каждый контейнер docker ответит на
ping
, проверьте его сначала с хоста docker (в данном случае linux), с windows cmd
позже
Я использовал эту опцию (в docker.service
), чтобы сделать правило постоянным:
ExecStartPost=/bin/sh -c '/etc/iptables/accept172_16.sh'
Для docker на внешнем (совместно используемом в локальной сети) хосте вы должны использовать route add
(или файл hosts
на вашем компьютере или маршрутизаторе) для пересылки адресов 172.xxx на хост lan docker.
Подсказка: используйте проект portainer
(с политикой перезапуска - всегда) для управления docker контейнерами. Также легче увидеть ошибки конфигурации.