Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Consul.io – Service discovery and configuration made easy

consul.io

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Consul.io – Service discovery and configuration made easy

#11

Post by bascule »

Consul looks awesome. The only thing I don't like about it is they chose to use a homebrew encryption scheme for Serf's gossip protocol:

http://www.serfdom.io/docs/internals/security.html

(If you're confused about how this relates to Consul, see this: http://www.consul.io/docs/internals/security.html)

Worse, their justification for using this instead of standard schemes like (D)TLS seems to be that they don't need the sorts of features transport encryption normally needs because they lean on the protocol's state machine to provide some of the features transport encryption would normally provide for free, like replay attack avoidance.

Not only does homebrewing encryption almost always carry with it design and implementation mistakes, but someone auditing the protocol not only needs to understand the cryptographic design, but how it interacts with the rest of the protocol's state machine.

My advice would be to scrap their homebrew encryption and use (D)TLS

Re: Consul.io – Service discovery and configuration made easy

#12

Post by jakozaur »

Wonder how this compare to Smart Stack: http://nerds.airbnb.com/smartstack-service-discovery-cloud/

E.g. you got webservices talking over HTTP. One goes bad, you want existing clients not to talk to them.

Smart Stack: you are using HTTP proxy on each machine. You're code doesn't has to be aware of who is talking to.

Consul: Not sure, but it sounds like server code has to be able to handle events to change that.

Re: Consul.io – Service discovery and configuration made easy

#14

Post by wernerb »

ericb wrote: post #13

Does this do leader election?

Yes, in quite the same way that etcd and ZooKeeper does it. Info here: http://www.consul.io/docs/guides/leader-election.html

I was looking it over and found how leader election is handled in general fascinating. Leader election can be tricky if you have a lot of machines. This example sets a watch on a single 'key'. But this would mean that all followers would be triggered upon lock-release, meaning all your machines will pound consul for a new lock request / leader election fight. To mitigate this, it seems they implemented 'lock-delay'.

In ZooKeeper what you typically do is create a linked-list of watches so that only the follower directly behind the leader gets triggered and so avoid 'disturbing the herd'.

In any case, consul seems great, and will probably use it!

Re: Consul.io – Service discovery and configuration made easy

#15

Post by armon »

bascule wrote: post #11

Consul looks awesome. The only thing I don't like about it is they chose to use a homebrew encryption scheme for Serf's gossip protocol: http://www.serfdom.io/docs/internals/security.html (If you're confused about how this relates to Consul, see this: http://www.consul.io/docs/internals/security.html ) Worse, their justification for using this instead of standard schemes like (D)TLS seems to be that they don't need t…

We did take a look at D(TLS) when implementing Serf and the associated encryption mechanism. D(TLS) is much better suited when you are doing point-to-point duplex communication. The gossip algorithm instead is doing peer-to-peer (N-to-N instead of 1-to-1) in a half-duplex model. Using DTLS would've been too heavy for our use case.

We did develop the algorithm in the open (see this gist: https://gist.github.com/armon/7159161), and made a call on the community to provide feedback to help improve the design of the system.

The crypto system used is actually pretty vanilla based on AES-GCM. We certainly didn't attempt to invent our crypto primitives, and instead stuck to the best practices around the most modern systems.

Re: Consul.io – Service discovery and configuration made easy

#16

Post by burnout1540 »

jakozaur wrote: post #12

Wonder how this compare to Smart Stack: http://nerds.airbnb.com/smartstack-service-discovery-cloud/ E.g. you got webservices talking over HTTP. One goes bad, you want existing clients not to talk to them. Smart Stack: you are using HTTP proxy on each machine. You're code doesn't has to be aware of who is talking to. Consul: Not sure, but it sounds like server code has to be able to handle events to change that.

Some more info here: https://consul.io/intro/vs/smartstack.html

Re: Consul.io – Service discovery and configuration made easy

#17

Post by tigeba »

jakozaur wrote: post #12

Wonder how this compare to Smart Stack: http://nerds.airbnb.com/smartstack-service-discovery-cloud/ E.g. you got webservices talking over HTTP. One goes bad, you want existing clients not to talk to them. Smart Stack: you are using HTTP proxy on each machine. You're code doesn't has to be aware of who is talking to. Consul: Not sure, but it sounds like server code has to be able to handle events to change that.

Consul provides service discovery via a REST API and via DNS. I had to make some small configuration and code changes to my existing services to make use of SRV records. They have no knowledge of Consul's existence.

Re: Consul.io – Service discovery and configuration made easy

#18

Post by dang »

somethingnew wrote: post #4

Has this never been posted before?

Actually two significant posts in the last year:

https://news.ycombinator.com/item?id=7604787

https://news.ycombinator.com/item?id=7682173

So by HN standards (https://news.ycombinator.com/newsfaq.html) this is unequivocally a dupe. But the community interest here seems genuine, so we won't apply the full penalty.

Re: Consul.io – Service discovery and configuration made easy

#19

Post by armon »

jakozaur wrote: post #12

Wonder how this compare to Smart Stack: http://nerds.airbnb.com/smartstack-service-discovery-cloud/ E.g. you got webservices talking over HTTP. One goes bad, you want existing clients not to talk to them. Smart Stack: you are using HTTP proxy on each machine. You're code doesn't has to be aware of who is talking to. Consul: Not sure, but it sounds like server code has to be able to handle events to change that.

We compare Consul to SmartStack here: https://www.consul.io/intro/vs/smartstack.html

With a tool like consul-template, you can have the same behavior that Synapse gives you. https://hashicorp.com/blog/introducing-consul-template.html

In the general case, clients of Consul don't need special handling code for events, it's handled by Consul for you.

Re: Consul.io – Service discovery and configuration made easy

#20

Post by kilburn »

jakozaur wrote: post #12

Wonder how this compare to Smart Stack: http://nerds.airbnb.com/smartstack-service-discovery-cloud/ E.g. you got webservices talking over HTTP. One goes bad, you want existing clients not to talk to them. Smart Stack: you are using HTTP proxy on each machine. You're code doesn't has to be aware of who is talking to. Consul: Not sure, but it sounds like server code has to be able to handle events to change that.

As far as I understand, the less involved method is:

Consul: your calling webservice uses a DNS name served by consul. Consul responds with a pool of working servers. As soon as one fails, consul doesn't include its address anymore, and hence the calling services stop talking to it.

Post reply on HN