Узлы Corda 3.3 не взаимодействуют в докерной сети (yo-cordapp) - PullRequest
0 голосов
/ 06 ноября 2018

Я строю сеть разработки для Corda 3.3, используя Docker. Есть 3 узла (PartyA, PartyB, PartyC) и нотариус, работающий в разных контейнерах. У меня по умолчанию приложение YoPapp: https://github.com/roger3cev/yo-cordapp.

Когда я пытаюсь отправить "Yo" из PartyA в PartyB, я не получаю никакой реакции от PartyB. Накопленные журналы просто останавливаются после этого:

partya        | [INFO] 13:09:38+0000 [Node thread-1] flow.[83616806-a4ad-42b0-9971-9a0823bce6cc].initiateSession - Initiating flow session with party O=PartyB, L=London, C=GB. Session id for tracing purposes is SessionId(toLong=3440335321282531945).
partya        | [INFO] 13:09:38+0000 [Messaging DLDRewETrQQASyFCr8arRT7PKymb77wj2rz1d3KVrMYvPb] messaging.P2PMessagingClient.createQueueIfAbsent - Create fresh queue internal.peers.DL6cscJ1aLiDExFxGHY2MoMuhDHx2gZBQZYgj5gNNttNap bound on same address
partya        | [INFO] 13:09:38+0000 [Thread-1 (ActiveMQ-client-global-threads)] bridging.BridgeControlListener.processControlMessage - Received bridge control message Create(nodeIdentity=DLDRewETrQQASyFCr8arRT7PKymb77wj2rz1d3KVrMYvPb, bridgeInfo=BridgeEntry(queueName=internal.peers.DL6cscJ1aLiDExFxGHY2MoMuhDHx2gZBQZYgj5gNNttNap, targets=[partyb:10002], legalNames=[O=PartyB, L=London, C=GB])) {actor_id=corda, actor_owningIdentity=O=PartyA, L=London, C=GB, actor_store_id=NODE_CONFIG, invocation_id=eaa433d0-d02c-4350-8dbb-6da7c5c3709b, invocation_timestamp=2018-11-06T13:09:37.649Z, session_id=a05854b9-2bc2-426d-af65-3aa6c5b2d7be, session_timestamp=2018-11-06T13:06:32.553Z}
partya        | [INFO] 13:09:38+0000 [Thread-1 (ActiveMQ-client-global-threads)] peers.DL6cscJ1aLiDExFxGHY2MoMuhDHx2gZBQZYgj5gNNttNap -> partyb:10002:O=PartyB, L=London, C=GB.start - Create new AMQP bridge {actor_id=corda, actor_owningIdentity=O=PartyA, L=London, C=GB, actor_store_id=NODE_CONFIG, invocation_id=eaa433d0-d02c-4350-8dbb-6da7c5c3709b, invocation_timestamp=2018-11-06T13:09:37.649Z, session_id=a05854b9-2bc2-426d-af65-3aa6c5b2d7be, session_timestamp=2018-11-06T13:06:32.553Z}
partya        | [INFO] 13:09:38+0000 [Thread-1 (ActiveMQ-client-global-threads)] netty.AMQPClient.start - connect to: partyb:10002 {actor_id=corda, actor_owningIdentity=O=PartyA, L=London, C=GB, actor_store_id=NODE_CONFIG, invocation_id=eaa433d0-d02c-4350-8dbb-6da7c5c3709b, invocation_timestamp=2018-11-06T13:09:37.649Z, session_id=a05854b9-2bc2-426d-af65-3aa6c5b2d7be, session_timestamp=2018-11-06T13:06:32.553Z}
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] netty.AMQPClient.operationComplete - Connected to partyb:10002
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] O=PartyB, L=London, C=GB.channelActive - New client connection 122b0447 from partyb/172.18.0.3:10002 to /172.18.0.4:50744
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] netty.LoggingTrustManagerWrapper.checkServerTrusted - Check Server Certpath:
partya        |   C=GB,L=London,O=PartyB[484605596E5E68D784949F808BDF6BC1AE27E6E1] issued by C=GB,L=London,O=PartyB[null]
partya        |   C=GB,L=London,O=PartyB[0216D463A9D1253A112E96A7852347564333B32E] issued by CN=Corda Node Intermediate CA,O=R3,OU=corda,L=London,C=UK[null]
partya        |   CN=Corda Node Intermediate CA,O=R3,OU=corda,L=London,C=UK[EBEE2E30152940AE19981ED86FE37D7F07A2C213] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[null]
partya        |   CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[null]
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] O=PartyB, L=London, C=GB.userEventTriggered - Handshake completed with subject: O=PartyB, L=London, C=GB
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] peers.DL6cscJ1aLiDExFxGHY2MoMuhDHx2gZBQZYgj5gNNttNap -> partyb:10002:O=PartyB, L=London, C=GB.onSocketConnected - Bridge Connected
partya        | [INFO] 13:09:38+0000 [nioEventLoopGroup-2-1] O=PartyA, L=London, C=GB.onConnectionLocalOpen - Connection local open org.apache.qpid.proton.engine.impl.ConnectionImpl@53bbae2d

Мой node.conf читает:

myLegalName : "O=PartyA, L=London, C=GB"
p2pAddress : "partya:10002"
webAddress : "partya:10005"
devMode : true
rpcSettings = {
    address : "partya:10003"
    adminAddress : "partya:10004"
}
rpcUsers=[
    {
        user=corda
        password=corda_initial_password
        permissions=[
            ALL
        ]
    }
]
detectPublicIp : false

В чем причина отсутствия реакции со стороны PartyB? Судя по логам, все просто прекращается после успешного рукопожатия.

1 Ответ

0 голосов
/ 06 ноября 2018

TL; DR: Аутентификация в моей сети была ошибочной, поскольку контейнеры создали свои собственные файлы nodeInfo- *, которые не совпадали с файлами nodeInfo- *, которые я предоставил в каталоге "Additional-Node-Infos /" .


После активации режима отладки с помощью аргумента командной строки «--logging-level DEBUG» я обнаружил ошибку аутентификации. Для локального тестирования я сейчас делаю следующее:

  1. Совместное использование тома докера между всеми контейнерами, сопоставленными с каталогом "extra-node-infos"
  2. Пусть контейнеры совместно используют свои nodeInfo при запуске.

Это скрипт, который я использую для запуска контейнеров Corda в режиме dev:

#!/bin/sh

# If variable not present use default values
: ${CORDA_HOME:=/opt/corda}
: ${JAVA_OPTIONS:=-Xmx512m}

export CORDA_HOME JAVA_OPTIONS

cd ${CORDA_HOME}

### share the node-info with the other nodes via docker volume
java $JAVA_OPTIONS -jar ${CORDA_HOME}/corda.jar --just-generate-node-info
cp -f nodeInfo-* additional-node-infos/

### usual start
java $JAVA_OPTIONS -jar ${CORDA_HOME}/corda-webserver.jar 2>&1 &
java $JAVA_OPTIONS -jar ${CORDA_HOME}/corda.jar --log-to-console 2>&1
...