原文来自这里。
如果不熟悉capability,那么操作前可以查阅Capabilities。需要注意的是在启用capabilities前,需要升级归属该通道的peer节点和排序节点。
更多关于最新版Fabric中capabilities版本的信息,详见Upgrading your components。
注意:在Hyperledger Fabric中使用术语升级时,指的是升级组件的版本(例如,将可执行文件升级到最新版)。使用更新时,指的是配置的更新,例如更新通道的配置或部署脚本。在Fabric中,如果没有数据迁移的话,我们不会使用术语迁移。
先决条件和注意事项
更新前,请先确保你的机器上有Prerequisites中所提及的所有依赖。这将保证你拥有更新通道配置所需的最新版工具。
由于Fabric可以并且应该滚动更新,所以启用capabilities前需要完成Fabric的升级。任何没有升级到至少capabilities相关的可执行程序都将引起崩溃,并指出错误的配置,否则会导致账本分叉。
一旦启用capabilities,它成为该通道的永久记录。这意味着即使之后禁用了capabilities,旧的可执行程序也无法参与到该通道中,因为它无法处理启用capabilities到禁用capabilities期间的所有区块。结果就是一旦启用了capabilities,就不建议或不支持禁用它。
有鉴于此,可将启用capabilities视为不可逆的。所以在测试设置新capabilities,并在生成环境下启用之前,请三思。
概览
在接下来的教程中,我们将展示如何在所有的系统通道和应用程序通道中配置capabilities更新。
是否需要为所有的通道更新配置的每个部分,这取决于最新版的内容以及你的使用场景。详情参见Upgrading to the latest version of Fabric。需要注意的是在使用最新版功能前,可能需要更新到最新的capability版本,最好的做法是始终使用最新版的可执行程序和最新的capability版本。
因为更新capability版本涉及到配置更新事务流程,相关命令详见Updating a 通道 configuration。
与通道其它配置更新一样,capability版本更新也分三步(每个通道):
- 获取最新的通道配置
- 创建修改后的通道配置
- 创建配置更新事务
我们将按照下面的顺序来启用capabilities:
- Orderer system 通道
- Orderer group
- 通道 group
- Application 通道
- Orderer group
- 通道 group
- Application group
尽管可以同时编辑通道配置的多个部分,但在本教程中我们将展示如何逐步处理这些过程。也就是说我们不会在一次配置修改中同时修改系统通道的Orderer
组和通道
组。这是因为并不是每次发布都有新的Orderer
组capability和通道
组capability。
在生成网络中,单个用户可以独立完成所有通道(和其它配置)更新时不可能的,也是不明智的。例如,orderer system 通道更新,只能由组织的管理员来执行(尽管可以将peer组织添加到排序服务组织中)。同样地,更新其它的Orderer
或通道
组的通道配置除了需要排序服务组织的签名外还需要peer组织的签名。分布式系统需要协同管理。
新建capabilities配置文件
本教程假设名为capabilities.json
的文件已创建,它包含所有你想更新的capabilities。使用jq
将编辑的配置应用到修改后的文件中。
你也不是非要创建类似capabilities.json
的文件或使用jq
工具。修改后的配置也可手动编辑,详见sample 通道 configuration。
然而,这里所描述的过程(使用JSON文件和jq
工具)在脚本化方面确实有优势,这使得它适合想大量的通道进行配置更新。这也是这种方式为什么会成为更新通道的推荐方式。
示例中,capabilities.json
文件内容如下(如果将更新通道作为你Fabric升级到最新版的一部分,则需要将capabilities设置为适合该版本的版本):
{
"通道": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
},
"orderer": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
},
"application": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
}
}
默认情况下,peer节点并不是orderer system 通道的管理员,所以peer节点不能发起orderer system 通道配置更新。排序组织的管理员必须创建类似的文件(没application
组capability,因为系统通道中不存在application
组)来执行系统通道配置更新操作。默认情况下应用程序通道配置是复制系统通道的,所以除非为了特定的capability版本而创建了不同的通道配置,否则应用程序通道的Orderer
组和通道
组与网络中其它的系统通道是一样的。
orderer system 通道 capabilities
默认情况下应用程序通道复制系统通道的配置,所以最好的操作是在跟应用程序通道前先更新系统通道的capabilities。就像Upgrading your components中所述,更新peer之前先将排序节点更新至最新版。
orderer system 通道归排序服务组织管理。默认情况下,只有一个组织(在排序服务初始化节点时创建的组织),但也可以扩展多个组织(例如,有多个组织为排序服务提供节点)。
在更新Orderer
和通道
capability之前,请确保在你的排序服务中的所有节点都已经升级到所需版本。如果排序节点没有升级到所需版本,它将无法处理具有该capability的配置块,并且将崩溃。类似的,如果排序服务中新增一条通道,那所有将被加入到该通道的peer节点必须至少处于通道
和Application
capabilities相近的节点版本,否则在处理配置块时这些peer节点将会崩溃。要了解更多信息,详见Capabilities。
设置环境变量
你需要导入以下环境变量:
- CH_NAME:待更新的系统通道名称。
- CORE_PEER_LOCALMSPID:执行通道更新操作的MSP ID,排序服务组织中的MSP。
- TLS_ROOT_CA:排序节点TLS证书的绝对路径。
- CORE_PEER_MSPCONFIGPATH:标识你的组织的MSP存放的绝对路径。
- ORDERER_CONTAINER:排序节点的容器名称。访问排序服务时,你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。
Orderer
组
关于如何拉取、传递和确定通道配置范围的命令,详见Step 1: Pull and translate the config。如果你有了modified_config.json
文件,那你可以使用下面的命令来新增Orderer
组capabilities:
jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
因为你现在更新的是系统通道,系统通道修改策略只需要排序服务组织的管理员签名。
通道
组
关于如何拉取、传递和确定通道配置范围的命令,详见Step 1: Pull and translate the config。如果你有了modified_config.json
文件,那你可以使用下面的命令来新增通道
组capabilities:
jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
因为你现在更新的是系统通道,系统通道的修改策略只需要排序服务组织的管理员签名。在应用程序通道中,假如你没有修改默认值,通常需要同时满足Application
组(由peer组织的MSPs组成)和Orderer
组(由排序服务组织组成)的大多数管理员策略。
在已有通道上启用capabilities
现在我们来更新orderer system 通道的capabilities,我们将会更新已有通道(你想更新的)的配置。
应用程序通道的配置与系统通道的非常相似。这样,我们就能复用capabilities.json
文件,并使用相同的命令来进行更新(只需要重新设置环境变量即可)。
在更新capabilities前,请确保排序服务中的所有排序节点和通道中的所有peer节点都已升级至要求的版本,否则未升级的节点将无法处理启用了capability的配置块并引起崩溃。更多信息详见Capabilities。
设置环境变量
- CH_NAME:待更新的应用程序通道名称。
- CORE_PEER_LOCALMSPID:执行通道更新操作的MSP ID,peer组织中的MSP。
- TLS_ROOT_CA:peer组织TLS证书的绝对路径。
- CORE_PEER_MSPCONFIGPATH:标识你的组织的MSP存放的绝对路径。
- ORDERER_CONTAINER:排序节点的容器名称。访问排序服务时,你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。
Orderer
组
Step 1: Pull and translate the config。如果你有了modified_config.json
文件,那你可以使用下面的命令来新增Orderer
组capabilities:
jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Orderer
组中大多数管理员同意(即,大多数排序服务的管理员)。peer组织可以更新该capability,但这种情况下,peer组织的签名并不满足该策略。
通道
组
Step 1: Pull and translate the config。如果你有了modified_config.json
文件,那你可以使用下面的命令来新增通道
组capabilities:
jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Application
和Orderer
组大多数管理员审核通过。也就是说,需要peer组织和排序服务组织中大多数管理员对该请求进行签名认证。
Application
组
Step 1: Pull and translate the config。如果你有了modified_config.json
文件,那你可以使用下面的命令来新增通道
组capabilities:
jq -s '.[0] * {"通道_group":{"groups":{"Application": {"values": {"Capabilities": .[1].application}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Application
组大多数管理员审核通过。也就是说,需要peer组织中的大多数管理员进行投票。排序服务的管理员不需要参与。
这样的结果就是不要将此capability设置为不存在的版本。因为排序节点既不会解析应用程序capabilities,也不会验证它,排序节点会审核通过所有的应用程序capabilities版本并将新的配置块分发给peer节点以便peer节点将其保存到账本中。这样的话,peer节点将无法处理该capability并引起崩溃。即使之后再将一个合法的capability版本配置到peer节点上,但之前的配置块仍存在于账本中,当尝试处理之前的配置块时还是会引发崩溃。
这也是为什么需要capabilities.json
这样的文件。它可以有效防止简单的用户错误,例如,当将应用程序的apability设置为V20
,而不是V2_0
时,这会导致通道不可用且无法恢复。
启用capabilities后进行验证
验证capabilities是否成功启用的最好方式是在所有的通道上执行一次chaincode调用。未升级到相应版本的节点都无法解析新的capabilities,这些节点都会崩溃。在这些节点成功重启之前你需要将它们升级至相应的版本。
声明:本作品采用署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)进行许可,使用时请注明出处。
Author: MonsterMeng92