由于区块链系统自身的分布式特性，对其中配置进行更新和管理是一件很有挑战的任务。一旦出现不同节点之间配置不一致，就可能导致整个网络功能异常。
在Fabric网络中，通过采用配置交易（Configuration Transaction，ConfigTX）这一创新设计来实现对通道相关配置的更新。配置更新操作如果被执行，也要像应用交易一样经过网络中节点的共识确认。
configtxgen（Configuration Transaction Generator）工具是一个很重要的辅助工具，它可以配合cryptogen生成的组织结构身份文件使用，离线生成跟通道有关的配置信息，相关的实现 在common/configtx包下。
主要功能有如下三个：
·生成启动Orderer需要的初始区块，并支持检查区块内容；
·生成创建应用通道需要的配置交易，并支持检查交易内容；
·生成锚点Peer的更新配置交易。
默认情况下，configtxgen工具会依次尝试从$FABRIC_CFG_PATH环境变量指定的路径，当前路径和 /etc/hyperledger/fabric路径下查找configtx.yaml配置文件并读入，作为默认的配置。环境变量中以CONFIGTX_ 前缀开头的变量也会被作为配置项。
Fabric代码中也提供了一些示例配置文件可以作为参考。
10.5.1 configtx.yaml配置文件
configtx.yaml配置文件一般包括四个部分：Profiles、Organizations、Orderer和Application。
·Profiles：一系列通道配置模板，包括Orderer系统通道模板和应用通道类型模板；
·Organizations：一系列组织结构定义，被其他部分引用；
·Orderer：Orderer系统通道相关配置，包括Orderer服务配置和参与Ordering服务的可用组织信息；
·Application：应用通道相关配置，主要包括参与应用网络的可用组织信息。
下面以源码中提供的配置文件为例，进行示例讲解。
1.Profiles
定义了一系列的Profile，每个Profile代表了某种应用场景下的通道配置模板，包括Orderer系统通道模板或应用通道模板，有时候也混合放到一起。
Orderer系统通道模板必须包括Orderer、Consortiums信息：
·Orderer：指定Orderer系统通道自身的配置信息。包括Ordering服务配置（包括类型、地址、批处理限制、Kafka信息、最大应用通道数目等），参与到此Orderer的组织信息。网络启动时，必须首先创建Orderer系统通道；
·Consortiums：Orderer所服务的联盟列表。每个联盟中组织彼此使用相同的通道创建策略，可以彼此创建应用通道。
应用通道模板中必须包括Application、Consortium信息：
·Application：指定属于某应用通道的信息，主要包括属于通道的组织信息；
·Consortium：该应用通道所关联联盟的名称。
一般建议将Profile分为Orderer系统通道配置（至少包括指定Orderers和Consortiums）和应用通道配置（至少包括指定Applications和Consortium）两种，分别进行编写，如下所示：
Profiles:
TwoOrgsOrdererGenesis: # Orderer系统通道配置。通道为默认配置，添加一个OrdererOrg
组织；联盟为默认的SampleConsortium联盟，添加了两个组织
Orderer:
<<: *OrdererDefaults
Organizations: # 属于Orderer通道的组织
- *OrdererOrg
Consortiums:
SampleConsortium: # 创建更多应用通道时的联盟
Organizations:
- *Org1
- *Org2
TwoOrgsChannel: # 应用通道配置。默认配置的应用通道，添加了两个组织。联盟为SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations: # 初始加入应用通道的组织
- *Org1
- *Org2
Consortium: SampleConsortium # 联盟
代码中代表一个Profile相关配置的数据结构定义如下，同时支持Orderer系统通道和应用通道的配置数据：
type Profile struct {
// 应用通道相关
Consortium string `yaml:"Consortium"`
Application *Application `yaml:"Application"`
// Orderer系统通道相关
Orderer *Orderer `yaml:"Orderer"`
Consortiums map[string]*Consortium `yaml:"Consortiums"`
}
提示 在YAML文件中，&KEY所定位的字段信息，可以通过'<<：KEY'语法来引用，相当于导入定位部分的内容。
2.Organizations
这一部分主要定义一系列的组织结构，根据服务对象类型的不同，包括Orderer组织和普通的应用组织。
Orderer类型组织包括名称、ID、MSP文件路径、管理员策略等，应用类型组织还会配置锚点Peer信息。这些组织都会被Profiles部分引用使用。
配置文件内容如下所示：
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererOrg # MSP的ID
MSPDir: msp # MSP相关文件所在本地路径
AdminPrincipal: Role.ADMIN # 组织管理员所需要的身份，可以为Role.ADMIN或
Role.MEMBER
- &Org1
Name: Org1MSP
ID: Org1MSP # MSP的ID
MSPDir: msp # MSP相关文件所在本地路径
AnchorPeers: # 锚节点地址，用于跨组织的Gossip通信
- Host: peer0.org1.example.com
Port: 7051
- &Org2
Name: Org2MSP
ID: Org2MSP # MSP的ID
MSPDir: msp # MSP相关文件所在本地路径
AnchorPeers: # 锚节点地址，用于跨组织的Gossip通信
- Host: peer0.org2.example.com
Port: 7051
代表一个组织的相关配置的数据结构定义如下所示，包括名称、ID、MSP文件目录、管理员身份规则、锚节点等：
type Organization struct {
Name string `yaml:"Name"`
ID string `yaml:"ID"`
MSPDir string `yaml:"MSPDir"`
AdminPrincipal string `yaml:"AdminPrincipal"`
AnchorPeers []*AnchorPeer `yaml:"AnchorPeers"`
}
3.Orderer
示例排序节点的配置，默认是solo类型，不包括任何组织。源码中自带的配置文件内容如下所示，包括类型、地址、批处理超时和字节数限制、最大通道数、参与组织等。被Profiles部分引用：
Orderer: &OrdererDefaults
OrdererType: solo # orderer类型，包括solo（单点）和kafka（kafka集群作为
后端）
Addresses: # 服务地址
- orderer.example.com:7050
BatchTimeout: 2s # 创建批量交易的最大超时，一批交易可以构建一个区块
BatchSize: # 控制写入到区块内交易的个数
MaxMessageCount: 10 # 一批消息最大个数
AbsoluteMaxBytes: 98 MB # batch最大字节数，任何时候不能超过
PreferredMaxBytes: 512 KB # 通常情况下，batch建议字节数；极端情况下，如单个消
息就超过该值（但未超过最大限制），仍允许构成区块
MaxChannels: 0 # ordering服务最大支持的应用通道数，默认为0，表示无限制
Kafka:
Brokers: # Kafka brokers作为orderer后端
- 127.0.0.1:9092
Organizations: # 参与维护orderer的组织，默认为空
代表Orderer相关配置的数据结构定义如下所示，包括类型、地址、块超时和限制、Kafka信息，支持的最大通道数、关联的组织信息等：
type Orderer struct {
OrdererType string `yaml:"OrdererType"`
Addresses []string `yaml:"Addresses"`
BatchTimeout time.Duration `yaml:"BatchTimeout"`
BatchSize BatchSize `yaml:"BatchSize"`
Kafka Kafka `yaml:"Kafka"`
MaxChannels uint64 `yaml:"MaxChannels"`
Organizations []*Organization `yaml:"Organizations"`
}
4.Application
示例应用通道相关的信息，不包括任何组织。被Profiles部分引用。源码中自带的配置文件内容如下所示：
Application: &ApplicationDefaults
Organizations: # 加入到通道中的组织的信息
代表Application相关配置的数据结构定义如下所示，记录所关联的组织：
type Application struct {
Organizations []*Organization `yaml:"Organizations"`
}
10.5.2 命令选项
下面介绍一些关键的命令选项。
通用选项：
·-profilestring：从configtx.yaml中查找到指定的profile来生成配置，默认为使用Sample-InsecureSolo；
·-channelID string：指定操作的通道的名称，默认是testchainid。
生成选项：
·-outputBlock：将初始区块写入指定文件；
·-outputCreateChannelTx string：将通道创建交易写入指定文件；
·-outputAnchorPeersUpdate string：创建更新锚点Peer的配置更新请求，需要同时使用-asOrg来指定组织身份；
·-asOrg string：以指定的组织身份执行更新配置交易（如更新锚节点）的生成，意味着在写集合中只包括了该组织有权限操作的键值。
查看选项：
·-inspectBlock string：打印指定区块文件中的配置信息；
·-inspectChannelCreateTx：打印通道创建交易文件中的配置更新信息。
10.5.3 生成Orderer初始区块并进行查看
将编写好的configtx.yaml文件以及提前生成好的crypto-config目录都放到默认的$FABRIC_CFG_PATH/路径下。
通过如下命令来指定TwoOrgsOrdererGenesis profile生成Orderer通道的初始区块文件orderer.genesis.block：
$ configtxgen -profile TwoOrgsOrdererGenesis -outputBlock orderer.genesis.block
[common/configtx/tool] main -> INFO 001 Loading configuration
[common/configtx/tool] doOutputBlock -> INFO 002 Generating genesis block
[common/configtx/tool] doOutputBlock -> INFO 003 Writing genesis block
该区块的整体结构如图10-1所示，包括四个组的配置：channel、orderer、application和consortiums。
图10-1 系统通道初始区块的整体结构
其中包括：
·channel组配置：包括Hash算法、数据块Hash结构以及默认的全局策略；
·orderer组配置：包括Orderer相关配置、Orderer组的策略以及各成员组织的策略；
·application组配置：包括Application组的策略，以及各成员组织的策略。这一部分配置在系统通道的初始区块中往往不包括；
·consortiums：包括Consortiums组的策略、各个Consortium的策略以及其下组织的策略。
注意，ConfigEnvelope结构中，Config域用来记录最新版本的配置内容，LastUpdate域用来记录最近一次变更的内容（ConfigUpdate结构）。
可以通过如下命令来查看该区块内的通道配置部分（区块内data.payload.data.config.ChannelGroup部分）内容，系统通道名称采用默认的testchainid：
$ configtxgen -profile TwoOrgsOrdererGenesis -inspectBlock orderer.genesis.block
Config for channel: testchainid at sequence 0
{
"Channel": {
...
}
}
整个通道的配置构成树状结构，包括Values、Policies、Groups三大部分，如图10-2所示。
图10-2 Orderer初始区块内容
Values、Policies两棵子树都只有一层，其叶子节点（深色节点）上会记录具体的配置数据。Groups子树下则再次递归结构形成更深层的树状结构，包括Consortium和Orderer子树。
所有的叶子节点都包括三个元素：
·Value/Policy：记录所配置的内容数据结构；
·Version：该内容的版本信息，每次修改都会更新版本号；
·ModPolicy：对该内容修改策略。
下面分别对这三棵子树结构进行介绍。
1.Values子树
Values子树记录通道上的Hash算法类型、计算区块Hash值时构建Merkle树的宽度、Orderer的地址等。
配置内容如下所示。OrdererAddresses修改策略指定了必须是策略Orderer下管理员身份；对HashingAlgorithm和BlockDataHashingStructure配置修改则必须是系统通道管理员身份：
"OrdererAddresses": {
"Version": "0",
"ModPolicy": "/Channel/Orderer/Admins",
"Value": {
"addresses": [
"orderer.example.com:7050"
]
}
},
"HashingAlgorithm": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"name": "SHA256"
}
},
"BlockDataHashingStructure": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"width": 4294967295
}
}
2.Policies子树
Policies子树包括Readers、Writers、Admins三部分，分别规定了对链的读、写和管理者角色所指定的权限策略。策略中规定了如何对签名来进行验证，以证明权限。
每种角色都包括ModPolicy（指定对该策略进行修改的身份），以及Policy（规定了该角色需要满足的策略）。其中，Policy又包括PolicyType和Policy域。
PolicyType的数值代表含义为：
·0：表示UNKNOWN，保留值，用于初始化；
·1：表示SIGNATURE，必须要匹配指定签名的组合；
·2：表示MSP，某MSP下的身份即可；
·3：表示IMPLICIT_META，表示隐式的规则，该类规则需要对通道中所有的子组检查策略，并通过rule来指定具体的规则，包括ANY、ALL、MAJORITY三种：
·ANY：满足任意子组的读角色；
·ALL：满足所有子组的读角色；
·MAJORITY：满足大多数子组的读角色。
配置内容如下，定义了子组中任意读或写权限角色即可进行读写；拥有超过一半子组的管理员权限者才拥有整体的管理权限：
"Readers": {
"Version": "0",
"ModPolicy": "Admins",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Readers",
"rule": "ANY"
}
}
},
"Writers": {
"Version": "0",
"ModPolicy": "Admins",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Writers",
"rule": "ANY"
}
}
},
"Admins": {
"Version": "0",
"ModPolicy": "Admins",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Admins",
"rule": "MAJORITY"
}
}
}
3.Groups.Consortiums子树
Consortiums包括一个联盟SampleConsortium，由Org1和Org2两个组织构成。每个组织又进一步地构成子树结构，其结构如图10-3所示。
图10-3 Orderer初始区块中Groups.Consortiums子树结构
对应的配置如下所示：
"Consortiums": {
"Values": {},
"Policies": {},
"Groups": {
"SampleConsortium": {
"Values": {
"ChannelCreationPolicy": {
"Version": "0",
"ModPolicy": "/Channel/Orderer/Admins",
"Value": {
"type": 3,
"policy": "CgZBZG1pbnM="
}
}
},
"Policies": {},
"Groups": {
"Org1MSP": {
...
},
"Org2MSP": {
...
}
}
}
}
}
两个组织又形成子树结构，以Org1为例，其结构如图10-4所示。
图10-4 Org1子树结构
其中，MSP.config中为一个FabricMSPConfig结构，包括了MSP名称、根证书、管理员证书等信息，而“CgdPcmcxTVNQ”和“CgdPcmcxTVNQEAE=”都是“Org1MSP”的base64编码值。
另外，identity采用了MSPPrincipal结构进行表示，该结构代表了一组特定的identity，包括一个PrincipalClassification表示类型，一个Principal值。
PrincipalClassification代表的类型可以为：
·0：表示基于实体的角色来进行判断，此时Principal值可以为Admin或Member，表示MSP中的管理员或成员角色；
·1：表示基于实体所属的ORGANIZATION_UNIT进行判断，此时Principal值可以为指定的组织单元；
·2：表示基于实体的身份来进行判断，此时Principal值可以为指定的实体。
4.Groups.Orderer子树
Orderer部分配置如图10-5所示。其中，Values中大部分都是配置文件中的数据；Policies部分包括 了Admins、BlockValidation、Readers、Writers四种角色的权限；Groups部分还包括了OrdererOrg的配置 信息。
示例配置如下所示：
"Orderer": {
"Values": {
Groups.Orderer 子树结构
"ChannelRestrictions": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"maxCount": "0"
}
},
"ConsensusType": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"type": "solo"
}
},
"BatchSize": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"maxMessageCount": 10,
"absoluteMaxBytes": 103809024,
"preferredMaxBytes": 524288
}
},
"BatchTimeout": {
"Version": "0",
"ModPolicy": "Admins",
"Value": {
"timeout": "2s"
}
}
},
"Policies": {
"Admins": {
...
},
"BlockValidation": {
...
},
"Readers": {
...
},
"Writers": {
...
}
},
"Groups": {
"OrderOrg": {
...
}
}
}
图10-5 Orderer初始区块中Groups.Orderer子树结构
其中OrdererOrg组织的结构如图10-6所示。
10.5.4 生成新建通道交易文件并进行查看
通过如下命令来指定生成新建businesschannel应用通道的交易文件：
$ configtxgen -profile TwoOrgsChannel -channelID businesschannel -output-
Create-ChannelTx businesschannel.tx
图10-6 OrdererOrg组织子树结构
该配置交易是个Envelope结构，如图10-7所示。
图10-7 新建应用通道交易结构
通过如下命令查看该文件配置内容，包括读集合和写集合等信息。读集合中主要记录当前配置的版本号；写集合中记录对配置的修改和新的版本号信息（新版本号必须为当前版本号加一）：
$ configtxgen -profile TwoOrgsChannel -inspectChannelCreateTx businesschannel.tx
Channel creation for channel: businesschannel
Read Set:
{
"Channel": {
"Values": {
"Consortium": {
"Version": "0",
"ModPolicy": "",
"Value": {
"name": "SampleConsortium"
}
}
},
"Policies": {},
"Groups": {
"Application": {
"Values": {},
"Policies": {},
"Groups": {
"Org1MSP": {
"Values": {},
"Policies": {},
"Groups": {}
},
"Org2MSP": {
"Values": {},
"Policies": {},
"Groups": {}
}
}
}
}
}
}
Write Set:
{
"Channel": {
"Values": {
"Consortium": {
"Version": "0",
"ModPolicy": "",
"Value": {
"name": "SampleConsortium"
}
}
},
"Policies": {},
"Groups": {
"Application": {
"Values": {},
"Policies": {
"Admins": {
"Version": "0",
"ModPolicy": "",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Admins",
"rule": "MAJORITY"
}
}
},
"Writers": {
"Version": "0",
"ModPolicy": "",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Writers",
"rule": "ANY"
}
}
},
"Readers": {
"Version": "0",
"ModPolicy": "",
"Policy": {
"PolicyType": "3",
"Policy": {
"subPolicy": "Readers",
"rule": "ANY"
}
}
}
},
"Groups": {
"Org1MSP": {
"Values": {},
"Policies": {},
"Groups": {}
},
"Org2MSP": {
"Values": {},
"Policies": {},
"Groups": {}
}
}
}
}
}
}
Delta Set:
[Groups] /Channel/Application
[Policy] /Channel/Application/Admins
[Policy] /Channel/Application/Writers
[Policy] /Channel/Application/Readers
可以看到，新建一个应用通道，对系统通道的配置更新主要是添加了/Channel/Application部分的配置项。
10.5.5 生成锚节点更新交易文件
可以采用类似如下命令生成锚节点更新交易文件，注意需要同时使用-asOrg来指定组织身份：
$ configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate Org1MS-Panchors.
tx -channelID businesschannel -asOrg Org1MSP
$ configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate Org2MS-Panchors.
tx -channelID businesschannel -asOrg Org2MSP
来源：我是码农，转载请保留出处和链接！
本文链接：http://www.54manong.com/?id=918
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
