I had a problem recently. I’m deploying services, and everything is Puppetized, but I have to manually tell other infrastructure that it exists. It’s frustrating. As an “ops guy” I focus on making my infrastructure services available, resiliant and distributed so that they can scale well and not fail catastrophically. I think we’ve all done this when deploying $things, and most people (in my experience) go through the following stages..
Stage 1 - DNS based discovery
Everyone has used or is using a poor man’s load balancer somewhere in their infrastructure. DNS is also basically the most basic of service discovery tools, you enter a DNS name and it provides the address of the service! Great! You can also get really fancy and use SRV records for port discovery as well, but then you realise there’s quite a few problems with doing load balancing and service discovery like this:
- One of the servers in your infrastructure breaks or goes offline.
- The DNS record (either an A record or SRV record) for broken service still exists
- Your DNS server, quite rightly, keeps resolving that address for $service because it doesn’t know any better
- Pretty much half of your requests to $service fail (assuming you have two servers for $service)
I know this pain, and I’ve had to deal with an outage like this. In order to fix this problem, I went with stage 2..
Stage 2 - An actual load balancer
Once you have your service fail once (and it will..) you think you need a better solution, so you look at an actual load balancer, like HAProxy (or in my case, an F5 Big-IP). This has extra goodness, like service availability healthchecks, and will present a single VIP for the service address. You add your service to the load balancing pool, set up a healthcheck and assign a VIP to it, and it will yank out any service provider that isn’t performing as expected (perhaps the TCP port doesn’t respond?) - Voila! You’re not going to have failures for $service now.
This is really great for us infrastructure guys, and a lot of people stop there. Their service is now reliable, and all you have to do is set up a DNS record for the VIP and point all your clients to it.
Well, this wasn’t good enough for me because everytime I provisioned a new instance of $service, I had to add it to the load balancer pool. Initially we did it manually, and then we got bored and used the API. I was still annoyed though, because I had to keep track of what $service was running where and make sure every instance of it was in the pool. In a land managed by configuration management, this really wasn’t much fun at all. I want to provision a VM for $service, and I want it to identify when it’s ready and start serving traffic automatically, with no manual intervention required.
The straw that broke the camels back for me was spinning up a new Puppetmaster. We might do this rarely, but it should be an automated job - create a new VM and assign it the Puppetmaster role in Puppet, then use a little script on VM startup to add the puppetmaster to the load balancing pool. It worked, but I wanted more.
- Notifications when a puppetmaster failed, so I could fix
- Service availability announcements - when the Puppetmaster was ready, I wanted it to announce its availability to the world and start serving traffic. A script just didn’t feel…right.
Stage 3 - A different way
- It uses operationally available tools to practice service discovery, like DNS and Nagios Checks
- It’s written in Go (performance, concurrency, language agnostic)
- We use hashicorp tools elsewhere, and they have always proved to be very reliable and well designed.
In order for consul to do its thing, you need to understand a few basic concepts about how it works..
- The best way to implement is to deploy the consul agent to all your service providing infrastructure and clients. The way consul works means that this seems (to me) to be the best implementation.
- The consul agent will form a cluster using the raft consensus protocol
- There are some agents in your infrastructure that operate in “server mode” - these perform consensus checks and elect a leader. You need to decide how many there are in advance, and I suggest an odd number so they can elect a leader.
- Consul uses DNS for service discovery. To do that, it provides a DNS resolver on port 8600.
- The way it decides what to serve on that DNS resolver is by healthchecking services and determining their health status. If the service is healthy, you can query port 8600 on any consul agent (port 8600) and it will provide the list of available servers.
- The healthcheck can be done in a variety of ways, but a particularly nice way of doing it is by having consil execute nagios scripts. There’s also a pure TCP check, a HTTP check and many more
This provides three interesting problems for deployment:
- How do I get my DNS queries to Consul?
- How do I deploy Consul?
- How do I put an infrastructure service in Consul?
Well, I’m going to write about the ways I did this!
Deploying Consul with Puppet
Consul has an excellent Puppet Module written by @solarkennedy of Yelp which will handle the deploy for you pretty nicely. I found that it wasn’t great at bootstrapping the cluster, but once you have your servers up and running it worked pretty flawlessly!
Deploying the servers
To deploy the servers with Puppet, create a consul server role and include the puppet module:
The important params here are:
- bootstrap_expect: How large should your server cluster be?
- node_name: Make sure it’s unique, $::fqdn fact seems reasonable to me
- server: true - make sure it’s a server
Once you’ve deployed this to your three consul hosts, and the service is started, you’ll see something like this in the logs of each server:
What’s happening here is that your cluster is looking for peers, but it can’t find them, so let’s make a cluster. From one of the servers, perform the following command:
and then, in the logs, you’ll see something like this
You have now bootstrapped a consul cluster, and you’re ready to start adding agents to it from the rest of your infrastructure!
Deploying the agents
As I said earlier, you’ll probably want to deploy the agent to every single host that hosts a service or queries a service. There are other ways to do this, such as not deploying the agent everywhere and changing your DNS servers to resolve to the consul servers, but I chose to do it this way. Your mileage may vary.
Using Puppet, you deploy the agent to every server like so:
The key differences from the servers are:
- the server param is not defined (it’s false by default)
- retry_join is set: this tells the agent to try and retry these servers and therefore rejoin the cluster when it starts up.
Once you’ve deployed this, you’ll have a consul cluster running with agents attached. You can see the status of the cluster like so:
Now we have our cluster deployed, we need to make it aware of services. There’s a service already deployed for the consul cluster itself, and you can see how it’s deployed and the status of it using a DNS query to the consul agent.
Here, consul has returned the status of the consul service to let me know it’s available from these IP addresses. Consul also supports SRV records, so it can even return the port that it’s listening on
The way it determines what nodes are available to provide a service is using checks which I mentioned earlier. These can be either:
- A script which is executed and returns a nagios compliant code, where 0 is healthy and anything else is an error
- HTTP check which returns a HTTP response code, where anything with 2XX is healthy
- TCP check, basically checking if a port is open.
There are 2 more, TTL and Docker + Interval, but for the sake of this post I’m going to refer you to the documentation for those.
In order for us to get started with a consul service, we need to deploy a check..
I chose to first deploy a puppetmaster service check, so I’ll use that as my example. Again, I used the puppet module to do this, so in my Puppetmaster role definition, I simple did this:
This defines the service that this node provides and on which port. I now need to define the healthcheck for this service - I used a simple TCP check:
now, when Puppet converges, I should be able to query my service on the Puppetmaster:
Excellent, the service exists and it must be healthy, because there’s a result for the service. Just to confirm this, lets use consul’s http API to query the service status:
A failing check
Now, this is great at this point, we have a healthy service with a passing healthcheck - but what happens when something breaks. Let’s say a Puppetmaster service is stopped - what exactly happens?
Well, let’s stop our Puppetmaster and see.
Now, let’s do our DNS query again
I’m not getting any dns results from consul. This is basically because I’ve only deployed one Puppetmaster, and I just stopped it from running, but in a multi-node setup, it would return only the healthy nodes. I can confirm this from the consul API again:
Note here how the service is returning critical, so consul has removed it from the DNS query! Easy!
Now if I start it back up, it will of course start serving traffic again and become available in the DNS query:
The final piece of this puzzle is to make sure regular DNS traffic can perform these queries. Because consul serves DNS on a non-standard port, we need to figure out how standard DNS queries from applications that expect DNS to always be on port 53 can get in on the action. There are a couple of ways of doing this:
- Have your DNS servers forward queries for the .consul domain to their local agent
- Install a stub resolver or caching resolver on each host which does support port config, like dnsmasq.
In my homelab, I went for option 2, but I would imagine in lots of production environments this wouldn’t really be an options, so forwarding with bind would be a better idea. Your mileage may vary.
Assuming dnsmasq is installed, you just need a config option in /etc/dnsmasq.d/10-consul like so:
Now, set your resolv.conf to look at localhost first:
And now you can make DNS queries without the port for consul services!
Puppetmaster Service Deployment
For the final step, you need to do a final thing for your Puppermasters. Because the puppetmaster is now being served on the address puppetmaster.service.home.consul, you’ll need to tweak your puppet config slightly to get things working. First, updated the cert names allowed adding the following to your master’s /etc/puppet/puppet.conf:
Then, clean our the master’s client key (not the CA!) and regenerate a new cert:
At this point, we should be able to run puppet against this new DNS name:
Now, we just need to change the master setting in our puppet.conf, which you can do with Puppet itself of course!
Congratulations, you’ve deployed a service with infrastructure service discovery!
What we’ve deployed here only used a single node, but the real benefits should be obvious.
- When we deploy ANY new puppetmaster now, it will use our role definition, and automatically add the service and the healthcheck
- Using whatever deployment automation we use, we should be able to deploy a new service immediately and it will automatically start serving traffic for our infrastructure - no additional config necessary
This article only covers a few of the possibilites with consul. I didn’t cover the key/value store or adding services dynamically using the API. Consul also has first class support for distributed datacenters which wasn’t covered here, which means you can even distribute your services across DC’s and over the WAN.