fabric的各个配置文件做讲解
【我的区块链之路】- Hyperledger fabric的简单入门（三）fabric主要配置文件细讲
2018年07月26日 12:50:38 GavinXujiacan 阅读数：689
fabric的各个配置文件做讲解
【转载请标明出处】：https://blog.csdn.net/qq_25870633/article/details/81184781
-
Peer 配置剖析
本例子是拿fabric-samples 来说的，【如果是 fabric 的话，在 fabric/的根目录下有一个 core.yaml 】在 fabric-samples/config 目录下有一个 core.yaml 文件 该文件就是 peer 节点的各项配置，其中主要包含了：logging （日志）、 peer （节点）、 vm （链码运行环境）、chaincode （链码相关）、ledger （账本） 等 5 大部分
文件内容及各项说明如下所示：
-
logging: ## 日志级别有： critical、 error、 warning、 notice、 info、 debug 级别由大到小， 级别越小输出越详细 -
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: ## 本地私钥文件路径，默认指向/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
-
Orderer 配置剖析
在 fabric-samples/config 目录下有一个 orderer.yaml 文件 该文件就是 Orderer 节点的各项配置，其中主要包含了：General（日志）、 FileLedger（节点）、 RAMLedger（链码运行环境）、Kafka（链码相关） 等 4 大部分
文件内容及各项说明如下所示：
-
################################################################################ -
# -
# Orderer Configuration orderer的配置 -
# -
# - This controls the type and configuration of the orderer. -
# -
################################################################################ -
General: -
LedgerType: file ## 账本类型，支持ram、json、file 三种类型【建议用file】，其中ram保存在内存中；json、file保存在本地文件中 (通常为 /var/hyperledger/production/orderer 下) -
ListenAddress: 127.0.0.1 ## 服务监听地址，一般需要制定为服务的特定网络接口地址 或者全网(0.0.0.0) -
ListenPort: 7050 ## 服务监听端口 默认7050 -
TLS: ## 启用TLS 时的相关配置 (grpc 传输) -
Enabled: false -
PrivateKey: tls/server.key ## Orderer 签名私钥 -
Certificate: tls/server.crt ## Orderer 身份证书 -
RootCAs: -
- tls/ca.crt ## 根证书 -
ClientAuthRequired: false ## 是否对客户端也进行认证 -
ClientRootCAs: -
Keepalive: ## 设置GRPC 服务心跳检查 -
ServerMinInterval: 60s ## 客户端和 orderer 的 最小心跳间隔 -
ServerInterval: 7200s ## 客户端和 orderer 的心跳间隔时间 -
ServerTimeout: 20s ## 客户端和 Orderer 的超时时间 -
LogLevel: info ## 日志等级 -
## 日志输出格式 -
LogFormat: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}' -
GenesisMethod: provisional ## 创世块的提供方式 (系统通道初始区块的提供方式，支持 provisional 或者 file；前者根据GenesisProfile 指定默认的 $FABRIC_CFG_PATH/config.yaml 文件中的profile生成；后者使用GenesisFile 指定现成的初始区块文件) -
GenesisProfile: SampleInsecureSolo ## 创世块使用的Profile；GenesisMethod: provisional 才有效 -
GenesisFile: genesisblock ## 使用现成创世块文件时，文件的路径 [创世块的位置] GenesisMethod: file 才有效 -
LocalMSPDir: msp ## 本地MSP文件的路径 【orderer节点所需的安全认证文件的位置】 -
LocalMSPID: SampleOrg ## Orderer所关联的MSP的ID MSP管理器用于注册安全认证文件的ID, 此ID必须与配置系统通道和创世区块时(configtx.yaml的OrdererGenesis部分)指定的组织中的某一个组织的ID一致 -
Profile: ## 为Go pprof性能优化工具启用一个HTTP服务以便作性能分析(https://golang.org/pkg/net/http/pprof) -
Enabled: false ## 不启用 -
Address: 0.0.0.0:6060 ## Go pprof的HTTP服务监听的地址和端口 -
BCCSP: ## 加密库配置 具体参照Peer 配置 -
Default: SW -
SW: -
Hash: SHA2 -
Security: 256 -
FileKeyStore: -
KeyStore: -
Authentication: -
TimeWindow: 15m -
################################################################################ -
# -
# SECTION: File Ledger 基于文件账本 配置 (file和json两种类型) -
# -
# - This section applies to the configuration of the file or json ledgers. -
# -
################################################################################ -
FileLedger: -
Location: /var/hyperledger/production/orderer ## 指定存放文件的位置，一般为 /var/hyperledger/production/orderer, 该目录下的 chains目录存放各个chain的区块，index目录存放 索引文件 (如果这项不指定, 每次节点重启都将使用一个新的临时位置) -
Prefix: hyperledger-fabric-ordererledger ## 如果不指定Location，则在临时目录下创建账本时目录的名称 -
################################################################################ -
# -
# SECTION: RAM Ledger 基于内存账本 配置 -
# -
# - This section applies to the configuration of the RAM ledger. -
# -
################################################################################ -
RAMLedger: -
HistorySize: 1000 ## 内存账本所支持存储的区块的数量, 如果内存中存储的区块达到上限, 继续追加区块会导致最旧的区块被丢弃 -
################################################################################ -
# -
# SECTION: Kafka kafka 集群配置 -
# -
# - This section applies to the configuration of the Kafka-based orderer, and -
# its interaction with the Kafka cluster. -
# -
################################################################################ -
Kafka: -
# kafka是一种基于发布/订阅模式的分布式消息系统 -
# fabric网络中, orderer节点集群组成kafka集群, 客户端是kafka集群的Producer(消息生产者), peer是kafka集群的Consumer(消息消费者) -
# kafka集群使用ZooKeeper(分布式应用协调服务)管理集群节点, 选举leader. -
Retry: ## 连接时的充实操作 kafka 会利用 sarama 客户端为chennel创建一个producer 负责向kafka 写数据，一个comsumer负责kafka读数据 -
ShortInterval: 5s ## 操作失败后的快速重试间隔时间 -
ShortTotal: 10m ## 快速重试阶段最对重试多久 -
LongInterval: 5m ## 快速充实阶段仍然失败后进入 慢重试阶段，慢重试的时间间隔 -
LongTotal: 12h ## 慢重试最多重试多久 -
# https://godoc.org/github.com/Shopify/sarama#Config -
NetworkTimeouts: ## Sarama 网络超时时间 -
DialTimeout: 10s -
ReadTimeout: 10s -
WriteTimeout: 10s -
Metadata: ## kafka集群leader 选举中的metadata 请求参数 -
RetryBackoff: 250ms ## leader选举过程中元数据请求失败的重试间隔 -
RetryMax: 3 ## 最大重试次数 -
Producer: ## 发送消息到kafka集群时的超时 -
RetryBackoff: 100ms ## 向kafka集群发送消息失败后的重试间隔 -
RetryMax: 3 ## 最大重试次数 -
Consumer: ## 从kafka集群接收消息时的超时 -
RetryBackoff: 2s ## 从kafka集群拉取消息失败后的重试间隔 -
Verbose: false ## 是否开启kafka的客户端的调试日志 (orderer与kafka集群交互是否生成日) -
TLS: ## 与kafka集群的连接启用TLS时的相关配置 -
Enabled: false ## 是否开启TLS，默认不开启 -
PrivateKey: ## Orderer 身份签名私钥 -
# File: ## 私钥文件路径 -
Certificate: ## kafka的身份证书 -
# File: ## 证书文件路径 -
RootCAs: ## 验证kafka证书时的根证书 -
# File: ## 根证书文件路径 -
Version: ## kafka的版本，默认为 0.9.0.1 -
################################################################################ -
# -
# Debug Configuration orderer节点的调试参数 -
# -
# - This controls the debugging options for the orderer -
# -
################################################################################ -
Debug: -
BroadcastTraceDir: ## 该orderer节点的广播服务请求保存的位置 -
DeliverTraceDir: ## 该orderer节点的传递服务请求保存的位置
-
核心配置 crypto-config.yaml 配置剖析
我们在【我的区块链之路】- Hyperledger fabric的简单入门（二）中已经知道，在启动网络前，我们需要做一些准备工作，例如： 先使用cryptogen工具及 crypto-config.yaml 配置文件，生成整个fabric网络的组织架构及对应的身份证书；在crypto-config.yaml 文件中我们定义了 整个fabric网络的组织结构，然后工具会根据定义的配置生成对应的组织结构及把对应的身份证书放置对应的目录下以便区分使用；
具体的 crypto-config.yaml 文件内容如下所示：
-
OrdererOrgs: ## 定义Orderer组织结构 -
- Name: Orderer ## Orderer的名称 -
Domain: example.com ## 组织的命名域 -
# --------------------------------------------------------------------------- -
# "Specs" - 有关完整说明，请参阅下面的PeerOrgs -
# --------------------------------------------------------------------------- -
Specs: -
- Hostname: orderer -
# --------------------------------------------------------------------------- -
# "PeerOrgs" - 管理Peer节点的组织的定义 -
# --------------------------------------------------------------------------- -
PeerOrgs: -
- Name: Org1 ## 组织名称 组织 1 -
Domain: org1.example.com ## 组织域 -
EnableNodeOUs: true ## 如果设置了EnableNodeOUs，就在msp下生成config.yaml文件 -
Template: ## 允许定义从模板顺序创建的1个或多个主机。 默认情况下，这看起来像是从0到Count-1的“peer”。 您可以覆盖节点数（Count），起始索引（Start）或用于构造名称的模板（Hostname）。 -
Count: 2 ## 表示生成几个Peer -
# Start: 5 -
# Hostname: {{.Prefix}}{{.Index}} # default -
# --------------------------------------------------------------------------- -
# "Users" -
# --------------------------------------------------------------------------- -
# Count: 除Admin之外的用户帐户数量 -
# --------------------------------------------------------------------------- -
Users: -
Count: 1 ## 表示生成几个 普通User -
# --------------------------------------------------------------------------- -
# Org2: 参照 组织 1 -
# --------------------------------------------------------------------------- -
- Name: Org2 -
Domain: org2.example.com -
EnableNodeOUs: true -
Template: -
Count: 2 -
Users: -
Count: 1
紧接着我们就可以使用命令来生成我们的组织结构及对应目录下的身份证书了：
cryptogen generate --config=./crypto-config.yaml上述命令默认会在当前目录生成一个名叫 crypto-config 目录，当然也可以在命令中添加 --output 选项来指定输出的目录；在这个目录下就会根据Orderer 和Peer 各自生成两个 文件夹： ordererOrganizations 和 peerOrganizations 分别代表着Orderer 和Peer的组织及对应目录下的证书文件；每个组织树下都有ca、msp、orderers(或者Peers)、users 等4个目录；下面我们来详细的说明下这两个组织下都是些什么：
-
. ## Orderer 组织配置 -
├── ordererOrganizations -
│ │ -
│ └── example.com -
│ │ -
│ ├── ca ## 存放组织根证书 及 私钥 (采用EC算法) 证书为【自签名】，组织内的实体将给予该根证书作为证书根 -
│ │ -
│ │ ├── 56d9c0c46acdda38a174a5ba3ffc44726a2c027e16bb22b460413acbcb9b3a90_sk -
│ │ │ -
│ │ └── ca.example.com-cert.pem -
│ │ -
│ ├── msp ## 存放该组织身份信息 -
│ │ │ -
│ │ ├── admincerts ## 组织管理员 身份验证证书，【被根证书签名】 -
│ │ │ │ -
│ │ │ └── [email protected] -
│ │ │ -
│ │ ├── cacerts ## 组织的根证书 【和CA目录 里面一致】 -
│ │ │ │ -
│ │ │ └── ca.example.com-cert.pem -
│ │ │ -
│ │ └── tlscacerts ## 用于TLS的CA证书， 【自签名】 -
│ │ │ -
│ │ └── tlsca.example.com-cert.pem -
│ │ -
│ │ -
│ ├── orderers ## 存放所有 Orderer 的身份信息 -
│ │ │ -
│ │ └── orderer.example.com ## 第一个 Orderer 的信息 msp 及 tls -
│ │ │ -
│ │ ├── msp -
│ │ │ │ -
│ │ │ ├── admincerts ## 组织管理员的身份验证证书。Peer将给予这些证书来确认交易签名是否为管理员签名 【和MSP.admincerts 一致】 -
│ │ │ │ │ -
│ │ │ │ └── [email protected] -
│ │ │ │ -
│ │ │ ├── cacerts -
│ │ │ │ │ -
│ │ │ │ └── ca.example.com-cert.pem ## 存放组织根证书，【和CA目录 里面一致】 -
│ │ │ │ -
│ │ │ ├── keystore ## 本节点的身份私钥，用来签名 -
│ │ │ │ │ -
│ │ │ │ └── 2ec1193fe048848eaa8e20666e26c527b791c4fb127d69cae65095bd31b6c80e_sk -
│ │ │ │ -
│ │ │ ├── signcerts ## 验证本节点签名的证书，【被根证书签名】 -
│ │ │ │ │ -
│ │ │ │ └── orderer.example.com-cert.pem -
│ │ │ │ -
│ │ │ └── tlscacerts ## TLS连接用的身份证书， 【和msp.tlscacerts 一致】 -
│ │ │ │ -
│ │ │ └── tlsca.example.com-cert.pem -
│ │ │ -
│ │ └── tls ## tls 的相关信息 -
│ │ ├── ca.crt ## 【组织的根证书】 -
│ │ ├── server.crt ## 验证本节点签名的证书， 【被根证书签名】 -
│ │ └── server.key ## 本节点的身份私钥，用来签名 -
│ │ -
│ ├── tlsca ## 存放tls相关的证书和私钥 -
│ │ │ -
│ │ ├── 2d66be83c519da67bb36b0972256a3b24357fa7f5b3a61f11405bc8b1f4d7c53_sk -
│ │ │ -
│ │ └── tlsca.example.com-cert.pem -
│ │ -
│ └── users ## 存放属于该组织的用户的实体 -
│ │ -
│ └── [email protected] ## 管理员用户的信息，其中包括msp证书和tls证书两类 -
│ │ -
│ ├── msp -
│ │ │ -
│ │ ├── admincerts ## 组织根证书作为管理员身份验证证书，【和MSP.admincerts 一致】 -
│ │ │ │ -
│ │ │ └── [email protected] -
│ │ │ -
│ │ ├── cacerts ## 存放组织的根证书，【和CA目录 里面一致】 -
│ │ │ │ -
│ │ │ └── ca.example.com-cert.pem -
│ │ │ -
│ │ ├── keystore ## 本用户的身份私钥，用来签名 -
│ │ │ │ -
│ │ │ └── a3c1d7e1bc464faf2e3a205cb76ea231bd3ee7010655d3cd31dc6cb78726c4d0_sk -
│ │ │ -
│ │ ├── signcerts ## 管理员用户的身份验证证书，被组织根证书签名。要被某个Orderer认可，则必须放到该 Orderer 的msp/admincerts目录下 -
│ │ │ │ -
│ │ │ └── [email protected] -
│ │ │ -
│ │ └── tlscacerts ## TLS连接用的身份证书，即组织TLS证书，【和msp.tlscacerts 一致】 -
│ │ │ -
│ │ └── tlsca.example.com-cert.pem -
│ │ -
│ │ -
│ └── tls ## tls 的相关信息 -
│ ├── ca.crt -
│ ├── client.crt ## 管理员的身份验证证书，【被 组织根证书签名】 -
│ └── client.key ## 管理员的身份私钥，用来签名 -
│ -
│ -
│ -
│ ## Peer 组织配置 -
└── peerOrganizations -
│ -
├── org1.example.com ## 第一个组织的所有身份证书 -
│ │ -
│ ├── ca ## 存放组织根证书及私钥 (采用EC算法) 证书为【自签名】，组织内的实体将给予该根证书作为证书根 -
│ │ │ -
│ │ ├── 496d6a41ae5f66bf120df3eab3a9d2dc4d268b2ab9a22af891d33d323bbdb5c8_sk -
│ │ │ -
│ │ └── ca.org1.example.com-cert.pem -
│ │ -
│ ├── msp ## 存放该组织身份信息 -
│ │ │ -
│ │ ├── admincerts ## 组织管理员 身份验证证书，【被根证书签名】 -
│ │ │ │ -
│ │ │ └── [email protected] -
│ │ │ -
│ │ ├── 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 ## 第一个Peer的信息 msp 及 tls -
│ │ │ │ -
│ │ │ ├── msp -
│ │ │ │ │ -
│ │ │ │ ├── admincerts ## 组织管理员的身份验证证书。Peer将给予这些证书来确认交易签名是否为管理员签名 【和MSP.admincerts 一致】 -
│ │ │ │ │ │ -
│ │ │ │ │ └── [email protected] -
│ │ │ │ │ -
│ │ │ │ ├── cacerts ## 存放组织根证书，【和CA目录 里面一致】 -
│ │ │ │ │ │ -
│ │ │ │ │ └── ca.org1.example.com-cert.pem -
│ │ │ │ │ -
│ │ │ │ ├── config.yaml -
│ │ │ │ │ -
│ │ │ │ ├── keystore ## 本节点的身份私钥，用来签名 -
│ │ │ │ │ │ -
│ │ │ │ │ └── 0f0c2e1835086161f6a10c4bb38c2d89b2cee4e1128cee0fcda4433feb6eb6f8_sk -
│ │ │ │ │ -
│ │ │ │ │ -
│ │ │ │ ├── signcerts ## 验证本节点签名的证书，【被根证书签名】 -
│ │ │ │ │ │ -
│ │ │ │ │ └── peer0.org1.example.com-cert.pem -
│ │ │ │ │ -
│ │ │ │ └── tlscacerts ## TLS连接用的身份证书， 【和msp.tlscacerts 一致】 -
│ │ │ │ │ -
│ │ │ │ └── tlsca.org1.example.com-cert.pem -
│ │ │ │ -
│ │ │ │ -
│ │ │ └──tls ## tls 的相关信息 -
│ │ │ ├── ca.crt ## 【组织的根证书】 -
│ │ │ ├── server.crt ## 验证本节点签名的证书， 【被根证书签名】 -
│ │ │ └── server.key ## 本节点的身份私钥，用来签名 -
│ │ │ -
│ │ │ -
│ │ └── peer1.org1.example.com -
│ │ -
│ │ -
│ │ -
│ │ -
│ ├── tlsca ## 存放tls相关的证书和私钥 -
│ │ │ -
│ │ ├── 3d39ea82dd5343c261b0480bc13d645a3cee13b7e7aa8c54fd2b5162f709671f_sk -
│ │ └── tlsca.org1.example.com-cert.pem -
│ │ -
│ │ -
│ │ -
│ └── users ## 存放属于该组织的用户的实体 -
│ │ -
│ ├── [email protected] ## 管理员用户的信息，其中包括msp证书和tls证书两类 -
│ │ │ -
│ │ ├── msp -
│ │ │ │ -
│ │ │ ├── admincerts ## 组织根证书作为管理员身份验证证书，【和MSP.admincerts 一致】 -
│ │ │ │ │ -
│ │ │ │ └── [email protected] -
│ │ │ │ -
│ │ │ ├── cacerts ## 存放组织的根证书，【和CA目录 里面一致】 -
│ │ │ │ │ -
│ │ │ │ └── ca.org1.example.com-cert.pem -
│ │ │ │ -
│ │ │ ├── keystore ## 本用户的身份私钥，用来签名 -
│ │ │ │ │ -
│ │ │ │ └── 2b933c0740d857284be98ff218bf279261e55eff2b89d973e0a1f435f7c7d28b_sk -
│ │ │ │ -
│ │ │ ├── signcerts ## 管理员用户的身份验证证书，被组织根证书签名。要被某个Peer认可，则必须放到该Peer的msp/admincerts目录下 -
│ │ │ │ │ -
│ │ │ │ └── [email protected] -
│ │ │ │ -
│ │ │ └── tlscacerts ## TLS连接用的身份证书，即组织TLS证书，【和msp.tlscacerts 一致】 -
│ │ │ │ -
│ │ │ └── tlsca.org1.example.com-cert.pem -
│ │ │ -
│ │ └── tls ## tls 的相关信息 -
│ │ ├── ca.crt -
│ │ ├── client.crt ## 管理员的身份验证证书，【被 组织根证书签名】 -
│ │ └── client.key ## 管理员的身份私钥，用来签名 -
│ │ -
│ │ -
│ └── [email protected] -
│ ├── msp -
│ │ ├── admincerts ## 组织根证书作为管理员身份验证证书 -
│ │ │ └── [email protected] -
│ │ ├── cacerts ## 存放组织的根证书，【和CA目录 里面一致】 -
│ │ │ └── ca.org1.example.com-cert.pem -
│ │ ├── keystore ## 【参考admin】 -
│ │ │ └── 11ebc5afac42348f84a8882f329d18beee079efd4fd5d9b30389dc82053fc0c9_sk -
│ │ ├── signcerts ## 【参考admin】 -
│ │ │ └── [email protected] -
│ │ └── tlscacerts ## 【参考admin】 -
│ │ └── tlsca.org1.example.com-cert.pem -
│ └── tls ## 【参考admin】 -
│ ├── ca.crt -
│ ├── client.crt -
│ └── client.key -
│ -
└── org2.example.com
我们可以知道 cryptogen 工具无非就是在各个资源下生成 组织 和 私钥、证书等等，其中最关键的就是 各个资源下的MSP 目录内容：
- admincerts： 管理员的身份证书文件
- cacerts： 信任的根证书文件
- keystore： 节点的签名私钥文件
- signcerts： 节点的签名身份证书文件
- tlscacerts： TLS连接用的证书
等等 5 种文件
-
通道及锚节点的配置 configtx.yaml 配置剖析
在上一篇文章中我们知道在启动网络之前我们需要做一些准备工作，上面我们已经使用 cryptogen 工具生成了 组织的结构及对应的 身份证书等等。现在我们需要使用 configtxgen 这个工具并使用 在 fabric-samples/config 目录下的 configtx.yaml 这个核心配置文件用来做三件事：【1】生成启动 Orderer 需要的创世块；【2】创建应用通道的 配置交易文件；【3】生成组织锚节点更新配置交易文件 ；在 configtx.yaml 配置中主要包括：Profiles、Organizations、Orderer、Application 等等 4 部分；
具体的 configtx.yaml 内容如下所示：
-
## 一些列组织的定义，【被其他 部分引用】 -
## -
## 【注意】：本文件中 &KEY 均为 *KEY 所引用； xx：&KEY 均为 <<: *KEY 所引用 -
## -
Organizations: -
## 定义Orderer组织 【&OrdererOrg 这类语法类似 Go的中的指针及对象地址， 此处是被Profiles 中的 - *OrdererOrg 所引用，以下均为类似做法】 -
- &OrdererOrg -
Name: OrdererOrg ## Orderer的组织的名称 -
ID: OrdererMSP ## Orderer 组织的ID （ID是引用组织的关键） -
MSPDir: crypto-config/ordererOrganizations/example.com/msp ## Orderer的 MSP 证书目录路径 -
AdminPrincipal: Role.ADMIN ## 【可选项】 组织管理员所需要的身份，可选项: Role.ADMIN 和 Role.MEMBER -
## 定义Peer组织 1 -
- &Org1 -
Name: Org1MSP ## 组织名称 -
ID: Org1MSP ## 组织ID -
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp ## Peer的MSP 证书目录路径 -
AnchorPeers: ## 定义组织锚节点 用于跨组织 Gossip 通信 -
- Host: peer0.org1.example.com ## 锚节点的主机名 -
Port: 7051 ## 锚节点的端口号 -
## 定义Peer组织 2 -
- &Org2 -
Name: Org2MSP -
ID: Org2MSP -
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp -
AnchorPeers: -
- Host: peer0.org2.example.com -
Port: 7051 -
################################################################################ -
# -
# SECTION: Capabilities 【注意】： 该部分是 V1.1.0 版本提出来的， 不可以在更早的版本中使用 -
# -
# - 本节定义了 fabric 网络的功能. 这是v1.1.0中的一个新概念，不应在v1.0.x的peer和orderers中使用. -
# Capabilities 定义了存在于结构二进制文件中的功能，以便该二进制文件安全地参与结构网络. -
# 例如，如果添加了新的MSP类型，则较新的二进制文件可能会识别并验证此类型的签名，而没有此支持的旧二进制文件将无法验证这些事务. -
# 这可能导致具有不同世界状态的不同版本的结构二进制文件。 相反，为通道定义功能会通知那些没有此功能的二进制文件， -
# 它们必须在升级之前停止处理事务. 对于v1.0.x，如果定义了任何功能（包括关闭所有功能的配置），那么v1.0.x的peer 会主动崩溃. -
# -
################################################################################ -
Capabilities: -
## 通道功能适用于orderers and the peers，并且必须得到两者的支持。 将功能的值设置为true. -
Global: &ChannelCapabilities -
## V1.1 的 Global是一个行为标记，已被确定为运行v1.0.x的所有orderers和peers的行为，但其修改会导致不兼容。 用户应将此标志设置为true. -
V1_1: true -
## Orderer功能仅适用于orderers，可以安全地操纵，而无需担心升级peers。 将功能的值设置为true -
Orderer: &OrdererCapabilities -
## Orderer 的V1.1是行为的一个标记，已经确定为运行v1.0.x的所有orderers 都需要，但其修改会导致不兼容。 用户应将此标志设置为true -
V1_1: true -
## 应用程序功能仅适用于Peer 网络，可以安全地操作，而无需担心升级或更新orderers。 将功能的值设置为true -
Application: &ApplicationCapabilities -
## V1.2 for Application是一个行为标记，已被确定为运行v1.0.x的所有peers所需的行为，但其修改会导致不兼容。 用户应将此标志设置为true -
V1_2: true -
################################################################################ -
# -
# SECTION: Application -
# -
# - 应用通道相关配置，主要包括 参与应用网络的可用组织信息 -
# -
################################################################################ -
Application: &ApplicationDefaults ## 自定义被引用的地址 -
Organizations: ## 加入通道的组织信息 -
################################################################################ -
# -
# SECTION: Orderer -
# -
# - Orderer 系统通道相关配置，包括 Orderer 服务配置和参与Orderer 服务的可用组织 -
# -
# Orderer 默认是 solo 的 且不包含任何组织 【主要被 Profiles 部分引用】 -
################################################################################ -
Orderer: &OrdererDefaults ## 自定义被引用的地址 -
OrdererType: solo ## Orderer 类型，包含 solo 和 kafka 集群 -
Addresses: ## 服务地址 -
- orderer.example.com:7050 -
BatchTimeout: 2s ## 区块打包的最大超时时间 (到了该时间就打包区块) -
BatchSize: ## 区块打包的最大包含交易数 -
MaxMessageCount: 10 ## 一个区块里最大的交易数 -
AbsoluteMaxBytes: 99 MB ## 一个区块的最大字节数， 任何时候都不能超过 -
PreferredMaxBytes: 512 KB ## 一个区块的建议字节数，如果一个交易消息的大小超过了这个值, 就会被放入另外一个更大的区块中 -
MaxChannels: 0 ## 【可选项】 表示Orderer 允许的最大通道数， 默认 0 表示没有最大通道数 -
Kafka: -
Brokers: ## kafka的 brokens 服务地址 允许有多个 -
- 127.0.0.1:9092 -
Organizations: ## 参与维护 Orderer 的组织，默认为空 -
################################################################################ -
# -
# Profile -
# -
# - 一系列通道配置模板，包括Orderer 系统通道模板 和 应用通道类型模板 -
# -
################################################################################ -
Profiles: -
## Orderer的 系统通道模板 必须包括 Orderer、 Consortiums 两部分 -
TwoOrgsOrdererGenesis: ## Orderer 系统的通道及创世块配置。通道为默认配置，添加一个OrdererOrg 组织， 联盟为默认的 SampleConsortium 联盟，添加了两个组织 【该名称可以自定义 ？？】 -
Capabilities: -
<<: *ChannelCapabilities -
Orderer: ## 指定Orderer系统通道自身的配置信息 -
<<: *OrdererDefaults ## 引用 Orderer 部分的配置 &OrdererDefaults -
Organizations: -
- *OrdererOrg ## 属于Orderer 的通道组织 该处引用了 【 &OrdererOrg 】位置内容 -
Capabilities: -
<<: *OrdererCapabilities -
Consortiums: ## Orderer 所服务的联盟列表 -
SampleConsortium: ## 创建更多应用通道时的联盟 引用 TwoOrgsChannel 所示 -
Organizations: -
- *Org1 -
- *Org2 -
## 应用通道模板 必须包括 Application、 Consortium 两部分 -
TwoOrgsChannel: ## 应用通道配置。默认配置的应用通道，添加了两个组织。联盟为SampleConsortium -
Consortium: SampleConsortium ## 通道所关联的联盟名称 -
Application: ## 指定属于某应用通道的信息，主要包括 属于通道的组织信息 -
<<: *ApplicationDefaults -
Organizations: ## 初始 加入应用通道的组织 -
- *Org1 -
- *Org2 -
Capabilities: -
<<: *ApplicationCapabilities
写的是真的累了；好了，到这里我们大致上对Fabric网络的几个主要配置做了讲解，后续我们还会讲解Fabric-CA及往正在运行的fabric网络动态添加新的组织及通道的操作哈~