TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Etcd v0.1.0 release

83 点作者 polvi将近 12 年前

7 条评论

jandy将近 12 年前
Interesting timing. I was playing with Etcd just this morning. I&#x27;m glad there&#x27;s some more options in this space. I haven&#x27;t been happy with any setup so far.<p>Doozer (<a href="https://github.com/ha/doozerd" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ha&#x2F;doozerd</a>) got me excited. It&#x27;s small, fast, and written in Go. Unfortunately, its development seems quiet and fragmented. Its lack of TTL-style values made it a pain to do a distributed lock service without having a sweeper for cleaning up dead locks.<p>Zookeeper (<a href="http://zookeeper.apache.org" rel="nofollow">http:&#x2F;&#x2F;zookeeper.apache.org</a>) is much more fully featured and mature, but felt way too heavy compared to my nimble Go stack. Installing and maintaining a JVM just for Zookeeper made me uncomfortable.<p>Etcd is interesting. It has TTLs, it&#x27;s small and fast, easy to pick up&#x2F;learn, and it&#x27;s in active development (and it&#x27;s tied with CoreOS and Docker, so it&#x27;s bound to get some reflected love).
评论 #6198158 未加载
评论 #6198244 未加载
tptacek将近 12 年前
This looks pretty neat. Is anyone using it? The Golang implementation of Raft these documents link to also looks pretty nice.
评论 #6197723 未加载
kbd将近 12 年前
What are the reasons this isn&#x27;t just a json-serving front-end to Redis? Is it largely because Redis clustering isn&#x27;t baked yet?
评论 #6198162 未加载
jokull将近 12 年前
We reviewed the current options at one point (Zookeper, Doozer and something from Netflix) but ended up just using DNS (Route 53) for our config. This however looks great, and supports nested keys (trees) whereas DNS comes up short in that, and other aspects.
peterwwillis将近 12 年前
How is 1000s of writes a second fast? Especially for a key&#x2F;value store? Also, why is it returning redundant information?<p><pre><code> $ curl -L http:&#x2F;&#x2F;127.0.0.1:4002&#x2F;v1&#x2F;keys&#x2F;foo {&quot;action&quot;:&quot;GET&quot;,&quot;key&quot;:&quot;&#x2F;foo&quot;,&quot;value&quot;:&quot;bar&quot;,&quot;index&quot;:5} </code></pre> You already know the action and the key; all it needs to return is &quot;bar&quot; and the index, though even the index might be unnecessary. While i&#x27;m at it, why is &#x27;curl&#x27; returning JSON? I don&#x27;t know a lot of Unix commands that take JSON input.<p>While i&#x27;m throwing around my valueless opinions, this thing is wholly uncomfortable and over-engineered for its supposed purpose. Further complications from unnecessary requirements like the Raft protocol (what the fuck does autonomous distribution of resource management have to do with sharing configuration?!? s&#x27;like building X.509 into Telnet) make this thing&#x27;s hinges groan from feature bloat.<p>Yet more blather: Why do you have to configure each host&#x27;s address and a unique port? Isn&#x27;t etcd supposed to support automatic service discovery? Zeroconf (among many, many others) has had this working for years and it&#x27;s not hard to use the existing open-source implementations. And why is HTTPS an advanced use?
评论 #6199860 未加载
评论 #6200024 未加载
e12e将近 12 年前
I do think this looks interesting, but the second bullet point makes me cringe (my emphasis):<p>- Secure: <i>optional</i> SSL client cert authentication<p>Reading the section on SSL in the guide makes me feel slightly better, although I&#x27;m worried that it doesn&#x27;t mention anything about revoking certificates and&#x2F;or online status checking.<p>Perhaps we need a (better?) library for TLS-PSK and&#x2F;or TLS+kerberos for these types of uses of HTTPS? That or a compact stand-alone CA that simplifies certificate management and enrolment to the point where it is both usable, deployable and <i>reasonably</i> secure.<p>I&#x27;m guessing a compact &quot;master CA&quot;-service that only deals with maintaining (optionally) off-line root certs, that only certify intermediary on-line CA(s), that deal with enrolment and revocation of service and client (ie: &quot;principal&quot;) certs.<p>Of course, at that point, you&#x27;ve pretty much created a kerberos work-a-like on top of TLS (for some extra spiffy-ness, set the intermediary CAs to issue certs with 10minute life-times...) -- and I&#x27;m not sure if such a system would really be better than just using kerberos in the first place...<p>[edit: formatting]<p>Maybe the ease of interop with other rest&#x2F;http-based services and clients would be worth it -- maybe not.
评论 #6198783 未加载
jared314将近 12 年前
I am still a little confused. Is CoreOS designed to be used inside a container, or as a host OS to other containers?
评论 #6197776 未加载
评论 #6197771 未加载