I'm VERY impressed, even more impressed by the fact that it speaks DNS. I do with however that it came with a "driver" option rather running a consul client (or even just SkyDNS-like http option, although I'm unsure how you would manage membership). That way you could just "include" consul in your python/ruby/go application, and not have to worry about adding another service to your chef/pupper config and running yet another service.
Consul, a new tool for service discovery and configuration
51–60 of 62 posts
Re: Consul, a new tool for service discovery and configuration
#52Earlier quoted context omitted.
Ah OK, was feeling I was explaining far too much -- no worries, but if HN is no longer a place for complex arguments, I think it'd be a lot less valuable... Also, me being wrong certainly sounds like a great chance for Hashicorp people to correct me.
You were looking at very, very old documentation which is why I wanted to drop it. Cassandra is on 2.0 and uses a practically identical consensus algorithm [Paxos] to Consul [Raft] except for the implementation details. I'm not sure how much practical advantage something like Consul has over a discovery layer built on Cassandra. I didn't see a good way to sort this conversation out without a very, very long conversat…
Well you definitely just cleared it up, thanks -- was completely wrong in my assumptions. Looks like armon from consul team has answered, that's probably a much better way to go.
I did see that the documentation was very old (notice @ top of page I linked) -- I switched to this: http://www.datastax.com/documentation/cassandra/2.0/cassandr...
Still -- I think that consul is a more generic tool than Cassandra. The cluster-management tools I see on their page seem to be java-focused, if not cassandra-focused (as in, outside of just managing the cassandra cluster, JConsole manages java apps, supposedly, not any kind of app that can make an HTTP request, which Consul seems to offer).
Re: Consul, a new tool for service discovery and configuration
#53Earlier quoted context omitted.
Wouldn't a centralized Cassandra cluster be reliable enough to meet that need? I've never had a cluster completely collapse on me unless things were already screwed up enough that Service Discovery was ultimately useless since nothing else would work. It just seems to me that losing your datastore makes your services unusable...at which point 'discovering them' isn't really the issue. Instead, everyone wants to intro…
To reiterate a bit on what hardwaresofton has already said, yes you could use Cassandra. However, Cassandra like ZooKeeper is just a building block. It doesn't actually provide service discovery, health checking, etc. You could use it to build all of those, but it doesn't provide it. We compare Consul to ZooKeeper here, but much of that applies to Cassandra as well: http://www.consul.io/intro/vs/zookeeper.html Intern…
I hadn't seen LMDB before. How does it compare to LevelDB? On first glance it looks like the two have similar characteristics.
Re: Consul, a new tool for service discovery and configuration
#54Earlier quoted context omitted.
To reiterate a bit on what hardwaresofton has already said, yes you could use Cassandra. However, Cassandra like ZooKeeper is just a building block. It doesn't actually provide service discovery, health checking, etc. You could use it to build all of those, but it doesn't provide it. We compare Consul to ZooKeeper here, but much of that applies to Cassandra as well: http://www.consul.io/intro/vs/zookeeper.html Intern…
I hadn't seen LMDB before. How does it compare to LevelDB? On first glance it looks like the two have similar characteristics.
Check out LMDB's page:
I dunno if leveldb supports acid now (or recently came to), but that's a big difference
Re: Consul, a new tool for service discovery and configuration
#55This sounds very impressive, at the risk of breaking the chorus of awesome: what problem does this actually solve?
Discovery: The consul page alleges that it provides a DNS compatible DNS alternative for peer discovery but is unclear as to what improvements it offers other than 'health checks', with the documentation leaving failure resolution processes unspecified (as far as I can see) thus mandating a hyper-simplistic architecture strategy like run lots of redundant instances in case one fails. That's not very efficient. (It might be interesting to note that at the ethernet level, IP addresses also provide MAC address discovery. If you are serious about latency, floating IP ownership is generally far faster than other solutions.)
Configuration: We already have many configuration management systems, with many problems[1]. This is just a key/value store, and as such is not as immediately portable to arbitrary services as existing approaches such as "bunch-of-files", instead requiring overhead for each service launched in order to make it function with to this configuration model.
The use of the newer raft consensus algorithm is interesting, but consensus does not a high availability cluster make. You also need elements like formal inter-service dependency definition in order to have any hope of automatically managing cluster state transitions required to recover from failures in non-trivial topologies. Corosync/Pacemaker has this, Consul doesn't. Then there's the potential split-brain issues resulting from non-redundant communications paths... raft doesn't tackle this, as it's an algorithm only. Simply put: given five nodes, one of which fails normally, if the remaining four split in equal halves who is the legitimate ruler? Game of thrones.
As peterwwillis pointed out, for web-oriented cases, the same degree of architectural flexibility and failure detection proposed under consul can be achieved with significantly reduced complexity using traditional means like a frontend proxy. For other services or people wanting serious HA clustering, I would suggest looking elsewhere for the moment.
Re: Consul, a new tool for service discovery and configuration
#56Can anyone care to provide some real world examples? I'm having a hard time wrapping my head around what this exactly does.
Service Discovery is about helping services find one another. If your application relies on memcached, you need to pass the memcached location to your application somehow. For simple architectures, this may just be a hardcoded localhost:11211. As you scale, it becomes prudent to distribute services across different servers. Your configuration could then become something like "server1.mycompany.com:11211". But what if…
I am trying to figure out how Consul meshes with a configuration management system such as Puppet. There is a lot of overlap.
From what I can tell, Consul supports two registration mechanisms: Static defined services in /etc/consul.d, and dynamically defined services through the HTTP API.
For the statically-defined case, for any given node, you have to create Puppet (or Chef, or whatever) definitions that populate /etc/consul.d with the stuff that's going to run on that node. For the actual configuration itself, you still want Puppet to be the one to populate it. The question then is what you gain by doing this; if that configuration goes into Puppet, then Puppet is still the main truth where you want to centralize things, so then you have this flow of data:
client client The documentation makes a point about Puppet updates being slow and unsynchronized, and it's true that you get into situations where, for example, service A is configured with hosts that aren't up yet, for example. With Consul you can update the config "live"; surely you want to centralize config in Puppet and populate Consul's K/V from Puppet, and then you get the single-point-of-update synchronization missing from Puppet, but you still need to store the truth in Puppet.
So I'm counting two good, but not altogether mind-blowing benefits from using Consul with Puppet, over not using Consul at all. The overlap is looking a lot like two systems vaguely competing for dominance.
I suspect the better use of Consul is in conjunction with something like Docker, where you ditch Puppet altogether (except as a way to update the host OS), and instead build images of apps and services that don't contain any configuration at all, but simply point themselves at Consul. That means that when you bring up a new Docker container, it can start its Consul agent, register its services, and suddenly its contained services are dynamically available to the whole cluster.
The container itself contains no config, no context, just general-purpose application/service code; and Consul doesn't need to be populated through Puppet because in that way, Consul is (in conjunction with some container provisioning system) the application world's Puppet.
That, to me, sounds pretty nice.
Re: Consul, a new tool for service discovery and configuration
#57This sounds very impressive, at the risk of breaking the chorus of awesome: what problem does this actually solve? Discovery: The consul page alleges that it provides a DNS compatible DNS alternative for peer discovery but is unclear as to what improvements it offers other than 'health checks', with the documentation leaving failure resolution processes unspecified (as far as I can see) thus mandating a hyper-simplis…
For the record, Raft does mandate what happens in that split-brain scenario. Neither side will be able to elect a leader, and writes will halt. Electing a leader requires a quorum.
Re: Consul, a new tool for service discovery and configuration
#58i am constantly impressed at the hashicorp guys, who continue to release great tools. they actually released serf on the same day as we released nerve and synapse, which comprise airbnb's service registration and discovery platform, smartstack. see https://github.com/airbnb/nerve and https://github.com/airbnb/synapse
that said, as i wrote my blog post on service discovery ( http://nerds.airbnb.com/smartstack-service-discovery-cloud/ ), dns does not make for the greatest interface to service discovery because many apps and libraries cache DNS looksups.
an http interface might be safer, but then you have to build a connector for this into every one of your apps.
i still feel that smartstack is a better approach because it is transparent. haproxy also provides us with great introspection for what's happening in the infrastructure -- who is talking to whom. we can analyse this both in our logs via logstash and in real-time using datadog's haproxy monitoring integration, and it's been invaluable.
however, this definitely deserves a look if you're interested in, for instance, load-balancing UDP traffic
Re: Consul, a new tool for service discovery and configuration
#59i am constantly impressed at the hashicorp guys, who continue to release great tools. they actually released serf on the same day as we released nerve and synapse, which comprise airbnb's service registration and discovery platform, smartstack. see https://github.com/airbnb/nerve and https://github.com/airbnb/synapse that said, as i wrote my blog post on service discovery ( http://nerds.airbnb.com/smartstack-service-…
I think that Synapse already provides a plugin architecture. I t should be trivial to use the Consul HTTP API as a Synapse plugin. All this does is bridge the information Consul has and setup an HAProxy instance locally. If you want to go that route, should be pretty simple!
Re: Consul, a new tool for service discovery and configuration
#60Short question: Can I define the IP of the service in the service definition?
From the service definition[0] it looks like the IP is always the IP of the node hosting `/etc/consul.d/*` files. I am thinking about it in a scenario where each service (running in a container) is getting an IP address on a private network which is not the IP of the node.
[0]: http://www.consul.io/docs/agent/services.html
Update: An external service is possible: http://www.consul.io/docs/guides/external.html