导言：
旨在记录fabric环境搭建时使用的配置文件对应的功能和字节介绍。
目标：
- 了解节点证书和创世块生成的配置文件的配置信息；
- 了解各类节点的配置文件的配置信息；
- 了解系统core.yaml文件的配置信息；
- 了解fabric节点证书包括哪些内容；
配置文件：
文章中1-6对应的配置文件是本人在实际搭建fabric环境《深入理解hyperledger fabric环境搭建的详细过程》时使用的配置文件；第7段是对fabric-samples工程自带的core.yaml文件进行介绍。
1. configtx.yaml文件
此配置文件主要分为3部分。
1）Profiles部分。它是默认的，这部分包含一些用于开发或测试场景的示例配置，这些配置涉及fabric目录中的加密部分。configtxgen工具允许通过-profile标签来指定配置文件。Profiles部分可以显式声明所有配置，但是通常都是从默认配置中继承。
2）Organizations部分。它是默认的，这部分包含示例配置MSP定义的单一引用。对于生产部署，应该删除这部分配置，并以新网络成员的MSP定义来替代它。组织中每一个元素都必须带有锚标签，如&orgName，这些标签可以在Profiles中部分引用。
3）默认部分。此部分是Orderer和Application的配置，包括一些属性配置，如BatchTimeout和一般用作继承的基础值。
| # 一些列组织的定义，【被其他 部分引用】 # #【注意】：本文件中 &KEY 均为 *KEY 所引用； xx：&KEY 均为 <<: *KEY 所引用#
########################################################################### # # Section: Organizations # # - 本节定义了不同的组织标识，这些标识将在稍后的配置中引用。 # ########################################################################### Organizations:
# 定义Orderer组织【&OrdererOrg 这类语法类似 Go的中的指针及对象地址， 此处是被Profiles 中的 - *OrdererOrg 所引用，以下均为类似做法】 - &OrdererOrg Name: OrdererOrg #orderer组织名字 ID: OrdererMSP #orderer组织ID
# MSPDir是包含MSP配置的文件系统路径，由cryptogen工具生成的Orderer的 MSP 证书目录路径 MSPDir: crypto-config/ordererOrganizations/example.com/msp # AdminPrincipal: Role.ADMIN #【可选项】 组织管理员所需要的身份，可选项: Role.ADMIN 和 Role.MEMBER
# Policies定义了在这个配置树级别的策略集 # 对于组织策略，它们的规范路径通常是/Channel/<Application|Orderer>/<OrgName>/<PolicyName> Policies: Readers: Type: Signature Rule: "OR('OrdererMSP.member')" Writers: Type: Signature Rule: "OR('OrdererMSP.member')" Admins: Type: Signature Rule: "OR('OrdererMSP.admin')"
- &Org1 Name: Org1MSP #组织名字 ID: Org1MSP #组织ID
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp # Peer的MSP 证书目录路径
# Policies定义了在这个配置树级别的策略集 # 对于组织策略，它们的规范路径通常是/Channel/<Application|Orderer>/<OrgName>/<PolicyName> Policies: Readers: Type: Signature Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')" Writers: Type: Signature Rule: "OR('Org1MSP.admin', 'Org1MSP.client')" Admins: Type: Signature Rule: "OR('Org1MSP.admin')"
# 将此标志设置为true. AnchorPeers: # 定义组织锚节点 用于跨组织 Gossip 通信 # AnchorPeers定义了可以用于跨组织gossip通信的节点的位置 # 注意，这个值只在应用程序部分上下文的genesis块中编码 - Host: peer0.org1.example.com #瞄节点的主机名 Port: 7051 #瞄节点的端口号
- &Org2 Name: Org2MSP ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
# Policies定义了在这个配置树级别的策略集 # 对于组织策略，它们的规范路径通常是/Channel/<Application|Orderer>/<OrgName>/<PolicyName> Policies: Readers: Type: Signature Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')" Writers: Type: Signature Rule: "OR('Org2MSP.admin', 'Org2MSP.client')" Admins: Type: Signature Rule: "OR('Org2MSP.admin')"
AnchorPeers: # 定义组织锚节点 用于跨组织 Gossip 通信 # AnchorPeers定义了可以用于跨组织gossip通信的节点的位置 # 指明org2中使用peer0作为锚节点 - Host: peer0.org2.example.com Port: 9051
########################################################################### # # SECTION: Capabilities # # 本节定义fabric network的功能。这是v1.1.0的一个新概念，不应该在带有v1.0.x版本orderers和peers的混合网络中使用。 # 功能定义了fabric二进制文件中必须提供的特性，以便该二进制文件安全地参与fabric网络。 # 例如，如果添加了新的MSP类型，较新的二进制文件可能会识别并验证来自该类型的签名，而没有此支持的较老的二进制文件将无法验证这些交易。 # 这可能导致不同版本的fabric二进制文件具有不同的世界状态。相反，为通道定义一个功能会通知那些没有这个功能的二进制文件，它们必须停止处理交易，直到它们被升级。 # 对于v1.0.x 版本，如果定义了任何功能(包括关闭所有功能的映射)，v1.0.x版本的节点可能会故意崩溃。 # ########################################################################### Capabilities: # 通道功能同时适用于orderers和peers，并且必须得到双方的支持。 # 将功能的值设置为true以满足需要。 Channel: &ChannelCapabilities #Channel的V1.3是一个用来表示运行在V1.3.x版本上的所有orderers和peers都需要的行为的catchall标志，但这将与以前版本中的orderers和peers不兼容。 # 在启用V1.3通道功能之前，请确保通道上的所有orderers和peers都位于v1.3.0或更高版本。 V1_3: true
# Orderer功能只适用于Orderer，并且可以安全地与以前版本的节点一起使用。 # 将功能的值设置为true以满足需要 Orderer: &OrdererCapabilities # Orderer的V1.1是一个用来表示确定被在v1.1.x中运行的所有orderers所需要的行为的catchall标志，但这与以前版本中的orderers不兼容。 # 在启用V1.1 orderer功能之前，请确保通道上的所有orderer都处于v1.1.0或更高版本。 V1_1: true
# Application功能只应用于peer网络，并且可以安全地与以前的版本的orderers一起使用。 # 将功能的值设置为true以满足需要 Application: &ApplicationCapabilities # Application的V1.3用来启用新的非向后兼容特性fabric V1.3的补丁 V1_3: true # Application的V1.2用来启用新的非向后兼容特性和fabric V1.2的补丁(注意，如果设置了之后的版本的功能，则不需要设置此功能) V1_2: false # Application的V1.1启用新的非向后兼容特性和fabric V1.1的补丁(注意，如果设置了之后的版本的功能，则不需要设置此特性)。 # 所以这里设置是V1_3为true，另外两个为false V1_1: false
########################################################################### # # SECTION: Application # # 本节为Application相关参数定义要编码到配置交易或创世区块中的值 # 注意，只有在创建channel tx时才会用Application，否则是创建区块 # ########################################################################### Application: &ApplicationDefaults #自定义被引用的地址
# Organizations是定义为网络应用程序端参与者的组织列表 Organizations:
# Policies定义了在这个配置树级别的策略集 # 对于组织策略，它们的规范路径通常是/Channel/<Application|Orderer>/<OrgName>/<PolicyName> Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins"
Capabilities: <<: *ApplicationCapabilities ################################################################################ # # SECTION: Orderer # # 本节为orderer相关参数定义要编码到配置交易或创世区块中的值 # Orderer 默认是 solo 的 且不包含任何组织 【主要被 Profiles 部分引用】 ################################################################################ Orderer: &OrdererDefaults
# Orderer 类型: 要启动的Orderer实现类型 # 可用的类型有“solo”和“kafka”（fabric 1.4以前的版本） OrdererType: solo
Addresses: - orderer.example.com:7050
# 区块打包最大超时时间 BatchTimeout: 2s
#区块打包的最大包含交易数 BatchSize: MaxMessageCount: 10 # 一个区块里最大的交易数
AbsoluteMaxBytes: 99 MB # 一个区块的最大字节数， 任何时候都不能超过 # 一个区块的建议字节数，如果一个交易消息的大小超过了这个值, 就会被放入另外一个更大的区块中 PreferredMaxBytes: 512 KB
Kafka: # kafka的 brokens 服务地址 允许有多个 Brokers: - 127.0.0.1:9092
# Organizations是组织的列表，组织被定义为网络的orderer方的参与者 Organizations:
# Policies定义了在这个配置树级别的策略集 # 对于Orderer策略，它们的规范路径通常是/Channel/Orderer/<PolicyName> Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" # BlockValidation指定必须包含来自orderer的哪些签名，以便peer对其进行验证。 BlockValidation: Type: ImplicitMeta Rule: "ANY Writers"
################################################################################ # # CHANNEL # # 本节为channel相关参数定义要编码到配置交易或创世区块中的值 # ################################################################################ Channel: &ChannelDefaults
# Policies定义了在这个配置树级别的策略集 # 对于Channel策略，它们的规范路径通常是/Channel/<PolicyName> Policies: # 谁可能调用'Deliver' API Readers: Type: ImplicitMeta Rule: "ANY Readers" # 谁可能调用'Broadcast' API Writers: Type: ImplicitMeta Rule: "ANY Writers" # 默认，谁可能调用在这个配置级别的元素 Admins: Type: ImplicitMeta Rule: "MAJORITY Admins"
# Capabilities描述通道级功能，有关详细描述，请参阅此文件中其他部分的专用功能部分 Capabilities: <<: *ChannelCapabilities
################################################################################ # # Profile # # - 这里可以编码不同的配置概要文件，将其指定为configtxgen工具的参数 # ################################################################################ Profiles: # Orderer的 系统通道模板 必须包括 Orderer、 Consortiums 两部分 # Orderer系统的通道及创世块配置。通道为默认配置，添加一个OrdererOrg 组织， 联盟为默认的 SampleConsortium 联盟，添加了两个组织 【该名称可以自定义 ？？】 TwoOrgsOrdererGenesis: <<: *ChannelDefaults Orderer: # 指定Orderer系统通道自身的配置信息 <<: *OrdererDefaults # 引用 Orderer 部分的配置 &OrdererDefaults Organizations: - *OrdererOrg #引用& OrdererOrg Capabilities: <<: *OrdererCapabilities #引用& OrdererCapabilities Consortiums: # Orderer 所服务的联盟列表 SampleConsortium: # 创建更多应用通道时的联盟 引用 TwoOrgsChannel 所示 Organizations: - *Org1 - *Org2 # 应用通道模板 必须包括 Application、 Consortium 两部分 TwoOrgsChannel: Consortium: SampleConsortium Application: <<: *ApplicationDefaults Organizations: - *Org1 - *Org2 Capabilities: <<: *ApplicationCapabilities
SampleDevModeKafka: <<: *ChannelDefaults Capabilities: <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults OrdererType: kafka Kafka: Brokers: - kafka.example.com:9092
Organizations: - *OrdererOrg Capabilities: <<: *OrdererCapabilities Application: <<: *ApplicationDefaults Organizations: - <<: *OrdererOrg Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2 |
2. crypto-config.yaml文件
该文件可以配置org、peer、orderer的节点信息进行统一管理。以下配置文件配置了3个org机构、orderer的domain为zeuslook.com、每个机构有2个Peer节
点。
| # “OrdererOrgs”——管理orderer节点的组织的定义 OrdererOrgs: - Name: Orderer Domain: zeuslook.com Specs: - Hostname: orderer #“PeerOrgs”——管理peer节点的组织的定义 PeerOrgs: - Name: Org1 # 组织名称 Domain: org1.zeuslook.com # 组织域 EnableNodeOUs: true # 如果设置了EnableNodeOUs，就在msp下生成config.yaml文件 CA: Country: US Province: California Locality: San Francisco Template: # 允许定义从模板顺序创建的1个或多个主机 Count: 2 Users: Count: 1 - Name: Org2 Domain: org2.zeuslook.com EnableNodeOUs: true CA: Country: US Province: California Locality: San Francisco Template: Count: 2 Users: Count: 1 - Name: Org3 Domain: org3.zeuslook.com EnableNodeOUs: true CA: Country: US Province: California Locality: San Francisco Template: Count: 2 Users: Count: 1 |
Name和Domain就是关于这个组织的名字和域名，这主要是用于生成证书的时候，证书内会包含该信息。而Template Count=2是说我们要生成2套公私钥和证书，一套是peer0.org2的，还有一套是peer1.org2的。最后Users. Count=1是说每个Template下面会有几个普通User（注意，Admin是Admin，不包含在这个计数中），这里配置了1，也就是说我们只需要一个普通用户User1@org2.example.com 我们可以根据实际需要调整这个配置文件，增删Org Users等。
3. orderer.yaml
| version: '2' volumes: orderer0.example.com: services: orderer0.example.com: container_name: orderer0.example.com image: hyperledger/fabric-orderer:latest environment: - FABRIC_LOGGING_SPEC=INFO - GODEBUG=netdns=go - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0 - ORDERER_GENERAL_GENESISMETHOD=file - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block - ORDERER_GENERAL_LOCALMSPID=OrdererMSP - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp # 使能TLS，主要是用在通信的过程中；并制定TLS文件对应的路径 - ORDERER_GENERAL_TLS_ENABLED=true - ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key # fully qualified path of the file that contains the server private key - ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt # fully qualified path of the file that contains the server certificate - ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt] # fully qualified path of the file that contains the certificate chain of the CA that issued TLS server certificate - ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1 - ORDERER_KAFKA_VERBOSE=true - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt] working_dir: /opt/gopath/src/github.com/hyperledger/fabric command: orderer volumes: #挂载宿主机路径到docker容器内的路径 - ./channel-artifacts/genesis.block:/var/hyperledger/orderer/orderer.genesis.block - ./crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/msp:/var/hyperledger/orderer/msp - ./crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/:/var/hyperledger/orderer/tls - orderer0.example.com:/var/hyperledger/production/orderer ports: - 7050:7050 #docker 容器内外端口 extra_hosts: - "orderer0.example.com:192.168.128.81" - "orderer1.example.com:192.168.128.75" - "orderer2.example.com:192.168.128.76" - "orderer3.example.com:192.168.128.77" - "orderer4.example.com:192.168.128.63" |
4. peer.yaml
| volumes: peer0.org1.example.com: services: peer0.org1.example.com: container_name: peer0.org1.example.com hostname: peer0.org1.example.com image: hyperledger/fabric-peer:latest #最新镜像 environment: - CORE_LEDGER_STATE_STATEDATABASE=CouchDB #数据库 - CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb0:5984 # The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD # provide the credentials for ledger to connect to CouchDB. The username and password must # match the username and password set for the associated CouchDB. - CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME= - CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD= - CORE_PEER_ID=peer0.org1.example.com - GODEBUG=netdns=go - CORE_PEER_ADDRESS=peer0.org1.example.com:7051 - CORE_PEER_CHAINCODELISTENADDRESS=peer0.org1.example.com:7052 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051 - CORE_PEER_LOCALMSPID=Org1MSP - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock - FABRIC_LOGGING_SPEC=INFO - CORE_PEER_GOSSIP_USELEADERELECTION=true - CORE_PEER_GOSSIP_ORGLEADER=false - CORE_PEER_PROFILE_ENABLED=true - CORE_PEER_TLS_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 volumes: - /var/run/:/host/var/run/ - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls - peer0.org1.example.com:/var/hyperledger/production ports: - 7051:7051 - 7052:7052 - 7053:7053 extra_hosts: - "orderer0.example.com:192.168.128.81" - "orderer1.example.com:192.168.128.75" - "orderer2.example.com:192.168.128.76" - "orderer3.example.com:192.168.128.77" - "orderer4.example.com:192.168.128.63" - "couchdb0:192.168.128.81" |
5. cli.yaml
| version: '2' services: cli: container_name: cli image: hyperledger/fabric-tools:latest tty: true environment: - GOPATH=/opt/gopath - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock - FABRIC_LOGGING_SPEC=INFO - GODEBUG=netdns=go - CORE_PEER_ID=cli - CORE_PEER_ADDRESS=peer0.org1.example.com:7051 - CORE_PEER_LOCALMSPID=Org1MSP - CORE_PEER_TLS_ENABLED=true - CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt - CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key - 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 working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer #cli工作路径 volumes: - /var/run/:/host/var/run/ - ./chaincode:/opt/gopath/src/github.com/chaincode - ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ - ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts extra_hosts: - "orderer0.example.com:192.168.128.81" - "orderer1.example.com:192.168.128.75" - "orderer2.example.com:192.168.128.76" - "orderer3.example.com:192.168.128.77" - "orderer4.example.com:192.168.128.63" - "peer0.org1.example.com:192.168.128.81" - "peer1.org1.example.com:192.168.128.75" - "peer2.org1.example.com:192.168.128.76" - "peer3.org1.example.com:192.168.128.77" |
6. ca.yaml
|
version: '2'
services: ca0: image: hyperledger/fabric-ca:latest environment: - FABRIC_CA_HOME=/var/hyperledger/fabric-ca-server - FABRIC_CA_SERVER_CA_NAME=ca-org1 - FABRIC_CA_SERVER_CA_CERTFILE=/var/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem - FABRIC_CA_SERVER_CA_KEYFILE=/var/hyperledger/fabric-ca-server-config/f927725bac311668c1ee983e7adff9124edaabeee35ffccaa1bbb1e02ea4e820_sk - FABRIC_CA_SERVER_TLS_ENABLED=true - FABRIC_CA_SERVER_TLS_CERTFILE=/var/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem - FABRIC_CA_SERVER_TLS_KEYFILE=/var/hyperledger/fabric-ca-server-config/f927725bac311668c1ee983e7adff9124edaabeee35ffccaa1bbb1e02ea4e820_sk - FABRIC_CA_SERVER_PORT=7054 ports: - "7054:7054" command: sh -c 'fabric-ca-server start -b admin:adminpw -d' volumes: - ./crypto-config/peerOrganizations/org1.example.com/ca/:/var/hyperledger/fabric-ca-server-config container_name: ca_peerOrg1 |
7. db.yaml
| # Copyright IBM Corp. All Rights Reserved. # # SPDX-License-Identifier: Apache-2.0 # version: '2'
services: couchdb0: container_name: couchdb0 image: hyperledger/fabric-couchdb # Populate the COUCHDB_USER and COUCHDB_PASSWORD to set an admin user and password # for CouchDB. This will prevent CouchDB from operating in an "Admin Party" mode. environment: - COUCHDB_USER= - COUCHDB_PASSWORD= # Comment/Uncomment the port mapping if you want to hide/expose the CouchDB service, # for example map it to utilize Fauxton User Interface in dev environments. ports: - "5984:5984" |
8. core.yaml
该配置文件是一个示例文件，在fabric-samples/config目录下，主要包含了：logging（日志）、peer（节点）、vm（链码运行环境）、chaincode（链码相关）、ledger
（账本）、metrics 等 6 大部分。
| # 日志配置信息 # 日志级别有： critical、 error、 warning、 notice、 info、 debug 级别由大到小， 级别越小输出越详细 logging: level: info ## 全局的默认日志级别
## 各个模块日志级别， 覆盖全局配置 cauthdsl: warning gossip: warning grpc: error ledger: info msp: warning policies: warning peer: gossip: warning
# 日志的输出格式 format: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}'
############################################################################### # # Peer section peer部分 # ############################################################################### peer: id: jdoe ## Peer节点ID networkId: dev ## 网络ID listenAddress: 0.0.0.0:7051 ## 节点监听的本地网络接口地址 chaincodeAddress: 0.0.0.0:7052 ## 链码容器连接时的监听地址 如未指定, 则使用listenAddress的IP地址和7052端口 address: 0.0.0.0:7051 ## 节点对外的服务地址 （对外的地址）【还有人说是 与同组织内其他peer通信的地址; 配置在cli节点上表示peer与其通信的地址 ？？】 addressAutoDetect: false ## 是否自动探测服务地址 (默认 关闭， 如果启用TLS时，最好关闭) gomaxprocs: -1 ## Go的进程限制数 runtime.GOMAXPROCS(n) 默认 -1 keepalive: ## 客户端和peer间的网络心跳连接配置
minInterval: 60s ## 最小的心跳间隔时间 client: ## 该节点和客户端 的交互配置 interval: 60s ## 和客户端 的心跳间隔 必须 interval >= minInterval timeout: 20s ## 和客户端 间的网络连接超时时间 deliveryClient: ## 交付客户端用于与订购节点通信的心跳 interval: 60s timeout: 20s gossip: ## 节点间通信的gossip 协议的P2P通信 【主要包含了 启动 及 连接】 bootstrap: 127.0.0.1:7051 ## 启动节点后 向哪些节点发起gossip连接，以加入网络，且节点相互间都是同一个组织的 useLeaderElection: true ## 是否启动动态选举 组织的Leader 节点 与 orgLeader 互斥 orgLeader: false ## 是否指定本节点为 组织Leader 节点 与 useLeaderElection 互斥 endpoint: ## 本节点在组织内的gossip id maxBlockCountToStore: 100 ## 保存到内存的区块个数上限 maxPropagationBurstLatency: 10ms ## 保存消息的最大时间，超过则触发转发给其他节点 maxPropagationBurstSize: 10 ## 保存的最大消息个数，超过则触发转发给其他节点 propagateIterations: 1 ## 消息转发的次数 propagatePeerNum: 3 ## 推送消息给指定个数的节点 pullInterval: 4s ## 拉取消息的时间间隔 (unit: second) 必须大于 digestWaitTime + responseWaitTime pullPeerNum: 3 ## 从指定个数的节点拉取消息 requestStateInfoInterval: 4s ## 从节点拉取状态信息(StateInfo) 消息间隔 (unit: second) publishStateInfoInterval: 4s ## 向其他节点推动状态信息消息的间隔 (unit: second) stateInfoRetentionInterval: ## 状态信息消息的超时时间 (unit: second) publishCertPeriod: 10s ## 启动后在心跳消息中包括证书的等待时间 skipBlockVerification: false ## 是否不对区块消息进行校验，默认为false dialTimeout: 3s ## gRPC 连接拨号的超时 (unit: second) connTimeout: 2s ## 建立连接的超时 (unit: second) recvBuffSize: 20 ## 收取消息的缓冲大小 sendBuffSize: 200 ## 发送消息的缓冲大小 digestWaitTime: 1s ## 处理摘要数据的等待时间 (unit: second) 可以大于 requestWaitTime requestWaitTime: 1500ms ## 处理nonce 数据的等待时间 (unit: milliseconds) 可以大于 digestWaitTime responseWaitTime: 2s ## 终止拉取数据处理的等待时间 (unit: second) aliveTimeInterval: 5s ## 定期发送Alive 心跳消息的时间间隔 (unit: second) aliveExpirationTimeout: 25s ## Alive 心跳消息的超时时间 (unit: second) reconnectInterval: 25s ## 断线后重连的时间间隔 (unit: second) externalEndpoint: ## 节点被组织外节点感知时的地址，公布给其他组织的地址和端口, 如果不指定, 其他组织将无法知道本peer的存在 election: ## Leader 节点的选举配置 startupGracePeriod: 15s ## leader节点选举等待的时间 (unit: second) membershipSampleInterval: 1s ## 测试peer稳定性的时间间隔 (unit: second) leaderAliveThreshold: 10s ## pear 尝试进行选举的等待超时 (unit: second) leaderElectionDuration: 5s ## pear 宣布自己为Leader节点的等待时间 (unit: second)
pvtData: ## 这个我还真不知道干嘛的？谁知道告诉我 pullRetryThreshold: 60s transientstoreMaxBlockRetention: 1000 pushAckTimeout: 3s btlPullMargin: 10
events: ## 事件配置 address: 0.0.0.0:7053 ## 本地服务监听地址 (默认在所有网络接口上进心监听，端口 7053) buffersize: 100 ## 最大缓冲消息数，超过则向缓冲中发送事件消息会被阻塞 timeout: 10ms ## 事件发送超时时间, 如果事件缓存已满, timeout < 0, 事件被丢弃; timeout > 0, 阻塞直到超时丢弃, timeout = 0, 阻塞直到发送出去 timewindow: 15m ## 允许peer和 客户端 时间不一致的最大时间差
keepalive: ## 客户端到peer间的事件心跳 minInterval: 60s sendTimeout: 60s ## 在GRPC流上向客户端发送事件的超时时间
tls: ## tls配置
enabled: false ## 是否开启 TLS，默认不开启TLS clientAuthRequired: false ## 客户端连接到peer是否需要使用加密
cert: ## 证书密钥的位置, 各peer应该填写各自相应的路径 file: tls/server.crt ## 本服务的身份验证证书，公开可见，访问者通过该证书进行验证 key: file: tls/server.key ## 本服务的签名私钥 rootcert: file: tls/ca.crt ## 信任的根CA整数位置
clientRootCAs: ## 用于验证客户端证书的根证书颁发机构的集合 files: - tls/ca.crt clientKey: ## 当TLS密钥用于制作客户端连接。如果不设置，将使用而不是peer.tls.key.file file: clientCert: ## 在进行客户端连接时用于TLS的X.509证书。 如果未设置，将使用peer.tls.cert.file file: serverhostoverride: ## 是否制定进行TLS握手时的主机名称
authentication: ## 身份验证包含与验证客户端消息相关的配置参数 timewindow: 15m ## 客户端请求消息中指定的当前服务器时间与客户端时间之间的可接受差异
fileSystemPath: /var/hyperledger/production ## peer数据存储位置(包括账本,状态数据库等)
BCCSP: ## 加密库配置 与Orderer 配置一样 Default: SW ## 使用软件加密方式 (默认 SW) SW: Hash: SHA2 ## Hash 算法类型，目前仅支持SHA2 Security: 256
FileKeyStore: ## 本地私钥文件路径，默认指向 <mapConfigPath>/keystore KeyStore: # Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11) PKCS11: ## 设置 PKCS#11 加密算法 (默认PKCS11) Library: ## 本地PKCS11依赖库
Label: ## token的标识 Pin: ## 使用Pin Hash: Security: FileKeyStore: KeyStore:
mspConfigPath: msp ## msp 的本地路径
localMspId: SampleOrg ## Peer 所关联的MSP 的ID
client: ## cli 公共客户端配置选项 connTimeout: 3s ## 连接超时时间
deliveryclient: ## 交付服务配置 reconnectTotalTimeThreshold: 3600s ## 交付服务交付失败后尝试重连的时间 connTimeout: 3s ## 交付服务和 orderer节点的连接超时时间 reConnectBackoffThreshold: 3600s ## 设置连续重试之间的最大延迟
localMspType: bccsp ## 本地MSP类型 （默认为 BCCSP）
profile: ## 是否启用Go自带的profiling 支持进行调试 enabled: false listenAddress: 0.0.0.0:6060
adminService: ## admin服务用于管理操作，例如控制日志模块严重性等。只有对等管理员才能使用该服务
handlers: authFilters: - name: DefaultAuth - name: ExpirationCheck ## 此筛选器检查身份x509证书过期 decorators: - name: DefaultDecorator endorsers: escc: name: DefaultEndorsement library: validators: vscc: name: DefaultValidation library: validatorPoolSize: ## 处理交易验证的并发数, 默认是CPU的核数
discovery: ## 客户端使用发现服务来查询有关peers的信息，例如 - 哪些peer已加入某个channel，最新的channel配置是什么，最重要的是 - 给定chaincode和channel，哪些可能的peer满足认可 policy enabled: true authCacheEnabled: true authCacheMaxSize: 1000 authCachePurgeRetentionRatio: 0.75 orgMembersAllowedAccess: false ############################################################################### # # VM section 链码运行环境配置 目前主要支持 Docker容器 # ############################################################################### vm:
endpoint: unix:///var/run/docker.sock ## Docker Daemon 地址，默认是本地 套接字
docker: tls: ## Docker Daemon 启用TLS时的相关证书配置, 包括信任的根CA证书、服务身份证书、签名私钥等等 enabled: false ca: file: docker/ca.crt cert: file: docker/tls.crt key: file: docker/tls.key
attachStdout: false ## 是否启用绑定到标准输出，启用后 链码容器 的输出消息会绑定到标准输出，方便进行调试
hostConfig: ## Docker 相关的主机配置，包括网络配置、日志、内存等等，这些配置在启动链码容器时进行使用 NetworkMode: host Dns: # - 192.168.0.1 LogConfig: Type: json-file Config: max-size: "50m" max-file: "5" Memory: 2147483648
############################################################################### # # Chaincode section 链码相关配置 # ############################################################################### chaincode:
id: ## 记录链码相关信息，包括路径、名称、版本等等，该信息会以标签形式写到链码容器 path: name:
builder: $(DOCKER_NS)/fabric-ccenv:latest ## 通用的本地编译环境，是一个Docker 镜像 pull: false golang: ## Go语言的链码部署生成镜像的基础Docker镜像 runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION) dynamicLink: false car: ## car格式的链码部署生成镜像的基础Docker 镜像 runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION) java: ## java语言的基础镜像 Dockerfile: | from $(DOCKER_NS)/fabric-javaenv:$(ARCH)-1.1.0 node: ## node.js的基础镜像 runtime: $(BASE_DOCKER_NS)/fabric-baseimage:$(ARCH)-$(BASE_VERSION)
startuptimeout: 300s ## 启动链码容器超时，等待超时时间后还没收到链码段的注册消息，则认为启动失败
executetimeout: 30s ## invoke 和 initialize 命令执行超时时间
deploytimeout: ## 部署链码的命令执行超时时间 mode: net ## 执行链码的模式，dev: 允许本地直接运行链码，方便调试； net: 意味着在容器中运行链码 keepalive: 0 ## Peer 和链码之间的心跳超市时间， <= 0 意味着关闭 system: ## 系统链码的相关配置 (系统链码白名单 ??) cscc: enable lscc: enable escc: enable vscc: enable qscc: enable systemPlugins: ## 系统链码插件 logging: ## 链码容器日志相关配置 level: info shim: warning 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: ## 状态DB的相关配置(包括 golevelDB、couchDB)、DN连接、查询最大返回记录数等 stateDatabase: goleveldb ## stateDB的底层DB配置 (默认golevelDB) couchDBConfig: ## 如果启用couchdb，配置连接信息 (goleveldb 不需要配置这些) couchDBAddress: 127.0.0.1:5984 username: o prevent unintended users from discovering the password. password: maxRetries: 3 ## 运行时出错重试数 maxRetriesOnStartup: 10 ## 启动时出错的重试数 requestTimeout: 35s ## 请求超时时间 queryLimit: 10000 ## 每个查询最大返回数 maxBatchUpdateSize: 1000 ## 批量更新最大记录数 warmIndexesAfterNBlocks: 1 history: enableHistoryDatabase: true ## 是否启用历史数据库，默认开启
############################################################################### # # Metrics section 服务度量监控配置 # # ############################################################################### metrics: enabled: false ## 是否开启监控服务 reporter: statsd interval: 1s statsdReporter: address: 0.0.0.0:8125 flushInterval: 2s flushBytes: 1432 promReporter: ## prometheus 普罗米修斯服务监听地址 listenAddress: 0.0.0.0:8080 |
节点证书
| ordererOrganizations └── example.com ├── ca # 包含给Orderer组织颁发MSP证书的ca的公私钥 │ ├── ca.example.com-cert.pem │ └── e254d4b2463ddee8318d479f9ce7cebc54a5188917070cd55f60bda06df8733c_sk ├── msp # 包含Orderer组织的msp相关证书（admincerts，cacerts，tlscacerts） │ ├── admincerts # 组织管理员 身份验证证书，【被根证书签名】 │ │ └── Admin@example.com-cert.pem │ ├── cacerts # 组织的根证书 【和CA目录 里面一致】 │ │ └── ca.example.com-cert.pem │ └── tlscacerts # 用于TLS的CA证书， 【自签名】 │ └── tlsca.example.com-cert.pem ├── orderers # 存放所有 Orderer 的身份信息 │ ├── orderer0.example.com # 第一个 Orderer 的信息 msp 及 tls │ │ ├── msp │ │ │ ├── admincerts # 组织管理员的身份验证证书。Peer将给予这些证书来确认交易签名是否为管理员签名 【和MSP.admincerts 一致】 │ │ │ │ └── Admin@example.com-cert.pem │ │ │ ├── cacerts # 给Orderer组织颁发MSP证书的ca的证书 │ │ │ │ └── ca.example.com-cert.pem │ │ │ ├── keystore # 当前Orderer组织的私钥 │ │ │ │ └── 26e5eb7dfa37c20d2f2b177fc08a6b18d66be40d49a24dacdcf233595ec30d94_sk │ │ │ ├── signcerts # 当前Orderer组织的证书（包含公钥） │ │ │ │ └── orderer0.example.com-cert.pem │ │ │ └── tlscacerts # 给Orderer组织颁发TLS证书的ca的证书 │ │ │ └── tlsca.example.com-cert.pem │ │ └── tls │ │ ├── ca.crt # 【组织的根证书】 │ │ ├── server.crt # 验证本节点签名的证书，【被根证书签名】 │ │ └── server.key # 本节点的身份私钥，用来签名 │ ├── orderer1.example.com │ │ ├── msp │ │ │ ├── admincerts │ │ │ │ └── Admin@example.com-cert.pem │ │ │ ├── cacerts │ │ │ │ └── ca.example.com-cert.pem │ │ │ ├── keystore │ │ │ │ └── b4bc965178104fe156caf82e8ad4e66c92756b9aaca3c43e7c41708f6d58215e_sk │ │ │ ├── signcerts │ │ │ │ └── orderer1.example.com-cert.pem │ │ │ └── tlscacerts │ │ │ └── tlsca.example.com-cert.pem │ │ └── tls │ │ ├── ca.crt │ │ ├── server.crt │ │ └── server.key │ └── orderer2.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── Admin@example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.example.com-cert.pem │ │ ├── keystore │ │ │ └── 18391588e91f62c565ed84a78e60e52c9ad51dd979ff8ec5d967a419f08eed7b_sk │ │ ├── signcerts │ │ │ └── orderer2.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── server.crt │ └── server.key ├── tlsca # 包含给Orderer组织颁发TLS证书的ca的公私钥 │ ├── 920c2a2257410b6e125ab765734f7d51b1b7f01d5ef7a09de63292298e2dd260_sk │ └── tlsca.example.com-cert.pem └── users # 包含Orderer下普通用户和管理员用户的msp和tls证书 └── Admin@example.com # 管理员用户的信息，其中包括msp证书和tls证书两类 ├── msp │ ├── admincerts │ │ └── Admin@example.com-cert.pem │ ├── cacerts │ │ └── ca.example.com-cert.pem │ ├── keystore │ │ └── 163feb01e4891424ce715d75d20a5d049464ff5c0b25caba61e40b6a7e4087d0_sk │ ├── signcerts │ │ └── Admin@example.com-cert.pem │ └── tlscacerts │ └── tlsca.example.com-cert.pem └── tls ├── ca.crt ├── client.crt └── client.key
peerOrganizations └── org1.example.com # 第一个组织的所有身份证书 ├── ca # 存放组织根证书及私钥 (采用EC算法) 证书为【自签名】，组织内的实体将给予该根证书作为证书根 │ ├── ca.org1.example.com-cert.pem │ └── f927725bac311668c1ee983e7adff9124edaabeee35ffccaa1bbb1e02ea4e820_sk ├── msp # 存放该组织身份信息 │ ├── admincerts # 组织管理员 身份验证证书，【被根证书签名】 │ │ └── Admin@org1.example.com-cert.pem │ ├── cacerts # 组织的根证书 【和CA目录 里面一致】 │ │ └── ca.org1.example.com-cert.pem │ ├── config.yaml # 记录 OrganizationalUnitIdentitifiers 信息，包括 根证书位置 和 ID信息 (主要是 crypto-config.yaml 的peer配置中配了 EnableNodeOUs: true ： 如果设置了EnableNodeOUs，就在msp下生成config.yaml文件) │ └── tlscacerts # 用于TLS的CA证书， 【自签名】 │ └── tlsca.org1.example.com-cert.pem ├── peers # 存放所有 Peer 的身份信息 │ ├── peer0.org1.example.com │ │ ├── msp │ │ │ ├── admincerts │ │ │ │ └── Admin@org1.example.com-cert.pem │ │ │ ├── cacerts │ │ │ │ └── ca.org1.example.com-cert.pem │ │ │ ├── config.yaml │ │ │ ├── keystore │ │ │ │ └── f29be486ec42d4397a091acf457d79400e49ed9146b95ae7ec393296ec9b4138_sk │ │ │ ├── signcerts │ │ │ │ └── peer0.org1.example.com-cert.pem │ │ │ └── tlscacerts │ │ │ └── tlsca.org1.example.com-cert.pem │ │ └── tls │ │ ├── ca.crt │ │ ├── server.crt │ │ └── server.key │ ├── peer1.org1.example.com │ │ ├── msp │ │ │ ├── admincerts │ │ │ │ └── Admin@org1.example.com-cert.pem │ │ │ ├── cacerts │ │ │ │ └── ca.org1.example.com-cert.pem │ │ │ ├── config.yaml │ │ │ ├── keystore │ │ │ │ └── 21f08b518f02cb38270ddcc359ce19931dc9ae89a4fdf149a69da9afb1142561_sk │ │ │ ├── signcerts │ │ │ │ └── peer1.org1.example.com-cert.pem │ │ │ └── tlscacerts │ │ │ └── tlsca.org1.example.com-cert.pem │ │ └── tls │ │ ├── ca.crt │ │ ├── server.crt │ │ └── server.key │ ├── peer2.org1.example.com │ │ ├── msp │ │ │ ├── admincerts │ │ │ │ └── Admin@org1.example.com-cert.pem │ │ │ ├── cacerts │ │ │ │ └── ca.org1.example.com-cert.pem │ │ │ ├── config.yaml │ │ │ ├── keystore │ │ │ │ └── 03a4dab32984788ab4e16ad8b35241d450f9459345a0a8a94b5895c9cca407a2_sk │ │ │ ├── signcerts │ │ │ │ └── peer2.org1.example.com-cert.pem │ │ │ └── tlscacerts │ │ │ └── tlsca.org1.example.com-cert.pem │ │ └── tls │ │ ├── ca.crt │ │ ├── server.crt │ │ └── server.key │ └── peer3.org1.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── Admin@org1.example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.org1.example.com-cert.pem │ │ ├── config.yaml │ │ ├── keystore │ │ │ └── 3dd435cab316f0c77a49ab3a3c59a990045dc12d30351a013faad3e4ca3bad48_sk │ │ ├── signcerts │ │ │ └── peer3.org1.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.org1.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── server.crt │ └── server.key ├── tlsca # 存放tls相关的证书和私钥 │ ├── f1dd977a02b48cc48cb297c55289b5028c104d747dff828054c56e68286ae3b2_sk │ └── tlsca.org1.example.com-cert.pem └── users ├── Admin@org1.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── Admin@org1.example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.org1.example.com-cert.pem │ │ ├── keystore │ │ │ └── d5caa8a030c4afde16c16f79de24bb2c53ea30bf4ef3fbf1ac129d9e0e671ab0_sk │ │ ├── signcerts │ │ │ └── Admin@org1.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.org1.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── client.crt │ └── client.key ├── User1@org1.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── User1@org1.example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.org1.example.com-cert.pem │ │ ├── keystore │ │ │ └── 94f5dee62e28c1aa70333fbe9caf4bcf25b43671fe4dfe34c9cb5a3336c087e0_sk │ │ ├── signcerts │ │ │ └── User1@org1.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.org1.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── client.crt │ └── client.key ├── User2@org1.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── User2@org1.example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.org1.example.com-cert.pem │ │ ├── keystore │ │ │ └── d56df33a16908ea50702a1710de3eae69160e9215d1070dc8d6e171f5f85b44b_sk │ │ ├── signcerts │ │ │ └── User2@org1.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.org1.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── client.crt │ └── client.key ├── User3@org1.example.com │ ├── msp │ │ ├── admincerts │ │ │ └── User3@org1.example.com-cert.pem │ │ ├── cacerts │ │ │ └── ca.org1.example.com-cert.pem │ │ ├── keystore │ │ │ └── 2d1be077615cf21da32553fe40a95e1677975ac6542881af0c2fd1283c6ef374_sk │ │ ├── signcerts │ │ │ └── User3@org1.example.com-cert.pem │ │ └── tlscacerts │ │ └── tlsca.org1.example.com-cert.pem │ └── tls │ ├── ca.crt │ ├── client.crt │ └── client.key └── User4@org1.example.com ├── msp │ ├── admincerts │ │ └── User4@org1.example.com-cert.pem │ ├── cacerts │ │ └── ca.org1.example.com-cert.pem │ ├── keystore │ │ └── 4875a44bb21a209c64e4c019e8359a319c0ab95b9fb3037f04a82d830e106fa3_sk │ ├── signcerts │ │ └── User4@org1.example.com-cert.pem │ └── tlscacerts │ └── tlsca.org1.example.com-cert.pem └── tls ├── ca.crt ├── client.crt └── client.key |
|
补充说明
1、MSP证书解释
- admincerts：管理员证书，它比普通的peer0证书有一些特殊的权限，比如对节点的修改或者配置等操作
- cacerts：里面放的是对这个peer0颁发证书的ca是谁，里面放的是ca的公钥
- keystore：是peer0这个节点msp的自己的私钥
- signcerts：里面放的是这个organization的ca（ca.org1.example.com-cert.pem）给peer0颁发的证书
- tlscacerts：里面放的是对这个peer0办法TLS证书的ca是谁，里面放的是TLS ca的公钥
- admincerts和signcerts都是签发之后的证书，只是他们的角色不同，admincerts对peer0有一些特殊的管理权限，但signcerts只是一个普通的certs
2、TLS证书解释
- ca.crt：TLS安全认证过程的时候验证证书的ca
- server.crt：节点本身的TLS证书
- server.key：节点本身的TLS私钥
487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
