нет интернета внутри службы docker-compose

В последний раз, когда у меня была такая проблема, я решил ее так:

https://github.com/docker/docker/issues/866#issuecomment-19218300

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

Это заставит докер воссоздать мост и переустановить все сетевые правила.

Что касается причин, по которым это происходит, у меня нет хороших ответов. Но я недавно отследил проблему до journald. Когда я перезапускаю journald (например, потому что я изменил его конфигурацию), разрешение DNS внутри контейнеров docker-compose постоянно / воспроизводимо прерывается. Не знаю почему, могу только сказать, что для меня это надежный способ воспроизвести его на RHEL.

ИЗМЕНИТЬ Команда docker -d может не работать для вас в зависимости от используемой вами версии докера, но не беспокойтесь об этом, вы можете пропустить эту команду.

Отметьте /etc/default/docker, чтобы убедиться, что в нем нет следующей строки:

DOCKER_OPTS="--iptables=false"

Также проверьте /etc/docker/daemon.json, чтобы убедиться, что у него нет следующего ключа:

{
"iptables":false
}

Мы добавили это на один сервер, чтобы UFW работал с докером. Затем мы перешли на внешний брандмауэр. Потратил много времени на поиск причины, по которой внешняя сеть не работает, потому что она была удалена из нашего руководства по развертыванию. Надеюсь, это поможет кому-то другому.

Контейнеры Docker по умолчанию имеют возможность доступа в Интернет. Вот как я решил проблему на прошлой неделе: контейнер докеров может только доступ в Интернет с помощью сетевого хоста

Или вы просто позволяете контейнеру работать в режиме хоста:

version: '2'
service:
  nginx:
    image: nginx
    network_mode: host

Но, как отметил @peedee в комментарии, это решение потеряет разделение сети между хостом и контейнерами.

Образ nginx, который вы загружаете, по умолчанию не установлен ping. Поэтому, если вы действительно используете ping для проверки своего соединения, вы должны сначала установить его.

Я создал собственный Dockerfile для его установки:

FROM nginx:latest
RUN apt update && apt -y install iputils-ping

Затем я построил его локально и пометил как mynginx.

Затем я изменил docker-compose.yml, чтобы использовать пользовательское изображение mynginx:

version: '2'
services:
  nginx:
    image: mynginx

Наконец, я запустил docker-compose up, выполнил для него docker exec и протестировал ping. Все работало нормально. Я тоже сделал docker run -ti ..., и это сработало.

Что меня беспокоит в вашем вопросе, так это то, как docker run может дать вам контейнер с другим поведением, чем если бы он был создан docker-compose up.

Тем не менее, было бы полезно прояснить, как вы проверяете доступ в Интернет.

Я только что столкнулся с этим. Запустив любой контейнер с docker run -it <image> bash, я мог делать все, что было связано с сетью, что мне было нужно, но подключение к контейнеру, запущенному через docker-compose с docker exec -it <conatiner> bash, ничего не могло запустить. Даже apt-get выйдет из строя из-за временного сбоя в ошибке разрешения имен.

Я обнаружил, что добавление network_mode: "bridge" к каждой службе позволит включить внешнюю сеть в каждом контейнере за счет подключения всего к сети докеров по умолчанию. Однако я хотел сохранить стек изолированным, поэтому выбрал альтернативное решение.

Я запустил docker inspect network bridge, чтобы просмотреть сеть по умолчанию, и то же самое с моей сетью стека. Единственными существенными различиями, которые я обнаружил, была разница в подсети / шлюзе (что, я считаю, вполне ожидаемо, однако перечисленные IP-адреса различались значительно, 192. * против 172. *), и что сеть по умолчанию имел несколько опций, которых не было в стековой сети:

"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"

Мне удалось изолировать его от "com.docker.network.bridge.default_bridge": "true", однако это нарушило сеть для контейнеров вне стека, до такой степени, что мне в конечном итоге пришлось полностью удалить и переустановить докер. Я предполагаю, что демон докера путается с двумя сетями, отмеченными как стандартные, и не может разрешить его даже после удаления сети стека.

Одна вещь, которую я заметил после этого, заключалась в том, что подсеть и выход были просто отключены от адаптера по умолчанию. Я подтвердил, что удаление вышеуказанного параметра вернуло подсеть и шлюз к тому, что я видел изначально, что он и сделал. Затем я использовал эту сетевую конфигурацию в своем файле создания:

networks:
  default:
    driver: "bridge"
    ipam:
      driver: default
      config:
        - subnet: X.X.0.0/16

Где первое значение подсети было таким же, как у адаптера моста по умолчанию, а второе значение было плюс один. И это, по крайней мере, заставило все работать нормально, за исключением того, что адаптер по умолчанию все еще сломан.

Интересно, что когда я переустановил докер, чтобы попытаться восстановить сеть по умолчанию, я в основном выполнил следующее после просмотра docker составляет сетевую документацию для внешней сети.

sudo snap remove docker
sudo sysctl net.ipv4.conf.all.forwarding=1
sudo iptables -P FORWARD ACCEPT
sudo snap install docker

И последующий docker-compose up -d с удаленными сетевыми настройками привел к тому же IP-адресу подсети, который я определил ранее, без наличия для него конфигурации. Я считаю, что основная проблема заключается просто в том, что что-то мешало демону докера правильно найти доступную действительную подсеть, и как только это будет решено, все должно снова работать из коробки.

В моем случае докер был установлен через snap, после его удаления и установки, следуя инструкциям официального сайт заработал нормально.