Я настраиваю среду разработки, следуя инструкциям на официальном сайте Hyperledger Fabric: https://hyperledger-fabric.readthedocs.io/en/latest/peer-chaincode-devmode.html Я успешно запустил заказчицу, используя:
ORDERER_GENERAL_GENESISPROFILE=SampleDevModeSolo orderer
Эта команда не работала сначала, но она работала после того, как я cd fabric/sampleconfig
2020-12-21 11:23:15.084 CST [orderer.common.server] Main -> INFO 009 Starting orderer: Version: 2.3.0 Commit SHA: dc2e59b3c Go version: go1.15.6 OS/Arch: darwin/amd64
2020-12-21 11:23:15.084 CST [orderer.common.server] Main -> INFO 00a Beginning to serve requests
Но когда я запускаю одноранговый узел, используя:
export PATH=$(pwd)/build/bin:$PATH
export FABRIC_CFG_PATH=$(pwd)/sampleconfig
export FABRIC_LOGGING_SPEC=chaincode=debug
export CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
peer node start --peer-chaincodedev=true
Выявляется ошибка:
FABRIC_LOGGING_SPEC=chaincode=debug
CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
peer node start --peer-chaincodedev=true
2020-12-21 11:25:13.047 CST [nodeCmd] serve -> INFO 001 Starting peer: Version: 2.3.0 Commit SHA: dc2e59b3c Go version: go1.15.6 OS/Arch: darwin/amd64 Chaincode: Base Docker Label: org.hyperledger.fabric Docker Namespace: hyperledger
2020-12-21 11:25:13.048 CST [peer] getLocalAddress -> INFO 002 Auto-detected peer address: 10.200.83.208:7051
2020-12-21 11:25:13.048 CST [peer] getLocalAddress -> INFO 003 Host is 0.0.0.0 , falling back to auto-detected address: 10.200.83.208:7051 Error: failed to initialize operations subsystem: listen tcp 127.0.0.1:9443: bind: address already in use
Это ошибка:
Error: failed to initialize operations subsystem: listen tcp 127.0.0.1:9443: bind: address already in use
Я проверил эту проблему, и кажется, что это происходит из-за того, что одноранговый узел использует тот же порт 9443, что и узел-заказчик для той же службы. Как я могу заставить два узла работать отдельно? Кажется, докер тоже работает.
Если вы видите свою ошибку, вы можете легко следовать Error: failed to initialize operations subsystem: listen tcp 127.0.0.1:9443: bind: address already in use Говорят, что порт 9443 уже используется.
Похоже, вы не запускаете ордер и пиринг как отдельные контейнеры в виртуальной сети на основе докера, а работаете на хост-компьютере. В конечном итоге это конфликтует с двумя серверами, запрашивающими один порт 9443 на вашем компьютере.\
Ссылаясь на приведенную ниже конфигурацию fabric-2.3/sampleconfig, вы можете видеть, что каждый порт 9443 назначен серверу. Назначение одного из них другому порту решает эту проблему.
Ткань-2.3/sampleconfig/orderer.yaml
конфигурация ордера
# orderer.yaml
...
Admin:
# host and port for the admin server
ListenAddress: 127.0.0.1:9443
...
Ткань-2.3/sampleconfig/core.yaml
конфигурация однорангового узла
# core.yaml
...
operations:
# host and port for the operations server
# listenAddress: 127.0.0.1:9443
listenAddress: 127.0.0.1:10443
...
При работе с несколькими контейнерами рекомендуется строить сеть через docker-compose. То же самое можно применить к фабрике, и если она построена через контейнер, необходимо учитывать только конфликт портов на хост-компьютере и другую топологию сети. Посмотреть официальный образец ткани можно здесь. образцы тканей/docker-compose-test-net.yaml
Действительно полезно. Большое спасибо!
Это не прямой ответ на проблему сопоставления/коллизии портов, но мы добились большого успеха, используя новую Тестовую сеть Kubernetes в качестве платформы разработки, работающей в локальной системе с виртуальным кластером Kubernetes, работающим в KIND (Kubernetes в Докер).
В этом режиме приложения могут разрабатываться с использованием клиента шлюза (предоставленного через переадресацию порта или вход), а смарт-контракты, работающие как служба, могут быть запущены либо в кластере, либо на локальной ОС хоста в контейнере, двоичном файле или запускал в отладчике.
Документации для настройки разработки по-прежнему мало, но мы хотели бы услышать отзывы об общем подходе, поскольку он предлагает экспоненциально лучший опыт работы с тестовой сетью в контексте разработки. В целом процесс «жонглирования портами» с Compose больше не актуален при работе на локальном кластере Kubernetes. В этом режиме вы можете запускать сервисы в хост-сети, инструктируя пиров/заказчиков и т.д. для подключения к удаленному процессу, работающему в хост-ОС.
Да, это работает. Спасибо. Но другие порты тоже конфликтуют. Вы знаете, как запустить заказы и одноранговые процессы в двух докер-контейнерах? Спасибо за вашу помощь.