Here’s an example of something that you could do with docker-machine that I haven’t been able to solve on Docker for Mac:
Take Kafka running on Zookeeper. The new producer for Kafka requires that you initially connect to a broker and then Zookeeper gives you a list of broker hostnames and ports to use for all other communication. This list is going to be hostnames that are resolvable inside of Docker, even if the initial connection was established on a published port on localhost.
With docker-machine, it was possible to set Kafka to advertise a hostname that worked both inside and outside of Docker, giving you the ability to publish to topics from, say, a REPL on a Dockerized Kafka broker, while not breaking communication with Kafka from other containers. This doesn’t seem possible with Docker for Mac, and Kakfa is far from the only kind of distributed system that works on this kind of bootstrap discovery model.
If you have --net=host then any ports mapped with -p are not exported. You seem to get one or the other on Docker for Mac. At least that’s the behavior a couple releases ago. We have scripts to work around this, so I can’t verify it hasn’t been fixed in the latest update.
In my setup, I’m still using docker toolbox for MAC (i.e. virtualbox as docker machine) and a workaround to make this behaviour happens is to establish a reverse tunnel between MAC OSX and docker-machine
ssh -t -R8000:localhost:8000 docker@$(docker-machine ip dev)
after having the tunnel opened, I can “docker run -it --rm --net=host buildpack-deps:curl curl localhost:8000” and get the desired behaviour
I know it is just a work around… but it is there… just in case it could be useful for somebody
you are welcome to try it on xhyve as well, I think it should work AS-IS
It would be really nice if you documented that this does not work the way one would expect. Anyone that has read the marketing for Docker for Mac hears that the OSX host acts like the host. Look at the -p and -v options for mapping.
–net=host simply does not behave the same way, and --net=host combined with -p : behaves in a VERY surprising way.
The very least you could do is document this behavior. It seems reasonable to warn anyone who actually tries to use these flags when they use them that they are not going to get what they would on Linux.
I mean, yeah, that sounds reasonable. But I’m not actually, myself, connected with Docker. I’m just a random person who has invested a lot of time and interest into various emulation and virtualization stuff, and then worked at Google, and when I left, I didn’t have borg. So…
you might be able to find an official contact method to get in touch with someone, or possibly file a “bug” noting that documentation isn’t clear about --net=host outside of Linux. (The same problem is going to manifest in Windows as well.)
I agree with the original poster. Quite simply if something isn’t working the same it should be documented as such. All the technical explanations in the world about why do not change the the issue, nor that the documentation misrepresents it. Funnily enough I came here with the same problem, but on linux - I guess mine is different. Hope it’s all working good now anyway.
In my opinion, you should check your iptables rules. To access the port of your container from your host, you must open the corresponding port, for example 80 of the host machine (because docker does not create an iptables rule to redirect port 80 of your machine to port 80 of the container because the container directly uses the port 80 of your machine, distributions like centos have rules of firewall which blocks the connection on the ports)
Pour autoriser une connexion sur un port : sudo iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT