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

题图摄于三藩市Pier 7：Coit Tower

上次我们介绍了用 Kubernetes 部署 Fabric （可点击）的总体架构和网络、存储的规划，本期为连载之二，详述部署工具设计的细节，包括模板的定制和配置的设定。文后附下载PDF版本的方法。

3. 源码的说明与使用
3.1 环境准备
假定 K8s 平台已经成功部署，并且在各个 worker 节点已经预先下载相应的 Fabric v1.0.0 的 Docker 镜像，如表3-1。（预先下载镜像是由于国内网速较慢，在一台机器预先下载后，可用Docker命令导出并导入其他机器。）
 

IMAGE	TAG	ID
hyperledger/fabric-tools	x86_64-1.0.0	0403fd1c72c7
hyperledger/fabric-orderer	x86_64-1.0.0	e317ca5638ba
hyperledger/fabric-peer	x86_64-1.0.0	6830dcd7b9b5
hyperledger/fabric-ccenv	x86_64-1.0.0	7182c260a5ca
hyperledger/fabric-ca	x86_64-1.0.0	a15c59ecda5b
hyperledger/fabric-baseimage	x86_64-0.3.1	9f2e9ec7c527
hyperledger/fabric-baseos	x86_64-0.3.1	4b0cab202084

表 3- 1
本文涉及代码的目录结构及其作用如下：

Fabric-on-k8s   - README.md   - setupCluster         - generateALL.sh        // 负责生成K8S部署文件         - transform                 // 用于启动部署文件         - templates                // 存放模板         - cluster-config.yaml // 用于配置Fabric集群         - configtx.yaml          // 用于配置channel 3.2 配置文件说明在规划 Fabric 集群部署时，要按实际需求，编辑以下两个 Fabric 集群的定义文件：

a.   cluster-config.yaml cryptogen 工具根据 cluster-config.yaml 来生成 Fabric 成员的证书，一个简单的例子如下:OrdererOrgs: - Name: Orderer   Domain: orgorderer1   Template:     Count: 1 PeerOrgs: - Name: Org1   Domain: org1   Template:     Count: 2  - Name: Org2   Domain: org2   Template:     Count: 2  其中 OrdererOrgs 和 PeerOrgs 关键字区分 organization 的类型，两种组织的内部结构如下：

1) OrdererOrgs 中定义了一个名字为 Orderer ，域名为 orgorderer1 的 org ，并且它指定 template 中 count 的数值为 1，则在该 org 下只有一个 orderer ，其 id 为 orderer0 。

2) PeerOrgs 中定义了两个 org ，分别为 Org1 和 Org2 ，对应的域名为 org1、 org2 与 orderer 类似，每个 org 生成了两个 peers ，虽然 org1 中 peer0 和 org2 中 peer0 的ID重复，但是他不属于同一个 org ，通过域名很容易就能区分出它们。 需要注意的是，由于 K8S 中的 namespace 不支持‘.’和大写字母，因此各个组织的域名不能包含这些字符。 更多关于 cluster-config.yaml 的配置方式，请读者可参考 Fabric 源码中的关于cryptogen 的描述 ( fabric/common/tools/cryptogen/main.go ) 以上定义的 cluster-config.yaml ，cryptogen 工具会生成 crypto-config 目录，该目录的结构如下：           crypto-config                  ---ordererOrganizations                   --- orgorderer1                        ---msp                        --- ca                            --- tlsca                        --- users                        --- orderers                             ---orderer0.orgorderer1                                  ---msp                                  --- tls                  ---peerOrganizations                       --- org1                        ---msp                        --- ca                            --- tlsca                        --- users                        --- peers                              ---peer0.org1                                   ---msp                                   --- tls                                     --- peer1.org1                                   ---msp                                   --- tls                       --- org2                       --- msp                       ---  ca                          --- tlsca                       --- users                       --- peers                             ---peer0.org2                                  --- msp                                  --- tls                                    --- peer1.org2                                  --- msp                                  --- tls 可以看出，每个 org 都包含了 msp、 ca、 tlsca 和 users 目录，然后根据 org 类型的不同，还分别有 peers 和 orderers 目录，里面存放着 org 中每个成员的 msp 和 tls 文件。 b.   configtx.yaml configtxgen 工具根据该文件生成 Orderer 初始化的时候要使用的 genesis.block，获知 organization 的各种信息，因此，用户要根据 cluster-config.yaml 中关于 organization 的定义来修改 configtx.yaml 以生成合适的 genesis.block 。例如，用户在 cluster-config.yaml 中增加了一个 Org3 ，并且要创建一个包含 Org1， Org2， Org3 的集群，则应该通过以下两步修改 configtx.yaml ：            1. 在 profile 中增加 Org3 ，如图3-1。


图 3- 1 2. 在 Organization 中增加 Org3 的 MSPDir ，如图3-2:

图 3-2

注意的是每个 organization 中的 MSPDir 的值必须是这种形式：crypto-config/{OrgType}/{OrgName}/mps

3.3 模板文件 在 Kubernetes 中部署 Fabric 时，需要为每个节点编写相应的配置文件。由于节点数可能很多，这是既复杂又易错的重复劳动。为提高效率，可通过模板自动生成配置文件。本文使用了5个模板文件，可用脚本替换其中的变量，均在笔者给出示例代码中的 templates 目录中，这些模板的作用如下： a.   fabric_1_0_tmeplate_namespace.yaml 定义Fabric集群在 K8s 中的 namespace ，它对应着 organization 的域名。为了在多节点共享证书等文件，使用了 NFS 服务器作为存储。在 K8s 中通过相应的 PV 和 PVC ，namespace 下的 Pod 可以通过 PVC 来获取与之相应的文件。 b.   fabric_1_0_template_cli.yaml     CLI pod 模板，每个 organization 中都配备了一个 CLI pod，目的是提供命令行界面，可统一管理组织内的所有 peer ，其中包括 channel 的创建， chaincode 的安装等。CLI Pod 的 CORE_PEER_ADDRESS 环境变量默认值为 org 中的第一个 peer，可以通过修改该环境变量来连接不同的 peer 。 yaml 文件中的 command 是为了防止 CLI pod 自动退出，CLI 的默认工作目录为/opt/gopath/src/github.com/hyperledger/fabric/peer。由于该目录下的 channel-artifacts 挂载了 NFS 上 /opt/share/channel-artifacts，因此把创建 channel 时返回的 xxx.block 文件放在该目录下供所有 CLI Pod共享。 c.   fabric_1_0_template_ca.yaml Fabric 的 CA 服务的 pod 定义模板，用于 organization 中的证书管理，其 yaml 文件除了定义 deployment 外，还定义了 service 。service 通过 selector 与 deployment 绑定，其中 deployment 中的 label 是 selector 与其绑定的根据。    d.   fabcric_1_0_template_orderer.yaml Orderer 的 pod 定义模板，需要注意的是，cryptogen 并不会生成 genesis.block ，然而缺少该文件时，orderer 会启动失败，因此在启动 orderer 之前需要预先生成 genesis.block ，并将其放在相应的 org 目录下。 e.   fabric_1_0_template_peer.yaml 每个 peer pod 的定义模板。在该 yaml 中分别定义了 peer 和 couchDB 两个container 。在实例化 chaincode  (cc) 时，peer 需要连接 Docker 引擎来创建 cc 容器，因此要把 worker 宿主机的 var/run/docker.sock 映射到 peer 容器内部（参见图2-1）。

（未完待续）
欢迎读者们继续在文后点赞、留言交流，告诉我们你喜欢这样的文章。【注：下载本文PDF版本以及本文源代码，可关注本公众号：亨利笔记，后台发送消息“区块链即服务” [b][b]或 [b]“baas”[/b][/b]即可。】[/b]相关文章：超级账本Fabric 1.0 多节点集群的部署《区块链技术指南》介绍更多关于超级账本的信息，以及区块链的技术细节，包括比特币、以太坊、公有链、联盟链、侧链、闪电网络等等，请参考笔者和邹均博士等作者合著的《区块链技术指南》，机械工业出版社：


京东购买链接：
http://item.jd.com/12007317.html
欢迎读者们继续在文后点赞、留言交流，亨利笔记主要包含关于区块链、云计算的技术文章，欢迎关注：