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

31–35 of 35 posts

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

#31

Post by cristobal23 »

nhjk wrote: post #29
krat0sprakhar wrote: post #8

For people interested in Distributed Systems the architecture[0] page is a treasure trove. The explanation of the gossip(SWIM) and consensus protocol(Raft) used is easy to understand and quite lucid. It would be wonderful if all (most?) open-source projects have a such beautiful documentation explaining their architecture. Thank you Armon and team for sharing this with us! [0] - https://consul.io/docs/internals/archi…

Any suggestions on where to get an in depth intro to distributed systems in general?

I enjoyed Berkeley's CS162 because its from the perspective of an operating system. http://bit.ly/11rTdEw

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

#32

Post by raspasov »

armon wrote: post #28
raspasov wrote: post #26

Love the nice informative website. However: [1] https://www.consul.io/intro/vs/zookeeper.html This did not unequivocally convince me in the benefits over ZooKeeper. On the contrary, it makes it seems that ZooKeeper tries to do less, and I strongly prefer simpler tools. [2] http://aphyr.com/posts/316-call-me-maybe-etcd-and-consul Have the issues discussed in this article been fully addressed yet? Overall, can you outl…

The issues discussed by aphyr have been fully fixed as of Consul 0.2, several months ago. In the initial release of Consul, only the "default" mode was available and has the now-documented caveat of a stale read possibility. The various consistency modes are now discussed here: https://www.consul.io/docs/internals/consensus.html#default With respect to ZooKeeper, there are different approaches. ZK provides a low-leve…

Thank you for detailed answer!

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

#33

Post by michaelmior »

If @armon is still listening, curious if there's been any talk of maintaining a log of the state of Consul. Along with consul-template, Consul provides a great way to maintain application configuration. However, there's still currently a need from external change tracking mechanism to facilitate rollback.

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

#34

Post by tptacek »

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…

I'm pretty glad they're not using DTLS. TLS is the sane and (usually) correct choice for normal client-server protocols, but DTLS is not necessarily the conservative choice for group messaging systems.

This isn't a particularly sophisticated cryptosystem --- AES-GCM with keys broadcasted between the trusted participants --- but it's simple and, while GCM is nobody's favorite AEAD, it is at least a formal AEAD mode, leaving not a whole lot of room to screw the basics up.

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

#35

Post by jimktrains2 »

armon wrote: post #23
jimktrains2 wrote: post #22

Earlier quoted context omitted.

> The gossip algorithm instead is doing peer-to-peer (N-to-N instead of 1-to-1) in a half-duplex model. Unless you mean you're doing multicast, you're still doing 1-to-1 connections. > We did develop the algorithm in the open and made a call on the community to provide feedback to help improve the design of the system. I wouldn't trust myself, let alone many unknown people who are just volunteering their time and hav…

You are right, the communication is still unicast in nature. I should clarify to say that there isn't a persistent 1-to-1 communication, the nodes we gossip with are randomly selected on each interval. There is no connection or session establishment between peers. I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang s…

> There is no connection or session establishment between peers.

OK, so I'm not understanding why isn't a 1-to-1 message, nor why DTLS isn't an option here.

> I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang stdlib.

You need to read better. I didn't say "crypto primitives", I've said "crypto _system_". That includes everything, including primitives, key management, authentication, replay (which means your application protocol is now part of the crypto system, not a good sign), field concatenation for singing/hashing, &c.

The most important thing is that when your improvised system fails, you will more-than-likely never know and it'll never cause any errors.

Post reply on HN