Во-первых, ваша служба заказа сети должна быть настроена как Kafka, а не как одиночная. Вы можете сделать это в файле configtx.yaml в разделе OrdererType. Затем вам также нужно будет создать брокеров, зоопарков и настроить все это. Если вы не знакомы с этим, я обнаружил, что экспериментирование и изучение этого репо https://github.com/keenkit/fabric-sample-with-kafka очень полезно.
Предполагая, что у вас есть рабочая сеть со службой заказа Kafka, добавление дополнительного заказчика осуществляется через обновление канала, что очень похоже на добавление новой организации. Здесь достаточно много шагов, но все они перечислены и объяснены здесь http://hyperledger -fabric.readthedocs.io / en / release-1.1 / channel_update_tutorial.html . Я бы порекомендовал вам понять, как вначале работает добавление организации, но если вы чувствуете себя комфортно, то единственными отличиями для добавления заказчика являются:
- очевидно, нет необходимости создавать новые криптографические материалы org, но вам понадобятся криптографические материалы для другого заказчика
- вместо запуска команды
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json, которая добавляет новый криптографический материал org в сеть, откройте файл json и найдите «OrdererAddresses». Там должен быть массив заказчиков там под другим тегом «адреса». Добавьте ваш заказчик здесь и просто сохраните файл какified_config.json. Затем вы можете просто выполнить те же команды, двигаясь вперед.
- когда вы подписываете конверт с помощью
peer channel signconfigtx -f org3_update_in_envelope.pb, загрузите CLI с активным заказчиком и используйте OrdererMSP, иначе заказчик отклонит вашу транзакцию. Организации MSP, которые используются для добавления новых организаций, не будут работать.
Чтобы устранить неполадки, я обнаружил, что проще сначала развернуть установку 2 Orderer, которую создает вышеупомянутое репозиторий github, а затем протестировать удаление 1 ордера, а затем добавить его обратно. После этого эксперимента добавьте еще 3.
В качестве примечания вы можете найти все остальные вещи, которые можно изменить с помощью обновления канала, здесь: http://hyperledger -fabric.readthedocs.io / en / release-1.1 / config_update.html, Нажмите «Нажмите здесь, чтобы увидеть конфигурацию», чтобы увидеть пример конфигурации json (Примечание: этот пример - соло, а не Кафка).
Шаг за шагом (по запросу):
- В crypto-config под OrdererOrgs: Specs: создайте новое имя хоста для вашего заказчика (используя тот же домен и имя, что и у вашего другого).
- Запустите команду
cryptogen extend --config=./crypto-config.yaml ПРИМЕЧАНИЕ: часть 'extended' генерирует то, что вам нужно, а не восстанавливает все.
- Раскрутите новый контейнер с заказчиком, который по существу идентичен другому заказчику, за исключением того, что криптографические тома указывают на новый криптогенерируемый на шаге 2 (и, возможно, другой порт в зависимости от вашей настройки). В этот момент вы можете заметить, что он подключен к брокерам kafka и имеет ваш канал и блоки, потому что он использует тот же самый блок генеза. Что нужно сделать, так это то, что сеть должна быть уведомлена об адресе этого нового заказчика.
docker exec -it cli bash в свой контейнер CLI и загрузите его с активной информацией о заказчике, поскольку вам потребуется OrdererMSP для подписания этого изменения.
Бутстрап, например (ваш может быть другим): CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@example.com/msp
CORE_PEER_ADDRESS=orderer0.example.com:7050
CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/ca.crt
ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer0.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
CHANNEL_NAME=mychannel
- установить jq в контейнер CLI для преобразования блоков в json и обратно
apt update && apt install -y jq
- получить последний блок конфигурации
peer channel fetch config config_block.pb -o orderer0.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
- конвертировать в json и обрезать заголовки
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json
- откройте файл json, найдите «OrdererAddresses», и под этим заголовком должен быть еще один тег «адреса». Добавьте новый IP и PORT для нового заказчика в этом массиве. Сохраните изменения как updated_config.json
- скрытая форма json, шаг 7 для блокировки
configtxlator proto_encode --input config.json --type common.Config --output config.pb
- преобразовать JSON из шага 8 в блок
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
- вычислить дельту между кадрами в шаге 9 и 10
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb
- изменить дельту обратно на json
configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json
- завернуть JSON в заголовок
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json
- преобразовать его обратно в блок
configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb - Поскольку вы загружаете как активный заказчик, вы можете просто отправить его, так как отправляющая сторона дает вам бесплатную подпись и единственную, которая вам нужна
peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer0.example.com:7050 --tls --cafile $ORDERER_CA
Как только ваши коллеги получат этот новый блок, они узнают адрес нового заказчика и могут связаться с ним.