當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

4.4 开发模式下的测试：简化我们对链码的测试过程

發布時間：2025/3/21 编程问答 42 豆豆

生活随笔收集整理的這篇文章主要介紹了 4.4 开发模式下的测试：简化我们对链码的测试过程小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

4.4 開發模式下的測試：簡化我們對鏈碼的測試過程

原創kevin-hf(ID不是微信)?最后發布于2019-02-26 16:48:19?閱讀數 180??收藏

展開

目標

熟練掌握鏈碼的 dev 開發測試模式

任務實現

從之前對鏈碼操作來看，我們需要在相關操作（安裝、實例化、升級、調用、查詢）命令中加入大量的參數，尤其是開啟 TLS 驗證之后指定 TLS 證書時的那一長串路徑會讓人不厭其煩。如果每次都需要輸入那么內容，我想大部分人都會崩潰掉的。那么我們現在就來掌握一種能夠快速對鏈碼進行測試而不需要輸入那些煩瑣的內容，從而簡化我們對鏈碼的測試。

正常情況下 chaincode 由 peer 啟動和維護。然而，在 dev “開發模式”下，鏈碼由用戶構建并啟動。

如果沒有下載安裝 Hyperledger Fabric Samples 請先下載安裝；
如果沒有下載 Docker images 請先下載。

在 dev 開發模式下我們可以使用三個終端來實現具體的測試過程

4.4.1 啟動網絡

終端1（當前終端）

為了確保我們的系統中的 Docker 鏡像文件是完整的，首先使用?docker images?命令查看 Docker 鏡像信息(顯示本地 Docker Registry)：

$ sudo docker images

終端中會看到如下類似輸出：

REPOSITORY TAG IMAGE ID CREATED SIZE hyperledger/fabric-ca 1.2.0 66cc132bd09c 4 weeks ago 252 MB hyperledger/fabric-ca latest 66cc132bd09c 4 weeks ago 252 MB hyperledger/fabric-tools 1.2.0 379602873003 4 weeks ago 1.51 GB hyperledger/fabric-tools latest 379602873003 4 weeks ago 1.51 GB hyperledger/fabric-ccenv 1.2.0 6acf31e2d9a4 4 weeks ago 1.43 GB hyperledger/fabric-ccenv latest 6acf31e2d9a4 4 weeks ago 1.43 GB hyperledger/fabric-orderer 1.2.0 4baf7789a8ec 4 weeks ago 152 MB hyperledger/fabric-orderer latest 4baf7789a8ec 4 weeks ago 152 MB hyperledger/fabric-peer 1.2.0 82c262e65984 4 weeks ago 159 MB hyperledger/fabric-peer latest 82c262e65984 4 weeks ago 159 MB hyperledger/fabric-zookeeper 0.4.10 2b51158f3898 5 weeks ago 1.44 GB hyperledger/fabric-zookeeper latest 2b51158f3898 5 weeks ago 1.44 GB hyperledger/fabric-kafka 0.4.10 936aef6db0e6 5 weeks ago 1.45 GB hyperledger/fabric-kafka latest 936aef6db0e6 5 weeks ago 1.45 GB hyperledger/fabric-couchdb 0.4.10 3092eca241fc 5 weeks ago 1.61 GB hyperledger/fabric-couchdb latest 3092eca241fc 5 weeks ago 1.61 GB hyperledger/fabric-baseos amd64-0.4.10 52190e831002 6 weeks ago 132 MB

在 dev 模式中所需的必要鏡像文件為：

hyperledger/fabric-tools
hyperledger/fabric-orderer
hyperledger/fabric-peer
hyperledger/fabric-ccenv

關閉之前已啟動的網絡環境：

$ sudo docker-compose -f docker-compose-cli.yaml down

進入 chaincode-docker-devmode 目錄

$ cd ~/hyfa/fabric-samples/chaincode-docker-devmode/

進入 chaincode-docker-devmode 目錄下我們會發現與網絡、通道、初始區塊相關的所有內容。如：

**docker-compose-simple.yaml：**網絡啟動依賴的配置文件

該配置文件中指定了四個容器，分別為：orderer、peer、cli、chaincode，各項的配置內容大家可以通過 cat 命令查看，在此不再贅述。
**msp：**網絡環境的 MSP，包含一系列的證書及私鑰。
**myc.block：**代表通道配置塊文件。
**myc.tx：**應用通道交易配置文件。
**orderer.block：**初始區塊配置文件。

下面，我們使用 docker-compose-simple.yaml 配置文件來啟動網絡：

$ sudo docker-compose -f docker-compose-simple.yaml up -d

上面的命令以 docker-compose-simple.yaml 啟動了網絡，并以開發模式啟動 peer。另外還啟動了兩個容器：

一個 chaincode 容器，用于鏈碼環境
一個 CLI 容器，用于與鏈碼進行交互。

命令執行后，終端中輸出如下：

Creating orderer Creating peer Creating chaincode Creating cli

創建和連接通道的命令嵌入到 CLI 容器中，因此我們可以立即跳轉到鏈碼調用。

4.4.2 構建并啟動鏈碼

網絡啟動成功后，下一步需要開發者自行對已經編寫好的鏈碼進行構建及啟動。

終端2（開啟一個新的終端2）

4.4.2.1 進入chaincode容器

chaincode 容器的作用是為了以簡化的方式建立并啟動鏈碼

$ sudo docker exec -it chaincode bash

命令提示符變為：

root@858726aed16e:/opt/gopath/src/chaincode#

進入 chaincode 容器之后就可以構建與啟動鏈碼。

4.4.2.2 編譯

現在我們對 fabric-samples 提供的 chaincode_example02 進行測試，當然，在實際環境中，我們可以將開發的鏈碼添加到 chaincode 子目錄中并重新構建及啟動鏈碼，然后進行測試。

進入?chaincode_example02/go/?目錄編譯 chaincode

# cd chaincode_example02/go/# go build

4.4.2.3 運行chaincode

使用如下命令啟動并運行鏈碼：

# CORE_PEER_ADDRESS=peer:7052 CORE_CHAINCODE_ID_NAME=mycc:0 ./go

命令執行后輸出如下：

[shim] SetupChaincodeLogging -> INFO 001 Chaincode log level not provided; defaulting to: INFO [shim] SetupChaincodeLogging -> INFO 002 Chaincode (build level: ) starting up ...

命令含義：

**CORE_PEER_ADDRESS：**用于指定peer。
**CORE_CHAINCODE_ID_NAME：**用于注冊到peer的鏈碼。
- mycc：?指定鏈碼名稱
- 0：?指定鏈碼初始版本號
- ./go：?指定鏈碼文件

注意，此階段，鏈碼與任何通道都沒有關聯。我們需要在后續步驟中使用“實例化”命令來完成.

4.4.3 調用鏈碼

終端3（開啟一個新的終端3）

首先進入 cli 容器

$ sudo docker exec -it cli bash

進入 CLI 容器后，執行如下命令安裝及實例化 chaincode

即使我們在 dev 模式下，也需要安裝鏈碼，使鏈碼能夠正常通過生命周期系統鏈碼的檢查。將來可能會刪除此步驟。

安裝：

# peer chaincode install -p chaincodedev/chaincode/chaincode_example02/go -n mycc -v 0

注意：安裝鏈碼時指定的鏈碼名稱與版本號必須與在終端2中注冊的鏈碼名稱及版本號相同。

安裝命令執行后，終端中輸出如下：

...... -----END CERTIFICATE----- [msp] setupSigningIdentity -> DEBU 034 Signing identity expires at 2027-11-10 13:41:11 +0000 UTC [msp] Validate -> DEBU 035 MSP DEFAULT validating identity [grpc] Printf -> DEBU 036 parsed scheme: "" [grpc] Printf -> DEBU 037 scheme "" not registered, fallback to default scheme [grpc] Printf -> DEBU 038 ccResolverWrapper: sending new addresses to cc: [{peer:7051 0 <nil>}] [grpc] Printf -> DEBU 039 ClientConn switching balancer to "pick_first" [grpc] Printf -> DEBU 03a pickfirstBalancer: HandleSubConnStateChange: 0xc4204e7c40, CONNECTING [grpc] Printf -> DEBU 03b pickfirstBalancer: HandleSubConnStateChange: 0xc4204e7c40, READY [grpc] Printf -> DEBU 03c parsed scheme: "" [grpc] Printf -> DEBU 03d scheme "" not registered, fallback to default scheme [grpc] Printf -> DEBU 03e ccResolverWrapper: sending new addresses to cc: [{peer:7051 0 <nil>}] [grpc] Printf -> DEBU 03f ClientConn switching balancer to "pick_first" [grpc] Printf -> DEBU 040 pickfirstBalancer: HandleSubConnStateChange: 0xc420072170, CONNECTING [grpc] Printf -> DEBU 041 pickfirstBalancer: HandleSubConnStateChange: 0xc420072170, READY [msp] GetDefaultSigningIdentity -> DEBU 042 Obtaining default signing identity [chaincodeCmd] checkChaincodeCmdParams -> INFO 043 Using default escc [chaincodeCmd] checkChaincodeCmdParams -> INFO 044 Using default vscc [chaincodeCmd] getChaincodeSpec -> DEBU 045 java chaincode disabled [golang-platform] getCodeFromFS -> DEBU 046 getCodeFromFS chaincodedev/chaincode/chaincode_example02/go [golang-platform] func1 -> DEBU 047 Discarding GOROOT package fmt [golang-platform] func1 -> DEBU 048 Discarding provided package github.com/hyperledger/fabric/core/chaincode/shim [golang-platform] func1 -> DEBU 049 Discarding provided package github.com/hyperledger/fabric/protos/peer [golang-platform] func1 -> DEBU 04a Discarding GOROOT package strconv [golang-platform] GetDeploymentPayload -> DEBU 04b done [container] WriteFileToPackage -> DEBU 04c Writing file to tarball: src/chaincodedev/chaincode/chaincode_example02/go/chaincode_example02.go [msp/identity] Sign -> DEBU 04d Sign: plaintext: 0AC4070A5C08031A0C08C3F492DC0510...21E3DF010000FFFF4C61C899001C0000 [msp/identity] Sign -> DEBU 04e Sign: digest: 6F0F7CF70A07027506571AAC56B978353CA3C73E311C882AB57263543ECE7B76 [chaincodeCmd] install -> INFO 04f Installed remotely response:<status:200 payload:"OK" >

實例化：

# peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a", "100", "b","200"]}' -C myc

實例化命令執行后，終端中輸出如下內容：

...... [common/configtx] addToMap -> DEBU 091 Adding to config map: [Policy] /Channel/Application/Readers [common/configtx] addToMap -> DEBU 092 Adding to config map: [Policy] /Channel/Application/Writers [common/configtx] addToMap -> DEBU 093 Adding to config map: [Policy] /Channel/Application/Admins [common/configtx] addToMap -> DEBU 094 Adding to config map: [Value] /Channel/BlockDataHashingStructure [common/configtx] addToMap -> DEBU 095 Adding to config map: [Value] /Channel/OrdererAddresses [common/configtx] addToMap -> DEBU 096 Adding to config map: [Value] /Channel/HashingAlgorithm [common/configtx] addToMap -> DEBU 097 Adding to config map: [Value] /Channel/Consortium [common/configtx] addToMap -> DEBU 098 Adding to config map: [Policy] /Channel/Writers [common/configtx] addToMap -> DEBU 099 Adding to config map: [Policy] /Channel/Admins [common/configtx] addToMap -> DEBU 09a Adding to config map: [Policy] /Channel/Readers [chaincodeCmd] InitCmdFactory -> INFO 09b Retrieved channel (myc) orderer endpoint: orderer:7050 [grpc] Printf -> DEBU 09c parsed scheme: "" [grpc] Printf -> DEBU 09d scheme "" not registered, fallback to default scheme [grpc] Printf -> DEBU 09e ccResolverWrapper: sending new addresses to cc: [{orderer:7050 0 <nil>}] [grpc] Printf -> DEBU 09f ClientConn switching balancer to "pick_first" [grpc] Printf -> DEBU 0a0 pickfirstBalancer: HandleSubConnStateChange: 0xc42043d790, CONNECTING [grpc] Printf -> DEBU 0a1 pickfirstBalancer: HandleSubConnStateChange: 0xc42043d790, READY [chaincodeCmd] checkChaincodeCmdParams -> INFO 0a2 Using default escc [chaincodeCmd] checkChaincodeCmdParams -> INFO 0a3 Using default vscc [chaincodeCmd] getChaincodeSpec -> DEBU 0a4 java chaincode disabled [msp/identity] Sign -> DEBU 0a5 Sign: plaintext: 0AC9070A6108031A0C08F2F592DC0510...30300A000A04657363630A0476736363 [msp/identity] Sign -> DEBU 0a6 Sign: digest: B7822DC27649C2CE85206E13DC69861CDB6C4786D6D3E299032BE2A187C0A362 [msp/identity] Sign -> DEBU 0a7 Sign: plaintext: 0AC9070A6108031A0C08F2F592DC0510...025C39086D09D5D731F33C16A2E53492 [msp/identity] Sign -> DEBU 0a8 Sign: digest: 27E503A393AD2B63F56A02FD29E4495999D913F037FEE4BCD894C16447EDAB35

測試：

查詢：

# peer chaincode query -n mycc -c '{"Args":["query","a"]}' -C myc

執行成功輸出查詢結果：?100

調用：

# peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -C myc

執行成功輸出如下：

[chaincodeCmd] chaincodeInvokeOrQuery -> INFO 0a8 Chaincode invoke successful. result: status:200

查詢：

# peer chaincode query -n mycc -c '{"Args":["query","a"]}' -C myc

執行成功輸出查詢結果：?90

FAQ

net 模式與 dev 模式到底有什么區別？

使用 net 模式每次修改鏈碼后想要測試，需要對鏈碼進行升級重新實例化（或重新安裝再實例化），指定一大堆參數，給開發調試帶來了很大的不便。而 dev 模式就簡化了這些過程。

CORE_PEER_ADDRESS=peer:7052 中的 7052 端口到底指的是什么？為什么不是 7051 ？

peer:7052 是用于指定鏈碼的專用監聽地址及端口號。而7051是peer節點監聽的網絡端口

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的4.4 开发模式下的测试：简化我们对链码的测试过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：利用Hyperledger Fabric
下一篇：利用Hyperledger Fabric