Share and learn in the Docker community.
Prior to beta 9 the use of docker.local resolved to a private ip address. Now using localhost, it conflicts with other local development tools like Vagrant that also maps to localhost.
In beta 8 i was able to run the 2 tools side by side.
I am not sure if you will see this as an issue, I just thought I would reported it to see if docker.local could be bought back.
I agree. Many services that I run in containers (various database servers for example) I also run locally for use with other projects, so I constantly get port conflicts and have to stop/start services before I can run my Docker containers.
It would be great if you could bring us support for non default bridged networks.
I would very much like to see this exposed as an option; hopefully that’s planned for a future beta?
I understand and appreciate the desire to have the two tools side-by-side, but in my developers’ environment we’re using Vagrant with port mapping and are populating our /etc/hosts files to point to localhost. With Docker for Mac + port mapping we can simplify these environments and replace the Vagrant layer entirely.
It sounds like both options have solid use cases?
+1 the idea of a flag,
docker.local or localhost
i much prefer the docker.local method
Even if its not docker.local, give the user a way to get the machine ip. This was supported in docker-machine & beta 8.
I am not sure if localhost is the right choice. That is just my opinion.
Agreed - localhost is a bad option as it requires managing exposed ports against what you may already be using on the Mac side.
It should be optional. It’s going to conflict, and I really like the idea of having a different ip-address.
Thanks
While I can understand the surprise around the change, I actually prefer being able to connect to localhost by default.
From a new user’s point of view, this may also be better behaviour since it avoids a major head-scratcher for them. When I was helping a bunch of co-workers on how to develop with Docker and Docker Machine a few months ago, they had real trouble with the problem of having to figure out the IP address. At the time, I told them “it’s a simple docker-machine ip default away,” but it was still difficult for them to understand. Most of the time they would just assume the IP was always going to be 192.168.99.100, and run into problems later when it changed. Eventually many of them simply stopped using Docker Machine, and instead SSHed into Vagrant-provisioned VMs to do their Docker-based development. Obviously, not ideal.
Finally, this is similar to the behaviour seen on Linux natively, so users who are used to using Docker in Linux won’t be surprised when they run Docker for Mac.
All this being said, I do concur with the earlier suggestions to make it possible to not bind to localhost. I just think the default should be to use localhost.
The difference with the native Linux install is you have the option for the daemon to listen on 0.0.0.0 or bind it to the machines ip which is perfect for devlopment, leaving localhost free for other tools.
Binding to 0.0.0.0 (or a non-localhost IP) effectively opens up the VM (and all containers) to the host’s network, which could potentially be hostile. From a secure-by-default perspective, development environments shouldn’t be exposing themselves to the network quite so readily.
That being said, it’d be useful to be able to more easily set up port-forwarding so users can do this if they really really know what they’re doing.