I’m running Docker for Windows 1.12.0-rc2 and trying to configure the new Swarm service discovery following this latest blog post. I think I’m missing a step in configuring the networking. I expect to be able to create a Docker service named ‘pending’ on port 3000 and navigate to ‘http://pending:3000’, but I am not able to resolve the service name. What am I missing here?
Playing around with this some more, in my Docker for Windows settings, I enabled “Expose container ports on localhost” under the Network tab. I can now ‘curl localhost:3000’, but when I scale via ‘docker service scale pending=3’, I am always routed to a single container.
NETWORK ID NAME DRIVER SCOPE
6fccb3626b08 bridge bridge local
cb39a667eb69 docker_gwbridge bridge local
6e5b882d316a host host local
1njmqwgiij8i ingress overlay swarm
enndjmsxqdr9 mynet overlay swarm
6ffdc31c69e8 none null local
5b7bd030cff2 wettech_default bridge local
Right, a single replica for that service.
So the scale command didn’t work or wasn’t run. docker service scale pending=3 should fire up 2 extra containers. And the REPLICAS value should immediately change from 1/1 to something else, when your run docker service ls again.
Scaling works fine, I am able to use the scale command, and swarm will add additional containers. The problem I’m having is the service discover aspect of this. I should be able to curl pending:3000 and get a response for one of the containers, but I am not able to resolve the address.
Hi, what do you mean by that? Don’t the hosts files get updated by docker themselves?
I am stuck at the same position. I want to have containers access services provided by other containers. From reading the docs I would expect the containers to be able to do “ping pending” and get the IP of the pending container. Is this correct? Does docker swarm start a DNS server somewhere in the background that should provide these mappings?
Folks, I don’t think Docker for Mac/Windows is intended to publish services by hostname / DNS name lookup on the host computer at all (perhaps a maintainer of these projects can step in and correct me if I’m wrong). They expose the published ports from those services for access on localhost (or docker in Windows’s case).
In the above example, pending:3000 isn’t intended to be available from these tools. The ports get forwarded to localhost on OSX and a docker hostname on Windows. So it’d be:
localhost:3000 on OSX docker:3000 on Windows
e.g. on Mac:
$ docker service create --publish 80:80 nginx
$ # wait a second if nginx image not available locally..
$ curl localhost
<title>Welcome to nginx!</title>
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
Commercial support is available at
<p><em>Thank you for using nginx.</em></p>
After reading your answer I think I was misunderstanding how the service routing works. I’d gone to David Gageot’s talk at DockerCon, and he was routing service to service via service names, which you can see embedded in his code, but I think what you said clicked. Externally these services won’t be available by name. I assume this functionality should be present internally though. Looks like everything is working as expected then.
You cannot today, however it should not be too much effort to rig up a service using $PROXY of your choice to resolve requests to the relevant downstream containers. e.g., you could expose a HAProxy service on port 80/443 which routes requests for foo.mycompany.com to service foo. (This is all just my own personal ideas, no de jure or even de facto solutions have emerged clearly yet).