Michael.W谈hyperledger Fabric第9期-手动搭建Fabric网络之编写用于启动网络的docker-compose配置文件-peer节点
2019-03-10 00:04
786 查看
版权声明：原创内容，转载请注明作者。 https://blog.csdn.net/michael_wgy_/article/details/88371862
那docker网络的真实名字叫什么？就是这个
我的路径结构为：
所以当我的Fabric网络运行起来之后，该docker网络名为test_byfn。这个可以在后面进行验证。
Michael.W谈hyperledger Fabric第9期-手动搭建Fabric网络之编写用于启动网络的docker-compose配置文件-peer节点
4 修改peer节点容器的配置
老样子，先看一下docker-compose-cli.yaml文件中对peer节点容器的配置：
# 文件：docker-compose-cli.yaml services: peer0.org1.example.com: # 组织1中peer0节点的服务名 container_name: peer0.org1.example.com # 组织1中peer0节点的容器名设置 extends: file: base/docker-compose-base.yaml # 继承于的文件 service: peer0.org1.example.com # 继承于文件内的服务名 networks: # 服务基于的网络 - byfn # 以下三个服务分别是：组织1中的peer1节点、组织2中的peer0节点和组织2中的peer1节点。 # 结构与上面一致，不做解释。 peer1.org1.example.com: # 组织1中peer1节点的服务名 container_name: peer1.org1.example.com extends: file: base/docker-compose-base.yaml service: peer1.org1.example.com networks: - byfn peer0.org2.example.com: # 组织2中peer0节点的服务名 container_name: peer0.org2.example.com extends: file: base/docker-compose-base.yaml service: peer0.org2.example.com networks: - byfn peer1.org2.example.com: # 组织1中peer1节点的服务名 container_name: peer1.org2.example.com extends: file: base/docker-compose-base.yaml service: peer1.org2.example.com networks: - byfn
这四个节点均继承于base/docker-compose-base.yaml文件。看一下该文件：
# 文件：base/docker-compose-base.yaml services: peer0.org1.example.com: # 被继承于的服务名 container_name: peer0.org1.example.com # 被继承于的服务对应的容器名 extends: file: peer-base.yaml # 该服务继承文件peer-base.yaml service: peer-base # 继承于peer-base.yaml中的peer-base服务 environment: # 指定当前peer节点的ID（名字），可自定义 - CORE_PEER_ID=peer0.org1.example.com # 指定当前peer节点的域名+端口号 - CORE_PEER_ADDRESS=peer0.org1.example.com:7051 # 当该peer节点启动时，将自动连接的peer节点的地址[1]。可以连接自己，也可以连接别人（同组的其他peer节点）。 - CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.example.com:7051 # 设置当前peer节点可否被外部感知。如果想被外部感知，这个地方要写自己的地址；如果不想，就不要设置该环境变量[2]。 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051 # 当前节点所在组织的ID.需要查看configtx.yaml。 - CORE_PEER_LOCALMSPID=Org1MSP volumes: - /var/run/:/host/var/run/ # 当前peer节点的证书（身份信息）路径挂载到容器中 - ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp # 当前peer节点的TLS通信加密的相关文件挂载到容器中 - ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls # 这个在后面的帖子跟orderer指令一起介绍，现在不细说。 - peer0.org1.example.com:/var/hyperledger/production ports: # 端口映射 - 7051:7051 # peer节点默认的通信端口 - 7053:7053 # 某些事件默认的通信端口 # 剩下的三个peer节点服务分别是：组织1中的peer1服务、组织2中的peer0服务、组织2中的peer1服务所继承于的服务 # 结构与上面相同，不再解释。 ...
[1] GOSSIP是一个协议，称之为流言协议。这个协议是用于数据传播的，目的是为了在一个网络中能迅速将数据传播出去。
传播模型例如：一个网络中有A,B,C三个人，A想将一个消息传播出去。但是这个消息C知道但B不知道，那么A只将该消息告知给B，并不会告知C。每个节点都会将消息传播给与其连接的未获得此消息的节点。
如果这个peer节点是该组织中第一个启动的节点，那么它只能连接自己。如果不是该组织内第一个启动的节点，就可以连接组织内任意一个节点。
如果你无法确定各个peer节点的启动顺序，那么就都连接自己！这样绝对没错。
[2] 如果不指定环境变量CORE_PEER_GOSSIP_EXTERNALENDPOINT的值，那么当前网络中就没有节点会知道该节点的存在。这样，就完成不了节点间数据的同步！
通过文件base/docker-compose-cli.yaml可知这些peer几点继承于的服务还有父类服务！在文件peer-base.yaml中：
# 文件：base/peer-base.yaml
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
version: '2' # 版本号
services:
peer-base:
image: hyperledger/fabric-peer:$IMAGE_TAG # 基于镜像
environment:
# 本地套接字，不需要修改
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
# the following setting starts chaincode containers on the same
# bridge network as the peers
# https://docs.docker.com/compose/networking/
# 指定docker要加入的网络的网络名[1]
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_byfn
# 日志级别
- CORE_LOGGING_LEVEL=INFO
#- CORE_LOGGING_LEVEL=DEBUG
# peer通信时是否TLS加密
- CORE_PEER_TLS_ENABLED=true
# 是否让Fabric自动选举leader节点。具体含义会在下面的4.1中进行说明。
- CORE_PEER_GOSSIP_USELEADERELECTION=true
# 是否指定当前节点为leader节点。具体含义会在下面的4.1中进行说明。
- CORE_PEER_GOSSIP_ORGLEADER=false
# peer节点容器启动后，容器内会启动一个PROFILE进程。该项就是设置这个PROFILE进程是否启动。
- CORE_PEER_PROFILE_ENABLED=true
# 以下三个文件在容器内的路径都是在base/docker-compose-base.yaml文件中从宿主机挂载到容器的。
# peer节点TLS加密通信的证书文件。
- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
# peer节点TLS加密通信的秘钥文件
- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
# peer节点TLS加密通信的根证书文件
- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
# peer节点启动后切换到的进程路径
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
# peer节点容器启动后默认执行的命令
command: peer node start
[1] 我将前面设置的所有服务的网络名称都设置为byfn，但是利用
docker network ls查询到的网络名就是byfn么？答案是否定的。之前服务所处的网络名设置成byfn，是因为我在前面的docker-compose-cli.yaml文件中将网络声明成了byfn。
那docker网络的真实名字叫什么？就是这个
${COMPOSE_PROJECT_NAME}_byfn定义的。${COMPOSE_PROJECT_NAME}表示docker-compose-cli.yaml文件所在目录的名字。但是，如果所在目录名字中存在大写字母，对应的网络名前缀将变成对应的小写字母。我的路径结构为：
所以当我的Fabric网络运行起来之后，该docker网络名为test_byfn。这个可以在后面进行验证。
4.1 leader节点
leader节点也成为主节点。一个leader节点其实就是一个peer节点，只不过它有自己的职责：代表所在的组织跟orderer节点通信。与之功能相似的节点是锚节点，只不过锚节点是代表所在组织跟其他peer组织通信。
众所周知，orderer节点负责数据的打包和分发。当orderer节点打包完数据后分发给的，就是各个组织的leader节点。然后leader节点再将数据分发给组织中的各个peer节点。如果一个peer节点设置为不被外界感知，那么此时leader节点就无法将打包好的数据分发给它。
在一个组织中，只有一个leader节点。
那么谁来当leader节点呢？有两种方法：
- 人为手动指定某peer节点成为leader节点
- 框架自动选举某peer节点成为leader节点
手动指定leader节点有个缺点，就是：如果被指定的leader节点出现故障了，那么该组织中将不再有leader节点！这是一个很可怕的事情。没有了leader节点就等于组织丧失了与orderer节点通信的能力。
但是自动选举的话，当leader节点出现故障之后，Fabric会从当前组织中再选举出来一个leader节点。
这样看来，自动选举要好于手动选举。
所以，关于上面环境变量CORE_PEER_GOSSIP_USELEADERELECTION和CORE_PEER_GOSSIP_ORGLEADER的设置有如下组合：
- 手动指定leader节点：
# 手动指定当前peer节点为leader节点 (被选择成为leader的peer节点这样设置) - CORE_PEER_GOSSIP_USELEADERELECTION=false - CORE_PEER_GOSSIP_ORGLEADER=true # 手动指定当前peer节点不为leader节点（其他的peer节点这样设置） - CORE_PEER_GOSSIP_USELEADERELECTION=false - CORE_PEER_GOSSIP_ORGLEADER=false
- 自动选举leader节点：
# Fabric自动选举peer节点为leader节点（每个peer节点都需要这样设置） - CORE_PEER_GOSSIP_USELEADERELECTION=true - CORE_PEER_GOSSIP_ORGLEADER=false
我在这里建议大家将每个peer节点都设置为自动选举leader节点。
所有关于peer节点的配置项都介绍完毕后，我列出我修改后的peer节点的配置文件：
# 文件：base/peer-base.yaml version: '2' services: peer-base: image: hyperledger/fabric-peer # 修改 environment: - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock # test为工程目录的名字。因为docker默认生成的网络名是：顶级工程路径名_byfn。byfn是在前面设置services的时候，network关键字下设置的名字。 - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=test_byfn - CORE_LOGGING_LEVEL=INFO - CORE_PEER_TLS_ENABLED=true - CORE_PEER_GOSSIP_USELEADERELECTION=true - CORE_PEER_GOSSIP_ORGLEADER=false - CORE_PEER_PROFILE_ENABLED=true - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer command: peer node start
# 文件：base/docker-compose-base.yaml version: '2' ... peer0.org1.michael.com: # 修改 container_name: peer0.org1.michael.com # 修改 extends: file: peer-base.yaml service: peer-base environment: - CORE_PEER_ID=peer0.org1.michael.com # 修改 - CORE_PEER_ADDRESS=peer0.org1.michael.com:7051 # 修改 - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.michael.com:7051 # 修改 我将该节点设置为启动后自己连接自己 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.michael.com:7051 # 修改 - CORE_PEER_LOCALMSPID=Org1MSP volumes: - /var/run/:/host/var/run/ - ../crypto-config/peerOrganizations/org1.michael.com/peers/peer0.org1.michael.com/msp:/etc/hyperledger/fabric/msp # 修改 - ../crypto-config/peerOrganizations/org1.michael.com/peers/peer0.org1.michael.com/tls:/etc/hyperledger/fabric/tls # 修改 - peer0.org1.michael.com:/var/hyperledger/production # 修改 ports: - 7051:7051 - 7053:7053 # 后面三个peer节点服务都是按照上面对应的选项进行修改，这里不予赘述 peer1.org1.michael.com: container_name: peer1.org1.michael.com extends: file: peer-base.yaml service: peer-base environment: - CORE_PEER_ID=peer1.org1.michael.com - CORE_PEER_ADDRESS=peer1.org1.michael.com:7051 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.michael.com:7051 - CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.michael.com:7051 - CORE_PEER_LOCALMSPID=Org1MSP volumes: - /var/run/:/host/var/run/ - ../crypto-config/peerOrganizations/org1.michael.com/peers/peer1.org1.michael.com/msp:/etc/hyperledger/fabric/msp - ../crypto-config/peerOrganizations/org1.michael.com/peers/peer1.org1.michael.com/tls:/etc/hyperledger/fabric/tls - peer1.org1.michael.com:/var/hyperledger/production ports: - 8051:7051 - 8053:7053 peer0.org2.michael.com: container_name: peer0.org2.michael.com extends: file: peer-base.yaml service: peer-base environment: - CORE_PEER_ID=peer0.org2.michael.com - CORE_PEER_ADDRESS=peer0.org2.michael.com:7051 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org2.michael.com:7051 - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org2.michael.com:7051 - CORE_PEER_LOCALMSPID=Org2MSP volumes: - /var/run/:/host/var/run/ - ../crypto-config/peerOrganizations/org2.michael.com/peers/peer0.org2.michael.com/msp:/etc/hyperledger/fabric/msp - ../crypto-config/peerOrganizations/org2.michael.com/peers/peer0.org2.michael.com/tls:/etc/hyperledger/fabric/tls - peer0.org2.michael.com:/var/hyperledger/production ports: - 9051:7051 - 9053:7053 peer1.org2.michael.com: container_name: peer1.org2.michael.com extends: file: peer-base.yaml service: peer-base environment: - CORE_PEER_ID=peer1.org2.michael.com - CORE_PEER_ADDRESS=peer1.org2.michael.com:7051 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org2.michael.com:7051 - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org2.michael.com:7051 - CORE_PEER_LOCALMSPID=Org2MSP volumes: - /var/run/:/host/var/run/ - ../crypto-config/peerOrganizations/org2.michael.com/peers/peer1.org2.michael.com/msp:/etc/hyperledger/fabric/msp - ../crypto-config/peerOrganizations/org2.michael.com/peers/peer1.org2.michael.com/tls:/etc/hyperledger/fabric/tls - peer1.org2.michael.com:/var/hyperledger/production ports: - 10051:7051 - 10053:7053
# 文件：docker-compose-cli.yaml services: ... peer0.org1.michael.com: # 修改 container_name: peer0.org1.michael.com # 修改 extends: file: base/docker-compose-base.yaml service: peer0.org1.michael.com # 修改 networks: - byfn # 后面三个peer节点服务都是按照上面对应的选项进行修改，这里不予赘述 peer1.org1.michael.com: container_name: peer1.org1.michael.com extends: file: base/docker-compose-base.yaml service: peer1.org1.michael.com networks: - byfn peer0.org2.michael.com: container_name: peer0.org2.michael.com extends: file: base/docker-compose-base.yaml service: peer0.org2.michael.com networks: - byfn peer1.org2.michael.com: container_name: peer1.org2.michael.com extends: file: base/docker-compose-base.yaml service: peer1.org2.michael.com networks: - byfn
我当前工程目录的文件组织结构如下图所示：
如果你的工程目录组织结构跟我的不同，那么docker-compose-cli.yaml和base/docker-compose-base.yaml中的volumes宿主机数据卷挂载目录也需要做对应修改。至此，peer节点相关的配置文件已经全部修改完毕。
ps:
本人热爱图灵，热爱中本聪，热爱V神，热爱一切被梨花照过的姑娘。
以下是我个人的公众号，如果有技术问题可以关注我的公众号来跟我交流。
同时我也会在这个公众号上每周更新我的原创文章，喜欢的小伙伴或者老伙计可以支持一下！
如果需要转发，麻烦注明作者。十分感谢！
公众号名称：后现代泼痞浪漫主义奠基人
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Michael.W谈hyperledger Fabric第11期-手动搭建Fabric网络之启动网络与功能调试二
- Michael.W谈hyperledger Fabric第10期-手动搭建Fabric网络之启动网络与功能调试一
- Fabric_超详细的fabric网络搭建03-docker-compose文件的编写
- HyperLedger Fabric：自顶向下的方法--第1篇 编译fabric源码及手工搭建单个Peer节点网络
- Michael.W谈hyperledger Fabric第25期-详细带读Fabric的源码10-peer节点交易的读写集合RWSet
- hyperledger fabric1.0动态添加peer节点之fabric-ca环境配置
- Fabric_超详细的fabric网络搭建04-Peer节点相关操作
- Michael.W谈hyperledger Fabric第20期-详细带读Fabric的源码5-orderer节点的solo排序
- Hyperledger Fabric 排序节点启动过程
- Hyperledger Fabric Orderer节点启动
- hyperledger fabric1.0动态添加peer节点之添加peer节点
- hyperLedger Fabric 系列二：peer节点的介绍
- Hyperledger Fabric 1.0 从零开始（七）——启动Fabric多节点集群
- Michael.W谈hyperledger Fabric第22期-详细带读Fabric的源码7-orderer节点相关源码梳理
- hyperledger fabric1.0动态添加peer节点之fabric-ca应用
- 区块链hyperledger fabric 环境搭建 centos7 docker环境
- Hyperledger fabric0.6 peer启动过程源码分析
- Michael.W谈hyperledger Fabric第19期-详细带读Fabric的源码4-orderer节点对交易数据的区块打包
- (二) Hyperledger Fabric 启动你的第一个网络
- docker-compose.yml 配置文件编写详解