用Kubernetes部署超级账本Fabric的区块链即服务(1)
用Kubernetes部署超級賬本Fabric的區(qū)塊鏈即服務(1)
2017年08月13日 00:00:00閱讀數(shù)：937題圖攝于舊金山市區(qū)：云海中的 Twin Peaks
不久前，我們發(fā)表了如何部署多節(jié)點 Fabric 1.0集群（可點擊）的方法，主要是描述手動部署的步驟。在本次連載中，我們將探討如何把 Fabric v1.0自動化部署在現(xiàn)今最流行的 Kubernetes 容器平臺上，從而實現(xiàn)對分布式區(qū)塊鏈平臺的管理和監(jiān)控等功能。
關(guān)注本公眾號的讀者可能發(fā)現(xiàn)，筆者主要研究區(qū)塊鏈和云原生應用兩個方面。看似不太相關(guān)的兩領(lǐng)域，在本文中得到完美結(jié)合，印證了筆者經(jīng)常分享的一句話：做技術(shù)總有會師的時候！
本文編寫過程中，我們團隊的工程師賈燚星對 Kubernetes 部分給出了建議和糾正，在此表示感謝。
【注：下載本文PDF版本以及本文源代碼，可關(guān)注本公眾號：亨利筆記，后臺發(fā)送消息“區(qū)塊鏈即服務”?或?“baas”即可?！?/span>
概述
盼望著，盼望著，超級賬本 Fabric 1.0 正式來了，社區(qū)用戶為之歡呼雀躍：終于等到一個企業(yè)級區(qū)塊鏈應用平臺了。然而在激動過后，回歸平靜之時，人們卻往往發(fā)現(xiàn)，搭建Fabric平臺是個相當披荊斬棘的歷程。不僅要具備密碼學、分布式計算、共識算法等區(qū)塊鏈理論基礎(chǔ)，而且要熟悉容器、Golang / Node.js 這些企業(yè)用戶不常用的工程技術(shù)，這常常是很多人把區(qū)塊鏈放棄在起跑線的原因。降低使用門檻，提高易用性，將是今后一段時間內(nèi)推廣企業(yè)區(qū)塊鏈應用的重要工作。
?
之前我們的文章描述過安裝部署多節(jié)點 Fabric 集群的步驟，旨在說明Fabric基本的運作原理，因此部署過程是手 ?(cao) ?動 ?(gen) ?的安裝方式。在實際的開發(fā)測試中，需要自動化部署來提高效率，本文介紹如何利用容器平臺Kubernetes（K8s）來自動部署 Fabric 1.0，實現(xiàn)區(qū)塊鏈即服務 (Blockchain as a Service, BaaS) 的基礎(chǔ)。
?
需要指出的是，BaaS目前多用于開發(fā)測試，即在同一個BaaS平臺，部署多個區(qū)塊鏈節(jié)點，每個節(jié)點代表不同組織機構(gòu)。這樣顯然是中心化的部署方式，只能用于開發(fā)測試用途。真實環(huán)境的部署需要分布在網(wǎng)絡中多個BaaS協(xié)同工作才能完成，這是另外一個尚待完善的工作。
?
我們選擇把 Fabric 部署在 K8s 上有幾個原因。首先 Fabric 的組件都經(jīng)過容器封裝好的，很方便部署在 K8s 這類容器平臺上，并借助平臺實現(xiàn)高可用、監(jiān)控管理、自動化運維等目的。
其次，Fabric 是分布式系統(tǒng)，根據(jù)應用的具體需求，集群的各個組件數(shù)會有不同，需要靈活地配置和調(diào)整。而 K8s 是面向微服務架構(gòu)的容器平臺，擴展方便，能夠很好地滿足 Fabric 這方面的要求。
還有就是 K8s 具備了多租戶的能力，可在同一個平臺中運行多個互相隔離的 Fabric 實例，方便開發(fā)測試，比如一個實例作為開發(fā)用，另一個實例作為測試用。
?
在超級賬本中有個子項目叫 Cello ，其目的是提供 Hyperledger 的 BaaS 。據(jù)了解，目前已經(jīng)支持把 Fabric 部署在 Docker 和 Swarm 上，有關(guān) K8s 的支持還在開發(fā)中。由于 Fabric 的設計中沒有考慮到 K8s 等平臺的特點，因此把 Fabric 部署在 K8s 上還需要一些變通的處理方法，后文相關(guān)部分會提到。
?
整體架構(gòu)
2.1 基礎(chǔ)設施
?
1) ? 網(wǎng)絡部分
?
Kubernetes 集群由多個節(jié)點組成，為使得集群上的容器正常通信，需要創(chuàng)建一個 overlay 網(wǎng)絡，并把集群上的容器都連接到這個網(wǎng)絡上。
圖 2- 1?
如圖2-1所示，宿主機網(wǎng)絡由藍色線標記，節(jié)點有 cmd 客戶機, Kubernetes 的 master 和 worker ，還有 NFS 服務器。其中，cmd 客戶機作為操作 K8S和 Fabric 集群的命令行客戶機。NFS服務器在各個節(jié)點間用于共享 Fabric 和 K8s 的各種配置文件，也可以用其他 K8s 支持的共享存儲代替。
?
通過 Kubernetes 的 cluster add-ons 可以很方便地創(chuàng)建 overlay 網(wǎng)絡，如 Flannel 。如圖 2-1的紅色線所示(為說明Flannel作用省去部分細節(jié))，Kubernetes 把所有pod加入到 Flannel 網(wǎng)絡中，因此 pod 中的容器可以相互通信。
Flannel網(wǎng)絡的地址段可以在 add-on 的配置文件中指定，同時 kube_dns 的 IP 地址也可以通過配置修改，但該IP地址必須處于指定地址段中。如圖2-1中 Flannel 的網(wǎng)絡為10.0.0.1/16，kube_dns 的 IP 地址為10.0.0.10。
在 Fabric 設計中， chaincode 目前是以 Docker 容器的方式運行在 peer 容器所在的宿主機上，peer 容器需要調(diào)用 Docker 引擎的接口來構(gòu)建和創(chuàng)建chaincode 容器，調(diào)用接口是通過這個連接：
unix:///var/run/docker.sock
這種方式其實是有安全隱患的，這里不作過多討論。正確的姿勢應該是調(diào)用chaincode 專用的運行環(huán)境，如新起一個 Docker Host ，用 TCP 接口遠程調(diào)用。
?
通過docker.sock 創(chuàng)建的容器脫離在 Kubernetes 的體系之外，雖然它仍在 Flannel 的網(wǎng)絡上，但卻無法獲得 peer 節(jié)點的 IP 地址。這是因為創(chuàng)建該容器的 Docker 引擎使用宿主機默認的 DNS 解析來 peer 的域名，所以無法找到。
?
為了解決解析域名的問題，需要在每個 worker 的 DOCKER_OPTS 中加入相關(guān)參數(shù)，以圖 2-1為例，kube_dns 的 IP 為10.0.0.10，宿主機網(wǎng)絡 DNS 的 IP 地址假設為192.168.0.1，為使得 chaincode 的容器可以解析到 peer 節(jié)點，修改步驟如下：
?
1. 編輯 /etc/default/docker，在 DOCKER_OPTS 中添加以下參數(shù)，設置 Kubernetes 使用的 DNS （很重要！）:
"--dns=10.0.0.10 --dns=192.168.0.1? --dns-search \?
default.svc.cluster.local--dns-search svc.cluster.local \
--dns-opt ndots:2 --dns-opt timeout:2 --dns-opt attempts:2"
?
2. 運行以下命令重啟Docker (注: 不同的Linux環(huán)境中命令可能會有不同)：
systemctl daemon-reload
systemctl restart docker
systemctl restart docker.service
【注：下載本文PDF版本以及本文源代碼，可關(guān)注本公眾號：亨利筆記，后臺發(fā)送消息“區(qū)塊鏈即服務”?或?“baas”即可?！?/span>?
2) ?共享存儲
?
K8s 和 Fabric 集群需要較多的配置文件，為方便管理，可通過 NFS 服務器來統(tǒng)一儲存這些文件，如圖 2-1所示。
?
cmd客戶機可通過 cryptogen 工具生成 crypto-config 目錄，該用于儲存 Fabric 集群中節(jié)點的配置文件，如 peer0.org1 所用到的 msp 存放在以下目錄：
?
crypto-config/PeerOrganization/org1/peers/peer0/msp
?
cmd客戶機只需要把 NFS 的共享目錄掛載到本地 /opt/share/ ，再把 crypto-config 寫到該目錄，即可讓各個節(jié)點訪問到配置文件。
?
在 Kubernetes 中，通過 PV 和 PVC 來把 NFS 上的文件掛載到容器中，除了創(chuàng)建相應的 PV 和 PVC 外，還需在節(jié)點的配置文件中把正確的路徑掛載進去。若NFS 服務器的共享目錄為 /opt/share ，創(chuàng)建 PV 時可指定 peer.org1 的掛載點為：??
?
/opt/share/crypto-config/PeerOrganization/org1/
?
然后創(chuàng)建與該 PV 相對應的 PVC ，這樣在節(jié)點的配置文件中就可以使用 PVC 來掛載這個目錄。節(jié)點需要根據(jù)自己的 ID 在掛載點后面加上相應的路徑來保證掛載的配置文件無誤，如 peer0.org1 應在路徑后加上 peers/peer0/msp ，則其掛載目錄的完整路徑如下：
?
/opt/share/crypto-config/PeerOrganization/org1/peers/peer0/msp
?
2.2 ?組件劃分
?
在 Kubernetes 中，Namespace 是一個很重要的概念，它用于劃分不同的虛擬集群，而 Fabric 中 organization 基于證書簽發(fā)機構(gòu)劃分，把 K8S 的 namespace 與 Fabric 的 organization 對應，既使得 organization 之間相互獨立，又充分利用了 K8S 的 DNS 服務，各個 organization 可以通過域名區(qū)分。采用 namespace 分隔各個組織的組件，還可實現(xiàn)網(wǎng)絡策略 (network policy) 來隔離不同組織，實現(xiàn)多租戶的能力 (本文未涉及)。
圖 2- 2
如圖 2-2所示，假設 Fabric 網(wǎng)絡中有多個 peer organization 和 orderer organization ，下面闡述如何在 Kubernetes 進行劃分和對應：
a.???若第N個 Fabric 的 peer organization 的域名為 orgN，則其在 Kubernetes 上對應的 namespace 設置為 orgN ，在該 namespace 下有多個 pod，pod 的類型如下：
1)???Peer Pod：包括 Fabric peer，couchDB （可選），代表每個組織的 peer節(jié)點。
2)???CA Server Pod： Fabric CA Server。
3)???CLI Pod：（可選）提供命令行工具的環(huán)境，用于操作本組織的節(jié)點、channel 或 chaincode。
?
b.???若第N個 Fabric 的 orderer organization 的域名為 orgordererN ，則其在Kubernetes 上對應的 namespace 為 orgordererN ，該 namespace 下只有一種 ?Pod ，它用于運行 orderer 節(jié)點。
?
c.???Kafka namespace 與 Fabric 的 organization 并無關(guān)系，它只用來運行和管理Zookeeper和Kafka容器，實現(xiàn)共識算法。
2.3? Pod之間的通信
Kubernetes?中的每個?Pod?都有獨立的?IP?地址，然而在各個?Pod?之間直接通過?IP:port?的方式來通信會帶來很多麻煩，因此有必要給每一個?Pod?綁定一個的?service?，以便用?service?名稱來訪問。
?
service?的命名方式應當遵循以下原則，彰顯與其綁定的?Pod?信息：
1)???service?與?pod?的?namespace?應當一致。
2)???service?的?name?應與?Pod?中容器的?id?一致。
?
例如，Fabric?中屬于?org1?的?peer0?節(jié)點，在?K8S?中用?namespace?為?org1、名字為?peer0?的?Pod?來運行，與該?Pod?綁定的?service?全稱應為?peer0.org1?。其中?peer0?為?service?的名稱，org1?為?service?的?namespace?。這樣的映射關(guān)系已經(jīng)和主機域名很接近了。
總結(jié)
以上是生活随笔為你收集整理的用Kubernetes部署超级账本Fabric的区块链即服务(1)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： BaaS（区块链即服务Blockchai
- 下一篇： 巨杉数据库：金融级数据库是怎样炼成的