fabric区块链_fabric区块链就是公有链的典型代表

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

　　前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

　　--- ca

　　--- peers

　　---peer0.org1

　　---peer0.org1.yaml

　　---peer1.org1

　　---peer1.org1.yaml

　　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

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

　　（全文完）

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

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

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