Do you kill registrator?

I’am a big fan of rancher since a couple of months and today we are about to go on and switch to a production environment.


In our microservices architecture we are using consul as discovery catalog and in order to be totally decoupled we are using registrator to automatically register/deregister services into consul. Then, consul-template dynamically update our HAProxy configuration. This works perfectly … in 1.1.x
In 1.2.x, its a completly different story :frowning:

This is an overview of our architecture :

And this is how we achieve “Third party registration”

One of advantages of rancher (imho) is the “managed network” functionnality with the ability to do a DNS load balancing. But, in 1.2.x and “managed network” mode, containers are now deployed with “none” docker networking, so registrator isn’t able to do its job anymore. None of our services are registered now with 1.2.x

This “third party registration” is a very important aspect of our architecture, so, how can we achieve it with the new version of rancher? Does anyboby else is using registrator ?

Thank you for your help.

I am also impacted by this change… pre 1.2 I used this method of service registration without problem, it does not work with the CNI network plugin that’s used > 1.2.

One way to make this work would be to write something (own implementation of registrator) that interfaces with the rancher API to obtain information about services and then register and deregister them in consul…


am surprised this doesn’t already exist…

Someone gives me another interesting way to achieve this by using the metadata service of rancher :

It could be done by looking at rancher-metadata…/container/ports/ will give you x.x.x.x:PORT:internal mappings. Where x.x.x.x will be a specific IP that is bound, or which could be substituted with the ./host/agent_ip. I am using relative paths, because it would depend on the entity responsible for registering. The container would use the self paths and a separate observer would watch the /container or /services endpoint. Here are the metadata docs:

I think I will create my own “registrator” plugged to the rancher metadata api

1 Like

I started writing a component in nodejs using the module docker-event which is an event-emitter based module. It allows to react to different events that occur on the docker.sock (like registrator).

Confd has an existing integration with the rancher API. You can use that to easily get the containers and stacks and then write your own hook to push those to consul

1 Like

That’s an interesting idea @cpoole. We had been using Registrator as well.
We use Consul in our environment outside of Rancher and so we were using registrator to map the public host port from Rancher into Consul so that external services could discover it.
I think the confd solution would be great. Just need a small container with Consul, confd, and monit on it. So that confd can single consul to reload the config files without a full restart start using a SIGHUP.

I take this opportunity to share to all interested people the ranger-registrator project that you can find here :

This is a replacement of registrator which almost offers the same functionnalities (service name overriding, declarative http health check …etc).

@johnrengelman kindly makes a pull request (thank you^^), so feel free to fork it, test it and submit your ideas and work.


You can use -useIpFromLabel=io.rancher.container.ip(or requested_ip, I’m not able to check it right now) flag and -internal flag in registrator to get ip and exposed ports. It works fine for me. But this feature only available in registrator’s master branch as I remember.

Hmmm … My problem is that I do not use the same port exposed internally on the host. For example I have containers port mapping like this : 50012:81/tcp

So in this case, -internal will register 81 instead of 50012 no ?

Yes, it’ll register internal port, but, you can use it without -internal flag. And, as far as I understood, you want to get mapped ports with host ip, doesn’t you? So, why don’t you want to use bridge mode with “” for interanal networking. If you use it, registrator will take host ip and you needn’t to use -useIpFromLabel flag.

I’ll try starting registrator with this command :

-ip=[my-host-ip] consul://localhost:8500

Network mode = host
Volume mapping : /var/run/docker.sock:/tmp/docker.sock

Then, I launch a container like this :

Network mode = Bridge
Port mapping = 50001:81/tcp
label : = true

Nothing appears in consul …

(tested on rancher v1.4.1)

We just resolvd our issue which is pretty similar by running the registrator master image and using the -useIpFromLabel. Registrator picked up the container with exposed ports and properly registered with Consul. We are using VXLAN network in Rancher, we also are able to route directly to containers.

image: gliderlabs/registrator:master
network_mode: host
- "/var/run/docker.sock:/tmp/docker.sock"
- “-internal”
- “-useIpFromLabel”
- “io.rancher.container.ip”
- "consul://CONSUL_IP:8500"
io.rancher.container.dns: 'true’
io.rancher.container.hostname_override: container_name
io.rancher.container.pull_image: always
io.rancher.container.system: 'true’ ‘true’

I’d like to thank @carinoob for his work on the rancher-registrator library.

It’s inspiring, and made me do some hacking on his library, that lead to me doing some hacking on the original gliderlabs registrator project.

I’ve done some commits to the original registrator project that get the external port from the rancher-cni using the rancher-metadata project. This works for me - and I’m looking for feedback (so the gliderlabs guys can merge it back into main).

sry for this little off topic question, @cabrinoob can you tell me the name of the tool to make those neat graphics?
I have to make an architechture presentation soon showing a proposal for docker

@Juan_Ignacio_Borda :