#hyperledger-fabric
#hyperledger-fabric
Вопрос:
Итак, я хотел бы знать, есть ли в моей настройке какие-то недостатки или я не понял концепцию жизненного цикла контейнера с цепным кодом.
Проблема заключается в следующем. После установки / создания экземпляра chaincode на канале я должен выполнить запрос / invoke через docker cli к chaincode, прежде чем я смогу сделать то же самое из серверной части nodejs с соответствующим зарегистрированным узлом.
Итак, при просмотре журналов docker контейнер с цепным кодом недоступен, пока я не выполнил вызов из командной строки docker. Предназначено ли это? Или что-то пропустил для настройки? Было бы очень здорово прояснить этот вопрос для меня или опубликовать некоторую документацию по этому поводу.
Ответ №1:
Это нормально, причина, по которой это происходит, заключается в том, что fabric при создании экземпляра запускает контейнер docker с цепным кодом только на узле, который создал его экземпляр. Итак, когда вы пытаетесь вызвать или запросить chaincode через какой-либо другой одноранговый узел, сначала необходимо вызвать контейнер, а затем выполнить запросы.
Альтернативой является создание экземпляра цепного кода через все поддерживающие одноранговые узлы в канале в качестве целевых объектов.Это гарантирует, что контейнер будет у всех одноранговых узлов в канале до вызова или запроса.
Если вы используете go-sdk, это делается через withTargets() or withTargetEndpoints()
:
peers = ["peer1.org1.example.com","peer1.org2.example.com"]
req := InstantiateCCRequest{Name: "name", Version: "version", Path: "path", Policy: ccPolicy}
, err := rc.InstantiateCC("mychannel", req, WithTargets(peers...))
Аналогичная логика используется в вызове cli, который выдает человек для создания экземпляра цепного кода (посмотрите, NOTICE --->
где я пометил требуемый флаг):
Deploy the specified chaincode to the network.
Usage:
peer chaincode instantiate [flags]
Flags:
-C, --channelID string The channel on which this command should be executed
--collections-config string The fully qualified path to the collection JSON file including the file name
--connectionProfile string Connection profile that provides the necessary connection information for the network. Note: currently only supported for providing peer connection information
-c, --ctor string Constructor message for the chaincode in JSON format (default "{}")
-E, --escc string The name of the endorsement system chaincode to be used for this chaincode
-h, --help help for instantiate
-l, --lang string Language the chaincode is written in (default "golang")
-n, --name string Name of the chaincode
"NOTICE--->" --peerAddresses stringArray The addresses of the peers to connect to
-P, --policy string The endorsement policy associated to this chaincode
--tlsRootCertFiles stringArray If TLS is enabled, the paths to the TLS root cert files of the peers to connect to. The order and number of certs specified should match the --peerAddresses flag
-v, --version string Version of the chaincode specified in install/instantiate/upgrade commands
-V, --vscc string The name of the verification system chaincode to be used for this chaincode
Global Flags:
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
--certfile string Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
--clientauth Use mutual TLS when communicating with the orderer endpoint
--connTimeout duration Timeout for client to connect (default 3s)
--keyfile string Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
-o, --orderer string Ordering service endpoint
--ordererTLSHostnameOverride string The hostname override to use when validating the TLS connection to the orderer.
--tls Use TLS when communicating with the orderer endpoint
--transient string Transient map of arguments in JSON encoding```