深度学习
由于区块链系统自身的分布式特性,对其中配置进行更新和管理是一件很有挑战的任务。一旦出现不同节点之间配置不一致,就可能导致整个网络功能异常。
在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
微信号:qq444848023 QQ号:444848023
加入【我是码农】QQ群:864689844(加群验证:我是码农)
全站首页 | 数据结构 | 区块链| 大数据 | 机器学习 | 物联网和云计算 | 面试笔试
var cnzz_protocol = (("https:" == document.location.protocol) ? "https://" : "http://");document.write(unescape("%3Cspan id='cnzz_stat_icon_1276413723'%3E%3C/span%3E%3Cscript src='" + cnzz_protocol + "s23.cnzz.com/z_stat.php%3Fid%3D1276413723%26show%3Dpic1' type='text/javascript'%3E%3C/script%3E"));本站资源大部分来自互联网,版权归原作者所有!
评论专区