Docker, Registrator and Consul by example

Question

I am new to both Docker and Consul, and am trying to get a feel for how containerized apps could use Consul for both service registry and KV pair config management ("configuration").

My understanding was that I could:

• Create an image that runs Consul server, so something like this; then
• Spin up three of these Docker-Consul containers (thus forming a cluster/quorum) on myvm01.example.com (an Ubuntu VM); then
• Refactor my app to use Consul and create a Docker image that runs my app and Consul agent, with the agent configured to join the 3-node quorum at startup. On startup, my app uses the local Consul agent to pull down all of its configurations, stored as KV pairs. It also pulls in registered/healthy services, and uses a local load balancing tool to balance the services it integrates with.
• Run my app's containers on, say, myvm02.example.com (another Ubuntu VM).

So to begin with, if any of this seems like I am misunderstanding the normal/proper uses of Docker and Consul (sans Registrator), please begin by correcting me!

Assuming I'm more or less correct, I recently stumbled across Registrator and am now even more confused. Registrator seems to be some middleman between your app containers and your Consul (or whatever registry you use) servers.

After reading their Quickstart tutorial, it sounds like what you're supposed to do is:

• Deploy my Consul cluster/quorum containers to myvm01.example.com like before
• Instead of "Dockerizing" my app to use Consul directly, I simply integrate it with Registrator
• Then I deploy a Registrator container somewhere, and configure it to integrate with Consul
• Then I deploy my app containers. They integrate with Registrator, and Registrator in turn integrates with Consul.

My concerns:

• Is my understanding here correct or way off base? If so, how?
• What is actually gained by the addition of Registrator. It doesn't seem (to the untrained eye at least) like anything more than a layer of indirection between the app and the service registry.
• Will I still be able to leverage Consul's KV config service through Registrator?

Answer 1

Is my understanding here correct or way off base? If so, how?

It seems to me, that it's not a good solution, to have all cluster/quorum members running inside the same VM. It's not so bad if you use it for development or tetsing or something, where you don't care much about reliability, but not for production.

Once your VM dies, you'll loose all the advantages you have by creating a cluster. And even more, you can loose all the data you have in K/V store, because you are running Consul servers inside a docker containers, which should be additionaly configured to share the configuration between runs.

As for the rest, I see it the same as you.

What is actually gained by the addition of Registrator.

From my point of view, the main thing is, that you don't have to provide an instance of Consul Agent in every container you run. And the container with the image you run is responsible only for their main functions, not for registering itself somewhere. You may simply pull an image and just run a container with it, to make it's service available, without making additional work.

Will I still be able to leverage Consul's KV config service through Registrator?

Unfortunately, no. At least, we didn't find a solution to use it this way, when we were looking for something to make service discovering and configuration management. We came to conclusion, that Registrator is not a proxy for K/V store and is used only to automate service discovery. So you have to use some other logic to access consul's K/V store.

Update: furthermore, here is 2 articles: "Automatic Docker Service Announcement with Registrator" and "Automatic container registration with Consul and Registrator", I found usefull to understand Registrator role in service discovery process.