Fabric 1.4.x升级2.x 更新通道配置

这里我们以mychannel通道作为示例

更新通道配置是一个概念上很简单的三步操作：

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

但是，正如您将看到的，这种概念上的简单性包含在一个有点复杂的过程中。因此，一些用户可能会选择为拉取、翻译和确定配置更新范围的过程编写脚本。用户还可以选择如何手动或使用类似工具修改通道配置本身jq。

我们有两个教程专门处理编辑通道配置以实现特定目的：

• 向频道添加组织：显示向现有频道添加其他组织的过程。
• 更新频道功能：展示如何更新频道功能。

在本主题中，我们将展示与配置更新的最终目标无关的编辑通道配置的过程。

为您的配置更新设置环境变量

在尝试使用示例命令之前，请确保导出以下环境变量，这取决于您构建部署的方式。请注意，CH_NAME必须为每个正在更新的频道设置频道名称，因为频道配置更新仅适用于正在更新的频道的配置。

• CH_NAME：正在更新的频道名称。
• TLS_ROOT_CA：提议更新的组织的 TLS CA 的根 CA 证书的路径。
• CORE_PEER_LOCALMSPID：您的 MSP 名称。
• CORE_PEER_MSPCONFIGPATH：您组织的 MSP 的绝对路径。
• ORDERER_CONTAINER：排序节点容器的名称。请注意，在定位排序服务时，您可以定位排序服务中的任何活动节点。您的请求将自动转发给领导。

注：本主题将提供各种JSON和protobuf的文件默认名称拉动和修改（config_block.pb，config_block.json，等）。您可以随意使用任何名称。但是，请注意，除非您在每次配置更新结束时返回并删除这些文件，否则在进行其他更新时必须选择不同的文件。

第 1 步：拉取并翻译配置

更新通道配置的第一步是获取最新的配置块。这是一个三步过程。首先，我们将以 protobuf 格式拉取通道配置，创建一个名为config_block.pb.

确保您在对等容器中。

现在发出：

peer channel fetch config config_block.pb -o $ORDERER_CONTAINER -c $CH_NAME --tls --cafile $TLS_ROOT_CA

接下来，我们将通道配置的 protobuf 版本转换为 JSON 版本，称为config_block.json（JSON 文件更易于人类阅读和理解）：

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json

最后，我们将从配置中排除所有不必要的元数据，这使其更易于阅读。您可以随意调用此文件，但在本示例中，我们将其命名为config.json.

jq .data.data[0].payload.data.config config_block.json > config.json

现在让我们制作一个config.json被调用的副本modified_config.json。不要编辑config.json直接，因为我们将用它来计算之间的差异config.json，并modified_config.json在后面的步骤。

cp config.json modified_config.json

第二步：修改配置

此时，您有两个选择要如何修改配置。

1. modified_config.json使用您选择的文本编辑器打开并进行编辑。在线教程描述了如何从没有编辑器的容器中复制文件、编辑它并将其添加回容器。
2. 使用jq到编辑应用到的配置。

选择手动编辑配置还是使用配置jq取决于您的用例。因为jq它简洁且可编写脚本（当对多个频道进行相同的配置更新时的优势），所以它是执行频道更新的推荐方法。有关如何jq使用的示例，请查看更新通道功能，其中显示了jq利用名为 .config 的功能配置文件的多个命令capabilities.json。如果您要更新频道中的功能以外的内容，则必须相应地修改您的jq命令和 JSON 文件。

有关频道配置的内容和结构的更多信息，请查看上面的示例频道配置。

第 3 步：重新编码并提交配置

无论您是手动进行配置更新还是使用类似工具进行配置更新jq，您现在都必须运行您运行的过程以反向拉取和范围配置，以及在提交之前计算旧配置和新配置之间差异的步骤将配置更新给通道上的其他管理员以得到批准。

首先，我们将我们的config.json文件恢复为 protobuf 格式，创建一个名为config.pb. 然后我们将对我们的modified_config.json文件做同样的事情。之后，我们将计算两个文件之间的差异，创建一个名为config_update.pb.

configtxlator proto_encode --input config.json --type common.Config --output config.pb

configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb

configtxlator compute_update --channel_id mychannel --original config.pb --updated modified_config.pb --output config_update.pb

现在我们已经计算了旧配置和新配置之间的差异，我们可以将更改应用于配置。

configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json

echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CH_NAME'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json

configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb

提交配置更新事务：

peer channel update -f config_update_in_envelope.pb -c $CH_NAME -o $ORDERER_CONTAINER --tls --cafile $TLS_ROOT_CA

我们的配置更新事务表示原始配置和修改后的配置之间的差异，但排序服务会将其转换为完整的通道配置。

获得必要的签名

成功生成新的配置 protobuf 文件后，它需要满足您尝试更改的任何内容的相关策略，通常（尽管并非总是）需要其他组织的签名。

注意：您可以编写签名集合的脚本，具体取决于您的应用程序。通常，您收集的签名可能总是比需要的多。

获取这些签名的实际过程将取决于您如何设置系统，但有两种主要实现方式。目前，Fabric 命令行默认为“传递”系统。也就是说，提议配置更新的组织管理员将更新发送给需要对其进行签名的其他人（通常是另一个管理员）。该管理员对其进行签名（或不签名）并将其传递给下一个管理员，依此类推，直到有足够的签名来提交配置。

这具有简单的优点——当有足够的签名时，最后一个管理员可以简单地提交配置事务（在 Fabric 中，该命令默认包含签名）。但是，此过程仅适用于较小的渠道，因为“传递”方法可能非常耗时。peer channel update

另一种选择是将更新提交给频道上的每个管理员，然后等待足够多的签名回来。然后可以将这些签名拼接在一起并提交。这使创建配置更新的管理员的生活变得更加困难（迫使他们处理每个签名者的文件），但对于正在开发 Fabric 管理应用程序的用户来说，这是推荐的工作流程。

将配置添加到分类帐后，最佳做法是将其拉出并将其转换为 JSON 以检查以确保所有内容都已正确添加。这也将作为最新配置的有用副本。