We’ve gone a long way to try and achieve this and we want to make sure that the experience for Mac users is the same as the experience on Linux.
What I’m trying to figure out exactly are:
What is the “host” in Docker for Mac context-- the xhyve VM, or the actual OSX host? (It seems to refer to both, depending on the speaker.)
What networking features of docker will not work as expected for someone coming from native docker on Linux “due to limtations in OSX”? What features will never work and what features are in the beta/planning stages but not yet available?
Is a user of Docker for Mac supposed to have to plan around interacting with the xhyve VM in the same way that a Docker Toolbox user does? Or is it supposed to “feel” native, like docker on Linux?
It’s beginning to look like this is just being deliberately ignored. It keeps being brought up without any response from anyone on the Docker team. It’s getting really difficult to sell this to the rest of my dev team with this kind of uncertainty.
Agreed. As I posted in one of those threads, I’m giving up on using the beta & native app until this issue is addressed. If it’s never addressed, I’ll stick with Docker Toolbox + Virtualbox until I no longer have the need to reach the host from a container.
The docker for mac solution is currently unusable in my work context as well due to networking issues with unclear resolutions.
We have nearly a dozen web apps that we need to run together using consul + registrator with our various docker-compose applications to provide cross-app communication.
Specifically, we are using consul’s DNS to provide lookups between container applications running on common ports and need to reach each app by DNS name from the host. We’ve set this up with docker-toolbox by adding an /etc/resolver/docker file and supporting routes that point to the consul container, which then allows us to use cookies and sessions across the *.docker hosts running locally.
But this solution doesn’t work for the native solution because the route to consul is unclear, and it looks like the communication is dropped.
I don’t think there will be a “fix” for this. Networking is all done within the VM and you can map ports on the Mac to the VM. That’s just the way Docker for Mac is designed.
You can run a swarm (or cluster of docker daemons) in the VM using “Docker in Docker” containers. Watch this video for how to swarm (with multiple user-defined networks) in the Docker for Mac VM.
For any services you need access to outside the VM, you should use port mapping.
@ktwalrus AFAIK you don’t need to port forward for standard Docker for Mac, so this seems like a broken abstraction. For example, if I run nginx with -p 80:80, it shows up on localhost:80 of my Mac without any port forwarding (as opposed to when we needed to do that with virtualbox). My impression was that there’s a networking layer that automatically forwards for you.
Put differently, how would you port forward on Docker for Mac?
When I say “port forwarding”, I mean that port 80 on localhost is forwarded to port 80 in your container (for your -p 80:80 example. Docker for Mac sets up a unix socket ( to connect the localhost:80 to container_ip:80). See the /port directory in the VM:
(I may not have the underlying mechanism that Docker uses to implement this since I know Docker uses iptables to forward traffic inside the VM to the correct network/port.)
Ahhh thanks @ktwalrus, this makes a lot more sense now. (For anyone else following along, screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty gets you into the xhyve vm)
Do you happen to have any pointers for how I would port forward to the VM?
This seems to create an issue with using Kafka when you don’t want to expose 9092 on Docker host machine. Haven’t found a workaround yet other than executing code using Kafka in another container…
Indeed. This is a shame on you Docker guys! MacOS is the BEST OS to run development, this situation can’t continue.
Please, help us with an official solution!