转载：http://www.csdn.net/article/2015-01-28/2823739/2
摘要：Etcd是CoreOS生态系统中处于连接各个节点通信和支撑集群服务协同运作的核心地位的模块，本文将主要介绍Etcd的RESTful API。如果说Etcd是CoreOS分布式架构的基石，Etcd的RESTful API就是架在这基石上的顶梁立柱。
Etcd的启动配置
Etcd的配置一般通过cloud-init在系统启动时就进行设定，具体设定方法与使用的平台有关。比如AWS、GCE这些会在启动Instance时有一步配置cloud-config里面。对于Vagrant启动的虚拟机，这个配置就是我们之前修改过的user-data文件。默认时候这个配置大致是这个样子的：
$ cat user-data ... etcd: discovery: https://discovery.etcd.io/09363c5fcdfcbd42ed60b8931263fda1 addr: $public_ipv4:4001 peer-addr: $public_ipv4:7001 ...
如何知道有哪些可用的配置参数呢？首先，通过 etcd -h 命令能够打印出所有Etcd启动时接收的参数项，将这些参数最开头的横杆去掉，并用冒号连接参数与值，写入 user-data文件后面，例如指定节点名称的参数是“-name=刘备”，写到 user-data 文件里面就成了“name: 刘备”。Etcd的文档中也有针对特定情况应该采用的配置，限于篇幅，不展开说了。
怎样在运行期动态修改这些配置哩？额，其实大部分是不可以修改的。并且这部分的API在V0.4到V2.0的升级是不兼容的。下面是V0.4.x版本中与集群成员配置相关的Etcd键，注意这里使用的是7001端口，也就说这些API最初是设计给Etcd服务之间通信使用的。通过PUT操作修改相应键的值就能动态的对这些配置进行修改。
core@core-01 ~ $ curl -L http://127.0.0.1:7001/v2/admin/config { "activeSize": 9, "removeDelay": 1800, "syncInterval": 5 } core@core-01 ~ $ curl -L http://127.0.0.1:7001/v2/admin/machines [ { "name": "0acdd9bf38194ea5ad1611ff9a4236f1", "state": "leader", "clientURL": "http://172.17.8.103:4001", "peerURL": "http://172.17.8.103:7001" }, { "name": "f2558aaa231044f3abbe01510ac2b1d8", "state": "follower", "clientURL": "http://172.17.8.101:4001", "peerURL": "http://172.17.8.101:7001" }, { "name": "f260afd8224c4854bdf8427d8451da23", "state": "follower", "clientURL": "http://172.17.8.102:4001", "peerURL": "http://172.17.8.102:7001" } ]
这些API在V2.0修改到了2379端口下的/v2/members路径下，结构也不太一样了，参见 官方文档。
小技巧
- 隐藏数据节点
在Etcd的存储系统中，所有以下划线开头的目录都被认为是“隐藏目录”。这种目录是不能通过 etcdctl ls 命令或 HTTP GET访问其上级目录列出来的。而知道路径的准确名称的用户可以通过的完整路径以处理普通数据一样的方式对隐藏目录下的数据节点进行增删查改。
core@core-01 ~ $ curl -L http://127.0.0.1:4001/v2/keys/App/_message-XPUT -d value="Hello hidden world" { "action":"set", "node": { "key":"/App/_message", "value":"Hello hidden world", "modifiedIndex":321911, "createdIndex":321911 } }
然后直接使用GET访问 /App 目录看到的是一个空目录，但显示的获取 /App/_message数据节点，却能发现这个键是确实存在的。也就是说，隐藏的目录或键不会被列出，只有知道完整路径的用户可以直接访问到。
core@core-01 ~ $ curl -L http://127.0.0.1:4001/v2/keys/App/ { "action":"get", "node":{ "key":"/App", <-- 没有 node.nodes 数据 "dir":true, "modifiedIndex":219320, "createdIndex":219320 } } core@core-01 ~ $ curl -L http://127.0.0.1:4001/v2/keys/App/_message { "action": "get", "node": { "key": "/App/_message", "value": "Hello hidden world", "modifiedIndex": 219320, "createdIndex": 219320 } }在 v0.4 的API中，有一个存放了集群节点信息的隐藏键，可以通过curl -L http://127.0.0.1:4001/v2/keys/_etcd命令查看到，这个键在 V2.0 中合并到 /v2/member 中成为非隐藏的普通键了。
- Json格式化
在控制台输出的Json内容难以直接阅读的，相关的格式化方法很多，这里推荐一个控制台下的开源工具软件jq，下载地址是：http://stedolan.github.io/jq/download/。它其实是一个Json数据的处理器，使用C语言编写，支持Windows、Linux、Mac等平台，使用起来十分方便。格式化Json数据可参考下面的例子，对于更完整的使用方法，请参考jq的官方文档。
wget http://stedolan.github.io/jq/download/linux64/jq chmod +x jq curl -L http://127.0.0.1:4001/v2/keys/coreos.com?recursive=true| ./jq '.'
小结
作为CoreOS最核心的服务，Etcd主要的功劳在于设计了一种简便、高效、可靠的集群应用程序配置共享的解决方案，并提供了编程语言无关RESTful API。围绕着这个悍将，CoreOS实现了集群的自组建（Discovery）、服务的跨节点调度（Fleet）、有序的集群重启（Locksmith）等许多分布式服务，极大的简化了集群的操作。同时由于Raft算法通过平等投票方式选择Leader节点，使用Etcd组成的网络具有一种高度扁平的系统结构，减少了层级带来的集群繁琐管理和资源浪费。扁平化的组织，不论是管人还是管机器，都真心好使，这是题外话。
这个系列写到这里，如果有人再要问我，CoreOS到底牛B在什么地方。我想在设计层面，Etcd至少功居前列。以下是我认为CoreOS三个最值得圈点的优秀之处：
- 高度精简的发行版和只读系统分区：不仅大大减少了系统的资源占用，更重要的意义在于迫使用户养成使用容器运行应用的习惯。就像智能手机系统给每个软件都包装了一个沙盒，其带来的安全和管理的好处远远大于使用沙盒带来的开销；
- 平滑升级的系统：这里只强调平滑升级，而不是官方大力宣传的AB双分区升级概念。其实即便使用了双分区，依然不可避免的需要重启完成升级，和单分区后台升级带来的好处并不是十分明显。而平滑升级却意味着操作系统可以长期运行，而不用担心版本过老又无法更新带来的漏洞问题；
- 稳定可靠的分布式配置系统（也就是Etcd服务），以及基于这个服务实现的一整套集群解决方案。这里包括刚刚提及的集群自组建，以及Fleet、Locksmith、Confd、Flannel、甚至Deis等众多基于Etcd构建的服务。
个人的薄见，不代表任何官方观点，欢迎共同探讨。
在下一篇中，我们将走进另一个大家应当早已熟识的鲸鱼朋友，Docker。聊聊它与CoreOS之间的那段佳事。 （作者/林帆 责编/周小璐）