利用 configtxlator 动态的添加 fabric 的组织

思路：

使用 configltxlator 可以将配置区块的二进制转换为 JSON ,然后修改JSON，增加ORG，再使用这个工具生成一个增量区块。再配合 peer channel update 命令，实现对原有的配置更新，最后启动新的组织的节点，把各个节点加入到通道中。

说明：

本文中都是以e2e网络，启动的整个fabric，并且关闭了TLS证书。

工具：

1.JQ :用来通过脚本处理与configlator 返回的JSON 交互，既可以格式化JSON数据
2.CURl
3.configtxlator:该工具能够在不同的等效数据在表示/格式之间轻松转换，可以基于两组不同的配置交易之间的区别来计算配置更新

步骤：

1. 检索当前配置。
2. 使用 configtxlator 将该配置解码为 JSON 配置的人类可读版本。
3. 提取 config 节。
4. 提取的 config 节上执行自动或手动编辑，以创建新配置。
5. 使用 configtxlator 对更新后的和原始的配置进行编码。
6. 将它们发送到 configtxlator 以计算配置更新增量，也就是对配置的更改。
7. 对配置更新进行解码并将它包装在一个配置更新envelope中。
8. 创建新配置交易。
9. 提交新的已签名配置交易来更新通道
10. 配置新的组织的证书文件crypto.yaml,利用cryptogen生成新的组织的证书
11. 配置新的组织的启动文件docker-compose.yaml,启动新的组织里的节
12. 把新组织的节点加入到通道中。

1.开启configtxlator
configtxlator start &

2.进入cli 获取通道的当前配置区块
docker exec -it cli bash
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c mychannel

3.使用 configtxlator 工具将二进制 protobuf 渠道配置块信息解码为人类可读的文本 JSON 格式。使用 file 命令验证 JSON 文件的已解码内容，看看是否已成功解码：
curl -X POST --data-binary @config_block.pb http://127.0.0.1:7059/protolator/decode/co... > config_block.json
(curl 操作要注意出现 failed to connect to 127.0.0.1 prot 7059:Connection refused.
出现的原因是：用docker启动的CLI网络和configtxlator不在同一个网络里面。
解决方案是：先把config_block.pb文件移动到docker容器和系统的映射文件都可以访问的到的文件夹：channel-artifacts里面，然后再退出cli。
因为我本地项目是用e2e启动的整个网络。)
使用file 命令验证json文件的已解码内容，查看是否解码成功
file *.json

4.从应用程序渠道 mychannel 的已解码渠道配置块中提取数据的载荷数据节的配置节，然后验证是否已正确且成功地提取:
jq .data.data[0].payload.data.config config_block.json > config.json

5.对提取的配置节进行编辑，以创建新配置
把config.json 文件复制一份，改成updated_config.json,在里面配置要添加的的组织，复制Org1的配置即可，修改对应的细节。

6.使用 configtxlator 编码原始的和修改后的配置。
使用该工具将应用程序 mychannel 的原始配置编码为 protobuf，然后验证是否已正确编码
curl -X POST --data-binary @config.json http://127.0.0.1:7059/protolator/encode/co... > config.pb

使用该工具将应用程序渠道 mychannel 的修改后的配编码为 protobuf，然后验证是否已正确编码
curl -X POST --data-binary @updated_config.json http://127.0.0.1:7059/protolator/encode/co... > updated_config.pb

7.将它们发送到 configtxlator 来计算配置更新增量:
执行以下命令来计算配置更新，它们是使用该工具在应用程序 mychannel 的原始和修改后的通道配置间的过渡。验证计算的配置更新是否正确
curl -X POST -F original=@config.pb -F updated=@updated_config.pb http://127.0.0.1:7059/configtxlator/comput... -F channel=mychannel > config_update.pb

8.解码配置更新并将它包装在一个配置更新 envelope中
curl -X POST --data-binary @config_update.pb http://127.0.0.1:7059/protolator/decode/co... > config_update.json

采用 JSON 格式为配置更新消息创建一个envelope中，验证envelope创建步骤是否已成功完成，如图 14 所示。
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel","type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' > config_update_as_envelope.json

9.创建新配置交易
将配置更新消息编码为 protobuf 格式，验证编码操作是否已成功完成，
curl -X POST --data-binary @config_update_as_envelope.json http://127.0.0.1:7059/protolator/encode/co... > config_update_as_envelope.pb

10.提交新的已签名配置交易来更新通道
用组织1（Org1）执行以下命令来对配置更新交易进行签名。 此命令将该交易的一个签名添加到文件系统中的合适位置。
peer channel signconfigtx -f config_update_as_envelope.pb -o orderer.example.com:7050
用组织2（Org2）执行以下命令来提交配置更新交易。在将配置更新提交到orderer之前，update 命令自动将用户的签名添加到配置更新上（所以不需要第二次使用 signconfigtx）
peer channel update -f config_update_as_envelope.pb -o orderer.example.com:7050 -c mychannel
（这里要用不同的组织来进行签名和更新操作，应该是背书策略中的组织都要对最新的配置交易签名，而 update 操作会先把签名添加到配置上，所以执行 update 命令的组织不要执行签名的操作）

查看组织是否添加成功：
执行以下命令来抓取更新的当前配置
peer channel fetch config config_block_Org3MSP.pb -o orderer.example.com:7050 -c mychannel

执行以下命令来解码成功更新的当前通道配置，然后验证更新操作，
curl -X POST --data-binary @config_block_Org3MSP.pb http://127.0.0.1:7059/protolator/decode/co... > config_block_Org3MSP.json

11. 组织更新完成之后，再e2e_cli目录下新建组织的crypto.yaml 配置文件，利用cryptogen工具生成新的组织证书。
./cryptogen generate --config=./org3-crypto-config.yaml
再把新生成的组织的证书文件夹放到crypto-config/peerORganizations/目录下

12.再e2e_cli目录下创建新组织的启动文件 dockers-compose-cli-org3.yaml
用docker-compose -f docker-compose-cli-org3.yaml up -d 命令启动

13. 进入新组织的CLI,将组织的节点加入到通道中
peer channel join -b ./mychannel.block

本作品采用《CC 协议》，转载必须注明作者和本文链接