djs55
commented
7 years ago Thanks for your report. I suspect your diagnosis is correct: that UDP port 4789 is not -- by default -- forwarded into the VM.
We recently experimented adding support for exposing the prometheus stats endpoint-- perhaps something similar could work for your case. To see how this works, run a root shell in the VM using something like
docker run --rm --net=host --pid=host --privileged -it justincormack/debian nsenter -m -t 1 shand then read /etc/init.d/docker, in particular:
# On desktop forward metrics to host if enabled in daemon.json
case "$(mobyplatform)" in
windows|mac)
METRICS_ADDR=$(cat /etc/docker/daemon.json | jq -e -r '."metrics-addr"')
if [ $? -eq 0 ]
then
METRICS_IP="$(echo "$METRICS_ADDR" | cut -d: -f1)"
METRICS_PORT="$(echo "$METRICS_ADDR" | cut -d: -f2)"
/usr/bin/slirp-proxy -proto tcp -host-ip 0.0.0.0 -host-port "$METRICS_PORT" -container-ip "$METRICS_IP" -container-po
rt "$METRICS_PORT" -i -no-local-ip &
fi
;;
esacTo expose UDP port 4789 you could run something like
/usr/bin/slirp-proxy -proto udp -host-ip 0.0.0.0 -host-port 4789 -container-ip <IP within VM> -container-port 4789 -i -no-local-ip(this is the user space proxy used to expose host ports to containers). I assume -container-ip <IP within VM> would have to refer the interface where the overlay network is configured. Perhaps -container-ip 192.168.65.1?
Could you try running this proxy and let me know if it helps? If we figure out a nice way to do it then we could consider a configuration option of some kind.
avsm
dimaspivak
StevenACoffman
bsb20
JooeunAhn
lawrsp
docker-robott
srids
nyonor
brian-farrell
Expected behavior
Using an external KV store and a correct set of Docker for Mac advanced daemon options, it should be possible to run a container on Docker for Mac, connect it to a pre-existing Docker for Linux overlay network, and interact with other containers on the network.
Actual behavior
While DNS resolution works, none of the packets from the Docker for Mac container are received.
Information
Steps to reproduce the behavior
cluster-storeto an external Consul KV instance 3) setcluster-advertisetoeth0:2375. I did the same steps on a second Linux machine, as well, purely to test out that the overlay network I'd eventually create is actually working. I also run a container callednode-1and attach it to this overlay network.docker network create --driver overlay mynetwork). I used the aforementioned second Linux machine as a check of the fact that containers spanning these two Linux machines can communicate correctly.-Hin the daemon options), use thesocatworkaround suggested here. With this in place, I can verify that_pingworks and reaches my Docker for Mac instance over the internet using my external IP address. I use this same external IP address when settingcluster-advertiseand the samecluster-storeConsul address as before.docker run --network cluster alpine:latest ping node-1. While the hostname gets resolved correctly, no transmitted packets get received.I assume this is related to the fact that the 4789 UDP port for VXLAN isn't being forwarded from the host to the HyperKit VM. Is there any hope of a configuration that might make it possible for this to work? My company's specific use case has us wanting to run locally-built tests out of a container on a dev's laptop against the overlay network we're hosting in the cloud. If not deserving of its own configuration option, is there any other way I can achieve this?