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

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

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

3. 源码的说明与使用

3.1 环境准备

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

表 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）。

（未完待续）

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