轉載:http://www.csdn.net/article/2015-01-28/2823739/2node
摘要:Etcd是CoreOS生態系統中處於鏈接各個節點通訊和支撐集羣服務協同運做的核心地位的模塊,本文將主要介紹Etcd的RESTful API。若是說Etcd是CoreOS分佈式架構的基石,Etcd的RESTful API就是架在這基石上的頂梁立柱。linux
Etcd的配置通常經過cloud-init在系統啓動時就進行設定,具體設定方法與使用的平臺有關。好比AWS、GCE這些會在啓動Instance時有一步配置cloud-config裏面。對於Vagrant啓動的虛擬機,這個配置就是咱們以前修改過的user-data文件。默認時候這個配置大體是這個樣子的:git
$ 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的文檔中也有針對特定狀況應該採用的配置,限於篇幅,不展開說了。github
怎樣在運行期動態修改這些配置哩?額,其實大部分是不能夠修改的。而且這部分的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訪問其上級目錄列出來的。而知道路徑的準確名稱的用戶能夠經過的完整路徑以處理普通數據同樣的方式對隱藏目錄下的數據節點進行增刪查改。api
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內容難以直接閱讀的,相關的格式化方法不少,這裏推薦一個控制檯下的開源工具軟件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三個最值得圈點的優秀之處:
我的的薄見,不表明任何官方觀點,歡迎共同探討。
在下一篇中,咱們將走進另外一個你們應當早已熟識的鯨魚朋友,Docker。聊聊它與CoreOS之間的那段佳事。 (做者/林帆 責編/周小璐)