- 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: warninggrpc: errorledger: infomsp: warningpolicies: warningpeer: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节点IDnetworkId: dev ##网络IDlistenAddress: 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)默认-1keepalive: ##客户端和peer间的网络心跳连接配置minInterval: 60s ##最小的心跳间隔时间client: ##该节点和客户端的交互配置interval: 60s ##和客户端的心跳间隔必须interval >= minIntervaltimeout: 20s ##和客户端间的网络连接超时时间deliveryClient: ##交付客户端用于与订购节点通信的心跳interval: 60stimeout: 20sgossip: ##节点间通信的gossip协议的P2P通信【主要包含了启动及连接】bootstrap: 127.0.0.1:7051 ##启动节点后向哪些节点发起gossip连接，以加入网络，且节点相互间都是同一个组织的useLeaderElection: true ##是否启动动态选举组织的Leader节点与orgLeader互斥orgLeader: false ##是否指定本节点为组织Leader节点与useLeaderElection互斥endpoint: ##本节点在组织内的gossip idmaxBlockCountToStore: 100 ##保存到内存的区块个数上限maxPropagationBurstLatency: 10ms ##保存消息的最大时间，超过则触发转发给其他节点maxPropagationBurstSize: 10 ##保存的最大消息个数，超过则触发转发给其他节点propagateIterations: 1 ##消息转发的次数propagatePeerNum: 3 ##推送消息给指定个数的节点pullInterval: 4s ##拉取消息的时间间隔(unit: second)必须大于digestWaitTime + responseWaitTimepullPeerNum: 3 ##从指定个数的节点拉取消息requestStateInfoInterval: 4s ##从节点拉取状态信息(StateInfo)消息间隔(unit: second)publishStateInfoInterval: 4s ##向其他节点推动状态信息消息的间隔(unit: second)stateInfoRetentionInterval: ##状态信息消息的超时时间(unit: second)publishCertPeriod: 10s ##启动后在心跳消息中包括证书的等待时间skipBlockVerification: false ##是否不对区块消息进行校验，默认为falsedialTimeout: 3s ## gRPC连接拨号的超时(unit: second)connTimeout: 2s ##建立连接的超时(unit: second)recvBuffSize: 20 ##收取消息的缓冲大小sendBuffSize: 200 ##发送消息的缓冲大小digestWaitTime: 1s ##处理摘要数据的等待时间(unit: second)可以大于requestWaitTimerequestWaitTime: 1500ms ##处理nonce数据的等待时间(unit: milliseconds)可以大于digestWaitTimeresponseWaitTime: 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: 60stransientstoreMaxBlockRetention: 1000pushAckTimeout: 3sbtlPullMargin: 10events: ##事件配置address: 0.0.0.0:7053 ##本地服务监听地址(默认在所有网络接口上进心监听，端口7053)buffersize: 100 ##最大缓冲消息数，超过则向缓冲中发送事件消息会被阻塞timeout: 10ms ##事件发送超时时间,如果事件缓存已满, timeout < 0,事件被丢弃; timeout > 0,阻塞直到超时丢弃, timeout = 0,阻塞直到发送出去timewindow: 15m ##允许peer和客户端时间不一致的最大时间差keepalive: ##客户端到peer间的事件心跳minInterval: 60ssendTimeout: 60s ##在GRPC流上向客户端发送事件的超时时间tls: ## tls配置enabled: false ##是否开启TLS，默认不开启TLSclientAuthRequired: false ##客户端连接到peer是否需要使用加密cert: ##证书密钥的位置,各peer应该填写各自相应的路径file: tls/server.crt ##本服务的身份验证证书，公开可见，访问者通过该证书进行验证key:file: tls/server.key ##本服务的签名私钥rootcert:file: tls/ca.crt ##信任的根CA整数位置clientRootCAs: ##用于验证客户端证书的根证书颁发机构的集合files:- tls/ca.crtclientKey: ##当TLS密钥用于制作客户端连接。如果不设置，将使用而不是peer.tls.key.filefile:clientCert: ##在进行客户端连接时用于TLS的X.509证书。如果未设置，将使用peer.tls.cert.filefile:serverhostoverride: ##是否制定进行TLS握手时的主机名称authentication: ##身份验证包含与验证客户端消息相关的配置参数timewindow: 15m ##客户端请求消息中指定的当前服务器时间与客户端时间之间的可接受差异fileSystemPath: /var/hyperledger/production ## peer数据存储位置(包括账本,状态数据库等)BCCSP: ##加密库配置与Orderer配置一样Default: SW ##使用软件加密方式(默认SW)SW:Hash: SHA2 ## Hash算法类型，目前仅支持SHA2Security: 256FileKeyStore: ##本地私钥文件路径，默认指向<mapConfigPath>/keystoreKeyStore:# Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11)PKCS11: ##设置PKCS#11加密算法(默认PKCS11)Library: ##本地PKCS11依赖库Label: ## token的标识Pin: ##使用PinHash:Security:FileKeyStore:KeyStore:mspConfigPath: msp ## msp的本地路径localMspId: SampleOrg ## Peer所关联的MSP的IDclient: ## cli公共客户端配置选项connTimeout: 3s ##连接超时时间deliveryclient: ##交付服务配置reconnectTotalTimeThreshold: 3600s ##交付服务交付失败后尝试重连的时间connTimeout: 3s ##交付服务和orderer节点的连接超时时间reConnectBackoffThreshold: 3600s ##设置连续重试之间的最大延迟localMspType: bccsp ##本地MSP类型（默认为BCCSP）profile: ##是否启用Go自带的profiling支持进行调试enabled: falselistenAddress: 0.0.0.0:6060adminService: ## admin服务用于管理操作，例如控制日志模块严重性等。只有对等管理员才能使用该服务handlers:authFilters:-name: DefaultAuth-name: ExpirationCheck ##此筛选器检查身份x509证书过期decorators:-name: DefaultDecoratorendorsers:escc:name: DefaultEndorsementlibrary:validators:vscc:name: DefaultValidationlibrary:validatorPoolSize: ##处理交易验证的并发数,默认是CPU的核数discovery: ##客户端使用发现服务来查询有关peers的信息，例如-哪些peer已加入某个channel，最新的channel配置是什么，最重要的是-给定chaincode和channel，哪些可能的peer满足认可policyenabled: trueauthCacheEnabled: trueauthCacheMaxSize: 1000authCachePurgeRetentionRatio: 0.75orgMembersAllowedAccess: false################################################################################# VM section链码运行环境配置目前主要支持Docker容器################################################################################vm:endpoint: unix:///var/run/docker.sock ## Docker Daemon地址，默认是本地套接字docker:tls: ## Docker Daemon启用TLS时的相关证书配置,包括信任的根CA证书、服务身份证书、签名私钥等等enabled: falseca:file: docker/ca.crtcert:file: docker/tls.crtkey:file: docker/tls.keyattachStdout: false ##是否启用绑定到标准输出，启用后链码容器的输出消息会绑定到标准输出，方便进行调试hostConfig: ## Docker相关的主机配置，包括网络配置、日志、内存等等，这些配置在启动链码容器时进行使用NetworkMode: hostDns:# - 192.168.0.1LogConfig:Type: json-fileConfig: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: falsecar: ## car格式的链码部署生成镜像的基础Docker镜像runtime: $(BASE_DOCKER_NS)/fabric-baseos:$(ARCH)-$(BASE_VERSION)java: ## java语言的基础镜像Dockerfile: |from $(DOCKER_NS)/fabric-javaenv:$(ARCH)-1.1.0node: ## 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: enablelscc: enableescc: enablevscc: enableqscc: enablesystemPlugins: ##系统链码插件logging: ##链码容器日志相关配置level: infoshim: warningformat: '%{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:5984username:o prevent unintended users from discovering the password.password:maxRetries: 3 ##运行时出错重试数maxRetriesOnStartup: 10 ##启动时出错的重试数requestTimeout: 35s ##请求超时时间queryLimit: 10000 ##每个查询最大返回数maxBatchUpdateSize: 1000 ##批量更新最大记录数warmIndexesAfterNBlocks: 1history:enableHistoryDatabase: true ##是否启用历史数据库，默认开启################################################################################# Metrics section服务度量监控配置#################################################################################metrics:enabled: false ##是否开启监控服务reporter: statsdinterval: 1sstatsdReporter:address: 0.0.0.0:8125flushInterval: 2sflushBytes: 1432promReporter: ## prometheus普罗米修斯服务监听地址listenAddress: 0.0.0.0:8080
在 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 ##服务监听端口默认7050TLS: ##启用TLS时的相关配置(grpc传输)Enabled: falsePrivateKey: 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: SWSW:Hash: SHA2Security: 256FileKeyStore: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#ConfigNetworkTimeouts: ## Sarama网络超时时间DialTimeout: 10sReadTimeout: 10sWriteTimeout: 10sMetadata: ## 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节点的传递服务请求保存的位置
我们在【我的区块链之路】- 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 ##组织名称组织1Domain: 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: Org2Domain: org2.example.comEnableNodeOUs: trueTemplate:Count: 2Users: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 ##组织管理员身份验证证书，【被根证书签名】│││││││└──Admin@example.com-cert.pem│││││├──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一致】│││││││││└──Admin@example.com-cert.pem│││││││├──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 ##存放属于该组织的用户的实体│││└──Admin@example.com ##管理员用户的信息，其中包括msp证书和tls证书两类│││├──msp│││││├──admincerts ##组织根证书作为管理员身份验证证书，【和MSP.admincerts一致】│││││││└──Admin@example.com-cert.pem│││││├──cacerts ##存放组织的根证书，【和CA目录里面一致】│││││││└──ca.example.com-cert.pem│││││├──keystore ##本用户的身份私钥，用来签名│││││││└──a3c1d7e1bc464faf2e3a205cb76ea231bd3ee7010655d3cd31dc6cb78726c4d0_sk│││││├──signcerts ##管理员用户的身份验证证书，被组织根证书签名。要被某个Orderer认可，则必须放到该Orderer的msp/admincerts目录下│││││││└──Admin@example.com-cert.pem│││││└──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 ##组织管理员身份验证证书，【被根证书签名】│││││││└──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 ##第一个Peer的信息msp及tls│││││││├──msp│││││││││├──admincerts ##组织管理员的身份验证证书。Peer将给予这些证书来确认交易签名是否为管理员签名【和MSP.admincerts一致】│││││││││││└──Admin@org1.example.com-cert.pem│││││││││├──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 ##存放属于该组织的用户的实体│││├──Admin@org1.example.com ##管理员用户的信息，其中包括msp证书和tls证书两类│││││├──msp│││││││├──admincerts ##组织根证书作为管理员身份验证证书，【和MSP.admincerts一致】│││││││││└──Admin@org1.example.com-cert.pem│││││││├──cacerts ##存放组织的根证书，【和CA目录里面一致】│││││││││└──ca.org1.example.com-cert.pem│││││││├──keystore ##本用户的身份私钥，用来签名│││││││││└──2b933c0740d857284be98ff218bf279261e55eff2b89d973e0a1f435f7c7d28b_sk│││││││├──signcerts ##管理员用户的身份验证证书，被组织根证书签名。要被某个Peer认可，则必须放到该Peer的msp/admincerts目录下│││││││││└──Admin@org1.example.com-cert.pem│││││││└──tlscacerts ## TLS连接用的身份证书，即组织TLS证书，【和msp.tlscacerts一致】│││││││└──tlsca.org1.example.com-cert.pem│││││└──tls ## tls的相关信息││├──ca.crt││├──client.crt ##管理员的身份验证证书，【被组织根证书签名】││└──client.key ##管理员的身份私钥，用来签名│││││└──User1@org1.example.com│├──msp││├──admincerts ##组织根证书作为管理员身份验证证书│││└──User1@org1.example.com-cert.pem││├──cacerts ##存放组织的根证书，【和CA目录里面一致】│││└──ca.org1.example.com-cert.pem││├──keystore ##【参考admin】│││└──11ebc5afac42348f84a8882f329d18beee079efd4fd5d9b30389dc82053fc0c9_sk││├──signcerts ##【参考admin】│││└──User1@org1.example.com-cert.pem││└──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 种文件
在上一篇文章中我们知道在启动网络之前我们需要做一些准备工作，上面我们已经使用 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所引用，以下均为类似做法】- &OrdererOrgName: 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- &Org1Name: Org1MSP ##组织名称ID: Org1MSP ##组织IDMSPDir: crypto-config/peerOrganizations/org1.example.com/msp ## Peer的MSP证书目录路径AnchorPeers: ##定义组织锚节点用于跨组织Gossip通信- Host: peer0.org1.example.com ##锚节点的主机名Port: 7051 ##锚节点的端口号##定义Peer组织2- &Org2Name: Org2MSPID: Org2MSPMSPDir: crypto-config/peerOrganizations/org2.example.com/mspAnchorPeers:- Host: peer0.org2.example.comPort: 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。将功能的值设置为trueOrderer: &OrdererCapabilities## Orderer的V1.1是行为的一个标记，已经确定为运行v1.0.x的所有orderers都需要，但其修改会导致不兼容。用户应将此标志设置为trueV1_1: true##应用程序功能仅适用于Peer网络，可以安全地操作，而无需担心升级或更新orderers。将功能的值设置为trueApplication: &ApplicationCapabilities## V1.2 for Application是一个行为标记，已被确定为运行v1.0.x的所有peers所需的行为，但其修改会导致不兼容。用户应将此标志设置为trueV1_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:7050BatchTimeout: 2s ##区块打包的最大超时时间(到了该时间就打包区块)BatchSize: ##区块打包的最大包含交易数MaxMessageCount: 10 ##一个区块里最大的交易数AbsoluteMaxBytes: 99 MB ##一个区块的最大字节数，任何时候都不能超过PreferredMaxBytes: 512 KB ##一个区块的建议字节数，如果一个交易消息的大小超过了这个值,就会被放入另外一个更大的区块中MaxChannels: 0 ##【可选项】表示Orderer允许的最大通道数，默认0表示没有最大通道数Kafka:Brokers: ## kafka的brokens服务地址允许有多个- 127.0.0.1:9092Organizations: ##参与维护Orderer的组织，默认为空################################################################################## Profile## -一系列通道配置模板，包括Orderer系统通道模板和应用通道类型模板#################################################################################Profiles:## Orderer的系统通道模板必须包括Orderer、Consortiums两部分TwoOrgsOrdererGenesis: ## Orderer系统的通道及创世块配置。通道为默认配置，添加一个OrdererOrg组织，联盟为默认的SampleConsortium联盟，添加了两个组织【该名称可以自定义？？】Capabilities:<<: *ChannelCapabilitiesOrderer: ##指定Orderer系统通道自身的配置信息<<: *OrdererDefaults ##引用Orderer部分的配置&OrdererDefaultsOrganizations:- *OrdererOrg ##属于Orderer的通道组织该处引用了【&OrdererOrg】位置内容Capabilities:<<: *OrdererCapabilitiesConsortiums: ## Orderer所服务的联盟列表SampleConsortium: ##创建更多应用通道时的联盟引用TwoOrgsChannel所示Organizations:- *Org1- *Org2##应用通道模板必须包括Application、Consortium两部分TwoOrgsChannel: ##应用通道配置。默认配置的应用通道，添加了两个组织。联盟为SampleConsortiumConsortium: SampleConsortium ##通道所关联的联盟名称Application: ##指定属于某应用通道的信息，主要包括属于通道的组织信息<<: *ApplicationDefaultsOrganizations: ##初始加入应用通道的组织- *Org1- *Org2Capabilities:<<: *ApplicationCapabilities
写的是真的累了；好了，到这里我们大致上对Fabric网络的几个主要配置做了讲解，后续我们还会讲解Fabric-CA及往正在运行的fabric网络动态添加新的组织及通道的操作哈~
扫一扫
1029
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
