docker host identification improvement and swarm mode support

[muradm]

First two commits addresses improvement in #475. Since contents of ServiceID changes, users has to make sure that old services match the new pattern, other wise old services has to be re-registered. This improvement simply uses docker info as suggested in #475 to fetch docker node name, which is commonly hostname. Thus there is no need to use registrator container's hostname or attach registrator to host network.

Third commit adds support of swarm node. Nothing breaks by the way. In addition to normal per container service registration adds support of registering docker swarm mode VIPs. Also populates service name from swarm service name, if not specified explicitly in SERVICE_X_NAME. In previous commits, node id in swarm mode was assigned to swarm node id, which is not very useful, as users most likely will know their host names, rather that node id in swarm cluster.

[bitsofinfo]

Any status on when this would be merged and added into a release? We'd like to be able to use registrator in the new 1.12 swarm mode

[ctooley]

This would also be helpful for us as well. Any chance this will get merged soon?

[MansM]

can really use this...

[progrium]

I like that it removes some of the tricky IP/hostname logic. The Docker info endpoint didn't exist when Registrator was made. Swarm mode support is great and seems like a drop-in solution, though I'm not able to test it. I'm assuming others have or will.

Should there be docs additions with this? Even just a first pass.

[MansM]

@progrium I can email you a vagrant setup for swarmmode if you want

[progrium]

Got it from you via email. Though I might not find time for it. Too bad you can't share it publicly for others to try. Though I'm assuming it works. If somebody else can give this PR thumbs up that's good enough for me at this point. Still want to make sure this is documented before merging.

[MansM]

building the source repo :(

# github.com/gliderlabs/registrator/bridge
bridge/bridge.go:254: invalid operation: services[0].Spec.EndpointSpec.Mode == "github.com/docker/engine-api/types/swarm".ResolutionModeVIP (mismatched types "github.com/docker/docker/api/types/swarm".ResolutionMode and "github.com/docker/engine-api/types/swarm".ResolutionMode)
bridge/bridge.go:256: cannot use services[0] (type "github.com/docker/docker/api/types/swarm".Service) as type "github.com/docker/engine-api/types/swarm".Service in argument to b.registerSwarmVipServices
The command '/bin/sh -c cd /go/src/github.com/gliderlabs/registrator 	&& go get 	&& go build -ldflags "-X main.Version=dev" -o /bin/registrator' returned a non-zero code: 2

[muradm]

In my setup with docker swarm it worked. However, with time I realized that changes for docker swarm mode support shall be more deep and probably require some design decisions, since docker swarm mode does not operate on containers, but services. definitely it will be --docker-swarm-mode flag.

On the other hand, probably I will be moving from consul and registrator in docker swarm mode. Docker swarm mode targets service discovery features of consul, making it unnecessary overhead. I don't think that in real world docker swarm mode + consul (or etcd or else) + registrator will be used.

I might look at this in next 2-3 weeks, if still be needed. But before that we can discuss your use-cases, to clarify the functionality. Because as I mentioned above, probably docker swarm mode + consul + registrartor is not effective combination.

[progrium]

@muradm thanks for the update.

Since none of us are using Swarm, if anybody else thinks this is worth getting in we'll need somebody else to take it over if @muradm ends up moving away from this setup.

[MansM]

The reason I want to use it:
use registrator for consul registration
consul template for generating dns based vhosts to make more then one service running on port 80.

I am not sure if this can be done in a different way

[muradm]

@MansM, I suppose that you run a number of "docker service create" with publishing port, is it right? Do you use VIP or dns-rr for service? And your consul template runs outside of docker? And your apache/nginx or what so ever runs outside of docker swarm as well, right? Could you please explain your case with details?

If that the case, I probably would move apache/nginx/or else inside docker swarm overlay network. Then each created service:
docker service create --name service1 --replicas 3 ... will get two DNS records available inside overlay network, so that ping service1 and ping tasks.service1 will work from any other service inside same overlay network. That means, you can make once your vhosts like:

• vhost1 -> service1:8081
• vhost2 -> service2:8082

service1 and service2 requests will be load-balanced by docker, so that you don't need to keep track of IP addresses of each specific instance.

[danvaida]

on the path of moving from docker 1.11 to 1.12 and naturally, trying the swarm mode.
I'd still like to keep consul but registrator is not helping due to this very issue.

would be willing to test the PR if it's going to be maintained.

I believe this is the kind of issue that comes from vendor locking. docker is (unfortunately) not going to be very keen on making it easy for us to bypass its own service discovery. just like prometheus is doing its best to get metrics and so is registrator to bridge the gap with consul.

IIRC, k8s users were also suffering because of these "portless" containers a while back. but at least k8s also supports rocket.

anyway, I really appreciate the PR & would definitely use this feature if it gets merged.

[pcittadini]

Thumbs up on this PR.
Tested in my scenario with an external Haproxy that needs dynamic reloading/creation of backends being created by services in the docker swarm cluster.
Would be nice to have it merged.

[peterthehermit]

This would be really useful to us too, upvote PR.

[ghost]

@peterthehermit +1 ! Need it really !

[ablojh]

+1 an awesome and much needed feature 👍

Anything needed or missing to get this PR merged?

[marcuslinke]

So whats the status of this PR currently?

[Justin-DynamicD]

To answer the question as to "why" is pretty simple: multiple swarm clusters. In many industries there are compliance guidelines that will practically force multiple clusters to be used. In this scenario having an "external" service discovery helps you maintain dynamic configurations while meeting compliance. consul templates to keep firewalls accurate and services reliable is not easily tossed aside.

As container use grows, there will be many who will be forced to separate PCI systems and general PII information in easily audit-able ways to comply with HIPPA, etc. Unless Docker plans on re-introducing the ability to register with Consul directly, we'll need tools like Registrator to fill that need.

Anyway, add me to the "would really like to see this" as well as "about to test this" :)

[marcuslinke]

Same problem here. Our current infrastructure heavily rely on consul for routing services to swarms , single docker hosts and even non-docker hosts. Additionally it acts as service discovery for our monitoring solution (prometheus). So it is an integration point we can't simply give up. We really need a migration path for our production infrastructure so I tried to combine the efforts of #476 and #520 for supporting swarm mode services here: #588

Any feedback is really appreciated.

[josegonzalez]

Supersceded by #588. Thanks for the initial PR though!