04-手动搭建Fabric网络-详解链码安装、实例化过程

前言

在关于 HyperLedger 的第一篇文章《1-HyperLedger 实战-快速搭建一个 Fabric1.0 环境》中，我们安装好了各种软件和环境。安装好以后，我们 git clone 下来最新的代码，并切换到 v1.0.0，并且下载好我们需要使用的 docker 镜像。但是在后面的创建Fabric 网络时，是使用命令

./network_setup.sh up

来创建了一个Fabric 网络。其中，network_setup.sh 是官方提供的脚本。这个脚本究竟做了哪些事情呢？其实，这个脚本做了下面的一些事情：

1. 编译生成几个工具。如 configtxgen，cryptogen 等工具。这些工具能够生成Fabric 网络所需要的公私钥和证书等信息，位于目录：fabric/release/linux-amd64/bin
2. 基于 configtx.yaml 生成创世区块和通道相关信息，并保存在 channel-artifacts 文件夹。
3. 基于 crypto-config.yaml 生成公私钥和证书信息，并保存在 crypto-config 文件夹中。
4. 基于 docker-compose-cli.yaml 启动 1Orderer+4Peer+1CLI 的Fabric容器。
5. 在 CLI 启动的时候，会运行 scripts/script.sh 文件，这个脚本文件包含了创建 Channel，加入 Channel，安装 Example02，运行 Example02 等功能。

在我们手动创建的过程中，前 4 步和上述一样。

第 5 步中，我们不运行 script.sh 文件，而是手动来创建 Channel，加入 Channel 以及安装和运行 ChainCode。好了，接下来，进入我们的手动搭建一个Fabric 网络实战。

声明：下面这一部分，主要参考深蓝-《深入理解 Fabric 环境搭建的详细过程》的博客。
以及：

Building Your First Network​hyperledger-fabric.readthedocs.io

手动搭建一个 Fabric 网络

1.生成公私钥和证书

Fabric中有两种类型的公私钥和证书，一种是给节点之间，为了通讯安全而准备的TLS 证书，另一种是用户登录和权限控制的用户证书。这些证书本来应该是由 CA 来颁发，但是我们这里是测试环境，并没有启用 CA 节点，这里我们使用：cryptogen 来生成这两种证书。由于这个工具并没有在源码中存在，需要我们手动编译生成。

1.1 编译生成 cryptogen

我们既然获得了Fabric的源代码，那么就可以轻易的使用 make 命令编译需要的程序。Fabric官方提供了专门编译 cryptogen 的入口，我们只需要运行以下命令即可：

cd ~/go/src/github.com/hyperledger/fabric
make cryptogen

运行成功后系统返回结果：

这说明我们在 build/bin 文件夹下可以看到编译出来的 cryptogen 程序。

如果出现下列情况，说明是缺少了编译工具 libltdl-dev

执行下面这句之后再运行 make 即可！

sudo apt install libtool libltdl-dev

1.2 配置 crypto-config.yaml

在本文中，我们所说的配置，并非真正的配置，而是看官方提供的 crypto-config.yaml 是怎么编写的。在实际的开发流程流程中，我们就是这样子一步步来配置的。examples/e2e_cli/crypto-config.yaml 已经提供了一个 Orderer Org 和两个 Peer Org 的配置，该模板中也对字段进行了注释。这个配置文件中，配置的 Org 与 peer，通道的关系，定义的组织结构如下图所示：

这也是我们这篇文章中最终要搭建的网络的拓扑结构。

我们可以把 crypto-config.yaml 文件中的 Org2 拿来分析一下：

- Name: Org2 
   Domain: org2.example.com 
   Template: 
     Count: 2 
   Users: 
     Count: 1

Name 和 Domain 就是关于这个组织的名字和域名，这主要是用于生成证书的时候，证书内会包含该信息。而 Template Count=2 是说我们要生成 2 套公私钥和证书，一套是 peer0.org2 的，还有一套是 peer1.org2 的。

最后 Users. Count=1 是说每个 Template 下面会有几个普通 User（注意，Admin 是 Admin，不包含在这个计数中）。

这里配置了 1，也就是说我们只需要一个普通用户。在实际生产环境中，我们可以根据实际需要调整这个配置文件，增删 Org Users 等。

Fabric 网络中，成员 与 用户的关系

在Fabric网络中，用户并不和 Peer 节点有直接的关联关系。

用户使用应用程序来和区块链网络进行交互，以完成交易。
该应用程序可以是 APP 或者 WebAPP，它通过使用用户身份来代表用户行事。

例如，用户可以使用银行应用程序，该应用程序通过 SDK 与网络交互。应用程序会在网络上传递用户的身份;也就是说，用户所做的每一笔交易都将承担用户的身份和签名。
另一方面，应用程序可以代表用户行事，并使用其自己的身份和签名来签发交易。
用户是借助应用，连接 Peer 节点，而进入区块链网络进行操作的。

HyperLedger Fabric中，成员和用户是两个不同的角色。
成员是针对区块链网络中的组织，联盟等而言，而用户，是针对整个应用而言。
用户指的是该系统给的使用者。

区块链网络中的成员参与到区块链网络之中，拥有 Peer 节点或者 Orderer 节点或运行在网络中的应用程序。

例如，多家银行可能会建立 Fabric 网络，因此他们是网络的成员，他们的客户可能是网络的用户。银行会部署 Peer 节点和 Orderer 节点来满足其客户的流量需求，但它不会是 1 个 Peer 对应 1 个用户。

1.3 生成公私钥和证书

我们配置好 crypto-config.yaml 文件后，就可以用工具 cryptogen 去读取该文件，并生成对应的公私钥和证书了。进入 fabric 根目录，运行下面命令：

cd examples/e2e_cli/
../../build/bin/cryptogen generate --config=./crypto-config.yaml

生成的文件都保存到 crypto-config 文件夹，我们可以进入该文件夹查看生成了哪些文件：

tree crypto-config

2.生成创世区块和 Channel 配置区块

这里的创始区块是指生成系统通道的创世区块，主要用于启动 Ordering 服务，配置网络中的策略。而 Channel 配置区块，主要用于新建应用通道，指定通道成员，以及访问策略等等。

2.1 编译生成 configtxgen

configtxgen 的作用是生成配置区块和配置交易。与前面 1.1 说到的类似，我们可以通过 make 命令生成 configtxgen 程序：

cd ~/go/src/github.com/hyperledger/fabric
make configtxgen

运行成功后，结果为：

2.2 配置 configtx.yaml

官方提供的 examples/e2e_cli/configtx.yaml 这个文件里面，

配置了由 2 个 Org 参与的 Orderer 共识配置TwoOrgsOrdererGenesis，

以及由 2 个 Org 参与的 Channel 配置：TwoOrgsChannel。

Orderer 可以设置共识的算法是 Solo 还是 Kafka，以及共识时区块大小，超时时间等，我们使用默认值即可，不用更改。而 Peer 节点的配置包含了 MSP 的配置，锚节点的配置。如果我们有更多的 Org，或者有更多的 Channel，那么就可以根据模板进行对应的修改。

2.3 生成创世区块

配置修改好后，我们就用 configtxgen 生成创世区块。并把这个区块保存到本地 channel-artifacts 文件夹中：

cd examples/e2e_cli/
../../build/bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

再次重申，创世区块的作用是开启 Ordering service 服务，配置网络中的策略。

2.4 生成 Channel 配置区块

../../build/bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID mychannel

再次重申，Channel 配置区块，用来新建 Channel 应用通道，指定通道成员以及访问策略等等。

2.5 锚节点的更新

我们使用 configtxgen 工具来生成的锚节点配置更新文件，锚节点负责代表组织与其他组织中的节点进行 Gossip 通信。具体命令如下：

../../build/bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP

../../build/bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP

最终，我们在 channel-artifacts 文件夹中，应该是能够看到 4 个文件。

3.配置 Fabric 环境的 docker-compose 文件

前面对节点和用户的公私钥以及证书，还有创世区块都生成完毕了。这里采用的是 docker-compose 的方式来部署环境的，所以接下来我们就可以配置 docker-compose 的 yaml 文件，以便顺利启动 Fabric 的 Docker 环境。

3.1 配置 Orderer

Orderer 的配置是在 base/docker-compose-base.yaml 里面，我们看看其中的内容：

，ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block，而这个创世区块就是我们之前创建的创世区块，上面的路径是本地文件到Docker 的映射。另外的配置主要是 TL，Log 等，最后暴露出服务端口 7050。

3.2 配置 Peer

Peer 的配置是在 base/docker-compose-base.yaml 和 peer-base.yaml 里面，我们摘取其中的 peer0.org1 看看其中的内容：

在 Peer 的配置中，主要是给 Peer 分配好各种服务的地址，以及 TLS 和 MSP 信息。

3.3 配置 CLI

CLI 在整个 Fabric 网络中扮演客户端的角色，我们在开发测试的时候可以用 CLI 来代替 SDK，执行各种 SDK 能执行的操作。CLI 会和 Peer 相连，把指令发送给对应的 Peer 执行。CLI 的配置在 docker-compose-cli.yaml 中，我们看看其中的内容：

从这里我们可以看到，CLI 启动的时候默认连接的是 http://peer0.org1.example.com，并且启用了 TLS。默认是以Admin@org1.example.com这个身份连接到 Peer 的。CLI 启动的时候，会去执行./scripts/script.sh 脚本，这个脚本也就是 fabric/examples/e2e_cli/scripts/script.sh 。
这个脚本完成了 Fabric 环境的初始化和 ChainCode 的安装及运行。

接下来要讲的步骤 4 和 5 在文件映射配置。

注意配置文件中链码的位置为

../chaincode/go/:/opt/gopath/src/github . com/hyperledger/fabric/examples/chaincode/go，

该目录是本地目录 fabric/examples/chaincode/go 在容器中 的映射。以后我们要开发自己的 ChainCode，只需要把我们的代码复制到该目录即可。

【注意：】

【请注释掉 cli 中 command 这一行，我们不需要 CLI 启动的时候自动执行脚本，我们在步骤 4,5 要一步步的手动执行！】

4.初始化 Fabric 环境

4.1 启动 Fabric 环境的容器

我们将整个 Fabric Docker 环境的配置放在 docker-compose-cli.yaml 后，只需要使用以下命令即可：

docker-compose -f docker-compose-cli.yaml up -d

最后这个-d 参数如果不加，那么当前终端就会一直附加在 docker-compose 上，而如果加上的话，那么 docker 容器就在后台运行。运行 docker ps 命令可以看启动的结果：

可以看到 1Orderer+4Peer+1CLI 都启动了。

4.2 创建 Channel

现在我们要进入 cli 容器内部，在里面创建 Channel。先用以下命令进入 CLI 内部 Bash：

docker exec -it cli bash

创建 Channel 的命令是 peer channel create，我们前面创建 2.4 创建 Channel 的配置区块时，指定了 Channel 的名字是 mychannel，那么这里我们必须创建同样名字的 Channel。创建 Channel 的命令如下：

ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile $ORDERER_CA

第一行是环境变量配置，指定证书的位置，是本地证书路径映射映射到容器中的路径。

第二行是创建一个名为 mychannel 的通道。运行成功后，会出现如下信息：

系统会在 cli 内部的当前目录创建一个 mychannel.block 文件，这个文件非常重要，接下来其他节点要加入这个 Channel 就必须使用这个文件。

如果出现下列情况，这是因为你正试图创建一个重名的通道，这个通道已经存在！

解决办法：删除所有的容器然后参照手动创建和加入通道部分的步骤继续执行。

在这个过程中，可能会出现很多的意想不到的问题，可以参考这篇文章《Hyperledger Fabric V1.0– 开发者快速入门》的第九部分-故障排除

4.3 各个 Peer 加入 Channel

前面说过，在 docker-composer-cli.yaml 文件汇总，我们的 CLI 默认连接的是 peer0.org1，那么我们要将这个 Peer 加入 mychannel 就很简单，只需要运行如下命令：

peer channel join -b mychannel.block

系统返回消息：

那么其他几个 Peer 又该怎么加入 Channel 呢？这里就需要修改 CLI 的环境变量，使其指向另外的 Peer。

修改 CLI 的环境变量的目的，是使得 cli 链接不同的 peer 节点。在 docker-compose-cli.yaml 文件中，默认连接的是 peer0.org1 节点。现在通过更改环境变量的方式，将其链接节点改为 peer1.org1.

比如我们要把 peer1.org1 加入 mychannel，那么命令是：

CORE_PEER_LOCALMSPID="Org1MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp 
CORE_PEER_ADDRESS=peer1.org1.example.com:7051

peer channel join -b mychannel.block

系统会返回成功加入 Channel 的消息。

同样的方法，将 peer0.org2 加入 mychannel：

CORE_PEER_LOCALMSPID="Org2MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 
CORE_PEER_ADDRESS=peer0.org2.example.com:7051

peer channel join -b mychannel.block

最后把 peer1.org2 加入 mychannel：

CORE_PEER_LOCALMSPID="Org2MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 
CORE_PEER_ADDRESS=peer1.org2.example.com:7051

peer channel join -b mychannel.block

我们搭建的 Fabric 网络的拓扑图如下所示：

4.4 更新锚节点

对于 Org1 来说，peer0.org1 是锚节点，我们需要连接上它并更新锚节点：

CORE_PEER_LOCALMSPID="Org1MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp 
CORE_PEER_ADDRESS=peer0.org1.example.com:7051

peer channel update -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx --tls true --cafile $ORDERER_CA

另外对于 Org2，peer0.org2 是锚节点，对应的更新代码是：

CORE_PEER_LOCALMSPID="Org2MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 
CORE_PEER_ADDRESS=peer0.org2.example.com:7051

peer channel update -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/Org2MSPanchors.tx --tls true --cafile $ORDERER_CA

5.链上代码的安装与运行

以上，整个 Fabric 网络和 Channel 都准备完毕，接下来我们来安装和运行 ChainCode。这里仍然以最出名的 Example02 为例。这个例子实现了 a，b 两个账户，相互之间可以转账。

5.1 Install ChainCode | 安装链上代码

链上代码的安装需要在各个相关的 Peer 上进行，对于我们现在这种 Fabric 网络，如果 4 个 Peer 都想对 Example02 进行操作，那么就需要安装 4 次。

仍然是保持在 CLI 的命令行下，我们先切换到 peer0.org1 这个节点：

CORE_PEER_LOCALMSPID="Org1MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp 
CORE_PEER_ADDRESS=peer0.org1.example.com:7051

使用 peer chaincode install 命令可以安装指定的 ChainCode 并对其命名：

peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02

安装成功，返回如下界面：

安装的过程其实就是对 CLI 中指定的代码进行编译打包，并把打包好的文件发送到 Peer，等待接下来的实例化。

其他节点由于暂时还没使用到，我们可以先不安装，等到了步骤 5.4 的时候再安装。

5.2 Instantiate ChainCode | 实例化链上代码

实例化链上代码主要是在 Peer 所在的机器上对前面安装好的链上代码进行包装，生成对应 Channel 的包含链码实例的 Docker 镜像和 Docker 容器。实例化之后，智能合约会与 Orderer 节点进行交互，生成配置交易区块，并同步到区块链网络之中。

在实例化时我们可以指定背书策略。我们运行以下命令完成实例化：

peer chaincode instantiate -o orderer.example.com:7050 --tls true --cafile $ORDERER_CA -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"

我们回到 Ubuntu 终端，使用 docker ps 可以看到有新的容器正在运行：

用下面这条命令调用链码查询数据

peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'

返回结果：Query Result: 100

接下来我们可以试着把 a 账户的 10 元转给 b。对应的代码：

peer chaincode invoke -o orderer.example.com:7050  --tls true --cafile $ORDERER_CA -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'

交易执行成功，返回：

5.4 在另一个节点上查询交易

前面的操作都是在 org1 下面做的，那么处于同一个区块链（同一个 Channel 下）的 org2，是否会看到 org1 的更改呢？我们试着给 peer0.org2 安装链上代码：

CORE_PEER_LOCALMSPID="Org2MSP" 
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 
CORE_PEER_ADDRESS=peer0.org2.example.com:7051

peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02

由于 mycc 已经在前面 org1 的时候实例化了，也就是说对应的区块已经生成了，所以在 org2 不能再次初始化。我们直接运行查询命令：

peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'

这个时候我们发现运行该命令返回结果是：

Query Result: 90

运行 docker ps ,发现了一个新的容器在运行：

5.5 链码容器变化情况。(该部分更新于 2018.12.20 日)

在对链码的操作过程中。虽然是指进行了一次实例化，但是对每个 Peer 节点，都进行了 install链码。在初次实例化的过程中，会生成一个运行链码的容器。但是，在安装的过程中，并没有生成相关的容器，这是为什么呢？因为链码安装好之后，需要对其进行调用，才能激活链码，生成运行链码的容器(如 invoke、query 等操作)。回顾下整个过程中，网络中 docker 数量的变化。

• 未安装，实例化链码之前，容器数量如下：

• peer0.org2 节点环境下，实例化链码，生成了一个容器

• 切换到 peer0.org1 节点环境下，安装链码，加入通道，并调用链码，生成第二个链码容器。

• 切换到 peer1.org1 节点环境下，安装链码，加入通道，并调用链码，生成第三个链码容器。

• 切换到 peer1.org1 节点环境下，安装链码，加入通道，并调用链码，生成第四个链码容器。

通过上面的实验结果，可以观察到安装链码与实例化链码的区别：

• 链码的实例化只需要一次
• 链码的安装针对每个背书节点，都需要安装一次。

这是因为，在实例化的过程中，需要将通道和 Orderer 节点之间建立通信联系。而安装的过程，是将链码打包发送到背书节点上，所以要保证一个背书节点安装一次链码。

a chaincode container is not started for a peer until an init or traditional transaction – read/write – is performed against that chaincode (e.g. query for the value of “a”).

5.6 关闭网络

关闭网络，可使用如下命令：

docker-compose -f docker-compose-cli.yaml down

总结

通过以上的分解，希望大家对 Fabric 环境的创建有了更深入的理解。这里的示例仍然是官方的示例，并没有什么太新的东西。只要把这每一步搞清楚，那么接下来我们在生产环境创建更多的 Org，创建大量的 Channel，执行各种 ChainCode 都是如出一辙。

在这个过程中，难免会出现一些意想不到的错误。很多原因都是因为环境不干净造成的。所以，如果实在碰到解决不了的办法，可以重新开一个虚拟机，从头开始，来试试。当然，如果你理解了 Docker，镜像，容器这些概念，会比较容易理解 Fabric 环境的搭建过程。

最后，如果理解了 Docker，Images 以及 Container 的关系，会更好的 Fabric 网络的运行原理。在这里推荐两篇简单介绍 Docker 的文章：

大白话 Docker 入门（一）-博客-云栖社区-阿里云

大白话 Docker 入门（二）-博客-云栖社区-阿里云

转自知乎 苏小乐 ：https://www.zhihu.com/people/shan-de-ding-zhu/activities

喜欢 (0)赏

[]

分享 (0)