Изменить:

Если вы используете Docker-for-mac или Docker-for-Windows 18.03+, просто подключитесь к своей службе mysql с помощью хоста host.docker.internal (вместо 127.0.0.1 в строке подключения).

Если вы используете Docker-for-Linux 20.10.0+, вы также можете использовать хост host.docker.internal , если вы запустили свой контейнер Docker с параметром --add-host host.docker.internal:host-gateway.

В противном случае читайте ниже

TL; DR

Используйте --network="host" в своей команде docker run, тогда 127.0.0.1 в вашем контейнере докера будет указывать на ваш хост докера.

Примечание. Этот режим работает только в Docker для Linux, согласно документации.

Примечание о сетевых режимах контейнера докеров

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

docker run --network = bridge (по умолчанию)

Docker по умолчанию создает мост с именем docker0. И у хоста докеров, и у контейнеров докеров есть IP-адрес на этом мосту.

на хосте Docker введите sudo ip addr show docker0, вы получите следующий результат:

[vagrant@docker:~] $ sudo ip addr show docker0
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::5484:7aff:fefe:9799/64 scope link
       valid_lft forever preferred_lft forever

Итак, мой хост-докер имеет IP-адрес 172.17.42.1 в docker0 сетевом интерфейсе.

Теперь запустите новый контейнер и установите на нем оболочку: docker run --rm -it ubuntu:trusty bash и внутри типа контейнера ip addr show eth0, чтобы узнать, как настроен его основной сетевой интерфейс:

root@e77f6a1b3740:/# ip addr show eth0
863: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 66:32:13:f0:f1:e3 brd ff:ff:ff:ff:ff:ff
    inet 172.17.1.192/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::6432:13ff:fef0:f1e3/64 scope link
       valid_lft forever preferred_lft forever

Здесь мой контейнер имеет IP-адрес 172.17.1.192. Теперь посмотрим на таблицу маршрутизации:

root@e77f6a1b3740:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.42.1     0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0

Таким образом, IP-адрес хоста докеров 172.17.42.1 установлен в качестве маршрута по умолчанию и доступен из вашего контейнера.

root@e77f6a1b3740:/# ping 172.17.42.1
PING 172.17.42.1 (172.17.42.1) 56(84) bytes of data.
64 bytes from 172.17.42.1: icmp_seq=1 ttl=64 time=0.070 ms
64 bytes from 172.17.42.1: icmp_seq=2 ttl=64 time=0.201 ms
64 bytes from 172.17.42.1: icmp_seq=3 ttl=64 time=0.116 ms

docker run --network = host

В качестве альтернативы вы можете запустить контейнер докеров с настройками сети, установленными на host. Такой контейнер будет совместно использовать сетевой стек с хостом докера, а с точки зрения контейнера localhost (или 127.0.0.1) будет относиться к хосту докера.

Имейте в виду, что любой порт, открытый в вашем контейнере докера, будет открыт на хосте докера. И это без необходимости использования параметра -p или -P docker run.

Конфигурация IP на моем хосте докеров:

[vagrant@docker:~] $ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:98:dc:aa brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe98:dcaa/64 scope link
       valid_lft forever preferred_lft forever

и из контейнера докеров в режиме хоста:

[vagrant@docker:~] $ docker run --rm -it --network=host ubuntu:trusty ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:98:dc:aa brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe98:dcaa/64 scope link
       valid_lft forever preferred_lft forever

Как вы можете видеть, и хост докера, и контейнер докера используют один и тот же сетевой интерфейс и, таким образом, имеют один и тот же IP-адрес.

Подключение к MySQL из контейнеров

мостовой режим

Чтобы получить доступ к MySQL, работающему на хосте докеров, из контейнеров в режиме моста, вам необходимо убедиться, что служба MySQL прослушивает соединения на 172.17.42.1 IP-адресе.

Для этого убедитесь, что в вашем конфигурационном файле MySQL (my.cnf) указано значение bind-address = 172.17.42.1 или bind-address = 0.0.0.0.

Если вам нужно установить переменную среды с IP-адресом шлюза, вы можете запустить следующий код в контейнере:

export DOCKER_HOST_IP=$(route -n | awk '/UG[ \t]/{print $2}')

затем в своем приложении используйте переменную среды DOCKER_HOST_IP, чтобы открыть соединение с MySQL.

Примечание. если вы используете bind-address = 0.0.0.0, ваш сервер MySQL будет прослушивать соединения на всех сетевых интерфейсах. Это означает, что к вашему серверу MySQL можно получить доступ из Интернета; убедитесь, что правильно настроили правила брандмауэра.

Примечание 2: если вы используете bind-address = 172.17.42.1, ваш сервер MySQL не будет прослушивать подключения к 127.0.0.1. Процессы, запущенные на хосте докеров, которые захотят подключиться к MySQL, должны будут использовать 172.17.42.1 IP-адрес.

режим хоста

Чтобы получить доступ к MySQL, запущенному на хосте докеров, из контейнеров в режиме хоста, вы можете сохранить bind-address = 127.0.0.1 в своей конфигурации MySQL, и все, что вам нужно сделать, это подключиться к 127.0.0.1 из ваших контейнеров:

[vagrant@docker:~] $ docker run --rm -it --network=host mysql mysql -h 127.0.0.1 -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.5.41-0ubuntu0.14.04.1 (Ubuntu)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

примечание: используйте mysql -h 127.0.0.1, а не mysql -h localhost; в противном случае клиент MySQL попытается подключиться через сокет unix.

Для macOS и Windows

Docker версии 18.03 и выше (с 21 марта 2018 г.)

Используйте свой внутренний IP-адрес или подключитесь к специальному DNS-имени host.docker.internal, которое будет преобразовано во внутренний IP-адрес, используемый хостом.

Ожидается поддержка Linux https://github.com/docker/for-linux/issues/264 < / а>

Решение и дополнительная документация здесь: https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds

с использованием

host.docker.internal

вместо того

localhost

у меня работает безупречно. ????

Я делаю хак, аналогичный приведенным выше сообщениям, чтобы получить локальный IP-адрес для сопоставления с псевдонимом (DNS) в контейнере. Основная проблема заключается в том, чтобы динамически получить с помощью простого скрипта, который работает как в Linux, так и в OSX, IP-адрес хоста. Я сделал этот сценарий, который работает в обеих средах (даже в дистрибутиве Linux с настроенным "$LANG" != "en_*"):

ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1

Итак, с помощью Docker Compose полная конфигурация будет:

Сценарий запуска (docker-run.sh):

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)
docker-compose -f docker-compose.yml up

docker-compose.yml:

myapp:
  build: .
  ports:
    - "80:80"
  extra_hosts:
    - "dockerhost:$DOCKERHOST"

Затем измените http://localhost на http://dockerhost в своем коде.

Более подробные инструкции по настройке сценария DOCKERHOST см. На странице этот пост с объяснением того, как это работает.

Это сработало для меня в стеке NGINX / PHP-FPM, не касаясь какого-либо кода или сети, где приложение просто ожидает возможность подключения к localhost

Смонтируйте mysqld.sock от хоста внутрь контейнера.

Найдите расположение файла mysql.sock на хосте, на котором запущен mysql:
netstat -ln | awk '/mysql(.*)?\.sock/ { print $9 }'

Подключите этот файл туда, где он должен быть в докере:
docker run -v /hostpath/to/mysqld.sock:/containerpath/to/mysqld.sock

Возможные местоположения mysqld.sock:

/tmp/mysqld.sock
/var/run/mysqld/mysqld.sock 
/var/lib/mysql/mysql.sock
/Applications/MAMP/tmp/mysql/mysql.sock # if running via MAMP

Решение для Linux (ядро> = 3.6).

Хорошо, ваш сервер localhost имеет интерфейс докеров по умолчанию docker0 с IP-адресом 172.17.0.1. Ваш контейнер запущен с настройками сети по умолчанию --net = "bridge".

1. Включите route_localnet для интерфейса docker0:
   $ sysctl -w net.ipv4.conf.docker0.route_localnet=1
2. Добавьте эти правила в iptables:
   $ iptables -t nat -I PREROUTING -i docker0 -d 172.17.0.1 -p tcp --dport 3306 -j DNAT --to 127.0.0.1:3306
$ iptables -t filter -I INPUT -i docker0 -d 127.0.0.1 -p tcp --dport 3306 -j ACCEPT
3. Создайте пользователя mysql с доступом от "%", что означает - от кого угодно, кроме localhost:
   CREATE USER 'user'@'%' IDENTIFIED BY 'password';
4. Измените в своем скрипте адрес mysql-сервера на 172.17.0.1

Из документации ядра:

route_localnet - BOOLEAN: не рассматривать адреса обратной связи в качестве марсианского источника или пункта назначения при маршрутизации. Это позволяет использовать 127/8 для целей локальной маршрутизации (по умолчанию FALSE).

Пока host.docker.internal не будет работать на всех платформах, вы можете использовать мой контейнер в качестве шлюза NAT без какой-либо ручной настройки:

https://github.com/qoomon/docker-host

Решение для Windows 10

Docker Community Edition 17.06.0-ce-win18 2017-06-28 (стабильный)

Вы можете использовать DNS-имя хоста docker.for.win.localhost для разрешения на внутренний IP-адрес. (Предупреждение, что некоторые источники упоминают windows, но это должно быть win)

Обзор
Мне нужно было сделать что-то подобное, то есть подключиться из моего контейнера Docker к моему локальному хосту, на котором выполнялись Azure Storage Emulator и CosmosDB Emulator.

Azure Storage Emulator по умолчанию прослушивает 127.0.0.1, хотя вы также можете изменить его IP-адрес, я искал решение, которое будет работать с настройками по умолчанию.

Это также работает для подключения из моего контейнера Docker к SQL Server и IIS, которые работают локально на моем хосте с настройками порта по умолчанию.

Очень просто и быстро, проверьте IP-адрес вашего хоста с помощью ifconfig (linux) или ipconfig (windows), а затем создайте

docker-compose.yml

version: '3' # specify docker-compose version

services:
  nginx:
    build: ./ # specify the directory of the Dockerfile
    ports:
      - "8080:80" # specify port mapping
    extra_hosts:
      - "dockerhost:<yourIP>"

Таким образом, ваш контейнер сможет получить доступ к вашему хосту. При доступе к вашей БД не забудьте использовать имя, которое вы указали ранее, в данном случае «dockerhost» и порт вашего хоста, на котором работает БД.

На ум приходят несколько решений:

1. Сначала переместите свои зависимости в контейнеры
2. Сделайте другие ваши сервисы доступными извне и подключайтесь к ним с помощью этого внешнего IP-адреса.
3. Запускайте свои контейнеры без сетевой изоляции
4. Избегайте подключения по сети, вместо этого используйте сокет, который монтируется как том.

Причина, по которой это не работает из коробки, заключается в том, что по умолчанию контейнеры работают со своим собственным сетевым пространством имен. Это означает, что localhost (или 127.0.0.1, указывающий на интерфейс обратной связи) уникален для каждого контейнера. Подключение к нему будет подключаться к самому контейнеру, а не к службам, работающим за пределами докера или внутри другого контейнера докера.

Вариант 1. Если вашу зависимость можно переместить в контейнер, я бы сделал это в первую очередь. Это делает ваш стек приложений переносимым, поскольку другие пытаются запустить ваш контейнер в своей собственной среде. И вы по-прежнему можете опубликовать порт на своем хосте, где другие сервисы, которые не были перенесены, все еще могут достичь его. Вы даже можете опубликовать порт в интерфейсе localhost на вашем хосте докеров, чтобы он не был доступен извне, используя синтаксис типа: -p 127.0.0.1:3306:3306 для опубликованного порта.

Вариант 2. Существует множество способов определить IP-адрес хоста изнутри контейнера, но у каждого из них есть ограниченное количество сценариев, в которых они работают (например, требуется Docker для Mac). Самый переносимый вариант - вставить IP-адрес вашего хоста в контейнер с чем-то вроде переменной среды или файла конфигурации, например:

docker run --rm -e "HOST_IP=$(ip route get 1 | sed -n 's/^.*src \([0-9.]*\) .*$/\1/p')" ...

Это действительно требует, чтобы ваша служба прослушивала этот внешний интерфейс, что может быть проблемой безопасности. Чтобы узнать о других методах получения IP-адреса хоста изнутри контейнера, см. Этот пост.

Чуть менее переносимым является использование host.docker.internal. Это работает в текущих версиях Docker для Windows и Docker для Mac. А в 20.10 в Docker для Linux добавлена ​​возможность, когда вы передаете специальную запись хоста с помощью:

docker run --add-host host.docker.internal:host-gateway ...

host-gateway - это специальное значение, добавленное в Docker 20.10, которое автоматически расширяется до IP-адреса хоста. Для получения дополнительных сведений см. этот PR.

Вариант 3: работа без сетевой изоляции, т. е. работа с --net host, означает, что ваше приложение выполняется в пространстве имен хост-сети. Это меньшая изоляция для контейнера и означает, что вы не можете получить доступ к другим контейнерам через общую сеть докеров с DNS (вместо этого вам нужно использовать опубликованные порты для доступа к другим контейнерным приложениям). Но для приложений, которым требуется доступ к другим службам на узле, которые прослушивают только 127.0.0.1 на узле, это может быть самый простой вариант.

Вариант 4. Различные службы также разрешают доступ через сокет на основе файловой системы. Этот сокет может быть установлен в контейнер в качестве тома, подключенного к привязке, что позволит вам получить доступ к службе хоста, не переходя через сеть. Что касается доступа к движку докера, вы часто видите примеры установки /var/run/docker.sock в контейнер (предоставляя этому контейнеру корневой доступ к хосту). С mysql вы можете попробовать что-то вроде -v /var/run/mysqld/mysqld.sock:/var/run/mysqld/mysql.sock, а затем подключиться к localhost, который mysql преобразует в использование сокета.

Для окон,

Я изменил URL-адрес базы данных в конфигурации Spring: spring.datasource.url=jdbc:postgresql://host.docker.internal:5432/apidb

Затем создайте образ и запустите. У меня это сработало.

Ни один из ответов не помог мне при использовании Docker Toolbox в Windows 10 Home, но 10.0.2.2 работал, поскольку он использует VirtualBox, который предоставляет хост для виртуальной машины по этому адресу.

Для тех, кто работает в Windows, при условии, что вы используете сетевой драйвер моста, вам нужно специально привязать MySQL к IP-адресу сетевого интерфейса Hyper-V.

Это делается через файл конфигурации в обычно скрытой папке C: \ ProgramData \ MySQL.

Привязка к 0.0.0.0 работать не будет. Необходимый адрес также отображается в конфигурации докера, и в моем случае это 10.0.75.1.

Изменить: я закончил прототипирование концепции на GitHub. Оформить заказ: https://github.com/sivabudh/system-in-a-box

Во-первых, мой ответ ориентирован на 2 группы людей: тех, кто использует Mac, и тех, кто использует Linux.

Сетевой режим хоста не работает на Mac. Вы должны использовать псевдоним IP, см. https://stackoverflow.com/a/43541681/2713729

Что такое сетевой режим хоста? См .: https://docs.docker.com/engine/reference/run/#/network-settings

Во-вторых, для тех из вас, кто использует Linux (мой непосредственный опыт был с Ubuntu 14.04 LTS, и я скоро обновлюсь до 16.04 LTS в производственной среде), да, вы можете запустить службу внутри Docker. контейнер подключается к localhost службам, запущенным на хосте Docker (например, на вашем ноутбуке).

Как?

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

docker run --network="host" -id <Docker image ID>

Когда вы выполните ifconfig (вам нужно apt-get install net-tools ваш контейнер для ifconfig, чтобы его можно было вызвать) внутри вашего контейнера, вы увидите, что сетевые интерфейсы такие же, как и на хосте Docker (например, на вашем ноутбуке).

Важно отметить, что я пользователь Mac, но я запускаю Ubuntu под Parallels, поэтому использование Mac не является недостатком. ;-)

Вот как вы подключаете контейнер NGINX к MySQL, работающему на localhost.

Самое простое решение для Mac OSX

Просто используйте IP-адрес вашего Mac. На Mac запустите это, чтобы получить IP-адрес и использовать его из контейнера:

$ ifconfig | grep 'inet 192'| awk '{ print $2}'

Пока сервер, работающий локально на вашем Mac или в другом контейнере докеров, прослушивает 0.0.0.0, контейнер докеров сможет связаться с этим адресом.

Если вы просто хотите получить доступ к другому контейнеру докеров, который прослушивает 0.0.0.0, вы можете использовать 172.17.0.1

Это не ответ на актуальный вопрос. Вот как я решил похожую проблему. Решение полностью исходит из: Определение сети контейнеров Docker, чтобы контейнеры могли взаимодействовать. Спасибо Нику Рабою

Оставим это здесь для других, которые могут захотеть выполнять вызовы REST между одним контейнером и другим. Отвечает на вопрос: что использовать вместо localhost в среде докеров?

Узнайте, как выглядит ваша сеть docker network ls

Создать новую сеть docker network create -d my-net

Запустить первый контейнер docker run -d -p 5000:5000 --network="my-net" --name "first_container" <MyImage1:v0.1>

Проверьте сетевые настройки для первого контейнера docker inspect first_container. «Сети»: должен иметь «my-net»

Запустить второй контейнер docker run -d -p 6000:6000 --network="my-net" --name "second_container" <MyImage2:v0.1>

Проверьте сетевые настройки для второго контейнера docker inspect second_container. «Сети»: должен иметь «my-net»

ssh во второй контейнер docker exec -it second_container sh или docker exec -it second_container bash.

Внутри второго контейнера вы можете пропинговать первый контейнер с помощью ping first_container. Кроме того, вызовы кода, такие как http://localhost:5000, можно заменить на http://first_container:5000

Я не согласен с ответом Томаслевейля.

Привязка mysql к 172.17.42.1 не позволит другим программам использовать базу данных на хосте для доступа к нему. Это будет работать только в том случае, если все пользователи вашей базы данных докеризированы.

Привязка mysql к 0.0.0.0 откроет базу данных для внешнего мира, что не только очень плохо, но и противоречит тому, что хочет сделать автор исходного вопроса. Он прямо говорит: «MySql работает на localhost и не предоставляет порт для внешнего мира, поэтому он привязан к localhost»

Чтобы ответить на комментарий ivant

"Почему бы также не привязать mysql к docker0?"

Это невозможно. В документации mysql / mariadb прямо говорится о невозможности привязки к нескольким интерфейсам. Вы можете привязать только 0, 1 или все интерфейсы.

В заключение я НЕ нашел способа получить доступ к базе данных (только localhost) на хосте из контейнера докеров. Это определенно кажется очень распространенным паттерном, но я не знаю, как это сделать.

Вам необходимо знать шлюз! Мое решение с локальным сервером заключалось в том, чтобы открыть его в 0.0.0.0:8000, затем запустить докер с подсетью и запустить контейнер, например:

docker network create --subnet=172.35.0.0/16 --gateway 172.35.0.1 SUBNET35
docker run -d -p 4444:4444 --net SUBNET35 <container-you-want-run-place-here>

Итак, теперь вы можете получить доступ к своей обратной связи через http://172.35.0.1:8000

Попробуй это:

version: '3.5'
services:
  yourservice-here:
    container_name: container_name
    ports:
      - "4000:4000"
    extra_hosts: # <---- here
      - localhost:192.168.1.202
      - or-vitualhost.local:192.168.1.202

Чтобы получить 192.168.1.202, используется ifconfig

Это сработало для меня. Надеюсь на эту помощь!

Вот мое решение: оно работает в моем случае

• установить публичный доступ к локальному серверу mysql с помощью комментария #bind-address = 127.0.0.1 в /etc/mysql/mysql.conf.d

• перезапустить сервер mysql sudo /etc/init.d/mysql restart

• выполните следующую команду, чтобы открыть пользователю root доступ к любому хосту mysql -uroot -proot GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'root' WITH GRANT OPTION; FLUSH PRIVILEGES;

• создать сценарий sh: run_docker.sh

    #!bin/bash

    HOSTIP=`ip -4 addr show scope global dev eth0 | grep inet | awk '{print \$2}' | cut -d / -f 1`


      docker run -it -d --name web-app \
                  --add-host=local:${HOSTIP} \
                  -p 8080:8080 \
                  -e DATABASE_HOST=${HOSTIP} \
                  -e DATABASE_PORT=3306 \
                  -e DATABASE_NAME=demo \
                  -e DATABASE_USER=root \
                  -e DATABASE_PASSWORD=root \
                  sopheamak/springboot_docker_mysql

  

• запустить с докером-композитором

  version: '2.1'
  
  
  services: 
  tomcatwar: extra_hosts: - "local: 10.1.2.232" образ: sopheamak / springboot_docker_mysql 
  порты: - 8080: среда 8080: - DATABASE_HOST = local - DATABASE_USER = root - DATABASE_PASSWORD = root - DATABASE_NAME = demo -  DATABASE_PORT = 3306

Для Linux, где вы не можете изменить интерфейс, к которому привязана служба localhost

Нам нужно решить две проблемы

1. Получение IP хоста
2. Делаем наш сервис localhost доступным для Docker

Первую проблему можно решить с помощью образа docker-host qoomon, как указано в других ответах.

Вам нужно будет добавить этот контейнер в ту же сеть моста, что и ваш другой контейнер, чтобы вы могли получить к нему доступ. Откройте терминал внутри вашего контейнера и убедитесь, что вы можете пинговать dockerhost.

bash-5.0# ping dockerhost
PING dockerhost (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.523 ms

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

Мы можем использовать telnet, чтобы проверить, можем ли мы получить доступ к порту на хосте (вам может потребоваться установить это).

Проблема в том, что наш контейнер будет иметь доступ только к службам, которые привязаны ко всем интерфейсам, таким как SSH:

bash-5.0# telnet dockerhost 22
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

Но сервисы, привязанные только к localhost, будут недоступны:

bash-5.0# telnet dockerhost 1025
telnet: can't connect to remote host (172.20.0.2): Connection refused

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

Во-первых, нам нужно найти имя сети моста, которую docker использует с ifconfig. Если вы используете безымянный мост, это будет просто docker0. Однако, если вы используете именованную сеть, у вас будет мост, начинающийся с br-, который докер будет использовать вместо него. Мой br-5cd80298d6f4.

Как только у нас есть имя этого моста, нам нужно разрешить маршрутизацию с этого моста на localhost. По умолчанию это отключено из соображений безопасности:

sysctl -w net.ipv4.conf.<bridge_name>.route_localnet=1

Теперь настроим наше iptables правило. Поскольку наш контейнер может получить доступ только к портам в сети моста докеров, мы собираемся сделать вид, что наша служба действительно привязана к порту в этой сети.

Для этого мы будем перенаправлять все запросы с <docker_bridge>:port на localhost:port

iptables -t nat -A PREROUTING -p tcp -i <docker_bridge_name> --dport <service_port> -j DNAT --to-destination 127.0.0.1:<service_port>

Например, для моей службы на порту 1025

iptables -t nat -A PREROUTING -p tcp -i br-5cd80298d6f4 --dport 1025 -j DNAT --to-destination 127.0.0.1:1025

Теперь у вас должна быть возможность получить доступ к своей службе из контейнера:

bash-5.0# telnet dockerhost 1025
220 127.0.0.1 ESMTP Service Ready

Сначала см. этот ответ о вариантах решения этой проблемы. Но если вы используете docker-compose, вы можете добавить network_mode: host к своей службе, а затем использовать 127.0.0.1 для подключения к локальному хосту. Это лишь один из вариантов, описанных в ответе выше. Ниже вы можете узнать, как я модифицировал docker-compose.yml из https://github.com/geerlingguy/php-apache-container.git:

 ---
 version: "3"
 services:
   php-apache:
+    network_mode: host
     image: geerlingguy/php-apache:latest
     container_name: php-apache
...

+ указывает на добавленную мной строку.

[Дополнительная информация] Это также работало в версии 2.2. и host или просто host работают в docker-compose.

 ---
 version: "2.2"

 services:
   php-apache:
+    network_mode: "host"
        or
+    network_mode: host
...

Подключитесь к адресу шлюза.

❯ docker network inspect bridge | grep Gateway
                    "Gateway": "172.17.0.1"

Убедитесь, что процесс на хосте прослушивает этот интерфейс или все интерфейсы и запускается после докера. Если вы используете systemd, вы можете добавить следующее, чтобы убедиться, что он запускается после docker.

[Unit]
After=docker.service

Пример

❯ python -m http.server &> /dev/null &
[1] 149976

❯ docker run --rm python python -c  "from urllib.request import urlopen;print(b'Directory listing for' in urlopen('http://172.17.0.1:8000').read())" 
True

Вы можете получить IP-адрес хоста, используя alpine image

docker run --rm alpine ip route | awk 'NR==1 {print $3}'

Это было бы более последовательным, поскольку вы всегда используете alpine для выполнения команды.

Подобно ответу Мариано, вы можете использовать ту же команду для установки переменной среды

DOCKER_HOST=$(docker run --rm alpine ip route | awk 'NR==1 {print $3}') docker-compose up

Группы C и пространства имен играют важную роль в экосистеме контейнеров.

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

Вот базовое понимание подхода к решению, которому вы могли бы следовать:

Использовать сетевое пространство имен

Когда контейнер появляется вне образа, определяется и создается сетевой интерфейс. Это дает контейнеру уникальный IP-адрес и интерфейс.

$ docker run -it alpine ifconfig

При изменении пространства имен на host, сети cotainers не остаются изолированными от своего интерфейса, процесс будет иметь доступ к сетевому интерфейсу хост-машины.

$ docker run -it --net=host alpine ifconfig

Если процесс прослушивает порты, они будут прослушиваться на интерфейсе хоста и сопоставлены с контейнером.

Использование пространства имен PID. Изменение пространства имен Pid позволяет контейнеру взаимодействовать с другим процессом за пределами его обычной области действия.

Этот контейнер будет работать в собственном пространстве имен.

$ docker run -it alpine ps aux

Изменив пространство имен на хост, контейнер также может видеть все другие процессы, запущенные в системе.

$ docker run -it --pid=host alpine ps aux

Совместное использование пространства имен

Это плохая практика в производственной среде, потому что вы выходите за рамки модели безопасности контейнера, которая может открываться для уязвимостей и легкого доступа к перехватчику. Это только для инструментов отладки и занижения лазеек в безопасности контейнеров.

Первый контейнер - это сервер nginx. Это создаст новую сеть и пространство имен процесса. Этот контейнер привяжется к порту 80 вновь созданного сетевого интерфейса.

$ docker run -d --name http nginx:alpine

Другой контейнер теперь может повторно использовать это пространство имен,

$ docker run --net=container:http mohan08p/curl curl -s localhost

Также этот контейнер может видеть интерфейс с процессами в общем контейнере.

$ docker run --pid=container:http alpine ps aux

Это позволит вам предоставить больше привилегий контейнерам без изменения или перезапуска приложения. Аналогичным образом вы можете подключиться к mysql на хосте, запустить и отладить свое приложение. Но идти этим путем не рекомендуется. Надеюсь, это поможет.

Я решил это, создав пользователя в MySQL для ip контейнера:

$ sudo mysql<br>
mysql> create user 'username'@'172.17.0.2' identified by 'password';<br>
Query OK, 0 rows affected (0.00 sec)

mysql> grant all privileges on database_name.* to 'username'@'172.17.0.2' with grant option;<br>
Query OK, 0 rows affected (0.00 sec)

$ sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
<br>bind-address        = 172.17.0.1

$ sudo systemctl restart mysql.service

Затем в контейнере: jdbc:mysql://<b>172.17.0.1</b>:3306/database_name

Вы можете просто сделать ifconfig на хост-машине, чтобы проверить IP-адрес вашего хоста, а затем подключиться к IP-адресу из вашего контейнера, отлично работает для меня.

Пока fix не будет объединен в ветку master, чтобы IP-адрес хоста запускался изнутри контейнер:

ip -4 route list match 0/0 | cut -d' ' -f3

(как предлагает @Mahoney здесь).

Чтобы все заработало, вам нужно создать конфиг для вашего сервера (caddy, nginx), где основным доменом будет docker.for.mac.localhost. Для этого замените в baseURL http: // localhost / api на http: //docker.for.mac.localhost/api

docker-compose.yml

backend:
  restart: always
  image: backend
  build:
    dockerfile: backend.Dockerfile
    context: .
  environment:
    # add django setting.py os.getenv("var") to bd config and ALLOWED_HOSTS CORS_ORIGIN_WHITELIST
    DJANGO_ALLOWED_PROTOCOL: http
    DJANGO_ALLOWED_HOSTS: docker.for.mac.localhost
    POSTGRES_PASSWORD: 123456
    POSTGRES_USER: user
    POSTGRES_DB: bd_name
    WAITDB: "1"
  volumes:
    - backend_static:/app/static
    - backend_media:/app/media
  depends_on:
    - db

frontend:
  restart: always
  build:
    dockerfile: frontend.Dockerfile
    context: .
  image: frontend
  environment:
    #  replace baseURL for axios
    API_URL: http://docker.for.mac.localhost/b/api
    API_URL_BROWSER: http://docker.for.mac.localhost/b/api
    NUXT_HOST: 0.0.0.0
  depends_on:
    - backend

caddy:
  image: abiosoft/caddy
  restart: always
  volumes:
    - $HOME/.caddy:/root/.caddy
    - ./Caddyfile.local:/etc/Caddyfile
    - backend_static:/static
    - backend_media:/media
  ports:
  - 80:80
  depends_on:
    - frontend
    - backend
    - db

Caddyfile.local

http://docker.for.mac.localhost {

  proxy /b backend:5000 {
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Port {server_port}
    header_upstream X-Forwarded-Proto {scheme}
  }

  proxy / frontend:3000 {
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Port {server_port}
    header_upstream X-Forwarded-Proto {scheme}
  }

  root /

  log stdout
  errors stdout
  gzip
}

http://docker.for.mac.localhost/static {
  root /static
}

http://docker.for.mac.localhost/media {
  root /media
}

django settings.py

ALLOWED_HOSTS = [os.getenv("DJANGO_ALLOWED_HOSTS")]
    
CORS_ORIGIN_WHITELIST = [f'{os.getenv("DJANGO_ALLOWED_PROTOCOL")}://{os.getenv("DJANGO_ALLOWED_HOSTS")}']

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql_psycopg2",
        "NAME": os.getenv("POSTGRES_DB"),
        "USER": os.getenv("POSTGRES_USER"),
        "PASSWORD": os.getenv("POSTGRES_PASSWORD"),
        "HOST": "db",
        "PORT": "5432",
    }
}

nuxt.config.js (переменная baseURL переопределит API_URL среды)

axios: {
  baseURL: 'http://127.0.0.1:8000/b/api'
},

сервер на хосте прослушивает порт 5000; он отправит строку response from host обратно в качестве ответа

echo "response from host" | nc -l -p 5000

докер по умолчанию работает в режиме моста (это более безопасно, чем в режиме хост-сети); процесс в докере получает адрес ipv4 для первого сетевого интерфейса на хосте, отличного от 127.0.0.1; этот адрес ipv4 передается докеру через переменную окружения HOSTIP; внутри докера есть команда nc, которая подключается к серверу по ip хоста и порту 5000; команда также читает ответ сервера.

HOST=$(ifconfig | grep 'inet ' | grep -v 127.0.0.1 | awk '{ print $2 }' | head -1 | sed -n 's/[^0-9]*\([0-9\.]*\)/\1/p'); docker run -e HOSTIP="${HOST}" --rm -it alpine /bin/sh -c 'echo "greetings from container" | nc $HOSTIP 5000 -v'

Выражение, которое вычисляет IPv4-адрес первого из перечисленных интерфейсов, действительно работает в OSX и Linux:

HOST=$(ifconfig | grep 'inet ' | grep -v 127.0.0.1 | awk '{ print $2 }' | head -1 | sed -n 's/[^0-9]*\([0-9\.]*\)/\1/p')

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

docker run --expose 5000 -p :5000:5000 --rm -it alpine /bin/sh -c 'echo "response from host" | nc -l -p 5000'

--expose 5000, контейнер докеров может принимать соединение через порт 5000

-p: 5000: 5000 механизм докеров на стороне хоста прослушивает порт 5000 на любом интерфейсе и перенаправляет соединения на порт 5000 в контейнерной сети (где запущен nc).

Для Windows Machine: -

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

$docker run -d --name MyWebServer -P mediawiki

В приведенном выше списке контейнеров вы можете увидеть порт, назначенный как 32768. Попробуйте получить доступ

localhost:32768 

Вы можете увидеть страницу mediawiki

Я делаю это так: передаю IP-адрес хоста в качестве переменной среды в контейнер. Затем контейнер обращается к хосту с помощью этой переменной.

если вы используете docker-compose, возможно, это сработает:

iptables -I INPUT ! -i eth0 -p tcp --dport 8001 -j ACCEPT

eth0 - это ваш сетевой интерфейс, который подключается к Интернету, а 8081 - порт хост-сервера.

лучший способ для правила iptables - iptables TRACE

Несмотря на множество длинных, непонятных ответов, короткий. Если ваша сеть моста докеров 172.17.0.0/16, выполните следующие действия:

1. Привяжите свой контейнер к 172.17.0.1, например. -p 172.17.0.1:8080:8080 (какой бы ни был шлюз в вашей сети моста Docker)
2. Просто войдите в порт 8080 172.17.0.1, например. curl http://172.17.0.1:8080/ из другого контейнера