用Kubernetes部署超级账本Fabric的区块链即服务(3)

题图摄于北京中轴线：鼓楼、玲珑塔、钉子塔、盘古大观

前2期文章我们分别介绍了用 Kubernetes 部署 Fabric （可点击）的总体架构和网络、存储的规划以及模板设计。作为可能是国内首篇关于 Kubernetes 部署 Fabric 1.0 的文章，详细到代码级，本文受到广泛的关注和欢迎。笔者们也百忙中快马加鞭，完成最后一部分，以飨读者。本期为连载之三，详述部署工具的具体实现步骤。文后附下载全文PDF版本和源代码的方法。

(接上期)

3.4  源码使用

 

以下操作都在图 2-1的 cmd 客户机上进行，NFS 的共享目录为 /opt/share ，该共享目录的 拥有者:用户组 建议设为 nobody:nogroup 。

 

a．生成启动文件

 

步骤：

1. 把 NFS 的 /opt/share 目录挂载到 host 的 /opt/share 。

 

2. 下载本文配套源码并进入 Fabric-on-K8S/ 目录，通过以下命令下载 Fabric 的 cryptogen 等工具：

$ curl https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric/linux-amd64-1.0.0/hyperledger-fabric-linux-amd64-1.0.0.tar.gz| tar xz

 

下载完毕后会在当前目录生成一个 bin 目录，该目录包含 cryptogen 和 configtx 等文件。

 

3. 更改 templates/fabric_1_0_template_pod_cli 的 NFS 地址，如图 3-3所示。

图 3- 3

 

4. 更改 templates/fabric_1_0_template_pod_namespace 的 NFS 地址，如图 3-4。

图 3- 4

 

5.  依照 3.2 的说明配置 cluster-config.yaml 和 configtx.yaml 。

 

6.   通过以下命令生成启动所需要的文件:

 

$ sudo bash generateAll.sh

  

运行 generateAll.sh 脚本时，除了调用 cryptogen 生成 crypto-config 目录之外，还在目录中的各个 organization 子目录下插入相应的 K8S 配置文件。以org1 为例，其目录下会有几个 yaml 文件用于启动：

crypto-config

  --- peerOrganizations

       --- org1

                        ---org1-ca.yaml

                        ---org1-cli.yaml

                        ---org1-namespace.yaml

                        ---msp

                        --- ca

                        --- tlsca

                        --- users

                        --- peers

                              ---peer0.org1

                                   ---peer0.org1.yaml

                                   ---msp

                                   --- tls

                              ---peer1.org1

                                   ---peer1.org1.yaml

                                   ---msp

                                   --- tls

 

b.   运行启动脚本

 

  通过以下命令启动Fabric集群(需要安装PyYAML-3.5):

  $ python3.5 transform/run.py

 对每个Fabric的 PeerOrganization ，启动脚本的工作流程如下：

·      在 Kubernetes 中创建org的 namespace；

·      创建 org 的 ca pod ；

·      创建 org 的 CLI pod ；

·      遍历 orgM/peers 的子目录找出相应的 yaml 文件，并启动所有 peer 。

           

c.   查看 cluster 状态

 

创建完成后，查看各个 pod 的状态，若都显示为 running 则说明所有部件工作正常，命令如下，结果如图3-5：

$ kubectl get pods–all-namespaces

图 3- 5

【注：下载本文PDF版本以及本文源代码，可关注本公众号：亨利笔记，后台发送消息“区块链即服务” 或 “baas”即可。】

4. 测试Fabric集群

假设已经成功启动 3.2.a 中定义的 Fabric 集群，下面通过运行测试 chaincode 来判断 Fabric 集群是否如预期般工作。

首先创建和加入 channel，使用 configtx 工具来生成与 channel 相关的文件：

[1]  进入 CMD 客户机的 Fabric-on-K8S/setupCluster/ 目录:

 

$ cd Fabric-on-K8S/setupCluster/

 

[2]  创建 channel 的 channel.tx 文件，该 channel 的 ID 为 mychannel :

 

$ ../bin/configtxgen -profileTwoOrgsChannel \

-outputCreateChannelTx \

./channel-artifacts/channel.tx \

-channelID mychannel

 

[3]  创建 channel 的升级文件，该文件用于更新 mychannel 中 Org1 的 anchor peer :

$ ../bin/configtxgen  -profile TwoOrgsChannel 

-outputAnchorPeersUpdate\

./channel-artifacts/Org1MSPanchors.tx \

-channelID mychannel -asOrg Org1MSP

 

[4]  创建 channel 的升级文件，该文件用于更新 mychannel 中 Org2 的 anchor peer:

$ ../bin/configtxgen  -profile TwoOrgsChannel \

-outputAnchorPeersUpdate\

./channel-artifacts/Org2MSPanchors.tx\

-channelID mychannel -asOrg Org2MSP

 

[5]  由于每个 Org 的 CLI Pod 需要用到以上步骤创建的文件，可以通过 NFS 来跟 CLI Pod 共享这些文件:

 

$ sudo cp -r ./channel-artifacts /opt/share/

          

完成以上工作后，就可以通过各组织的 CLI Pod 来测试集群是否正常运行。

通过以下操作进入任意 org 的 CLI Pod 内部，以 org1 为例：

1. 查看 namespace 为 org1下的所有 Pod ：

$ kubectl get pods –namespaces org1 

图 4- 1

  

如图 4-1所示 org1 的 CLI Pod 为 cli-2586364563-vclmr。

 

2.    进入 cli-2586364563-vclmr Pod：

 

$ kubectl exec -it cli-2586364563-vclmr bash --namespace=org1

 

进入 CLI Pod 后，可以执行以下命令以测试 Fabric 集群：

a.   创建channel

$ peer channel create -o orderer0.orgorderer1:7050 \

-c mychannel -f./channel-artifacts/channel.tx

 

b.   拷贝 mychannel.block 到 channel-artifacts 目录：

$ cp mychannel.block./channel-artifacts

 

c.   加入 mychannel

$ peer channel join -b./channel-artifacts/mychannel.block

 

d.   更新 anchor peer，每个 org 只需执行一次

$ peer channel update -o orderer0.orgorderer1:7050 \

-c mychannel -f./channel-artifacts/Org1MSPanchors.tx

 

e.   安装chaincode

请读者下载 Fabric 的 chaincode_example02 目录并将其放置在 CMD 客户机的 /opt/share/channel-artifacts 目录下：

$ peer chaincode install -n mycc -v 1.0 \

-p github.com/hyperledger/fabric/peer/channel-artifacts/chaincode_example02

 

f. 实例化 chaincode

$ peer chaincode instantiate -o orderer0.orgorderer1:7050 \

-C mychannel -n mycc -v1.0 -c '{"Args":["init","a","100","b","200"]}'\

-P "OR    ('Org1MSP.member','Org2MSP.member')"

 

通过以上命令实例化 mycc 后，读者可以自行切换到其他 org 的 CLI Pod 上通过加入 channel 等步骤，验证账本是否同步。

 

4.1 外部调用

在配置文件中 ca、peer 和 orderer 的 service 类型定义为 NodePort，这样做的目的是为了让用户在 K8S 外也能访问到Fabric中的各个成员，端口映射规则如下 (以下出现 N 和 M 的范围分别为 N>=1, M>=0 ):

 

1.   orgN 端口范围是 30000+(N-1)*100 ~ 30000+(N)*100-1，也就是说每一个 org 最多能分配到 100 个端口号，如 org1 的端口范围是 30000 到 30099。

 

2.   CA 的 7054 的映射关系如下：

ca.orgN:7054 ->  worker:30000+(N-1)*100

 

3.   由于每个peer需要映射7051和7052两个端口，因此org中peerM的端口映射关系如下:

 

peerM.orgN:7051 ->worker:30000+(N-1)*100 + 2 * M + 1

peerM.orgN:7052 ->worker:30000+(N-1)*100 + 2 * M + 2

 

4.   ordererN 的映射关系为：

ordererN:7050 -> worker:23700+N

 

若 worker1 的IP地址为 192.168.0.7，它运行 peer0.org1 ，则 Kubernetes 外的用户需要通过 192.168.0.7:30001 地址才能访问 peer0.org1 。

4.2 删除集群

当需要删除集群的时候，可以通过 transform 目录下的 delete.py 脚本来清理环境，该脚本会遍历 crypto-config 目录，找出所有的 yaml 文件，并通过 kuberclt delete -f xxx.yaml 的方式将资源逐个删除。

 

5. 小结

本文阐述了 Kubernetes 与 Fabric 结合的重要性，并给出 Fabric 与 Kubernetes 结合的思路与框架，然后结合脚本工具来解析快捷部署的实现方式，最后是测试部署的集群是否正常工作。本文介绍的部署方法，是基于 Kubernetes 容器云平台实现 BaaS 的基础步骤。在此之上，可以增加更多的区块链层管理功能，图形化运维界面，使得开发人员投入更多的精力到应用的业务逻辑上。

 

（全文完）

欢迎读者们继续在文后点赞、留言交流，告诉我们你喜欢这样的文章。

【注：下载本文PDF版本以及本文源代码，可关注本公众号：亨利笔记，后台发送消息“区块链即服务” 或 “baas”即可。】

相关文章：超级账本Fabric 1.0 多节点集群的部署

《区块链技术指南》介绍

更多关于超级账本的信息，以及区块链的技术细节，包括比特币、以太坊、公有链、联盟链、侧链、闪电网络等等，请参考笔者和邹均博士等作者合著的《区块链技术指南》，机械工业出版社：

京东购买链接：

http://item.jd.com/12007317.html

---

欢迎读者们继续在文后点赞、留言交流，亨利笔记主要包含关于区块链、云计算的技术文章，欢迎关注：