Open KartoffelToby opened 8 years ago
I had to abandon this for now, the NAT out to the internet is currently broken / flakey. Hoping this improves soon!
It's not super reliable, especially if you use a VPN on your mac then its --dns
option wreaks havoc, but I've used https://github.com/sshuttle/sshuttle (brew install sshuttle
) to allow an application running on my mac to have direct TCP access to my containers.
You'll need to know the subnet of your docker network, which can change. E.g. if your containers are in a compose project the network will be mycomposeproject_default
.
% docker network inspect mycomposeproject_default | jq -r '.[].IPAM.Config[0].Subnet'
172.21.0.0/16
You'll need to start a container on the same docker network that has sshd
running, expose its port 22 as localhost:4222, and set a root password in the container.
Then run sshuttle like:
% sshuttle --dns --no-latency-control --ssh-cmd "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --remote root@localhost:4222 172.21.0.0/16
[local sudo] Password: <type your mac password>
root@127.0.0.1's password: <type password for root in your sshd container>
c : Connected to server.
<Ctrl-Z>
zsh: suspended sshuttle ...
% bg
[1] + continued sshuttle ...
% curl -i http://mycontainer # this works from your mac!
...
It basically proxies all your TCP connections from your mac to that subnet through the container running sshd. It works for me when on VPN except I have to remove --dns
and can only access containers by their ip (or I can add /etc/hosts entries for them).
I had to abandon this for now, the NAT out to the internet is currently broken / flakey. Hoping this improves soon!
@blakebarnett that might be the same issue as https://github.com/docker/for-mac/issues/5680
Which sounds like it's fixed in the upcoming release.
P.S. Except for that general issue with the new framework, that route commands works for me.
It does seem that in a docker settings change or upgrade the IP address of the VM can change to another 192.*. FYI.
Yeah I think it is, hopefully in 3.4 everything will be smooth for this!
macOS Big Sur v11.4 and Docker Desktop v3.4.0 (65384) still has the issue, as per original request: But on Docker for Mac this isn't possible because i dont know the IP from the VM with the Toolbox (Docker Machine) i can route 172.17.0.x to docker machine ip.. is there any way to do that with Docker for Mac?
docker-tuntap-osx is a workaround that works.
Hey guys, tuntap is a workaround, but when I create a network by
docker network create acme-network
the container becomes unaccesible by previous IP. Did anyone experience such issue and overcome it?
So let's say I have two applications:
app1 with IP 192.168.211.1 and app2 with IP 192.168.213.1. tun/tap does the fix and I can access them by these IPs, but when I add any of applications to new network:
docker network create acme-network
docker network connect acme-network app1
docker network connect acme-network app2
none of the applications are accessible from host like they were before. The reason why I do need to add them to network, because the applications are different containers (with own databases), but I need them work via API.
But due limitation of docker to make them be available to each other I have to create network, and when I do it - containers are not available from host machine.
I tried to add tuntap gateway to docker network, but it didn't help:
docker network inspect acme-network | jq '.[0].IPAM.Config[0]'
sudo route -v add -net 172.19.0.1 -netmask 255.255.0.0 10.0.75.2
Any thoughts, gents?
2\. Find the bridge interface it creates (bridge100 for me), create a route for it, someth
Would you mind expanding on this a little? I've checked "Use the new Virtualization framework" on 3.5.2 on an M1 iMac, but ifconfig
is only showing one bridge network, bridge0
, which is status: inactive
and has no IPv4 address.
Output of ifconfig -l
: lo0 gif0 stf0 anpi0 anpi1 en0 en4 en5 en2 en3 bridge0 ap1 en1 awdl0 llw0 utun0 utun1 utun2 utun3 utun4 utun5 utun6 utun7
2\. Find the bridge interface it creates (bridge100 for me), create a route for it, someth
Would you mind expanding on this a little? I've checked "Use the new Virtualization framework" on 3.5.2 on an M1 iMac, but
ifconfig
is only showing one bridge network,bridge0
, which isstatus: inactive
and has no IPv4 address.
I upgraded to the Monterey beta on my M1 and haven't tried this out again, I can report back once I do.
I didn't find a way to do it in this way, but found way how to workaround this - just added app1 network to app2 docker-compose.yml, so basically app2 can connect to network of app1. Since both apps are on docker-compose and have own bridge networks, it works just fine.
Btw, I don't have M1 chip on the system I experienced the issue at
Can we keep the conversation focussed on the specific problem the issue is about - communicating with a container by IP address from the host.
This issue is not about communicating with the host from a container.
Nor is it about allowing two different containers to communicate with each other.
This is about being able to do the following on a Mac:
docker run --rm -d --name myservice nginx && \
MYSERVICE_IP=$(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' myservice ) && \
curl "http://$MYSERVICE_IP"
and seeing the Welcome to nginx!
HTML page come back.
If whatever you are suggesting does not make the above snippet work, it's not appropriate for this issue.
The Apple M1 Tech Preview uses the new Virtualization.framework in Big Sur which resolves this issue because a bridge interface is now connected between the host and container VM using the virtio driver and a NAT is done on the host as well.
Does this work?
I verified this works
- Enable the experimental support in docker-for-mac:
- Find the bridge interface it creates (bridge100 for me), create a route for it, something like:
sudo route -v add -net 172.18.0.1 -netmask 255.255.0.0 192.168.64.2
It worked on Docker Desktop 3.3.2/3.3.3. Newer versions don't create the bridge interface.
Could this be implemented via the new extension API?
There is a brew package that resolves the problem https://github.com/chipmk/docker-mac-net-connect
So you can access the container by IP directly.
Another problem need to be solved is static access to container by its docker's name. (or have it accessible on host machine by port) So I want to achieve behavior identical to--network=host
on Linux machine https://docs.docker.com/network/host/.
May be some DNS should work as well, please suggest any solution or workaround.
Please, do not suggest using -p
argument in docker run
command this is not an option for me.
@alexandertsukanov , amazing thanks for sharing. Do you guys know any similar solution for Windows? (sorry for offtopic)
Is there any update for this issue?
I need --network=host
feature in mac too.
Now with the new release 4.14.0 of Docker Desktop on Mac utilizing the Apple Virtualization Framework, it should be possible to add another network adapter featuring the bridged network aka. network_mode = host ?
Is this a big challenge? Can somebody point out the hypervisor configuration for the Apple Virtualization Framework here? :)
Also thanks for putting it in the "Considering" space of the docker-roadmap ! 👍
https://github.com/docker/roadmap/issues/238#issuecomment-1328246842
There is a brew package that resolves the problem https://github.com/chipmk/docker-mac-net-connect
So you can access the container by IP directly.
Unfortunately docker-mac-net-connect has stopped working with Docker for Mac 4.16.1: https://github.com/chipmk/docker-mac-net-connect/issues/21
This is a kind of a requst
Hello there,
i have a testing development scenario build with docker containers. on linux machines i can access them via the conatinaer IP (172.17.0.X) and intacting via the exposed Port.
But on Docker for Mac this isn't possible because i dont know the IP from the VM
with the Toolbox (Docker Machine) i can route 172.17.0.x to docker machine ip.. is there any way to do that with Docker for Mac?
I need this because i have multiple Database Containers each with the same Port... (so -p istn't the answer ;))