拆解fabric-sample/first-network/拆解eyfn.sh——拓展賬本增加新成員
This tutorial serves as an extension to the Building Your First Network (BYFN) tutorial, and will demonstrate the addition of a new organization – Org3 – to the application channel (mychannel) autogenerated by BYFN. It assumes a strong understanding of BYFN, including the usage and functionality of the aforementioned utilities.
原文參考
eyfn.sh腳本主要是用來拓展前一節(jié)中的fabric網(wǎng)絡(luò)勇吊，在原來的Org1和Org2的基礎(chǔ)上汉规，新增Org3成員。
還是從eyfn.sh的執(zhí)行過程來看一下新增成員的過程中經(jīng)歷了什么针史。
腳本拆解
執(zhí)行命令
eyfn.sh腳本的執(zhí)行還是保持原來的“./eyfn.sh up”
我們傳入up以后悟民，可以看到腳本調(diào)用了networkUp方法
#Create the network using docker compose
if [ "${MODE}" == "up" ]; then
networkUp
elif [ "${MODE}" == "down" ]; then ## Clear the network
networkDown
elif [ "${MODE}" == "generate" ]; then ## Generate Artifacts
generateCerts
generateChannelArtifacts
createConfigTx
elif [ "${MODE}" == "restart" ]; then ## Restart the network
networkDown
networkUp
else
printHelp
exit 1
fi
方法跟蹤
# Generate the needed certificates, the genesis block and start the network.
function networkUp () {
# generate artifacts if they don't exist
if [ ! -d "org3-artifacts/crypto-config" ]; then
##生成cert文件
generateCerts
##生成org3的節(jié)點資料
generateChannelArtifacts
##創(chuàng)建修改文件的配置
createConfigTx
fi
# start org3 peers
if [ "${IF_COUCHDB}" == "couchdb" ]; then
IMAGE_TAG=${IMAGETAG} docker-compose -f $COMPOSE_FILE_ORG3 -f $COMPOSE_FILE_COUCH_ORG3 up -d 2>&1
else
IMAGE_TAG=$IMAGETAG docker-compose -f $COMPOSE_FILE_ORG3 up -d 2>&1
fi
if [ $? -ne 0 ]; then
echo "ERROR !!!! Unable to start Org3 network"
exit 1
fi
echo
echo "###############################################################"
echo "############### Have Org3 peers join network ##################"
echo "###############################################################"
docker exec Org3cli ./scripts/step2org3.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
if [ $? -ne 0 ]; then
echo "ERROR !!!! Unable to have Org3 peers join network"
exit 1
fi
echo
echo "###############################################################"
echo "##### Upgrade chaincode to have Org3 peers on the network #####"
echo "###############################################################"
docker exec cli ./scripts/step3org3.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
if [ $? -ne 0 ]; then
echo "ERROR !!!! Unable to add Org3 peers on network"
exit 1
fi
# finish by running the test
docker exec Org3cli ./scripts/testorg3.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
if [ $? -ne 0 ]; then
echo "ERROR !!!! Unable to run test"
exit 1
fi
}
方法分解
networkUp方法主要流程又分為下面幾步：
- 檢測是否存在證書射亏、配置文件竭业、新增部分配置文件等，如果不存在則新建未辆；
- 啟動Org3節(jié)點咐柜；
- 將Org3節(jié)點加入已有的mychannel通道；
- 在mychannel通道網(wǎng)絡(luò)中更新鏈碼拙友，將鏈碼版本從1.0升級到2.0；
- 執(zhí)行腳本測試工作辐棒；
關(guān)鍵路徑
生成并提交Org3的配置文件
# Use the CLI container to create the configuration transaction needed to add
# Org3 to the network
function createConfigTx () {
docker exec cli scripts/step1org3.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
}
篇幅原因牍蜂，方法有刪減
這里我們看到主要流程在step1org3.sh中，該腳本的介紹頁表示了這是EYFN的第一步辐怕，創(chuàng)建并提交org3加入網(wǎng)絡(luò)的配置事物文件
This script is designed to be run in the org3cli container as the first step of the EYFN tutorial. It creates and submits a configuration transaction to add org3 to the network previously setup in the BYFN tutorial.
其中主要執(zhí)行命令如下：
# Fetch the config for the channel, writing it to config.json
fetchChannelConfig ${CHANNEL_NAME} config.json
# Modify the configuration to append the new org
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json
# Compute a config update, based on the differences between config.json and modified_config.json, write it as a transaction to org3_update_in_envelope.pb
createConfigUpdate ${CHANNEL_NAME} config.json modified_config.json org3_update_in_envelope.pb
echo "========= Config transaction to add org3 to network created ===== "
echo "Signing config transaction"
signConfigtxAsPeerOrg 1 org3_update_in_envelope.pb
echo "========= Submitting transaction from a different peer (peer0.org2) which also signs it ========= "
peer channel update -f org3_update_in_envelope.pb -c ${CHANNEL_NAME} -o orderer.example.com:7050 --tls --cafile ${ORDERER_CA}
分別看一下上面用到的幾個方法和命令
-
fetchChannelConfig
The reason why we have to pull the latest version of the config is because channel config elements are versioned.. Versioning is important for several reasons. It prevents config changes from being repeated or replayed (for instance, reverting to a channel config with old CRLs would represent a security risk). Also it helps ensure concurrency (if you want to remove an Org from your channel, for example, after a new Org has been added, versioning will help prevent you from removing both Orgs, instead of just the Org you want to remove).
官方說之所以必須提取配置的最新版本寄疏，是因為通道配置元素的版本化了，版本控制非常重要妖泄，它可以防止配置更改被重復(fù)或重播艘策，還有助于確保并發(fā)性
用命令獲取最新的區(qū)塊信息
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL --cafile $ORDERER_CA使用configtxlator proto_decode對區(qū)塊信息進行解碼操作
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >"${OUTPUT}"可以使用這個命令對所有的pb文件進行解密得到原文查看，官方也解釋了這個命令：
This command saves the binary protobuf channel configuration block to config_block.pb. Note that the choice of name and file extension is arbitrary. However, following a convention which identifies both the type of object being represented and its encoding (protobuf or JSON) is recommended.
-
createConfigUpdate
Takes an original and modified config, and produces the config update tx which transitions between the two
根據(jù)原始和修改的config生成新的配置文件
configtxlator proto_encode --input "${ORIGINAL}" --type common.Config >original_config.pb configtxlator proto_encode --input "${MODIFIED}" --type common.Config >modified_config.pb configtxlator compute_update --channel_id "${CHANNEL}" --original original_config.pb --updated modified_config.pb >config_update.pb configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >"${OUTPUT}"
-
signConfigtxAsPeerOrg
peer channel signconfigtx -f "${TX}"根據(jù)前一步生成的org3_update_in_envelope.pb文件進行簽名操作，官方默認的修改策略是需要“MAJORITY”（超過半數(shù)）節(jié)點進行簽名方可在賬本中進行配置文件生效驯妄，由于我們demo中只有Org1和Org2一共2個節(jié)點，所以需要2個節(jié)點都需要簽名才行源织。
However, we need signatures from the requisite Admin users before the config can be written to the ledger. The modification policy (mod_policy) for our channel Application group is set to the default of “MAJORITY”, which means that we need a majority of existing org admins to sign it. Because we have only two orgs – Org1 and Org2 – and the majority of two is two, we need both of them to sign. Without both signatures, the ordering service will reject the transaction for failing to fulfill the policy.
- peer channel update
上一步中提到的需要2個節(jié)點進行簽名微猖，在上一步中我們使用了Org1進行簽名，這一步主要是用peer channel update命令使Org2進行簽名操作peer channel update -f org3_update_in_envelope.pb -c ${CHANNEL_NAME} -o orderer.example.com:7050 --tls --cafile ${ORDERER_CA}
后續(xù)的啟動Org3節(jié)點侠仇、將Org3節(jié)點加入已有的mychannel通道犁珠、在mychannel通道網(wǎng)絡(luò)中更新鏈碼，將鏈碼版本從1.0升級到2.0犁享、執(zhí)行腳本測試工作與之前的byfn.sh腳本中類似饼疙，只是將Org從1和2改成了3，將鏈碼版本號從1.0改為2.0其余均一樣窑眯。
謝謝。
