Fabric网络升级（一）

原文来自这里。

本章节主要介绍如何从之前的版本或其他长期支持版本升级至最新版。

从2.1升级到2.2

Fabric v2.1和v2.2都是稳定版，以bug修复和其它形式的代码加固位置。因此，升级不需要特别考虑，也不需要更新特定的镜像版本或通道配置更新。

从v1.4.x长期支持版本升级到v2.2

从v1.4.x升级到v2.2，你需要考虑一下内容：

chaincode lifecycle

在chaincode被应用到通道前，允许多个组织表决该合约应该如何使用，这是v2.0新增的功能。要了解更多关于chaincode lifecycle的信息，可以参阅这里。

最佳操作是在启用使用了新的chaincode lifecycle的通道和应用程序之前，先升级通道中的所有peers节点（尽管通道 capabilities不是必须的，但此时更新它更有意义）。未更新至v2.x的peers节点都将会在启用任一capability后崩溃，未更新至v2的orderer节点会在启用通道 capability后崩溃。这种崩溃行为是有意义的，因为如果peers节点或orderer节点不支持必要的capabilities，那它将不能安全地参与到通道中。

在通道更新应用程序的capabilities到v2.0之后，你必须使用v2.x lifecycle程序来打包、安装、审核和提交新的chaincode。因此，在更新功能之前，请确保为新的 lifecycle做好准备。

新的lifecycle默认使用的背书策略是在配置在通道中的（例如 org中的MAJORITY），因此通道启用capabilities时应将背书策略添加到通道的配置中。

有关如何编辑相关通道配置以通过为每个组织添加背书策略的方式来启用行的lifecycle的信息，请查阅Enabling the new chaincode lifecycle。

chaincode shim包（仅Golang版）

在升级peers和通道之前，推荐使用vendor来管理v1.4版本的Go chaincode使用的shim包。这样的话，你就无需更改的你的chaincode。

Fabric网络升级后，如果你不使用vendor来管理你的shim包，尽管之前的chaincode镜像仍能正常工作，但这是有风险的。如果你的chaincode镜像从你的环境中删除了，那么v2.x的peer的invoke会重建chaincode镜像，但此时会报错，因为找不到shim包。

此时，你有两个选择：

1. 如果整个通道都已经准备好升级chaincode，那你可以在所有的peers和通道上升级chaincode（至于使用旧的还是新的lifecycle，这取决于你启用的capability版本）。此时最好的方式是使用go mod来管理新的chaincode使用的shim包。
2. 如果整个通道都没有准备好升级chaincode，那你可以使用环境变量来指定的重建chaincode镜像时使用v1.4的ccenv。v1.4的ccenv仍可以在v2.x的peers上使用。

chaincode日志（仅Golang版）

chaincode shim包中的日志服务shim.ChaincodeLogger已被删除，所以需要用户自己选择日志服务。详见Logging control。

Peer数据库升级

关于如何升级peers节点的详细信息，可以参考upgrading components。在升级的你的peers节点之前，你还需要额外进行一步操作，那就是升级peer数据库。所有peers节点的数据库（不仅包括状态数据库，还包括历史数据库和peer节点的其它内部数据库）都必须使用v2.x的数据格式进行重建，这是升级到v2.x版本的一部分。要出发重建操作，在peers节点启动前需要删除数据库。接下来介绍如何使用peer node upgrade-dbs命令来删除本地数据库并为升级做好准备，这样在启动v2.xpeers节点的第一时间，所有的数据库都会被重建。如果你使用CouchDB作为状态数据库，v2.2的peers已经支持自动删除CouchDB了。要启用该支持，需要你配置peer使用CouchDB，且在执行upgrade-dbs命令前启动CouchDB。在v2.0和v2.1中，peer并不支持自动删除CouchDB数据库，你需要自己手动删除。

在使用docker run命令启动新的peer容器之后，再使用下面的命令来升级peer节点（你可以跳过设置IMAGE_TAG的步骤，因为upgrade-dbs只对v2.x Fabric有效。如果跳过的话，你需要设置PEER_CONTAINER和LEDGERS_BACKUP 环境变量）。使用下面的命令来代替docker run命令启动peer的话，peer节点会删除本地的数据库，并为管理本地数据库做好准备（如果你是从v1.4.x版本升级的话，请使用v2.1代替v2.0）：

docker run --rm -v /opt/backup/$PEER_CONTAINER/:/var/hyperledger/production/ \
            -v /opt/msp/:/etc/hyperledger/fabric/msp/ \
            --env-file ./env<name of node>.list \
            --name $PEER_CONTAINER \
            hyperledger/fabric-peer:2.0 peer node upgrade-dbs

在v2.0和v2.1中，如果你使用的是CouchDB作为状态数据库，那么也需要删除CouchDB数据库。删除CouchDB的/data目录即可。

然后使用下面的命令来启动2.0标签的peer：

docker run -d -v /opt/backup/$PEER_CONTAINER/:/var/hyperledger/production/ \
            -v /opt/msp/:/etc/hyperledger/fabric/msp/ \
            --env-file ./env<name of node>.list \
            --name $PEER_CONTAINER \
            hyperledger/fabric-peer:2.0 peer node start

peer节点会在启动之后立即使用v2.x数据格式重建数据库。由于重建数据库可能是一个漫长的过程（这取决于你的数据库大小，可能长达数小时），所以需要实时检查peer节点的日志来确认重建的进度。每隔1000个区块，你会看到如下信息：

[lockbasedtxmgr] CommitLostBlock -> INFO 041 Recommitting block [1000] to state database

表示数据库还在重建中。

如果升级过程中没有删除数据库，在peer节点启动时会返回错误信息：peer节点使用的是老旧的数据格式，必须使用peer node upgrade-dbs命令删除上述数据库（如果使用CouchDB作为状态数据库，则需要手动删除）。处理完成后重启节点即可。

Capability

v2.0新增了下面三个Capabilities：

1. Application V2_0: 如Fabric chaincode lifecycle章节所述，启用了新的chaincode lifecycle。
2. 通道 V2_0：无更新，但与application和orderer版本保持一致。
3. Orderer V2_0：控制Use通道CreationPolicyAsAdmins，可修改通道创建交易的验证方式。当configtxgen与-bashProfile选项联用时，可重置从orderer系统通道继承的值。

与Capability版本更新一样，更新Application和通道之前，确保已经升级的了你的peer可执行文件，更新Orderer和通道之前，确保已经升级的了你的orderer可执行文件。

关于如何设置新的Capabilities，详见Updating the capability level of a 通道。

为每个组织配置orderer终端（推荐配置）

从v1.4.2开始，推荐在组织版本为所有的系统通道和应用程序通道定义orderer终端，可以在组织的通道配置中新增OrdererEndpoints来替代全局的OrdererAddresses。如果有一个组织设置了组织版本的的orderer服务终端，那么在连接orderer节点时，所有的orderers和peers都会忽略通道版本的终端。

当服务发现与多个组织提供的orderer节点一起使用时，那就必须使用组织版本的orderer终端。这需要客户端配置正确的TLS证书。

如果你的通道配置中每个组织都未包含OrdererEndpoints，那你需要升级你的通道配置来给它们添加这一配置。首先需要创建一个包含新配置章节的JSON文件。

在这个例子中，我们将为名为OrdererOrg的组织添加配置。如果你有多个提供orderer服务的组织，那么每个组织都需要添加配置。JSON文件orglevelEndpoints.json内容如下：

{
  "OrdererOrgEndpoint": {
      "Endpoints": {
          "mod_policy": "Admins",
          "value": {
              "addresses": [
                 "127.0.0.1:30000"
              ]
          }
      }
   }
}

之后，导入如下配置：

• CH_NAME：待更新的通道名称。所有的系统通道和应用程序通道都应该包含排序节点的组织终端。
• CORE_PEER_LOCALMSPID：提出通道更新的组织的MSPID。排序组织的MSP之一。
• CORE_PEER_MSPCONFIGPATH：标识你的组织的MSP的绝对路径。
• TLS_ROOT_CA：提出系统通道更新的组织根证书的绝对路径。
• ORDERER_CONTAINER：排序节点的容器名称。访问排序服务时，你可以访问提供排序服务的任何排序节点。你的请求会自动提交给leader节点。
• ORGNAME：当前你要更新的组织名称，例如OrdererOrg。

当你设置好环境变量后，就可以按照Step 1: Pull and translate the config。

之后使用下面的命令将组织的lifecycle策略（orglevelEndpoints.json文件中配置的）添加到名为modified_config的文件中：

jq -s ".[0] * {\"通道_group\":{\"groups\":{\"Orderer\": {\"groups\": {\"$ORGNAME\": {\"values\": .[1].${ORGNAME}Endpoint}}}}}}" config.json ./orglevelEndpoints.json > modified_config.json

之后的操作，详见Step 3: Re-encode and submit the config。

如果排序服务组织执行它们自己的通道编辑操作，那么它们可以在没有进一步签名（默认情况下，编辑组织内部参数只需要该组织管理员的签名）的情况下编辑配置。如果不同组织执行更新，那就需要被编辑的组织对更新请求进行签名。

---

声明：本作品采用署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)进行许可，使用时请注明出处。
Author: MonsterMeng92

---