本文详细介绍了Hyperledger Fabric网络的搭建流程，包括环境配置、获取源码、编译安装、配置示例、启动网络等核心步骤。深入解析了生成组织结构、证书、配置文件的方法，以及启动Orderer和Peer节点的操作细节。
一、环境配置
1.安装Go语言环境
当然可以采用去golang.org网站下载go源码的方式进行编译安装，但这里是通过添加apt仓库ppa:gophers/archive的方式安装go，按下面步骤进行：
(1).adding ppa:gophers/archive to your system’s Software Sources
sudo add-apt-repository ppa:gophers/archive
sudo apt-get update
(2).安装go：
sudo apt-get install -y golang
(3).Set GOPATH and PATH
For Go to work properly, you need to set the following two environment variables:
Setup a go folder
mkdir -p ~/go; echo "export GOPATH=$HOME/go" >> ~/.bashrc
Update your path
echo "export PATH=$PATH:$HOME/go/bin:/usr/local/go/bin" >> ~/.bashrc
Read the environment variables into current session:
source ~/.bashrc
注意：
也可以下载源码进行编译安装，方法如下：
Go语言环境可以自行访问golang.org网站下载二进制压缩包安装。 注意不推荐通过包管理器安装， 版本往往比较旧。
如下载Go 1.10.4版本， 可以采用如下命令：
$ curl -O https://storage.googleapis.com/golang/go1.10.4.linux-amd64.tar.gz
下载完成后， 解压目录， 并移动到合适的位置（推荐为/usr/local下） ：
$ tar -xvf go1.10.4.linux-amd64.tar.gz
$ sudo mv go /usr/local
上述命令完成后记得配置GOPATH环境变量(GOPATH环境变量指定了你的go的工作空间位置)：
mkdir -p ~/gopath
export GOPATH=$HOME/gopath
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
此时， 可以通过go version命令验证安装是否成功：
$ go version
go version go1.8 linux/amd64
注意：
上面没有设置GOROOT环境变量，是因为实际上go会默认它是被安装到/usr/local目录下的。也可以将go安装到其他位置，但此时必须设置GOROOT环境变量来指出它所安装的位置。
例如将go安装到你的home目录下，你应当将以下命令添加到$HOME/.profile文件中
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
2.安装依赖包
编译Fabric相关代码， 需要一些依赖包， 可以通过如下命令安装：
sudo apt-get update \
&& apt-get install -y libsnappy-dev zlib1g-dev libbz2-dev libltdl-dev libtool
注意:
如果这里报 No space left on device 的错误，参考：https://blog.youkuaiyun.com/yzpbright/article/details/83414498 这篇文章解决
3.安装Docker
1.使用apt-get命令安装Docker容器:
$sudo apt-get install docker.io
2.查看Docker版本
$docker --version
y@ubuntu:/usr/local/bin$ docker --version
Docker version 17.12.1-ce, build 7390fc6
看到类似信息说明docker安装成功。
二、获取Fabric源码
首先， 将Fabric代码按照Go语言推荐方式进行存放， 在GOPATH目录下创建目录结构并切换到该目录，如下命令所示：
mkdir -p $GOPATH/src/github.com/hyperledger
cd $GOPATH/src/github.com/hyperledger
通过下面命令获取fabric项目源码(该项目源码包括fabric-peer和fabric-orderer)：
git clone https://gerrit.hyperledger.org/r/fabric
通过下面命令获取fabric-ca项目源码：
git clone https://gerrit.hyperledger.org/r/fabric-ca
三、编译安装
编译安装fabric-peer组件
通过如下命令手动编译并安装fabric-peer到$GOPATH/bin下。 目前fabric处于1.0.0大版
本阶段， 因此指定相关版本号为1.0.0：
$ cd $GOPATH/src/github.com/hyperledger/fabric
$ ARCH=x86_64
$ BASEIMAGE_RELEASE=0.3.1
$ PROJECT_VERSION=1.0.0
$ LD_FLAGS="-X github.com/hyperledger/fabric/common/metadata.Version=${PROJECT_VERSION} \
-X github.com/hyperledger/fabric/common/metadata.BaseVersion=${BASEIMAGE_RELEASE} \
-X github.com/hyperledger/fabric/common/metadata.BaseDockerLabel=org.hyperledger.fabric \
-X github.com/hyperledger/fabric/common/metadata.DockerNamespace=hyperledger \
-X github.com/hyperledger/fabric/common/metadata.BaseDockerNamespace=hyperledger"
$ CGO_CFLAGS=" " go install -ldflags "$LD_FLAGS -linkmode external -extldflags
'-static -lpthread'" github.com/hyperledger/fabric/peer
当然， 用户也可以使用源码中的Makefile来进行编译。 这种方式下， 需要自动从
DockerHub上获取包括基础镜像在内的依赖文件， 花费时间可能稍长。 相关命令如下所
示：
$ cd $GOPATH/src/github.com/hyperledger/fabric
$ make peer
编译安装fabric-orderer组件
通过如下命令手动编译并安装fabric-orderer到$GOPATH/bin下：
$ cd $GOPATH/src/github.com/hyperledger/fabric
$ ARCH=x86_64
$ BASEIMAGE_RELEASE=0.3.1
$ PROJECT_VERSION=1.0.0
$ LD_FLAGS="-X github.com/hyperledger/fabric/common/metadata.Version=${PROJECT_VERSION} \
-X github.com/hyperledger/fabric/common/metadata.BaseVersion=${BASEIMAGE_RELEASE} \
-X github.com/hyperledger/fabric/common/metadata.BaseDockerLabel=org.hyperledger.fabric \
-X github.com/hyperledger/fabric/common/metadata.DockerNamespace=hyperledger \
-X github.com/hyperledger/fabric/common/metadata.BaseDockerNamespace=hyperledger"
$ CGO_CFLAGS=" " go install -ldflags "$LD_FLAGS -linkmode external -extldflags
'-static -lpthread'" github.com/hyperledger/fabric/orderer
同样， 使用源码中的Makefile来进行编译的命令如下：
$ cd $GOPATH/src/github.com/hyperledger/fabric
$ make orderer
编译安装fabric-ca组件
可以通过如下命令编译并安装fabric-ca相关组件到$GOPATH/bin下：
$ go install -ldflags " -linkmode external -extldflags '-static -lpthread'" github.com/hyperledger/fabric-ca/cmd/...
编译安装辅助工具
Fabric中提供了一系列辅助工具， 包括cryptogen（生成组织结构和身份文件） 、configtxgen（生成配置区块和配置交易） 、 configtxlator（解读配置信息） 等， 可以通过如下命令快速编译和安装：
# 编译安装 cryptogen
$ PROJECT_VERSION=1.0.0
$ CGO_CFLAGS=" " go install -tags "" -ldflags "-X github.com/hyperledger/fabric/common/tools/cryptogen/metadata.Version=${PROJECT_VERSION}" github.com/hyperledger/fabric/common/tools/cryptogen
# 编译安装 configtxgen
$ PROJECT_VERSION=1.0.0
$ CGO_CFLAGS=" " go install -tags "nopkcs11" -ldflags "-X github.com/hyperledger/fabric/common/configtx/tool/configtxgen/metadata.Version=${PROJECT_VERSION}" github.com/hyperledger/fabric/common/tools/configtxgen
# 编译安装 configtxlator
$ PROJECT_VERSION=1.0.0
$ CGO_CFLAGS=" " go install -tags "" -ldflags "-X github.com/hyperledger/fabric/common/tools/configtxlator/metadata.Version=${PROJECT_VERSION}" github.com/hyperledger/fabric/common/tools/configtxlator
当然也可进入到fabric根目录下，然后执行下面的make命令分别安装上述3个工具：
$ cd $GOPATH/src/github.com/hyperledger/fabric
$ make cryptogen
$ make configtxgen
$ make configtxlator
下面是上面3条make命令的执行结果：
root@local:~/go/src/github.com/hyperledger/fabric# make cryptogen
find: ‘/src/github.com/hyperledger/fabric/core/chaincode/shim’: No such file or directory
.build/bin/cryptogen
CGO_CFLAGS=" " GOBIN=/root/go/src/github.com/hyperledger/fabric/.build/bin go install -tags "" -ldflags "-X github.com/hyperledger/fabric/common/tools/cryptogen/metadata.CommitSHA=29db16685" github.com/hyperledger/fabric/common/tools/cryptogen
Binary available as .build/bin/cryptogen
root@local:~/go/src/github.com/hyperledger/fabric# make configtxgen
find: ‘/src/github.com/hyperledger/fabric/core/chaincode/shim’: No such file or directory
.build/bin/configtxgen
CGO_CFLAGS=" " GOBIN=/root/go/src/github.com/hyperledger/fabric/.build/bin go install -tags "" -ldflags "-X github.com/hyperledger/fabric/common/tools/configtxgen/metadata.CommitSHA=29db16685" github.com/hyperledger/fabric/common/tools/configtxgen
Binary available as .build/bin/configtxgen
root@local:~/go/src/github.com/hyperledger/fabric# make configtxlator
find: ‘/src/github.com/hyperledger/fabric/core/chaincode/shim’: No such file or directory
.build/bin/configtxlator
CGO_CFLAGS=" " GOBIN=/root/go/src/github.com/hyperledger/fabric/.build/bin go install -tags "" -ldflags "-X github.com/hyperledger/fabric/common/tools/configtxlator/metadata.CommitSHA=29db16685" github.com/hyperledger/fabric/common/tools/configtxlator
Binary available as .build/bin/configtxlator
root@local:~/go/src/github.com/hyperledger/fabric#
获取chaintool并安装
(chaintool项目地址：https://github.com/hyperledger/fabric-chaintool)
chaintool可以协助用户对链码进行打包和部署， 方便链码的开发测试， 用户可以通过如下命令进行快速安装：
$ curl -L https://github.com/hyperledger/fabric-chaintool/releases/download/v0.10.3/chaintool > /usr/local/bin/chaintool
$ chmod a+x /usr/local/bin/chaintool
安装Go语言相关工具
Fabric代码由Go语言构建， 开发者可以选择安装如下的Go语言相关工具， 以方便开发和调试：
go get github.com/golang/protobuf/protoc-gen-go \
&& go get github.com/kardianos/govendor \
&& go get github.com/golang/lint/golint \
&& go get golang.org/x/tools/cmd/goimports \
&& go get github.com/onsi/ginkgo/ginkgo \
&& go get github.com/axw/gocov/... \
&& go get github.com/client9/misspell/cmd/misspell \
&& go get github.com/AlekSi/gocov-xm
四、配置
示例配置
sampleconfig 目录下包括了一些示例配置文件， 可以作为参考基础进行编写。 将它们复制到默认的配置目录（/etc/hyperledger/fabric） 下：
cd $GOPATH/src/github.com/hyperledger/fabric/sampleconfig
cp configtx.yaml /etc/hyperledger/fabric
cp core.yaml /etc/hyperledger/fabric
cp orderer.yaml /etc/hyperledger/fabric
cp msp/config.yaml /etc/hyperledger/fabric
五、启动Fabric网络
启动Fabric网络是一个比较复杂的过程， 主要步骤包括规划拓扑、 准备相关配置文件、 启动Orderer节点、 启动Peer节点和操作网络等。 这里以Fabric代码中自带的示例为基础讲解相关的操作步骤。
5.1.网络拓扑
启动的Fabric网络中包括一个Orderer节点和四个Peer节点， 以及一个管理节点生成相关启动文件， 在网络启动后作为操作客户端执行命令。
四个Peer节点分属于同一个管理域（example.com） 下的两个组织Org1和Org2， 这两个组织都加入同一个应用通道（business-channel） 中。 每个组织中的第一个节点（peer0节点） 作为锚节点与其他组织进行通信， 所有节点通过域名都可以相互访问， 整体网络拓扑如图9-2所示。
5.2.准备相关配置文件
1.生成组织关系和身份证书
Fabric网络提供的是联盟链服务， 联盟由多个组织构成。Fabric项目提供了cryptogen工具（基于crypto标准库） 实现自动化生成联盟链的各成员的证书和私钥。 这一过程首先依赖crypto-config.yaml配置文件。
crypto-config.yaml配置文件可以参考官方的：https://github.com/hyperledger/fabric-samples/blob/release-1.3/first-network/crypto-config.yaml ，当然也可以通过命令:cryptogen showtemplate >> crypto-config.yaml 来新生成一份
使用下面的crypto-config.yaml配置文件(就是把 https://github.com/hyperledger/fabric-samples/blob/release-1.3/first-network/crypto-config.yaml 这份配置文件去掉了注释)：
OrdererOrgs:
- Name: Orderer
Domain: example.com
Specs:
- Hostname: orderer
PeerOrgs:
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
使用该配置文件， 通过如下命令可以为Fabric网络生成指定拓扑结构的组织和身份文件， 存放到crypto-config目录下：
cryptogen generate --config=./crypto-config.yaml --output ./crypto-config
执行结果：
root@local:~/go/src/github.com/hyperledger# cryptogen generate --config=./crypto-config.yaml --output ./crypto-config
org1.example.com
org2.example.com
查看crypto-config目录结构， 的确是按照示例crypto-config.yaml中的定义进行生成：
root@local:~/go/src/github.com/hyperledger# tree -L 4 crypto-config
crypto-config
├── ordererOrganizations
│ └── example.com
│ ├── ca
│ │ ├── bf005dda5e41011d3b045cfa1bcdf69438f9225fff26cef069db71a2ef4164d6_sk
│ │ └── ca.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ └── tlscacerts
│ ├── orderers
│ │ └── orderer.example.com
│ ├── tlsca
│ │ ├── 11b1c495239eb0e4a62288e7fae8768214feae27d68d17f95a2e4abd61871fa5_sk
│ │ └── tlsca.example.com-cert.pem
│ └── users
│ └── Admin@example.com
└── peerOrganizations
├── org1.example.com
│ ├── ca
│ │ ├── 2ebe206774b36810d9034e6155d7be25c1db3c43fabd6817ba1dfdb951279fb5_sk
│ │ └── ca.org1.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ ├── config.yaml
│ │ └── tlscacerts
│ ├── peers
│ │ ├── peer0.org1.example.com
│ │ └── peer1.org1.example.com
│ ├── tlsca
│ │ ├── fb3c765d6837d8edfc5c2cccc459622bd8d72895ac025cd626c9eaef16073566_sk
│ │ └── tlsca.org1.example.com-cert.pem
│ └── users
│ ├── Admin@org1.example.com
│ └── User1@org1.example.com
└── org2.example.com
├── ca
│ ├── ca.org2.example.com-cert.pem
│ └── d907339c6507847b2853e8c3bc0e6fccd2cfe14537263d46db91a2b3a344039b_sk
├── msp
│ ├── admincerts
│ ├── cacerts
│ ├── config.yaml
│ └── tlscacerts
├── peers
│ ├── peer0.org2.example.com
│ └── peer1.org2.example.com
├── tlsca
│ ├── 99ad394bd266090c467ebe546b4117b788f37c33e45d9fda71fb273e681c5c3e_sk
│ └── tlsca.org2.example.com-cert.pem
└── users
├── Admin@org2.example.com
└── User1@org2.example.com
39 directories, 14 files
root@local:~/go/src/github.com/hyperledger#
对于Orderer节点来说， 需要将crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com目录下的内容（包括msp和tls两个子目录） 复制到Orderer节点的/etc/hyperledger/fabric路径（与Orderer自身配置一致） 下。
操作：
因为总共只有3台节点服务器，所以我操作时是在Orderer节点(ip为：10.10.81.63)生成crypto-config目录的，即把Orderer节点也当做客户端管理节点，所以直接拷贝到本机的/etc/hyperledger/fabric目录即可：
cp -r crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/. /etc/hyperledger/fabric
对于Peer节点来说， 则需要复制peerOrganizations下对应的身份证书文件。 以org1的peer0为例， 将
crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com目录下的内容（包
括msp和tls） 复制到Peer0节点的/etc/hyperledger/fabric（与Peer自身配置一致） 路径下。
操作:
10.10.81.64和10.10.81.65这两个节点分别作为org1的peer0节点和org2的peer0节点。
在10.10.81.64 这台机子上执行
mkdir -p /etc/hyperledger/fabric
scp -r root@10.10.81.63:/root/go/src/github.com/hyperledger/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/. /etc/hyperledger/fabric
在10.10.81.65 这台机子上执行
mkdir -p /etc/hyperledger/fabric
scp -r root@10.10.81.63:/root/go/src/github.com/hyperledger/crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/. /etc/hyperledger/fabric
对于客户端节点来说， 为了方便操作， 可将完整的crypto-config目录复制到/etc/hyperledger/fabric（与configtx.yaml中配置一致） 路径下。
操作：
root@local:~/go/src/github.com/hyperledger# ls -l
total 16
drwxr-xr-x 4 root root 4096 Nov 23 08:30 crypto-config
-rw-r--r-- 1 root root 352 Nov 23 08:29 crypto-config.yaml
drwxr-xr-x 27 root root 4096 Nov 23 08:17 fabric
drwxr-xr-x 17 root root 4096 Nov 21 12:40 fabric-ca
root@local:~/go/src/github.com/hyperledger# cp -r crypto-config /etc/hyperledger/fabric
2.生成Ordering服务启动初始区块
Orderer节点在启动时， 可以使用提前生成的初始区块文件作为系统通道的初始配置。 初始区块文件中包括了Ordering服务的相关配置信息以及联盟信息。 初始区块文件可以使用configtxgen工具进行生成。 生成过程需要依赖/etc/hyperledger/fabric/configtx.yaml文件。configtx.yaml配置文件定义了整个网络中的相关配置和拓扑结构信息。
编写configtx.yaml配置文件，可以参考Fabric代码中（如examples/e2e_cli路径下 或 sampleconfig路径下） 的示例。 这里采用如下内容进行生成：
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
AnchorPeers:
- Host: peer0.org1.example.com
Port: 7051
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
AnchorPeers:
- Host: peer0.org2.example.com
Port: 7051
Application: &ApplicationDefaults
Organizations:
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 98 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Profiles:
TwoOrgsOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
该配置文件定义了两个模板： TwoOrgsOrdererGenesis和TwoOrgsChannel， 其中前者可以用来生成Ordering服务的初始区块文件。
通过如下命令指定使用configtx.yaml文件中定义的TwoOrgsOrdererGenesis模板， 来生成Ordering服务系统通道的初始区块文件。 注意这里排序服务类型采用了简单的solo模式， 生产环境中可以采用kafka集群服务：
root@local:/etc/hyperledger/fabric# configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./orderer.genesis.block
2018-11-30 07:24:16.067 UTC [common.tools.configtxgen] main -> WARN 001 Omitting the channel ID for configtxgen for output operations is deprecated. Explicitly passing the channel ID will be required in the future, defaulting to 'testchainid'.
2018-11-30 07:24:16.067 UTC [common.tools.configtxgen] main -> INFO 002 Loading configuration
2018-11-30 07:24:16.120 UTC [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 003 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2018-11-30 07:24:16.121 UTC [common.tools.configtxgen.encoder] NewOrdererGroup -> WARN 004 Default policy emission is deprecated, please include policy specifications for the orderer group in configtx.yaml
2018-11-30 07:24:16.155 UTC [common.tools.configtxgen.encoder] NewOrdererOrgGroup -> WARN 005 Default policy emission is deprecated, please include policy specifications for the orderer org group OrdererOrg in configtx.yaml
2018-11-30 07:24:16.213 UTC [common.tools.configtxgen.encoder] NewOrdererOrgGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the orderer org group Org1MSP in configtx.yaml
2018-11-30 07:24:16.228 UTC [common.tools.configtxgen.encoder] NewOrdererOrgGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the orderer org group Org2MSP in configtx.yaml
2018-11-30 07:24:16.229 UTC [common.tools.configtxgen] doOutputBlock -> INFO 008 Generating genesis block
2018-11-30 07:24:16.230 UTC [common.tools.configtxgen] doOutputBlock -> INFO 009 Writing genesis block
所生成的orderer.genesis.block需要复制到Orderer节点上（与Orderer配置中
ORDERER_GENERAL_GENESISFILE指定文件路径一致， 默认放到 /etc/hyperledger/fabric 路径下） ， 在启动Orderering服务时进行使用。
3.生成新建应用通道的配置交易
新建应用通道时， 需要事先准备好配置交易文件， 其中包括属于该通道的组织结构信息。 这些信息会写入该应用通道的初始区块中。
同样需要提前编写好configtx.yaml配置文件， 之后可以使用configtxgen工具来生成新建应用通道的配置交易文件。
为了后续命令使用方便， 将新建应用通道名称businesschannel复制到环境变量CHANNEL_NAME中：
root@local:/etc/hyperledger/fabric# CHANNEL_NAME=businesschannel
之后采用如下命令指定使用configtx.yaml配置文件中的TwoOrgsChannel模板， 来生成新建通道的配置交易文件。 TwoOrgsChannel模板指定了Org1和Org2都属于后面新建的应用通道：
root@local:/etc/hyperledger/fabric# configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./businesschannel.tx -channelID ${CHANNEL_NAME}
2018-11-30 08:42:59.110 UTC [common.tools.configtxgen] main -> INFO 001 Loading configuration
2018-11-30 08:42:59.128 UTC [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2018-11-30 08:42:59.128 UTC [common.tools.configtxgen.encoder] NewApplicationGroup -> WARN 003 Default policy emission is deprecated, please include policy specifications for the application group in configtx.yaml
2018-11-30 08:42:59.131 UTC [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 004 Default policy emission is deprecated, please include policy specifications for the application org group Org1MSP in configtx.yaml
2018-11-30 08:42:59.133 UTC [common.tools.configtxgen.encoder] NewApplicationOrgGroup -> WARN 005 Default policy emission is deprecated, please include policy specifications for the application org group Org2MSP in configtx.yaml
2018-11-30 08:42:59.134 UTC [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 006 Writing new channel tx
所生成的配置交易文件会在后续步骤被客户端使用， 因此可以放在客户端节点上。
4.生成锚节点配置更新文件
锚节点配置更新文件可以用来对组织的锚节点进行配置。
同样基于configtx.yaml配置文件， 可以通过如下命令使用configtxgen工具来生成锚节点配置更新文件。 每个组织都需要分别生成， 注意需要分别指定对应的组织名称：
root@local:/etc/hyperledger/fabric# configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./Org1MSPanchors.tx -channelID ${CHANNEL_NAME} -asOrg Org1MSP
2018-11-30 08:51:18.927 UTC [common.tools.configtxgen] main -> INFO 001 Loading configuration
2018-11-30 08:51:18.945 UTC [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2018-11-30 08:51:18.946 UTC [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update
root@local:/etc/hyperledger/fabric# configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./Org2MSPanchors.tx -channelID ${CHANNEL_NAME} -asOrg Org2MSP
2018-11-30 08:53:05.660 UTC [common.tools.configtxgen] main -> INFO 001 Loading configuration
2018-11-30 08:53:05.678 UTC [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2018-11-30 08:53:05.679 UTC [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update
所生成的锚节点配置更新文件会在后续步骤被客户端使用， 因此可以放在客户端节点上。
所有用于启动的配置文件生成并部署到对应节点后， 可以进行服务的启动操作， 首先要启动Orderer节点， 然后启动Peer节点。
5.3 启动Orderer节点
首先， 检查启动节点的所有配置是否就绪：
- 在/etc/hyperledger/fabric路径下放置有编写好的orderer.yaml（可以参考 sampleconfig/orderer.yaml 进行编写 ）；
- 在/etc/hyperledger/fabric路径下放置有生成的msp文件目录、 tls文件目录；
- 在/etc/hyperledger/fabric路径下放置有初始区块文件orderer.genesis.block
Orderer节点的默认配置文件中指定了简单的Orderer节点功能。
通常情况下， 在使用时根据需求往往要对其中一些关键配置进行指定。 表9-3总结了如何通过环境变量方式对这些关键配置进行更新。
表9-3 环境变量配置及其功能
参照上表，可以配置如下：
ORDERER_GENERAL_LOGLEVEL=INFO
ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
ORDERER_GENERAL_LISTENPORT=7050
ORDERER_GENERAL_GENESISMETHOD=file
ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/fabric/orderer.genesis.block
ORDERER_GENERAL_LOCALMSPID=OrdererMSP
ORDERER_GENERAL_LOCALMSPDIR=/etc/hyperledger/fabric/msp
配置完成后， 用户可以采用如下命令来快速启动一个本地Orderer节点(测试时我是在/etc/hyperledger/fabric下放置了order.yaml文件，因此这里我是修改order.yaml文件里的相应配置项)。 启动成功后可以看到本地输出的开始提供服务的消息， 此时Orderer采用指定的初始区块文件(orderer.genesis.block)创建了系统通道：
root@local:~/go/src/github.com/hyperledger/fabric/.build/bin# ./orderer start
2018-12-03 02:46:44.106 UTC [localconfig] completeInitialization -> INFO 001 Kafka.Version unset, setting to 0.10.2.0
2018-12-03 02:46:44.200 UTC [orderer.common.server] prettyPrintStruct -> INFO 002 Orderer config values:
General.LedgerType = "file"
General.ListenAddress = "127.0.0.1"
General.ListenPort = 7050
General.TLS.Enabled = false
General.TLS.PrivateKey = "/etc/hyperledger/fabric/tls/server.key"
General.TLS.Certificate = "/etc/hyperledger/fabric/tls/server.crt"
General.TLS.RootCAs = [/etc/hyperledger/fabric/tls/ca.crt]
General.TLS.ClientAuthRequired = false
General.TLS.ClientRootCAs = []
General.Cluster.RootCAs = [/etc/hyperledger/fabric/tls/ca.crt]
General.Cluster.ClientCertificate = ""
General.Cluster.ClientPrivateKey = ""
General.Cluster.DialTimeout = 5s
General.Cluster.RPCTimeout = 7s
General.Cluster.ReplicationBufferSize = 20971520
General.Cluster.ReplicationPullTimeout = 5s
General.Cluster.ReplicationRetryTimeout = 5s
General.Keepalive.ServerMinInterval = 1m0s
General.Keepalive.ServerInterval = 2h0m0s
General.Keepalive.ServerTimeout = 20s
General.GenesisMethod = "file"
General.GenesisProfile = "SampleInsecureSolo"
General.SystemChannel = "test-system-channel-name"
General.GenesisFile = "/etc/hyperledger/fabric/orderer.genesis.block"
General.Profile.Enabled = false
General.Profile.Address = "0.0.0.0:6060"
General.LocalMSPDir = "/etc/hyperledger/fabric/msp"
General.LocalMSPID = "OrdererMSP"
General.BCCSP.ProviderName = "SW"
General.BCCSP.SwOpts.SecLevel = 256
General.BCCSP.SwOpts.HashFamily = "SHA2"
General.BCCSP.SwOpts.Ephemeral = false
General.BCCSP.SwOpts.FileKeystore.KeyStorePath = "/etc/hyperledger/fabric/msp/keystore"
General.BCCSP.SwOpts.DummyKeystore =
General.BCCSP.SwOpts.InmemKeystore =
General.BCCSP.PluginOpts =
General.Authentication.TimeWindow = 15m0s
FileLedger.Location = "/var/hyperledger/production/orderer"
FileLedger.Prefix = "hyperledger-fabric-ordererledger"
RAMLedger.HistorySize = 1000
Kafka.Retry.ShortInterval = 5s
Kafka.Retry.ShortTotal = 10m0s
Kafka.Retry.LongInterval = 5m0s
Kafka.Retry.LongTotal = 12h0m0s
Kafka.Retry.NetworkTimeouts.DialTimeout = 10s
Kafka.Retry.NetworkTimeouts.ReadTimeout = 10s
Kafka.Retry.NetworkTimeouts.WriteTimeout = 10s
Kafka.Retry.Metadata.RetryMax = 3
Kafka.Retry.Metadata.RetryBackoff = 250ms
Kafka.Retry.Producer.RetryMax = 3
Kafka.Retry.Producer.RetryBackoff = 100ms
Kafka.Retry.Consumer.RetryBackoff = 2s
Kafka.Verbose = false
Kafka.Version = 0.10.2.0
Kafka.TLS.Enabled = false
Kafka.TLS.PrivateKey = ""
Kafka.TLS.Certificate = ""
Kafka.TLS.RootCAs = []
Kafka.TLS.ClientAuthRequired = false
Kafka.TLS.ClientRootCAs = []
Kafka.SASLPlain.Enabled = false
Kafka.SASLPlain.User = ""
Kafka.SASLPlain.Password = ""
Kafka.Topic.ReplicationFactor = 3
Debug.BroadcastTraceDir = ""
Debug.DeliverTraceDir = ""
Consensus = map[WALDir:/var/hyperledger/production/orderer/etcdraft/wal SnapDir:/var/hyperledger/production/orderer/etcdraft/snapshot]
Operations.ListenAddress = ""
Operations.Metrics.Provider = ""
Operations.Metrics.Statsd.Network = ""
Operations.Metrics.Statsd.Address = ""
Operations.Metrics.Statsd.WriteInterval = 0s
Operations.Metrics.Statsd.Prefix = ""
Operations.Metrics.Prometheus.HandlerPath = ""
Operations.TLS.Enabled = false
Operations.TLS.PrivateKey = ""
Operations.TLS.Certificate = ""
Operations.TLS.RootCAs = []
Operations.TLS.ClientAuthRequired = false
Operations.TLS.ClientRootCAs = []
2018-12-03 02:46:44.248 UTC [orderer.operations] initializeMetricsProvider -> WARN 003 Unknown provider type: ; metrics disabled
2018-12-03 02:46:44.391 UTC [fsblkstorage] newBlockfileMgr -> INFO 004 Getting block information from block storage
2018-12-03 02:46:44.503 UTC [orderer.commmon.multichannel] Initialize -> INFO 005 Starting system channel 'testchainid' with genesis block hash 1713e8c32c6d25c677c45d797fff333c85813987a2c863d5e2d12955ff353214 and orderer type solo
2018-12-03 02:46:44.503 UTC [orderer.common.server] Start -> INFO 006 Starting orderer:
Version: 1.4.0
Commit SHA: 29db16685
Go version: go1.10.4
OS/Arch: linux/amd64
2018-12-03 02:46:44.505 UTC [orderer.common.server] Start -> INFO 007 Beginning to serve requests
可以看到最后的log输出：Beginning to serve requests，说明Orderer节点启动成功了。
注意：orderer 启动的时候会查找一个名为 orderer.yaml 的配置文件，但这个配置文件不是必须的，在找不到这个配置文件时，orderer 命令会使用默认配置。我们也可以通过环境变量或命令行参数的方式去对默认配置的每个配置项进行覆盖。
5.4 启动Peer节点
首先， 检查启动所有Peer节点的所有配置是否就绪：
- 在/etc/hyperledger/fabric路径下放置有对应编写好的core.yaml（可以参考sampleconfig/core.yaml）
- 在/etc/hyperledger/fabric路径下放置生成的对应msp文件目录、 tls文件目录。
测试时使用的core.yaml文件的内容如下：
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
###############################################################################
#
# Peer section
#
###############################################################################
peer:
# The Peer id is used for identifying this Peer instance.
id: peer0.org1.example.com
# The networkId allows for logical seperation of networks
networkId: dev
# The Address at local network interface this Peer will listen on.
# By default, it will listen on all network interfaces
listenAddress: 0.0.0.0:7051
# The endpoint this peer uses to listen for inbound chaincode connections.
# If this is commented-out, the listen address is selected to be
# the peer's address (see below) with port 7052
# chaincodeListenAddress: 0.0.0.0:7052
# The endpoint the chaincode for this peer uses to connect to the peer.
# If this is not specified, the chaincodeListenAddress address is selected.
# And if chaincodeListenAddress is not specified, address is selected from
# peer listenAddress.
# chaincodeAddress: 0.0.0.0:7052
# When used as peer config, this represents the endpoint to other peers
# in the same organization. For peers in other organization, see
# gossip.externalEndpoint for more info.
# When used as CLI config, this means the peer's endpoint to interact with
address: 0.0.0.0:7051
# Whether the Peer should programmatically determine its address
# This case is useful for docker containers.
addressAutoDetect: false
# Setting for runtime.GOMAXPROCS(n). If n < 1, it does not change the
# current setting
gomaxprocs: -1
# Keepalive settings for peer server and clients
keepalive:
# MinInterval is the minimum permitted time between client pings.
# If clients send pings more frequently, the peer server will
# disconnect them
minInterval: 60s
# Client keepalive settings for communicating with other peer nodes
client:
# Interval is the time between pings to peer nodes. This must
# greater than or equal to the minInterval specified by peer
# nodes
interval: 60s
# Timeout is the duration the client waits for a response from
# peer nodes before closing the connection
timeout: 20s
# DeliveryClient keepalive settings for communication with ordering
# nodes.
deliveryClient:
# Interval is the time between pings to ordering nodes. This must
# greater than or equal to the minInterval specified by ordering
# nodes.
interval: 60s
# Timeout is the duration the client waits for a response from
# ordering nodes before closing the connection
timeout: 20s
# Gossip related configuration
gossip:
# Bootstrap set to initialize gossip with.
# This is a list of other peers that this peer reaches out to at startup.
# Important: The endpoints here have to be endpoints of peers in the same
# organization, because the peer would refuse connecting to these endpoints
# unless they are in the same organization as the peer.
bootstrap: 127.0.0.1:7051
# NOTE: orgLeader and useLeaderElection parameters are mutual exclusive.
# Setting both to true would result in the termination of the peer
# since this is undefined state. If the peers are configured with
# useLeaderElection=false, make sure there is at least 1 peer in the
# organization that its orgLeader is set to true.
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
# Overrides the endpoint that the peer publishes to peers
# in its organization. For peers in foreign organizations
# see 'externalEndpoint'
endpoint:
# Maximum count of blocks stored in memory
maxBlockCountToStore: 100
# Max time between consecutive message pushes(unit: millisecond)
maxPropagationBurstLatency: 10ms
# Max number of messages stored until a push is triggered to remote peers
maxPropagationBurstSize: 10
# Number of times a message is pushed to remote peers
propagateIterations: 1
# Number of peers selected to push messages to
propagatePeerNum: 3
# Determines frequency of pull phases(unit: second)
# Must be greater than digestWaitTime + responseWaitTime
pullInterval: 4s
# Number of peers to pull from
pullPeerNum: 3
# Determines frequency of pulling state info messages from peers(unit: second)
requestStateInfoInterval: 4s
# Determines frequency of pushing state info messages to peers(unit: second)
publishStateInfoInterval: 4s
# Maximum time a stateInfo message is kept until expired
stateInfoRetentionInterval:
# Time from startup certificates are included in Alive messages(unit: second)
publishCertPeriod: 10s
# Should we skip verifying block messages or not (currently not in use)
skipBlockVerification: false
# Dial timeout(unit: second)
dialTimeout: 3s
# Connection timeout(unit: second)
connTimeout: 2s
# Buffer size of received messages
recvBuffSize: 20
# Buffer size of sending messages
sendBuffSize: 200
# Time to wait before pull engine processes incoming digests (unit: second)
# Should be slightly smaller than requestWaitTime
digestWaitTime: 1s
# Time to wait before pull engine removes incoming nonce (unit: milliseconds)
# Should be slightly bigger than digestWaitTime
requestWaitTime: 1500ms
# Time to wait before pull engine ends pull (unit: second)
responseWaitTime: 2s
# Alive check interval(unit: second)
aliveTimeInterval: 5s
# Alive expiration timeout(unit: second)
aliveExpirationTimeout: 25s
# Reconnect interval(unit: second)
reconnectInterval: 25s
# This is an endpoint that is published to peers outside of the organization.
# If this isn't set, the peer will not be known to other organizations.
externalEndpoint: peer0.org1.example.com:7051
# Leader election service configuration
election:
# Longest time peer waits for stable membership during leader election startup (unit: second)
startupGracePeriod: 15s
# Interval gossip membership samples to check its stability (unit: second)
membershipSampleInterval: 1s
# Time passes since last declaration message before peer decides to perform leader election (unit: second)
leaderAliveThreshold: 10s
# Time between peer sends propose message and declares itself as a leader (sends declaration message) (unit: second)
leaderElectionDuration: 5s
pvtData:
# pullRetryThreshold determines the maximum duration of time private data corresponding for a given block
# would be attempted to be pulled from peers until the block would be committed without the private data
pullRetryThreshold: 60s
# As private data enters the transient store, it is associated with the peer's ledger's height at that time.
# transientstoreMaxBlockRetention defines the maximum difference between the current ledger's height upon commit,
# and the private data residing inside the transient store that is guaranteed not to be purged.
# Private data is purged from the transient store when blocks with sequences that are multiples
# of transientstoreMaxBlockRetention are committed.
transientstoreMaxBlockRetention: 1000
# pushAckTimeout is the maximum time to wait for an acknowledgement from each peer
# at private data push at endorsement time.
pushAckTimeout: 3s
# Block to live pulling margin, used as a buffer
# to prevent peer from trying to pull private data
# from peers that is soon to be purged in next N blocks.
# This helps a newly joined peer catch up to current
# blockchain height quicker.
btlPullMargin: 10
# the process of reconciliation is done in an endless loop, while in each iteration reconciler tries to
# pull from the other peers the most recent missing blocks with a maximum batch size limitation.
# reconcileBatchSize determines the maximum batch size of missing private data that will be reconciled in a
# single iteration.
reconcileBatchSize: 10
# reconcileSleepInterval determines the time reconciler sleeps from end of an iteration until the beginning
# of the next reconciliation iteration.
reconcileSleepInterval: 5m
# TLS Settings
# Note that peer-chaincode connections through chaincodeListenAddress is
# not mutual TLS auth. See comments on chaincodeListenAddress for more info
tls:
# Require server-side TLS
enabled: false
# Require client certificates / mutual TLS.
# Note that clients that are not configured to use a certificate will
# fail to connect to the peer.
clientAuthRequired: false
# X.509 certificate used for TLS server
cert:
file: tls/server.crt
# Private key used for TLS server (and client if clientAuthEnabled
# is set to true
key:
file: tls/server.key
# Trusted root certificate chain for tls.cert
rootcert:
file: tls/ca.crt
# Set of root certificate authorities used to verify client certificates
clientRootCAs:
files:
- tls/ca.crt
# Private key used for TLS when making client connections. If
# not set, peer.tls.key.file will be used instead
clientKey:
file:
# X.509 certificate used for TLS when making client connections.
# If not set, peer.tls.cert.file will be used instead
clientCert:
file:
# Authentication contains configuration parameters related to authenticating
# client messages
authentication:
# the acceptable difference between the current server time and the
# client's time as specified in a client request message
timewindow: 15m
# Path on the file system where peer will store data (eg ledger). This
# location must be access control protected to prevent unintended
# modification that might corrupt the peer operations.
fileSystemPath: /var/hyperledger/production
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
# Settings for the SW crypto provider (i.e. when DEFAULT: SW)
SW:
# TODO: The default Hash and Security level needs refactoring to be
# fully configurable. Changing these defaults requires coordination
# SHA2 is hardcoded in several places, not only BCCSP
Hash: SHA2
Security: 256
# Location of Key Store
FileKeyStore:
# If "", defaults to 'mspConfigPath'/keystore
KeyStore:
# Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11)
PKCS11:
# Location of the PKCS11 module library
Library:
# Token Label
Label:
# User PIN
Pin:
Hash:
Security:
FileKeyStore:
KeyStore:
# Path on the file system where peer will find MSP local configurations
mspConfigPath: msp
# Identifier of the local MSP
# ----!!!!IMPORTANT!!!-!!!IMPORTANT!!!-!!!IMPORTANT!!!!----
# Deployers need to change the value of the localMspId string.
# In particular, the name of the local MSP ID of a peer needs
# to match the name of one of the MSPs in each of the channel
# that this peer is a member of. Otherwise this peer's messages
# will not be identified as valid by other nodes.
localMspId: Org1MSP
# CLI common client config options
client:
# connection timeout
connTimeout: 3s
# Delivery service related config
deliveryclient:
# It sets the total time the delivery service may spend in reconnection
# attempts until its retry logic gives up and returns an error
reconnectTotalTimeThreshold: 3600s
# It sets the delivery service <-> ordering service node connection timeout
connTimeout: 3s
# It sets the delivery service maximal delay between consecutive retries
reConnectBackoffThreshold: 3600s
# Type for the local MSP - by default it's of type bccsp
localMspType: bccsp
# Used with Go profiling tools only in none production environment. In
# production, it should be disabled (eg enabled: false)
profile:
enabled: false
listenAddress: 0.0.0.0:6060
# The admin service is used for administrative operations such as
# control over logger levels, etc.
# Only peer administrators can use the service.
adminService:
# The interface and port on which the admin server will listen on.
# If this is commented out, or the port number is equal to the port
# of the peer listen address - the admin service is attached to the
# peer's service (defaults to 7051).
#listenAddress: 0.0.0.0:7055
# Handlers defines custom handlers that can filter and mutate
# objects passing within the peer, such as:
# Auth filter - reject or forward proposals from clients
# Decorators - append or mutate the chaincode input passed to the chaincode
# Endorsers - Custom signing over proposal response payload and its mutation
# Valid handler definition contains:
# - A name which is a factory method name defined in
# core/handlers/library/library.go for statically compiled handlers
# - library path to shared object binary for pluggable filters
# Auth filters and decorators are chained and executed in the order that
# they are defined. For example:
# authFilters:
# -
# name: FilterOne
# library: /opt/lib/filter.so
# -
# name: FilterTwo
# decorators:
# -
# name: DecoratorOne
# -
# name: DecoratorTwo
# library: /opt/lib/decorator.so
# Endorsers are configured as a map that its keys are the endorsement system chaincodes that are being overridden.
# Below is an example that overrides the default ESCC and uses an endorsement plugin that has the same functionality
# as the default ESCC.
# If the 'library' property is missing, the name is used as the constructor method in the builtin library similar
# to auth filters and decorators.
# endorsers:
# escc:
# name: DefaultESCC
# library: /etc/hyperledger/fabric/plugin/escc.so
handlers:
authFilters:
-
name: DefaultAuth
-
name: ExpirationCheck # This filter checks identity x509 certificate expiration
decorators:
-
name: DefaultDecorator
endorsers:
escc:
name: DefaultEndorsement
library:
validators:
vscc:
name: DefaultValidation
library:
# library: /etc/hyperledger/fabric/plugin/escc.so
# Number of goroutines that will execute transaction validation in parallel.
# By default, the peer chooses the number of CPUs on the machine. Set this
# variable to override that choice.
# NOTE: overriding this value might negatively influence the performance of
# the peer so please change this value only if you know what you're doing
validatorPoolSize:
# The discovery service is used by clients to query information about peers,
# such as - which peers have joined a certain channel, what is the latest
# channel config, and most importantly - given a chaincode and a channel,
# what possible sets of peers satisfy the endorsement policy.
discovery:
enabled: true
# Whether the authentication cache is enabled or not.
authCacheEnabled: true
# The maximum size of the cache, after which a purge takes place
authCacheMaxSize: 1000
# The proportion (0 to 1) of entries that remain in the cache after the cache is purged due to overpopulation
authCachePurgeRetentionRatio: 0.75
# Whether to allow non-admins to perform non channel scoped queries.
# When this is false, it means that only peer admins can perform non channel scoped queries.
orgMembersAllowedAccess: false
###############################################################################
#
# VM section
#
###############################################################################
vm:
# Endpoint of the vm management system. For docker can be one of the following in general
# unix:///var/run/docker.sock
# http://localhost:2375
# https://localhost:2376
endpoint: unix:///var/run/docker.sock
# settings for docker vms
docker:
tls:
enabled: false
ca:
file: docker/ca.crt
cert:
file: docker/tls.crt
key:
file: docker/tls.key
# Enables/disables the standard out/err from chaincode containers for
# debugging purposes
attachStdout: false
# Parameters on creating docker container.
# Container may be efficiently created using ipam & dns-server for cluster
# NetworkMode - sets the networking mode for the container. Supported
# standard values are: `host`(default),`bridge`,`ipvlan`,`none`.
# Dns - a list of DNS servers for the container to use.
# Note: `Privileged` `Binds` `Links` and `PortBindings` properties of
# Docker Host Config are not supported and will not be used if set.
# LogConfig - sets the logging driver (Type) and related options
# (Config) for Docker. For more info,
# https://docs.docker.com/engine/admin/logging/overview/
# Note: Set LogConfig using Environment Variables is not supported.
hostConfig:
NetworkMode: host
Dns:
# - 192.168.0.1
LogConfig:
Type: json-file
Config:
max-size: "50m"
max-file: "5"
Memory: 2147483648
###############################################################################
#
# Chaincode section
#
###############################################################################
chaincode:
# The id is used by the Chaincode stub to register the executing Chaincode
# ID with the Peer and is generally supplied through ENV variables
# the `path` form of ID is provided when installing the chaincode.
# The `name` is used for all other requests and can be any string.
id:
path:
name:
# Generic builder environment, suitable for most chaincode types
builder: $(DOCKER_NS)/fabric-ccenv:latest
# Enables/disables force pulling of the base docker images (listed below)
# during user chaincode instantiation.
# Useful when using moving image tags (such as :latest)
pull: false
golang:
# golang will never need more than baseos
runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION)
# whether or not golang chaincode should be linked dynamically
dynamicLink: false
car:
# car may need more facilities (JVM, etc) in the future as the catalog
# of platforms are expanded. For now, we can just use baseos
runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION)
java:
# This is an image based on java:openjdk-8 with addition compiler
# tools added for java shim layer packaging.
# This image is packed with shim layer libraries that are necessary
# for Java chaincode runtime.
runtime: $(DOCKER_NS)/fabric-javaenv:$(ARCH)-$(PROJECT_VERSION)
node:
# need node.js engine at runtime, currently available in baseimage
# but not in baseos
runtime: $(BASE_DOCKER_NS)/fabric-baseimage:$(ARCH)-$(BASE_VERSION)
# Timeout duration for starting up a container and waiting for Register
# to come through. 1sec should be plenty for chaincode unit tests
startuptimeout: 300s
# Timeout duration for Invoke and Init calls to prevent runaway.
# This timeout is used by all chaincodes in all the channels, including
# system chaincodes.
# Note that during Invoke, if the image is not available (e.g. being
# cleaned up when in development environment), the peer will automatically
# build the image, which might take more time. In production environment,
# the chaincode image is unlikely to be deleted, so the timeout could be
# reduced accordingly.
executetimeout: 30s
# There are 2 modes: "dev" and "net".
# In dev mode, user runs the chaincode after starting peer from
# command line on local machine.
# In net mode, peer will run chaincode in a docker container.
mode: net
# keepalive in seconds. In situations where the communiction goes through a
# proxy that does not support keep-alive, this parameter will maintain connection
# between peer and chaincode.
# A value <= 0 turns keepalive off
keepalive: 0
# system chaincodes whitelist. To add system chaincode "myscc" to the
# whitelist, add "myscc: enable" to the list below, and register in
# chaincode/importsysccs.go
system:
+lifecycle: enable
cscc: enable
lscc: enable
escc: enable
vscc: enable
qscc: enable
# System chaincode plugins: in addition to being imported and compiled
# into fabric through core/chaincode/importsysccs.go, system chaincodes
# can also be loaded as shared objects compiled as Go plugins.
# See examples/plugins/scc for an example.
# Like regular system chaincodes, plugins must also be white listed in the
# chaincode.system section above.
systemPlugins:
# example configuration:
# - enabled: true
# name: myscc
# path: /opt/lib/myscc.so
# invokableExternal: true
# invokableCC2CC: true
# Logging section for the chaincode container
logging:
# Default level for all loggers within the chaincode container
level: info
# Override default level for the 'shim' logger
shim: warning
# Format for the chaincode container logs
format: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}'
###############################################################################
#
# Ledger section - ledger configuration encompases both the blockchain
# and the state
#
###############################################################################
ledger:
blockchain:
state:
# stateDatabase - options are "goleveldb", "CouchDB"
# goleveldb - default state database stored in goleveldb.
# CouchDB - store state database in CouchDB
stateDatabase: goleveldb
# Limit on the number of records to return per query
totalQueryLimit: 100000
couchDBConfig:
# It is recommended to run CouchDB on the same server as the peer, and
# not map the CouchDB container port to a server port in docker-compose.
# Otherwise proper security must be provided on the connection between
# CouchDB client (on the peer) and server.
couchDBAddress: 127.0.0.1:5984
# This username must have read and write authority on CouchDB
username:
# The password is recommended to pass as an environment variable
# during start up (eg LEDGER_COUCHDBCONFIG_PASSWORD).
# If it is stored here, the file must be access control protected
# to prevent unintended users from discovering the password.
password:
# Number of retries for CouchDB errors
maxRetries: 3
# Number of retries for CouchDB errors during peer startup
maxRetriesOnStartup: 12
# CouchDB request timeout (unit: duration, e.g. 20s)
requestTimeout: 35s
# Limit on the number of records per each CouchDB query
# Note that chaincode queries are only bound by totalQueryLimit.
# Internally the chaincode may execute multiple CouchDB queries,
# each of size internalQueryLimit.
internalQueryLimit: 1000
# Limit on the number of records per CouchDB bulk update batch
maxBatchUpdateSize: 1000
# Warm indexes after every N blocks.
# This option warms any indexes that have been
# deployed to CouchDB after every N blocks.
# A value of 1 will warm indexes after every block commit,
# to ensure fast selector queries.
# Increasing the value may improve write efficiency of peer and CouchDB,
# but may degrade query response time.
warmIndexesAfterNBlocks: 1
# Create the _global_changes system database
# This is optional. Creating the global changes database will require
# additional system resources to track changes and maintain the database
createGlobalChangesDB: false
history:
# enableHistoryDatabase - options are true or false
# Indicates if the history of key updates should be stored.
# All history 'index' will be stored in goleveldb, regardless if using
# CouchDB or alternate database for the state.
enableHistoryDatabase: true
###############################################################################
#
# Metrics section
#
#
###############################################################################
metrics:
# statsd, prometheus, or disabled
provider: disabled
# statsd configuration
statsd:
# network type: tcp or udp
network: udp
# statsd server address
address: 127.0.0.1:8125
# the interval at which locally cached counters and gauges are pushsed
# to statsd; timings are pushed immediately
writeInterval: 10s
# prefix is prepended to all emitted statsd merics
prefix: peer
prometheus:
# listen address for prometheus scrape endpoint
listenAddress: 127.0.0.1:8080
# path to expose the metrics handler
handlerPath: /metrics
tls:
# TLS enabled
enabled: true
# path to PEM encoded server certificate for the scrape server
cert:
file: tls/server.crt
# path to PEM encoded server key for the scrape server
key:
file: tls/server.key
# require client certificate authentication to access metrics
# endpoint
clientAuthRequired: true
# paths to PEM encoded ca certificates to use for client
# authentication
clientRootCAs:
files:
- tls/ca.crt
Peer节点的默认配置文件中指定了适合调试的Peer节点功能。
使用时根据需求可能要对其中一些关键配置进行指定。 表9-4总结了如何通过环境变量方式对这些关键配置进行更新。
配置完成后， 用户可以采用如下命令在多个服务器上启动本地Peer节点， 启动成功后可以看到本地输出的日志消息：
root@local:~/gopath/src/github.com/hyperledger/fabric/.build/bin# ./peer node start
2018-12-03 09:05:36.925 UTC [nodeCmd] serve -> INFO 001 Starting peer:
Version: 1.4.0
Commit SHA: 29db16685
Go version: go1.10.4
OS/Arch: linux/amd64
Chaincode:
Base Image Version: 0.4.14
Base Docker Namespace: hyperledger
Base Docker Label: org.hyperledger.fabric
Docker Namespace: hyperledger
2018-12-03 09:05:36.927 UTC [peer.operations] initializeMetricsProvider -> WARN 002 Unknown provider type: ; metrics disabled
2018-12-03 09:05:36.928 UTC [ledgermgmt] initialize -> INFO 003 Initializing ledger mgmt
2018-12-03 09:05:36.928 UTC [kvledger] NewProvider -> INFO 004 Initializing ledger provider
2018-12-03 09:05:37.221 UTC [kvledger] NewProvider -> INFO 005 ledger provider Initialized
2018-12-03 09:05:37.438 UTC [ledgermgmt] initialize -> INFO 006 ledger mgmt initialized
2018-12-03 09:05:37.439 UTC [peer] func1 -> INFO 007 Auto-detected peer address: 10.10.81.64:7051
2018-12-03 09:05:37.439 UTC [peer] func1 -> INFO 008 Host is 0.0.0.0 , falling back to auto-detected address: 10.10.81.64:7051
2018-12-03 09:05:37.439 UTC [peer] func1 -> INFO 009 Auto-detected peer address: 10.10.81.64:7051
2018-12-03 09:05:37.439 UTC [peer] func1 -> INFO 00a Host is 0.0.0.0 , falling back to auto-detected address: 10.10.81.64:7051
2018-12-03 09:05:37.441 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00b Entering computeChaincodeEndpoint with peerHostname: 10.10.81.64
2018-12-03 09:05:37.441 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00c Exit with ccEndpoint: 10.10.81.64:7052
2018-12-03 09:05:37.442 UTC [nodeCmd] createChaincodeServer -> WARN 00d peer.chaincodeListenAddress is not set, using 10.10.81.64:7052
2018-12-03 09:05:37.456 UTC [sccapi] registerSysCC -> INFO 00e system chaincode lscc(github.com/hyperledger/fabric/core/scc/lscc) registered
2018-12-03 09:05:37.456 UTC [sccapi] registerSysCC -> INFO 00f system chaincode cscc(github.com/hyperledger/fabric/core/scc/cscc) registered
2018-12-03 09:05:37.456 UTC [sccapi] registerSysCC -> INFO 010 system chaincode qscc(github.com/hyperledger/fabric/core/scc/qscc) registered
2018-12-03 09:05:37.456 UTC [sccapi] registerSysCC -> INFO 011 system chaincode +lifecycle(github.com/hyperledger/fabric/core/chaincode/lifecycle) registered
2018-12-03 09:05:37.459 UTC [gossip.service] func1 -> INFO 012 Initialize gossip with endpoint 10.10.81.64:7051 and bootstrap set [127.0.0.1:7051]
2018-12-03 09:05:37.475 UTC [gossip.gossip] NewGossipService -> INFO 013 Creating gossip service with self membership of {peer0.org1.example.com:7051 [] [134 107 60 42 164 234 72 235 249 167 157 66 163 19 165 129 140 9 35 169 254 139 83 88 200 152 163 129 213 7 67 5] 10.10.81.64:7051 <nil> <nil>}
2018-12-03 09:05:37.477 UTC [gossip.gossip] start -> INFO 014 Gossip instance 10.10.81.64:7051 started
2018-12-03 09:05:37.498 UTC [sccapi] deploySysCC -> INFO 015 system chaincode lscc/(github.com/hyperledger/fabric/core/scc/lscc) deployed
2018-12-03 09:05:37.499 UTC [cscc] Init -> INFO 016 Init CSCC
2018-12-03 09:05:37.499 UTC [sccapi] deploySysCC -> INFO 017 system chaincode cscc/(github.com/hyperledger/fabric/core/scc/cscc) deployed
2018-12-03 09:05:37.500 UTC [qscc] Init -> INFO 018 Init QSCC
2018-12-03 09:05:37.500 UTC [sccapi] deploySysCC -> INFO 019 system chaincode qscc/(github.com/hyperledger/fabric/core/scc/qscc) deployed
2018-12-03 09:05:37.500 UTC [sccapi] deploySysCC -> INFO 01a system chaincode +lifecycle/(github.com/hyperledger/fabric/core/chaincode/lifecycle) deployed
2018-12-03 09:05:37.500 UTC [nodeCmd] serve -> INFO 01b Deployed system chaincodes
2018-12-03 09:05:37.502 UTC [discovery] NewService -> INFO 01c Created with config TLS: false, authCacheMaxSize: 1000, authCachePurgeRatio: 0.750000
2018-12-03 09:05:37.502 UTC [nodeCmd] registerDiscoveryService -> INFO 01d Discovery service activated
2018-12-03 09:05:37.502 UTC [nodeCmd] serve -> INFO 01e Starting peer with ID=[name:"peer0.org1.example.com" ], network ID=[dev], address=[10.10.81.64:7051]
2018-12-03 09:05:37.502 UTC [nodeCmd] serve -> INFO 01f Started peer with ID=[name:"peer0.org1.example.com" ], network ID=[dev], address=[10.10.81.64:7051]
Peer节点启动后， 默认情况下没有加入网络中的任何应用通道， 也不会与Orderer服务建立连接。 需要通过客户端对其进行操作， 让它加入网络和指定的应用通道中。
5.5 操作网络
网络启动后， 默认并不存在任何应用通道， 需要手动创建应用通道， 并让合作的Peer节点加入通道中。 下面在客户端进行相关操作。
1.创建通道
使用加入联盟中的组织管理员身份可以创建应用通道。
在客户端使用Org1的管理员身份来创建新的应用通道， 需要指定msp的ID信息、 msp文件所在路径、 Orderering服务的tls证书位置， 以及网络中Ordering服务地址、 应用通道名称和交易文件：
CHANNEL_NAME=businesschannel
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
peer channel create -o orderer.example.com:7050 -c ${CHANNEL_NAME} -f ./businesschannel.tx --tls --cafile /etc/hyperledger/fabric/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
参考：
主要参考：《区块链原理、设计与应用》这本书
另外还参考了：
Hyperledger Fabric 区块链多机部署
1.2 Fabric应用开发-配置文件(1)crypto-config.yaml
搭建基于hyperledger fabric的联盟社区（三） --生成公私钥证书及配置文件
Fabric 1.0 Crypto Generator的使用
自定义一个Fabirc网络
搭建 Fabric 网络分步走
peer channel create命令解析
https://hyperledger-fabric.readthedocs.io/en/release-1.3/commands/peerchannel.html
扫一扫
2745
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
