用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 的基础步骤。在此之上，可以增加更多的区块链层管理功能，图形化运维界面，使得开发人员投入更多的精力到应用的业务逻辑上。

（全文完）