did you find ip in virtualbox or on host ?

I think the docker0 was on the virtualbox VM.

Im talking about docker for mac that is in beta and does not do its work via a vm

I am also facing exact same issue. Found ip address of host on docker machine using below command. Assuming 0.0.0.0 represent host, correct me if i am wrong here.
netstat -nr | grep '^0.0.0.0' | awk '{print $2}'
172.17.0.1

but when do curl on this ip with a port where i am running a web server it gives connection refused.
curl 172.17.0.1:9000
curl: (7) Failed to connect to 172.17.0.1 port 9000: Connection refused

Not sure how to get proper fix. This seems to be giving trouble as need to connect to service which will run on host machine.
Also found a way to fix ip address of host machine by setting it in DOCKER_OPTS.
DOCKER_OPTS="-H tcp://0.0.0.0:5000 -H unix:///var/run/docker.sock --bip=172.17.42.1/16"

but where on mac can i put this options? on ubuntu it can be placed at /etc/default/docker.

Please provide directions if this can be fixed on mac.

ping @justincormack perhaps you have some hints here.

@MiteshSharma exactly, that is one of the first things I tried as well and with exactly the same problems

@NinoFloris Seems like we both are exact same place. In my case i am running mysql on my host machine.
Hey guys,
Do update if someone is able to do this.

I used this
https://docs.docker.com/engine/installation/mac/

not sure if your beta any special

@HackToday that's different, that's the VirtualBox based Mac installation; Docker for Mac is on beta.docker.com

Thanks @thaJeztah Any possible good doc link for related Mac Docker architecture or something else details? Seems interesting

@HackToday https://blog.docker.com/2016/03/docker-for-mac-windows-beta/ gives a little more, and there is documentation, but I think it's only if you are in the beta; https://beta.docker.com/docs/. If you sign-up for the beta, then give me a "ping"; I can try to get you on the priority list as a contributor :smile:

oh @thaJeztah Thanks, I thought it was a free to work and try. Not need any special to contribute. I will read that blog first to understand before I try. 😺

@HackToday it's completely free, just to not overwhelm the team, it was decided to release it as a "private" beta first, because "many users' === "many support questions" :smile:

Hi, yes there is not currently a way to route from the Mac to the docker0 bridge. We may be able to add this later, but generally we would recommend you connect from a container, or by exposing ports. This is the same as with docker overlay networks as well on Linux, which you cannot connect to from the host.

Well not really satisfactory as macs are usually not production servers but
dev machines.

On my production machines i dont mind the problem of not being able to
connect to the host.

But on a dev machine connecting to services on the same host from inside a
container is exactly the scenario where this functionality is desired the
most.

I need this docker0 interface too for using in mixed "docker + on host (from IDE) running apps" environment.

The current best solution is to connect to your containers from another container. At present there is no way we can provide routing to these containers due to issues with OSX that Apple have not yet resolved. we are tracking this requirement, but we cannot do anything about it at present.

Is the above comment accurate?

I found that, from within docker-for-mac-beta containers, the docker host could be found and connected to at the usual 172.17.0.1 address (assuming the service bound to 0.0.0.0).

@igrayson This is because the containers are in the VM with the docker daemon and can certainly access it.
The issue is routing from OSX into the VM net.

The issue is routing from OSX into the VM net.

That's not my understanding of the OP issue:

I would like to be able to connect to my local redis and other services without having to dockerize these...

I am running docker-for-mac-beta, and have no trouble connecting to redis and other local services -- running on OSX -- by having them listen on 0.0.0.0, and having my dockerized apps connect to 172.17.0.1.

Overview

I have the same problem. Using Docker version 1.11.1-beta14 (build: 8670) 984649fbd63d53a62b34f08b59694d4d569b74d5. My pinata doctor says everything is ok.

I cannot curl a service running in host, for example an ExpressJS application listening in the port 3001, from inside the container:

root@e19fc8e02595:/# curl localhost:3001
curl: (7) Failed to connect to localhost port 3001: Connection refused

root@e19fc8e02595:/# curl 0.0.0.0:3001
curl: (7) Failed to connect to 0.0.0.0 port 3001: Connection refused

root@e19fc8e02595:/# curl 172.25.8.25:3001
{"status":200} 
root@e19fc8e02595:/#

_Note: 172.25.8.25 is my WiFi IP._

Pinata

$pinata list
These are advanced configuration settings to customize Docker.app on MacOSX.
You can set them via pinata set <key> <value> <options>.

🐳  hostname = docker
   Hostname of the virtual machine endpoint, where container ports will be
   exposed if using nat networking. Access it via 'docker.local'.

🐳  hypervisor = native (memory=4, ncpu=6)
   The Docker.app includes embedded hypervisors that run the virtual machines
   that power the containers. This setting allows you to control which the
   default one used for Linux is.

 ▸  native: a version of the xhyve hypervisor that uses the MacOSX
              Hypervisor.framework to run container VMs. Parameters:
              memory (VM memory in gigabytes), ncpu (vCPUs)


🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

 ▸ hostnet: a mode that helps if you are using a VPN that restricts
              connectivity. Activating this mode will proxy container network
              packets via the Docker.app process as host socket traffic.
              Parameters: docker-ipv4 (docker node), host-ipv4 (host node)
 ▸     nat: a mode that uses the MacOS X vmnet.framework to route container
              traffic to the host network via a NAT.

🐳  filesystem = osxfs
   Controls the mode by which files from the MacOS X host and the container
   filesystem are shared with each other.

 ▸   osxfs: a FUSE-based filesystem that bidirectionally forwards OSX
              filesystem events into the container.


🐳  native/port-forwarding = true
   Expose container ports on the Mac, rather than the VM

 ▸    true: Container ports will be exposed on the Mac
 ▸   false: Container ports will be exposed on the VM

🐳  daemon = run 'pinata get daemon' or 'pinata set daemon [@file|-]>
   JSON configuration of the local Docker daemon. Configure any custom
   options you need as documented in:
   https://docs.docker.com/engine/reference/commandline/daemon/. Set it
   directly, or a @file or - for stdin.

Possible duplicates, references, help and etc

• https://github.com/docker/docker/issues/23388
• https://forums.docker.com/t/beta-9-and-localhost-connection-via-net-host/10471
• https://forums.docker.com/t/docker-for-mac-beta-9-and-daemon-options/10449/9
• http://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach
• http://stackoverflow.com/questions/29598504/how-to-connect-to-service-in-the-host-machine-from-inside-a-docker-container
• http://blog.michaelhamrah.com/2014/06/accessing-the-docker-host-server-within-a-container/

I had similiar issues and found 172.* ips would not let me connect to a local mysql instance binded to 0.0.0.0.

I could connect to it with any routable IP address from my host machine. ifconfig and find one of yours.

Now how do I get this dynamically into the container?

Having the same issue as @Kazanz (mysql running on locally/uncontained) trying 172.17.0.1. So I guess I'll try the Docker Toolbox? It would be helpful if this constraint was documented. I couldn't find anything about it until I stumbled upon this issue.

Ping @londoncalling ^^

Any news about this one? because in Ubuntu (host) the application inside container which listen on 0.0.0.0 can be contacted by the host using IP 172.17.*.*.. So no need to expose port when running the container.

On Docker for Mac Beta I can not do that because the absent of docker0. Hope it getting fixed on the final release :)

@thaJeztah @astasoft I'll look into it today, thanks@

My understanding is that your issue is accessing services running on your Mac from a container.
If that is the case, you can do that using the ip address exposed by en0 interface.
ifconfig en0 | grep "inet " | cut -d " " -f2

For example, if I have a web server running on my Mac on port 80:
docker run -it tutum/curl curl ifconfig en0 | grep "inet " | cut -d " " -f2

It works!

You could set that ip in an environment variable and pass that to your container, like I do for the X11 server in https://github.com/chanezon/docker-tips/blob/master/x11/README.md

@chanezon I was able to get this to work, but it seems less than ideal, as this IP changes often depending on the network you're connected to. I was hoping to set a more or less static IP representing my local docker bridge.

@londoncalling Thanks,

@chanezon No, my case is accessing service from Host to the container. There is a case when I want to run web server in my host on port 80 and the same port in my container. If I expose the container port 80 to the host, I will not able to run web server on my host machine. This kind of setup is big deal for my development.

My current workaround is go back to Docker Toolbox for Mac and do port forwarding on the Boot2Docker instance on Virtualbox.

sudo iptables -t nat -A PREROUTING -d 192.168.99.100/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.2:80

Then I can call service in the container by using boot2docker IP 192.168.99.100:80.

curl -i http://192.168.99.100

So I'm having the following issue that it might be related to this.
Just for the sake of being clear I'm running Docker Beta for Mac 1.12.0-beta21 (build: 10868).

Basically I can not connect from the host to the container using the 172.17.0.2 IP address, because there's no docker0 interface with the 172.17.0.1 address assigned.

The container is a ubuntu image and here's the networking relevant information

root@app:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:524 errors:0 dropped:0 overruns:0 frame:0
          TX packets:370 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:217502 (217.5 KB)  TX bytes:40451 (40.4 KB)

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

The host is a MacbookPro and as you can see in the next snippet that it has no docker0 (or any interface for this matter) with an IP address 172.17.0.1, which is assigned in the container as the gateway.

robert@localhost $ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 ::1 prefixlen 128
    inet 127.0.0.1 netmask 0xff000000
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
    ether f4:5c:89:c9:be:0d
    nd6 options=1<PERFORMNUD>
    media: autoselect (<unknown type>)
    status: inactive
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f0
    media: autoselect <full-duplex>
    status: inactive
en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f1
    media: autoselect <full-duplex>
    status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
    ether 06:5c:89:c9:be:0d
    media: autoselect
    status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1484
    ether 0e:f1:f1:4d:46:88
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether f6:5c:89:9c:e6:00
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x2
    member: en1 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 5 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 6 priority 0 path cost 0
    nd6 options=1<PERFORMNUD>
    media: <unknown type>
    status: inactive
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
    ether 39:c9:87:45:22:ee
    inet6 fe80::3ac9:86ff:fe40:22de%en4 prefixlen 64 scopeid 0x9
    inet 192.168.1.123 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=1<PERFORMNUD>
    media: autoselect (1000baseT <full-duplex,flow-control>)
    status: active

Some colleagues have this working properly on Ubuntus hosts, so I'm guessing this is either a Mac issue or local environment.
Any idea?

@robertoestivill not sure about the exact use-case, but if that container published a port, you can access it through localhost:port

@nikdavis if you want a stable IP, you can add an IP (any one that you will never route to) to the lo0 loopback interface of the Mac and use that.

Hi, imho, this is quite a big difference to docker on linux. There is a lot of documentation out there that simply doesn't apply. I am also not network-knowledgable enough to know how to attach another ip to lo0 and then what. It would be really helpful if there was a description of workarounds (that do not involve boot2docker) for this issue and mentioning it in the docs.

@justincormack @chanezon can we work together on this to get some good docs around this issue?

@pourquoi42
You can add another IP to the lo0 interface as follows:
CONTAINER_IP=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' container-name)
ifconfig lo0 alias $CONTAINER_IP

To remove it:
ifconfig lo0 -alias $CONTAINER_IP

@itilk Doesn't seem to work on MacOs. Tried with the names and container id.

robert@work:~ $ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
d047790e196a        group/name              "/bin/bash"         About a minute ago   Up About a minute                       jovial_goodall

robert@work:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' jovial_goodall

robert@work:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' d047790e196a

robert@work:~ $

I had Docker 1.12.0 (build 10871) running on Darwin,
1) All the docker container works fine;
2) The container can communicate with the host;
3) Communication between containers works fine;

Where is the docker0 virtual interface? OR there are any way can let host connect to the containers?

sad to read this: Known Limitations on OSX

Known Limitations
There is no docker0 bridge on OSX
Because of the way networking is implemented in Docker for Mac, you cannot see a docker0 interface in OSX. This interface is actually within HyperKit.

I can’t ping my containers
Unfortunately, due to limtations in OSX, we’re unable to route traffic to containers, and from containers back to the host.

So for now, We just one way to connect host to container: Port Mapping

Version 1.12.0-beta21 (build: 11019)
1) All the docker container works fine.
2) The container can't communicate with the host.
3) Communication between containers works fine.
4) docker0 not available.

Ad.2)

Im having hugo instance that binds to 0.0.0.0 on port 1313. curl from within the running container returns: curl: (7) Failed to connect to 172.19.0.1 port 1313: Connection refused.
Using ip address returned by ifconfig en0 | grep "inet " | cut -d " " -f2 does not work either:
curl: (7) Failed to connect to 172.19.27.228 port 1313: No route to host.

Hi all,

i found an article from other container product(not docker): https://www.flockport.com/using-flockbox-with-xhyve/, and i also haven't even tested it if it does work indeed.

at the end, it mentions:

You can also use routing instead of portforwarding described above to access apps in containers. Routing will make the entire container subnet inside the VM available on the host.

If you would prefer to use routing instead of port forwarding this is how it works. Routing commands need to be run on the host.

If your VM IP is 192.168.64.3 and container subnet is 10.0.3.0/24 you can create a route with a command like below

sudo route -n add 10.0.3.0/24 192.168.64.3

Xyhve creates a bridge100 interface automatically for VM networking. Run a quick ifconfig to check the interface bridge100 is on, for instance en4, and then run the command below.

sudo ifconfig bridge100 -hostfilter en4

Now you should be able to ping any container inside the VM directly from the host

ping 10.0.3.175

To access the app on your Hosts browser edit the /etc/hosts file on the host as described above with port forwarding but this time associate the container IP with the app URL.

Sorry that I have bare knowledge of the linux networking stuffs, but is it a workaround?

I don't know how to get the IP Address of the vm(alpine with docker) running inside xhyve, any ideas?

Hi @Kaijun , I had not install Docker Machine, and where your bridge100 comes from?

@junjiemars no, the article i posted is not docker related, it's just another container product which works basically in the same approach with docker. (Host -> VM(xhyve) -> Containers)

I thought if we can get inspired by this article or this product and apply the same workaround for docker itself.

@Kaijun , I know there may be a way to hack xhyve to get things done, If you done it please sharing your hacking.

@nikdavis if you want a stable IP, you can add an IP (any one that you will never route to) to the lo0 loopback interface of the Mac and use that.

@justincormack Would you mind being more precise how to achieve this? :)
I tried what @itilk posted, but it didn't work for me.

Generally speaking: Is there an ETA for re-introducing the docker0 network in docker for mac beta?

Thx

@georgehrke you can do sudo ifconfig lo0 alias 10.200.10.1/24 - obviously pick an address you are not going to find locally. Then you can use that address to talk to the host regardless of whether you have a network connection.

Sorry for not stating my issue more precisely.

I'm not trying to connect from a container to the host, but the other way around.
I can't connect from my host to a container directly.

I was using docker inspect container_name to get the IP.
But I can neither ping it nor open it it in a browser even though the Dockerfile has a web server and EXPOSE 80 in it

Yes there are two separate issues, which are somewhat related.

1. I want to connect from a container to a service on the host. The Mac has a changign IP address or none if you have no network access.

Current recommendation is to attach an unused IP to the lo0 interface on the Mac eg sudo ifconfig lo0 alias 10.200.10.1/24, make sure your service is listening on this address or 0.0.0.0 (ie not 127.0.0.1). Then containers can connect to this address.

1. I want to connect to a container from the Mac.

Current recommendation is to publish a port, or to connect from another container. Note that this is what you have to do even on Linux if the container is on an overlay network not a bridge network as these are not routed.

We understand that these are not ideal but there are several problems, in particular a bug in OSX that is only fixed in 10.12 and which is not being backported as far as we can tell which means that we could not support this in all the supported OSX versions. In addition this network setup would require root access which we are trying to avoid entirely in Docker for Mac (we currently have a very small root helper that we are trying to remove).

(@londoncalling do you want to add this summary to the docs?)

@justincormack you mean all --net=host on macOS Docker is useless?

@m1ome it is not completely useless - you can connect to services you run there from other containers as the ports are opened on the VM, but people expect the services there to be available on the Mac like published ports, which we have not got to work yet as this is rather complex (we dont get an event feed for ports you open like that, unlike published ports where we use docker events).

@justincormack is here some workaround for this issue a least for now? If Docker have it i think it will pretty useful to write it down in documentation.

@justincormack I can add your write up to the docs, but I think we should include some specific examples. I'll try it out myself, but will probably need yours or someone else's help. I'll get back to you on it as I work through it.

@londoncalling sure will send you some.

On 30 Aug 2016 6:28 p.m., "Victoria" [email protected] wrote:

@justincormack https://github.com/justincormack I can add your write up
to the docs, but I think we should include some specific examples. I'll try
it out myself, but will probably need yours or someone else's help. I'll
get back to you on it as I work through it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22753#issuecomment-243515932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPPgFU3H6TZCLcI0yUvbPn4tPwZj7ks5qlGhUgaJpZM4Ie9PB
.

@justincormack thanks - given this thread, I think we need at least two examples, and perhaps even three, as shown below. What do you think?

1. An example of how to access a service on the Mac host from a container (e.g., would it work to have the app be a webserver like nginx connecting to a redis database on the host?)
2. An example of connecting to a container from the Mac. Does our current nginx example cover the second case, since we expose a port in the run command; i.e., docker run -d -p 80:80 --name webserver nginx? @justincormack but we should show this with and without port mapping per @weaver 's comment below, so probably two different use cases here?
3. An example of how to run an app in one container that uses a service in another (e.g., repeat the nginx plus redis example but this time run redis in a container?

An example of connecting to a container from the Mac. Does our current nginx example cover the second case, since we expose a port in the run command; i.e., docker run -d -p 80:80 --name webserver nginx?

I would really appreciate an example of connecting from Mac to container that doesn't involve portmapping. My usecase is running a mesos cluster for local development. If portmapping is the only way to accomplish direct communication from the Mac to a container (slave), it requires extra work to make sure each mesos slave process runs on a unique port so that any access from the Mac (viewing logs for debugging, for example) is consistent with the ports mesos uses internally (otherwise mesos frameworks render URLs into dashboards with internal port numbers that don't work from the host).

Right now, I use docker-machine with a route from the Mac into the virtual network so that all IP addresses and port numbers that the mesos cluster uses "just work" from the Mac. This is a very simple solution.

@weaver as stated, there is no current way to connect to a container directly from the host if it does not have a published port. You can connect from another container though.

@justincormack I read all the thread trying to figure out how to connect from my mac to the container, just like I do on Linux: container-ip:8080 for example. As far I understand this should be possible in MacOS (10.12), right?

@matiasserrano you can do this with portmapping in e.g. docker run -p 8080:8080

@m1ome yes, I know that. But is not scalable for me. I'm a developer and I usually run several containers with apache/Nginx, so 80 is always in use. If I do what you propose, first I need to disable apache in my mac, second I need to run one container at a time because they share the same port. Using different ports is not an option.
In the other hand, we give containers to the devs to start working, and again they could be working on more than one project at the same time.
So the possibility of connecting from the Mac to the containers using their IP is a must for us.

@matiasserrano Why not use -P to forward the exposed ports to an arbitrary high port automatically? If you're looking up container IP via something like docker inspect it's possible to also do a very similar operation for the exposed port.

@nathanleclaire The problem is not about knowing the port or the container's IP, it is basically the same solution as the previous post. Another solution is to create a vagrant VM for each project and run docker inside or use docker-machine, that is basically the same. Both solutions are not acceptable for us. We prefer use Vagrant instead.

For what it's worth, I have a similar use-case as @weaver (i.e. directly accessing the container network from the host). I run a Spark cluster via Docker, on its own network. I use docker-machine and add a static route over the docker0 interface for the subnet the cluster uses.

The Spark UI is available on the master node, and includes HTML links out to all of the other cluster nodes (via their IP address). By adding the static route, I can access the Spark UI on the master directly from my development machine, and the links it generates through to other nodes in the cluster all just work. These links also mean that it's not just a case of forwarding port 7080 for the master to operate without docker0 - I need to be able to reach the entire network somehow.

I guess one workaround for now would be to do some smart routing via nginx or another web proxy in an additional container, though I haven't got an example of that working at present.

@nathanleclaire The problem is not about knowing the port or the container's IP, it is basically the same solution as the previous post.

I don't understand.

You say:

So the possibility of connecting from the Mac to the containers using their IP is a must for us.

Why different IP addresses specifically? You are describing port conflicts as the issue here:

I'm a developer and I usually run several containers with apache/Nginx, so 80 is always in use. If I do what you propose, first I need to disable apache in my mac, second I need to run one container at a time because they share the same port.

With -P no two containers would expose the same port, even if they're all listening on 80 internally. So why would you need to still disable Apache, etc.?

Another solution is to create a vagrant VM for each project and run docker inside or use docker-machine, that is basically the same. Both solutions are not acceptable for us. We prefer use Vagrant instead.

If you are adamant to use Vagrant and will not be using Docker Machine or Docker for Mac, why file / discuss here?

@nathanleclaire In Linux, using the containers I created, if I want I can run 4 containers at the same time, for example, that expose port 80. I.E.: One for Magento, one for Drupal, one for Larabel and another with a clean apache.

Each container will have an IP, for example, 192.100.200.1, 192.100.200.2, 192.100.200.3 and 192.100.200.4.

With those IPs, I add a host to my /etc/hosts file, with an alias for each one, example:

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 larabel.local
192.100.200.4 apache.local

and then enter to the servers directly from the browser.

In Mac, I can't do that, because I can't get an IP for each container. Using -P is not an option, because instead of having an alias for each container, I'll need to use something like localhost:8012, for Magento, localhost:9823 for drupal and so on.

Another work around is to use vagrant with a Linux VM for each container running the container inside and using the port mapping 80:80. With this solution, docker has no sense, because if I create a Vagrant machine, with the same things that the docker container have, is the same. (I know the differences between Docker and Vagrant, and I prefer Docker instead of Vagrant 100 times...)

I hope this use case helps you understand why is so important for us to get the container IP.

The example is with port 80 but is applicable to whatever port you want.

@matiasserrano OK, I suspected it might be related to desiring DNS / hostname mapping, thanks.

Was having the same issue (connecting to the host from the container). Using 192.168.65.1 worked for me. Not entirely sure what this is but I think it briefly appears in @thalesfsp's pinata log:

🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

(Thanks @feedthefire for showing me this!)

If you are adamant to use Vagrant and will not be using Docker Machine or Docker for Mac, why file / discuss here?

@nathanleclaire That's a pretty unhelpful response, perhaps even insinuating that people shouldn't be complaining if they disagree. It's this sort of attitude that will give Docker a bad name when it comes to community discussion.

Thanks @cpoonolly, your answer is very useful, but I think that your solution works in the opposite direction: Container trying to connect to Mac Host. What I need is just the opposite: Mac Host trying to connect to the containers using their IP.

Hey folks. This issue has become sprawled out into a variety of directions and I'd suggest to the docker/docker maintainers closing it and splitting it into several sub-issues. e.g., one for reaching the IP of the Mac from inside the D4M VM, and one for per-container IP addressability (although I'd argue this might be better as simply supporting container DNS/hostname mapping natively in D4M). Most likely in the Docker for Mac repo as this is the repository for the "Engine", and ideally should have tickets about Engine on Linux/Windows concerns in the tracker.

For what it's worth, there is _definitely_ a docker0 bridge in the Docker for Mac VM. You can see it yourself if you run a container with --net host and run ifconfig. The various issues here aren't about what the original title suggests, though: They're around container and VM networking and visibility.

@icecrime @justincormack What do you think. Thanks all.

@nathanleclaire That's a much better response, thank you, and I completely agree that splitting into several sub issues would be a good way forward here

I agree!!!! no problem if you do that!

@nathanleclaire @justincormack, in the meantime the Beta 25 docs (to be published today, a little lag behind the app releases) will provide Justin's and Nathan's suggestions for workarounds in the Networking and FAQ topics. Although, I know it doesn't solve everyone's issues, it will be a start at providing some solutions in the docs and acknowledging the issues.

@matiasserrano in the next beta, due on Tuesday, you will be able to publish ports on different IP addresses on the host. So if you add multiple addresses to the loopback interface, as I mention above, then add these in your hosts file, you will be able to publish different containers to port 80 on each of these addresses, and use the hostnames.

so if you add

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 larabel.local
192.100.200.4 apache.local

to /etc/hosts then you can do:

sudo ifconfig lo0 alias 192.100.200.1/24
sudo ifconfig lo0 alias 192.100.200.2/24
sudo ifconfig lo0 alias 192.100.200.3/24
sudo ifconfig lo0 alias 192.100.200.4/24

then

docker run -p 192.100.200.1:80:80 magento
docker run -p 192.100.200.2:80:80 drupal
...

then you should be able to connect directly to drupal.local etc.

@londoncalling we should document this for the next beta docs.

@justincormack nitpick: is this block correct?

$ ifconfig lo0 alias 192.100.200.1/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24

should the last two should be 192.100.200.3 and 192.100.200.4? And why alias the whole cidr (192.100.200.1/24 is full range of 192.100.200.0 through 192.100.200.255 right?)? Should it just be the one IP?

Sorry, typo. Yes, /32 is fine too.

@justincormack Will DNS be in the gui interface anytime soon ? Since beta25 still doesn't can't resolve dns names over split-tunnel vpn I was hoping to run dnsmasq on my mac host. All other ports on my mac are reachable via 192.168.65.1 from inside containers but not dns.

Also why does docker set 10 ip's [192.168.65.1 to 10] in /etc/resolv.conf ?
PS: don't use 192.100.x.x as that's a public range. Use 192.168.x.x

We are trying to avoid adding DNS to the interface, but just read the
settings from the Mac. We read the hosts file but will read all the
settings soon.

The hosts file addresses map to your hosts file resolvers, but wrapping
around, so that fail over works correctly.

On 11 Sep 2016 7:09 p.m., "Jijo Varghese" [email protected] wrote:

@justincormack https://github.com/justincormack Will DNS be in the gui
interface anytime soon ? Since beta25 still doesn't can't resolve dns names
over split-tunnel vpn I was hoping to run dnsmasq on my mac host. All other
ports on my mac are reachable via 192.168.65.1 from inside containers but
not dns.

Also why does docker set 10 ip's [192.168.65.1 to 10] in /etc/resolv.conf ?
PS: don't use 192.100.x.x as that's a public range. Use 192.168.x.x

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22753#issuecomment-246194539,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPEQcEyn3w7BPJCeaz5mlbgJx5etTks5qpEPUgaJpZM4Ie9PB
.

I just want to thank @justincormack for this:

Yes there are two separate issues, which are somewhat related.

1. I want to connect from a container to a service on the host. The Mac has a changign IP address or none if you have no network access.
   Current recommendation is to attach an unused IP to the lo0 interface on the Mac eg sudo ifconfig lo0 alias 10.200.10.1/24, make sure your service is listening on this address or 0.0.0.0 (ie not 127.0.0.1). Then containers can connect to this address.

While not ideal, this should work for us for now. (tested and working)

@justincormack

We are trying to avoid adding DNS to the interface, but just read the settings from the Mac.
VPN combinations are varied and complex, so it would be shortsighted to assume you can always read the right settings. https://github.com/docker/for-mac/issues/19 (closed) is still broken for us on split-tunnel vpn. It's probably not a docker issue but just how our vpn server does split-dns.

Another e.g. at my previous place we would tell QA and Dev folks to point to different nameservers depending on which env they wanted to hit. If that type of testing was needed only inside Docker then that's yet another use case to consider. Thanks.

We are working on split name server support for VPN.

On 13 Sep 2016 6:48 p.m., "Jijo Varghese" [email protected] wrote:

@justincormack https://github.com/justincormack

We are trying to avoid adding DNS to the interface, but just read the
settings from the Mac.
VPN combinations are varied and complex, so it would be shortsighted to
assume you can always read the right settings. docker/for-mac#19
https://github.com/docker/for-mac/issues/19 (closed) is still broken
for us on split-tunnel vpn. It's probably not a docker issue but just how
our vpn server does split-dns.

Another e.g. at my previous place we would tell QA and Dev folks to point
to different nameservers depending on which env they wanted to hit. If that
type of testing was needed only inside Docker then that's yet another use
case to consider. Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22753#issuecomment-246764433,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPDXx3ziQv81fPBXpQHvU7_j9YWKQks5qpuHdgaJpZM4Ie9PB
.

Thanks a lot @justincormack , I'm able to use your workaround to access all of my containers directly by aliasing onto lo0, which gets me up and running with Docker for Mac :+1:

I'm using docker-compose to run my containers, so the last wrinkle is needing to configure the port forwarding to bind to the correct IP address on the host, per container. (Binding to 0.0.0.0 will give me port conflicts when I have more than one container).

I'm not sure if anyone has found a way around this? - I effectively need to interpolate into the docker-compose config, as the IP address isn't known until the container starts up.

(Appreciate we're straying from the original issue here).

@NoOrdInaryGuy this should work on the latest releases (both stable and beta) - you can specify a specific IP that is on the Mac to bind to, eg an address on lo0.

@justincormack Yep, I can confirm that works successfully. The only problem is when using docker-compose (particularly with scaling, or I guess you could just configure static addresses). It's not possible to add port-forwards after a container is started, and I'm not aware of a way to reference the actual container IP address to the compose file / Dockerfile at "runtime", which I think I'd need in order to configure the port forward to listen on the correct IP.

I'm working around this at the moment by not using docker-compose in this scenario, and having a custom bash script to invoke docker, but I wondered if anyone else had thought of a better solution.

This looks promising.

My use case is similar to what others have stated. We create containers with java services running, and attempt to test those services from the host system. We run the tests in a jenkins pipeline, so publishing ports to the host system is problematic, because the host system could be running multiple containers all trying to bind the same ports.

So usually, we only "expose" the ports, and then use 'docker inspect' to discover the container IP and connect to the service ports at that IP. When devs want to try the tests on Mac, we had been using a boot2docker trick to add a static route to the containers through the VirtualBox VM.

I've been watching the Mac Beta hoping that we would be able to access the exposed ports using a similar method, and this lo0 alias trick looks like the ticket.

This probably isn't the place for a feature request, but I was wondering if it would be possible to add an IP as input to the docker run publish-all option. It would look something like this I:

sudo ifconfig lo0 alias 10.200.10.1/32
docker run --publish-all 10.200.10.1 -d --name webserver my_test_image

Then if there were multiple ports EXPOSED in my_test_image I could access them through the IP alias.

I can confirm the missing docker0 in latest docker-mac

MacBook $ docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.7.1
 Git commit:   6f9534c
 Built:        Thu Sep  8 10:31:18 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 17:52:38 2016
 OS/Arch:      linux/amd64
MacBook$ docker info
Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 107
Server Version: 1.12.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 133
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.20-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.953 GiB
Name: moby
ID: W53J:DFZB:4SCO:CS34:6CRF:FCDR:74RZ:TBJC:WZ35:QUVW:NZQU:7ANZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 17
 Goroutines: 29
 System Time: 2016-09-26T00:20:31.292958501Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

My need is reverse of the original post. I would like to access a fixed containter address such 172.17.0.3 from the host. For example I will have a web application running and I want to access this it from the host; I prefer not to do yucky port forwarding which is necessary without docker0 as an interface on the host. VirtualBox has host-only networking and I can speak to this host-only network from the host.

docker0 is seen if my host is linux; it's only missing with docker-mac. I also do not want to use virtualbox to run docker on mac.

As described in the doc: some kind of bugs are fixed in 10.12

We understand that these workarounds are not ideal, but there are several problems. In particular, _there is a bug in OSX that is only fixed in 10.12_ and is not being backported as far as we can tell, which means that we could not support this in all supported OSX versions.

So i would ask, does Docker already fix this problem in 10.12? or it still haven't, for the compatibility of all versions.

@Kaijun no, we need to support several versions of OSX, and the way we were doing it before has other prolems, so we are unlikely to revert to it.

Hi, I really appreciate all the discussion in this thread. I'm wondering: could someone summarize (or point me to) that actual issue with OS X that prevents us from being able to establish a route directly into containers?

I've seen comments about how it's some problem with OS X (here and in other threads). I can't seem to find a solid description of what's actually the issue, why 10.12 is sortof fixed, etc.

(1) Why does this work for something like virtualbox / docker-machine but not for xhyve?

(2a) Even if docker can't support this feature just for 10.12, is there something I can do if I run 10.12 to hack it and make it work?

(2b) What are the "other problems" with the "way we were doing it before"?

I'm really sorry if these are dumb questions (or if the answer is already in this thread and I missed it).

Thanks.

@weaver we were previously using the vmnet option on https://github.com/docker/hyperkit which does create a bridge for the VM, which allows routing from containers to the host on an IP on the bridge. It does not usefully allow routing to the containers though. There was a CVE related to this exposing an open DNS server when enabled, which was fixed in Sierra.

There are many other disadvantages to the vmnet mode: no IPv6 support, little control, we have to run as root, does not work with many VPN setups, and more. We started using the "VPN mode" as an option, which became the current default, and then the other option was removed after the security issue.

The option that the docker0 bridge would appear to be magically on the Mac and not on the Linux VM has never been implemented and as not really possible, the same way as it is not available if you use a remote host either. However people have come to rely on various ways in which they can use various routing setups, and we would like to try to accommodate some of these use cases, but it is not very easy to do. Virtualbox installs kernel modules in the Mac to do this, which we are not going to do.

Hi,

First of all, please let anyone stop responding with answers about portforwarding. We know that and we don't want that, because as many have posted now, we want simple port on IP access.
Can we try and keep this thread about solutions for that?
I was very surprised that this was not possible. I don't see why we need a bridge on the mac per se, as long as the network is routable?

So fo everyone who wants just that: remove docker for mac, install docker toolbox and run something like:
sudo route -n add 172.17.0.0/24 192.168.99.100
where 172.x.x.x is the docker network configured in the VirtualBox host and the the 192.x.x.x is the actual IP from that host that is routable on the mac (via the VirtualBox network interface).
It simply routes the traffic properly.

Can that be added to the docker documentation ?

Since the above gave me what I want, I did not look further into xhyve.
Wouldn't the solution be to enter a command similar to the above, that works with the network setup from that? I was not able to ping the 192.168.65.x address, so a route add wouldn't work. If someone post the command to get that enabled, the route command should just work too.

Problem solved? It would be great if these get documented where it describes the mac limitation.
thank you

@justincormack @dmp42 @jeanlaurent can you take a look at @VGerris comment directly above, and let me know how/where you would like this documented re: Toolbox and d4mac?

Is it possible that this can get fixed for 10.12 and throw a error/warning if the the required 10.12 fix is not present on the system? You can then document the /etc/host or toolbox workaround for people running 10.11.

Imho being able to access the container network from the host without port forwarding or manual network configuration is a fundamental feature of docker. The fact that this doesn't work as expected is really a major issue.

@justincormack - it still doesn't work for our split dns config after today's beta release.

repeating from above.

We are trying to avoid adding DNS to the interface, but just read the
settings from the Mac.

VPN combinations are varied and complex, so it would be shortsighted to assume you can always read the right settings.

@justincormack you have not supply any solution to users of Docker for mac, the ip access is very demanded, because develop with docker need direct access to the container service from docker-container and from host, port forwarding not works for this situation ( the service will have different address from different place).

also the libvmnet not so fine, but it is a solution, sudo is acceptable than nothing !!!

the tap device solution need no-sudo permission. at least, docker for mac should supply some hack way to let developer make their way. for example , the hyperkit start command argument can be custom by users.

At now, The docker for mac is almost useless for people.

shit !

Is there any sight on if or when this will be fixed ?

@justincormack: In addition this network setup would require root access which we are trying to avoid entirely in Docker for Mac (we currently have a very small root helper that we are trying to remove).

Why? On linux is not possible to run docker without root privileges and everything is fine, on OSX you want to avoid that. What is the reason behind that? So from now on docker for OSX should be like facebook app, it does not matter that core feature is not working, but it didn't require root privileges?

IMO if root privilege helps resolve that issue, then fix it and In the meantime try to achieve it without root. We are currently without core feature, that we used to, that we planned whole flow based on that feature, and now we need to resolve lots of issues.

Would an acceptable compromise be to consider this an advanced feature. And when advanced features are enabled they require additional privileges ?

The reason I want this feature returned is to keep stuff on standard ports. We have a standard naming convention for all our services. I have DNS records created for even dev which could point to a static IP on their Mac. Each container get it's own IP, so it's always port 3306 no matter which project you are working with. Each project is truly separated just like it is in qa all the way to prd.

Now, when a developer wants to connect to MySQL on their local machine they have to look at a chart to see what unique port the project has. Project A is 3307, Project B is 3308 what was Project Q again ? Randomizing port is also sloppy because it doesn't allow you to save connection settings and such. You still need to look it up all the time.

While this might seem like a minor issue. Switching between projects very frequently is annoying, with this standardization it removes a lot of extra steps. You want to work on a different project ? Git clone and run make. EVERYTHING is setup from there on out. Multiple containers, credentials, configs, etc. Single command development setup.

+1, desperately needed :-/

I just caught up on the documentation at https://docs.docker.com/docker-for-mac/networking/ so I understand the challenges involved.

Unfortunately this is a severe impediment for using docker native in our local development environment. I had hoped to migrate away from Virtualbox/Vagrant.

Our issue is that we use Consul for service discovery. For local development we want to run a mix of services from docker-compose and directly from developer's IDEs on the Mac. Since services running in containers register with consul using their docker ip:port, services running outside of docker cannot integrate.

Of course this is also an issue in a multi-host cluster, but that is solved by either overlay networking (or in our case, an obnoxiously hackish introspection entrypoint script that figures out the host ip:port mappings).

It looks like an introspection API is finally being worked on to help solve this kind of issue (https://github.com/docker/docker/issues/7472). Hopefully that introspection API will work with docker for the mac/windows as well).

hey guys, I think there is something that is worth sharing related to this thread, we are able to talk to the host machine from within the containers using the default IP created by Docker for Mac/Windows.

The IP is 192.168.65.1

You can test it by following the steps below:

rogaha@MacBook-Pro:~/development/rogaha$ docker run --name docker-nginx -p 80:80 -d nginx                                
4bc4818c49cffd7b4186294c71e6d4608c0482fd74521b3e9d03a14d499b3e6b
rogaha@MacBook-Pro:~/development/rogaha$

rogaha@MacBook-Pro:~/development/rogaha$ docker run -it --rm tutum/curl curl 192.168.65.1                                                                                   5:52:22
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
rogaha@MacBook-Pro:~/development/rogaha$

I hope it helps!

@rogaha That's interesting info. Is that documented somewhere? How did you find out about it?

I've confirmed locally on my Mac that it does indeed reach all the way to the host (not just another Docker container) via 192.168.65.1.

I'm not sure. @thaJeztah @justincormack do you happen to know?

Yes, that route was added to support contacting the host.

Until there is some standard naming, generally we would not recommend using
it, as obviously it will not work in production, but it is ok to pass as a
parameter.

On 27 Feb 2017 08:49, "Roberto Gandolfo Hashioka" notifications@github.com
wrote:

I'm not sure. @thaJeztah https://github.com/thaJeztah @justincormack
https://github.com/justincormack do you happen to know?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22753#issuecomment-282777837,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPJ3h5OrhxpgWao8by-qu-UmsuWIOks5rgv62gaJpZM4Ie9PB
.

@rogaha 192.168.65.1 is not working on my end. How did you find out about that IP?

I just wanted to add a +1/subscribe along with everyone else in this thread, and add another voice to the feature request of being able to easily access docker containers through the bridge interface on unique/custom IP addresses.

I was ramming my head into the wall for at least 4 hours trying to figure out why I couldn't get any documented examples working, until I somehow found this issue, describing the problem perfectly.

For now, the workaround mentioned by @justincormack (https://github.com/moby/moby/issues/22753#issuecomment-246054946) seems to work passably well. I'm adding experimental Docker support to Drupal VM using the instructions:

1. Add a host to /etc/hosts with sudo /etc/hosts (e.g. 192.168.1.100 mysite.dev)
2. Create an alias on the loopback interface: sudo sudo ifconfig lo0 alias 192.168.1.100/24

3. Bring up a container with the following pseudocompose:

     version: "3"
   
     services:
       app:
         image: image-name
         ports:
           - 192.168.1.100:80:80
           - 192.168.1.100:443:443
         [...]
   

This seems to work perfectly for me, and though it currently requires a couple manual steps (which are avoided if using other tools on top of Docker... something I don't want to force my users to do), it allows me to almost reach Docker nirvana on Mac.

So thanks for the workaround, and I hope you can find a way to get the bridge network working soon (or just abandon macOS < 10.12 😏)

@rogaha thank you sooo much, 192.168.65.1 has solved my issue. I hope this doesn't get changed in the future, unless they find a cleaner solution. As of Docker for Mac 17.0.3.1 this has allowed my container to talk to the MySQL server running on my machine's localhost.

@TheAntonioReyes I'm glad it worked for you. Thanks for the feedback!

Hi,

I am reading the docs here: https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds, and I am trying to use the _the special Mac-only DNS name_ mentioned there: docker.for.mac.localhost.

If I do a ping on a terminal inside the docker container, it gets resolved to 192.168.65.1, and doing a curl to an app running on my mac retrieves the expected result.

I am using this image: https://github.com/elgalu/docker-selenium, and I can open a Chrome browser there. So I wanted to go to http://docker.for.mac.localhost:80, and the connection was refused. However, doing http://192.168.65.1:80 works.

Am I missing something? I wanted to start using the docker.for.mac.localhost.

I am using this: Version 17.06.0-ce-mac18 (18433)

EDIT: Seems this only happens on Chrome and this issue explains it. https://github.com/docker/for-mac/issues/1837

I think that using docker.for.mac.localhost was a poor decision. The whole point of containers is that they are portable and _should_ have no dependency on what type of host they reside. If my team is half Windows users and half Mac, then the code inside of our containers will have to be configured differently.

I'm glad there's a hostname approach, I just think the meeting where this approach was decided should have lasted 5 more minutes.

docker.for.mac.localhost worked. Hilarious. https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds

I worked around this problem by reverting back to docker-machine for Mac. The docker machine VM is a Linux distro which means that it creates a docker0 interface which has access to the private network range of the docker containers. Then, on my host mac machine, I created a route for the 172.18.x.x address range of the containers which points to the ip address of the docker machine instance (192.168.99.100 in my case).

This allows packets destined for the private container network to be forwarded by my mac OS to the IP address of the linux VM of docker machine, which knows how to reach the private containers and forwards the packets to them directly.

Creating the route to the docker machine vm for the private container network

sudo route -n add -net 172.18.0.0/16 192.168.99.100

You can get the address for the container network by using docker network inspect or docker inspect <container_name>.

You can find ip of the host in docker for mac by running this command:

docker run busybox ping -c 1 docker.for.mac.localhost | awk 'FNR==2 {print $4}' | sed s'/.$//'

Run this command

docker run -i -d --expose=80 <container_name> bash

Then get the ip address from

docker ps

if it says 0.0.0.0 then that will work fine once the port is exposed or any other ip address written there.

The solution is actually relatively simple; IDK why Docker does not fix it.

See https://github.com/AlmirKadric-Published/docker-tuntap-osx for a workaround that shims the hyperkit binary.

Partial duplicate of #155 (and #171, #515, #3484).

I'm closing. This is by design and anyway unrelated to this repo.

The following works wonderfully for me. No intermediate containers, no DNS workaround.

From https://github.com/AlmirKadric-Published/docker-tuntap-osx#how-it-works :

Once done the IP address 10.0.75.2 can be used as a network routing gateway to reach any containers within the Host Virtual Machine:
route add -net <IP RANGE> -netmask <IP MASK> 10.0.75.2

Thank you @pauldraper (!).

@pauldraper commented on Jul 14, 2019

The solution is actually relatively simple; IDK why Docker does not fix it.

See https://github.com/AlmirKadric-Published/docker-tuntap-osx for a workaround that shims the hyperkit binary.

My macOS version:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G3020
$