Understanding DNS service discovery in Consul

[Robin]

Hello all,

I have no experience at all with Consul and little with DNS. I was wondering how service discovery via DNS works in Consul. Here is a simple use case:

I write a ruby app that requires redis and would like to connect to it in a Consul environment. How would I do this ? When I provide a redis host, the redis driver will perform a A record request, but it won't return a port number. Should I write specific code to perform a SRV lookup, parse the answer to get back the host and port and initialize my redis driver with that ?

Is there a mechanism where the client request a A or AAAA record and Consul returns a SRV record and the driver transparently handle this ?

I'm really interested in fully understanding service discovery using DNS so any pointers would be great.

Kind regards,

R

[Ryan Breen]

There is no mechanism for a ruby client to automatically get a SRV response from an A record request.  The approach would be to make a SRV request from Ruby using one of the many DNS facilities in Ruby, such as the built-in Resolv class.

However, are you sure you really need that?  Redis typically runs on port 6379, so if you are comfortable sticking with that default on all systems, the A record request your driver makes is all you need: it'll get the IPs of running Redis nodes and will connect to one of them.

Ryan

--
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robin Monjo]

Thank you for your answer, after more research that’s what I thought.

Yes I would need that if I have several redis database running on one server for example. I would have to make them bind to a different port. And yes I can perform a special SRV query to init my client but that would make me change some codes in my apps, and not just one environment variable.

Also I probably miss some points but what is the benefits of using Consul instead of something like AWS route 53 ? Consul as the services health check, which is great, but except from this it seems to me that one could achieve a similar result using a DNS server (in terms of service discovery). With some API, services could register themselves by adding an entry to the DNS server when they are up.

I’m not criticising at all, just trying understand.

Robin

[Ryan Breen]

Sure, you could build something that manages your DNS entries based on system health, but determining system health is hard.  Figuring out when to remove nodes if they drop off the map is hard.  Consul handles all of this stuff for you.

I think this article does a good job of covering the advantages Consul has over custom solutions: http://www.consul.io/intro/vs/custom.html

Ryan

[Nick Wales]

If you're into the realm of writing specific DNS SRV routines you may as well ask the Consul API for the address + port mapping that you're looking for. 

[Armon Dadgar]

Hey Robin,

You have a few options here:

* DNS A / AAAA record resolution with well known ports. This avoids the need for SRV records + custom code.

* DNS SRV lookups, typically this is invasive of code, but solves the unknown port issue.

* Consul HTTP API, again invasive but avoids unknown port and address issue.

* consul-template + configuration, avoids both well known port and address, avoids code changes. This is typically

  a fairly easy path.

* consul-template + HAProxy, in cases where an app cannot take a list of addresses, you can use HAProxy as a reverse

  proxy configured dynamically via consul-template.

The advantage over Route53 is a few fold, Consul is vastly more dynamic and is designed to understand things like

health check, and has native clients to register, run health checks, etc. With Route53 you have to write all of that yourself,

plus it’s not designed to be a dynamic system with sub-second update speeds.

Hope that helps!

Best Regards,

Armon Dadgar