ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Fabric网络升级(三)

2021-04-26 15:03:27  阅读:231  来源: 互联网

标签:Fabric 网络 capabilities 升级 json 排序 config 节点 通道


原文来自这里

如果不熟悉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版本更新也分三步(每个通道):

  1. 获取最新的通道配置
  2. 创建修改后的通道配置
  3. 创建配置更新事务

我们将按照下面的顺序来启用capabilities:

  1. Orderer system 通道
    1. Orderer group
    2. 通道 group
  2. Application 通道
    1. Orderer group
    2. 通道 group
    3. 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默认的修改策略是需要ApplicationOrderer大多数管理员审核通过。也就是说,需要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


标签:Fabric,网络,capabilities,升级,json,排序,config,节点,通道
来源: https://www.cnblogs.com/lianshuiwuyi/p/14704640.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有