Использование примера сети Fabric

После загрузки образов и примеров Hyperledger Fabric Docker можно развернуть пример сети с помощью сценариев из хранилища fabric-samples. Узлы можно запускать локально и пример сети можно использовать для изучения особенностей работы сети Fabric. Более опытные разработчики могут использовать пример сети для проверки работы собственных смарт-контрактов и приложений. Сеть предназначена только для изучения и тестирования. Она не должна использоваться в качестве шаблона для развертывания реальной сети. Пример сети был добавлен в Fabric версии 2.0 в качестве полноценной замены примера first-network.

Сеть развертывается с помощью Docker Compose. Поскольку узлы изолированы внутри Docker Compose, пример сети не настроен для подключения к другим работающим узлам Fabric.

Примечание. Эти инструкции подразумевают использование последних стабильных образов Docker Composite и скомпилированных инструментов установки в прилагаемом архиве tar. Возможно возникновение ошибок при запуске этих команд с образами или инструментами из текущей основной ветки.

Прежде чем начать

Перед запуском примера сети необходимо клонировать хранилище fabric-samples и загрузить образы Fabric. Также необходимо установить все компоненты из разделов Предварительные требования и Примеры, двоичные файлы и образы Docker.

Создание примера сети

Сценарии для создания сети находятся в каталоге test-network хранилища fabric-samples. Перейдите к каталогу примера сети, используя следующую команду:

cd fabric-samples/test-network

В этом каталоге находится файл сценария network.sh с подробным описанием, который позволяет создать сеть Fabric с помощью образов Docker на локальном компьютере. Для просмотра текста сценария можно использовать флаг ./network.sh -h:

```Использование:
  network.sh <Режим> [Флаги]
    <Режим>
      - 'up' — позволяет создать узел службы упорядочения и одноранговые узлы. При этом каналы не создаются.
      - 'up createChannel' — позволяет создать сеть Fabric с одним каналом.
      - 'createChannel' — позволяет создать и присоединиться к каналу после создания сети.
      - 'deployCC' — позволяет развернуть чейнкод fabcar в канале.
      - 'down' — позволяет остановить сеть с помощью команды down Docker Compose.
      - 'restart' — позволяет перезапустить сеть.

    Флаги:
    -ca <использовать удостоверяющий центры> — создает удостоверяющий центр для генерации криптографических ключей.
    -c <название канала>— название используемого канала (по умолчанию «mychannel»).
    -s <тип базы данных> — тип базы данных: goleveldb (по умолчанию) или couchdb.
    -r <макс. к-во попыток> — интерфейс командной строки отключается после определенного количества попыток (по умолчанию до 5).
    -d <задержка> — задержка в секундах (по умолчанию до 3).
    -l <язык> — язык программирования для развертывания чейнкода: go (по умолчанию), java, javascript, typescript.
    -v <версия> — версия чейнкода. Следует использовать целое число — 1, 2, 3 и т. д.
    -i <imagetag> — тег образа, используемый для запуска сети (по умолчанию на «latest»).
    -cai <ca_imagetag> — тег образа для создания удостоверяющего центра (по умолчанию «1.4.6»). 
    -verbose — режим отображения подробной информации.
  network.sh -h (отображение этого сообщения).

 Возможные комбинации режимов и флагов 
  network.sh up -ca -c -r -d -s -i -verbose
  network.sh up createChannel -ca -c -r -d -s -i -verbose
  network.sh createChannel -c -r -d -verbose
  network.sh deployCC -l -v -r -d -verbose

 Все по умолчанию:
	network.sh up

 Примеры:
  network.sh up createChannel -ca -c mychannel -s couchdb -i 2.0.0
  network.sh createChannel -c channelName
  network.sh deployCC -l javascript

Из каталога test-network запустите следующую команду для удаления контейнеров или артефактов предыдущих установок:

./network.sh down

После этого можно создать сеть, используя следующую команду. Могут возникнуть проблемы при запуске сценария из другого каталога:

./network.sh up

Эта команда создает сеть Fabric, которая состоит из двух одноранговых узлов и одного узла службы упорядочения. При использовании команды ./network.sh up каналы не создаются. Это можно сделать далее. При успешно выполнении команды будут отображена информация о созданных узлах:

Creating network "net_test" with the default driver
Creating volume "net_orderer.example.com" with default driver
Creating volume "net_peer0.org1.example.com" with default driver
Creating volume "net_peer0.org2.example.com" with default driver
Creating orderer.example.com    ... done
Creating peer0.org2.example.com ... done
Creating peer0.org1.example.com ... done
CONTAINER ID        IMAGE                               COMMAND             CREATED             STATUS                  PORTS                              NAMES
8d0c74b9d6af        hyperledger/fabric-orderer:latest   "orderer"           4 seconds ago       Up Less than a second   0.0.0.0:7050->7050/tcp             orderer.example.com
ea1cf82b5b99        hyperledger/fabric-peer:latest      "peer node start"   4 seconds ago       Up Less than a second   0.0.0.0:7051->7051/tcp             peer0.org1.example.com
cd8d9b23cb56        hyperledger/fabric-peer:latest      "peer node start"   4 seconds ago       Up 1 second             7051/tcp, 0.0.0.0:9051->9051/tcp   peer0.org2.example.com

Если результат отличается, перейдите к разделу Устранение ошибок. По умолчанию для создания сети используется инструмент cryptogen. Однако также можно создать сеть с помощью удостоверяющего центра.

Компоненты примера сети

После развертывания примера сети рекомендуется ознакомится с ее компонентами. Запустите следующую команду, чтобы просмотреть содержимое всех контейнеров Docker, запущенных на вашем компьютере. Будут отображены три узла, созданные сценарием network.sh:

docker ps -a

Для взаимодействия с сетью Fabric узлы и пользователи должны входить в состав организации, которая является членом сети. Группу организаций-членов сети Fabric часто называют консорциумом. В примере сети предусмотрено два члена консорциума — организации Org1 и Org2. Сеть также включает в себя одну организацию службы упорядочения, которая обслуживает службу упорядочения сети.

Одноранговые узлы являются фундаментальными компонентами любой сети Fabric. Одноранговые узлы хранят реестр блокчейн и проверяют транзакции перед записью в реестр. Одноранговые узлы выполняют смарт-контракты, которые содержат бизнес-логику, используемую для управления активами в реестре блокчейн.

Одноранговые узлы в сети должны принадлежать организациям-членам консорциума. В примере сети каждая организация имеет по одному одноранговому узлу — peer0.org1.example.com и peer0.org2.example.com.

Любая сеть Fabric также включает в себя службу упорядочения. Хотя одноранговые узлы проверяют транзакции и добавляют блоки транзакций в реестр блокчейн, они не принимают решения о порядке транзакций или не добавляют их в новые блоки. Одноранговые узлы распределенной сети могут располагаться на большом удалении друг от друга и не имеют общего представления о времени создания транзакции. Достижение консенсуса о порядке транзакций является затратным процессом, который создает дополнительные нагрузки на одноранговые узлы.

Служба упорядочения позволяет одноранговым узлам сосредоточиться на проверке транзакций и добавлении данных в реестр. В свою очередь узлы службы упорядочения получают одобренные транзакции от клиентов, приходят к консенсусу о порядке транзакций и добавляют их в блоки. Затем блоки распределяются по одноранговым узлам, которые добавляют блоки в реестр блокчейн. Узлы службы упорядочения также управляют системным каналом, который определяет возможности сети Fabric, например, особенности построения блоков или версию Fabric, используемую узлами. Системный канал определяет организации, которые являются членами консорциума.

В примере сети используется один узел службы упорядочения Raft, который находится под управлением организации службы упорядочения. На вашем компьютере узел службы упорядочения имеет название orderer.example.com. Хотя в примере сети используется только одон узел службы упорядочения, реальная сеть обычно имеет много узлов службы упорядочения, которые обслуживаются одной или несколькими организациями службы упорядочения. Различные узлы службы упорядочения будут использовать алгоритм консенсуса Raft для соглашения о порядке транзакций в сети.

Создание канала

После создания одноранговых узлов и узлов службы упорядочения можно использовать сценарий создания канала Fabric, чтобы дать возможность организациям Org1 и Org2 осуществлять транзакций. Каналы обеспечивают закрытую связь между конкретными членами сети. Каналы могут использоваться только организациями, которые приглашены в канал, и остаются невидимыми для других членов сети. Каждый канал имеет отдельный реестр блокчейн. Приглашенные организации добавляют свои одноранговые узлы в канал для хранения реестра канала и проверки транзакций в канале.

Сценарий network.sh можно использовать для создания канала для организаций Org1 и Org2, и добавления их одноранговых узлов в канал. Выполните следующую команду для создания канала с названием mychannel (по умолчанию):

./network.sh createChannel

При успешном выполнении команды в журнале появится следующее сообщение:

========= Channel successfully joined ===========

Также можно использовать соответствующий флаг канала для создания канала с пользовательским названием. Например, следующая команда создает канал с названием channel1:

./network.sh createChannel -c channel1

Соответствующий флаг канала также позволяет создавать несколько каналов с разными названиями. После создания канала mychannel или channel1 можно использовать следующую команду для создания второго канала с названием channel2:

./network.sh createChannel -c channel2

Для создания сети и канала одной командой можно использовать режимы up и createChannel вместе:

./network.sh up createChannel

Запуск чейнкода в канале

После создания канала можно использовать смарт-контракты для взаимодействия с реестром канала. Смарт-контракты содержат бизнес-логику, которая управляет активами, записанными в реестре. Выполняемые членами сети приложения могут вызывать смарт-контракты для создания активов в реестре, а также изменения и передачи этих активов другим пользователям. Приложения также могут использовать смарт-контракты для запроса данных из реестра.

Чтобы гарантировать действительность транзакций, созданные с использованием смарт-контрактов транзакции обычно должны быть подписаны несколькими организациями для возможности записи в реестр канала. Получение подписей от нескольких участников является стандартным правилом сетей Fabric. Так как для одобрения транзакции требуется одобрение от нескольких организаций, одна организация в канале не может осуществить неавторизованные действия с реестром на собственном одноранговом узле или с использованием неподтвержденной бизнес-логики. Чтобы подписать транзакцию каждая организация должна вызывать и выполнять смарт-контракт на собственных одноранговых узлах, и далее подписывать результат транзакции. Если результат соответствует требованиям и подписан достаточным количеством организаций, транзакция может быть записана в реестр. Установленные правила, определяющие набор организаций в канале, которые должны выполнить смарт-контракт, называется правилами одобрения и устанавливаются для каждого чейнкода в определении чейнкода.

В сетях Fabric смарт-контракты развертываются в пакетах под названием «чейнкод». Чейнкод устанавливается на одноранговые узлы организаций, а затем развертывается в канале и может далее быть использован для одобрения транзакций и взаимодействия с реестром блокчейн. Перед развертыванием чейнкода в канале, участники канала должны договориться об определении чейнкода, который описывает правила управления чейнкодом. При согласии требуемого количества организаций, определение чейнкода может быть записано в канале, после чего чейнкод будет готов к использованию.

После использования сценария network.sh для создания канала, чейнкод в канале запускается с помощью следующей команды:

./network.sh deployCC

Составляющая часть команды deployCC позволяет установить чейнкод fabcar на одноранговых узлах peer0.org1.example.com и peer0.org2.example.com, после чего происходит развертывание чейнкода в канале, который указан с помощью флага канала (или в канале mychannel по умолчанию, если название канала не указано). При первом развертывании чейнкода, сценарий установит зависимости чейнкода. По умолчанию сценарий устанавливает версию Go чейнкода fabcar. Тем не менее можно воспользоваться флагом языка -l для установки версий чейнкода на языках java или javascript. Чейнкод fabcar находится в подкаталоге chaincode каталога fabric-samples. Этот каталог содержит образец чейнкода, который используется в обучающих примерах для описания функций сети Fabric.

После записи определения чейнкода fabcar в канале, сценарий инициализирует чейнкод путем вызова функции init, а затем вызывает чейнкод, чтобы записать изначальный список автомобилей в реестр. Затем сценарий обращается к реестру, чтобы проверить успешное добавление данных. При правильной установке, развертывании и вызове чейнкода в журнал будет выведен следующий список автомобилей:

[{"Key":"CAR0", "Record":{"make":"Toyota","model":"Prius","colour":"blue","owner":"Tomoko"}},
{"Key":"CAR1", "Record":{"make":"Ford","model":"Mustang","colour":"red","owner":"Brad"}},
{"Key":"CAR2", "Record":{"make":"Hyundai","model":"Tucson","colour":"green","owner":"Jin Soo"}},
{"Key":"CAR3", "Record":{"make":"Volkswagen","model":"Passat","colour":"yellow","owner":"Max"}},
{"Key":"CAR4", "Record":{"make":"Tesla","model":"S","colour":"black","owner":"Adriana"}},
{"Key":"CAR5", "Record":{"make":"Peugeot","model":"205","colour":"purple","owner":"Michel"}},
{"Key":"CAR6", "Record":{"make":"Chery","model":"S22L","colour":"white","owner":"Aarav"}},
{"Key":"CAR7", "Record":{"make":"Fiat","model":"Punto","colour":"violet","owner":"Pari"}},
{"Key":"CAR8", "Record":{"make":"Tata","model":"Nano","colour":"indigo","owner":"Valeria"}},
{"Key":"CAR9", "Record":{"make":"Holden","model":"Barina","colour":"brown","owner":"Shotaro"}}]
===================== Query successful on peer0.org1 on channel 'mychannel' =====================

Взаимодействие с сетью

После создания примера сети можно использовать интерфейс командной строки одноранговых узлов для взаимодействия с сетью. Интерфейс командной строки одноранговых узлов позволяет вызывать развернутые смарт-контракты, обновлять каналы или устанавливать и развертывать новые смарт-контракты.

Убедитесь, что вы находитесь в каталоге test-network. При соблюдении инструкций по установке примеров, двоичных файлов и образов Dockers, двоичные файлы одноранговых узлов будут находится в каталоге bin хранилища fabric-samples. Используйте следующую команду, чтобы добавить эти двоичные файлы в путь интерфейса командной строки:

export PATH=${PWD}/../bin:$PATH

Также необходимо привязать FABRIC_CFG_PATH к файлу core.yaml в хранилище fabric-samples:

export FABRIC_CFG_PATH=$PWD/../config/

Теперь можно установить переменные среды, которые позволяют управлять интерфейсом командной строки одноранговых узлов от лица организации Org1:

# Переменные среды длял организации Org1

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

Переменные среды CORE_PEER_TLS_ROOTCERT_FILE и CORE_PEER_MSPCONFIGPATH указывают на криптографические ключи организации Org1 в каталоге organizations.

Если для установки и запуска чейнкода fabcar использовалась команда ./network.sh deployCC, то к реестру можно обращаться с помощью интерфейса командной строки. Запустите следующую команду для получения списка автомобилей, добавленных в реестр канала:

peer chaincode query -C mychannel -n fabcar -c '{"Args":["queryAllCars"]}'

При успешном выполнении команды будет отображен тот же список автомобилей, которые выводился в журнал при запуске сценария:

[{"Key":"CAR0", "Record":{"make":"Toyota","model":"Prius","colour":"blue","owner":"Tomoko"}},
{"Key":"CAR1", "Record":{"make":"Ford","model":"Mustang","colour":"red","owner":"Brad"}},
{"Key":"CAR2", "Record":{"make":"Hyundai","model":"Tucson","colour":"green","owner":"Jin Soo"}},
{"Key":"CAR3", "Record":{"make":"Volkswagen","model":"Passat","colour":"yellow","owner":"Max"}},
{"Key":"CAR4", "Record":{"make":"Tesla","model":"S","colour":"black","owner":"Adriana"}},
{"Key":"CAR5", "Record":{"make":"Peugeot","model":"205","colour":"purple","owner":"Michel"}},
{"Key":"CAR6", "Record":{"make":"Chery","model":"S22L","colour":"white","owner":"Aarav"}},
{"Key":"CAR7", "Record":{"make":"Fiat","model":"Punto","colour":"violet","owner":"Pari"}},
{"Key":"CAR8", "Record":{"make":"Tata","model":"Nano","colour":"indigo","owner":"Valeria"}},
{"Key":"CAR9", "Record":{"make":"Holden","model":"Barina","colour":"brown","owner":"Shotaro"}}]

Чейнкод вызывается, когда член сети хочет передать или изменить актив в реестре. Используйте следующую команду, чтобы изменить владельца автомобиля в реестре путем вызова чейнкода fabcar:

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"changeCarOwner","Args":["CAR9","Dave"]}'

Если команда выполнена успешна, будет отображен следующий результат:

2019-12-04 17:38:21.048 EST [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200

Примечание: Если вы развернули версию чейнкода на языке Java, запустите команду вызова invoke со следующими аргументами: '{"function":"changeCarOwner","Args":["CAR009","Dave"]}' Java-версия чейнкода fabcar имеет другой индекс в отличие от версий на языках Javascript и Go.

Поскольку правила одобрения чейнкода fabcar требуют подписания транзакции организациями Org1 и Org2, в команде вызова чейнкода должны быть указаны одноранговые узлы peer0.org1.example.com и peer0.org2.example.com с помощью флага --peerAddresses. Поскольку в сети используется шифрование на основе протокола TLS, в команде также следует указать сертификат TLS для каждого однорангового узла с помощью флага --tlsRootCertFiles.

После вызова чейнкода можно использовать другой запрос, чтобы посмотреть изменения активов в реестре блокчейн, произошедшие при вызове чейнкода. Поскольку мы уже обращались к одноранговому узлу организации Org1, можно воспользоваться этой возможностью, чтобы вызвать чейнкод на одноранговом узле организации Org2. Установите следующие переменные среды для работы от имени организации ORG2:

# Переменные среды для организации Org2

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

Теперь можно обратиться к чейнкоду fabcar на одноранговом узле peer0.org2.example.com:

peer chaincode query -C mychannel -n fabcar -c '{"Args":["queryCar","CAR9"]}'

Результат будет содержать информацию о том, что владельцем CAR9 теперь является «Dave»:

{"make":"Holden","model":"Barina","colour":"brown","owner":"Dave"}

Завершение работы сети

По завершению ознакомления с функциями примера сети, ее можно остановить с помощью следующей команды:

./network.sh down

Эта команда остановит сеть и удалит контейнеры узлов и чейнкода, а также удалит криптографические ключи организаций и образы чейнкода из Docker Registry. Эта команда также удалит артефакты каналов и томов Docker, оставшихся от предыдущих запусков, что позволяет повторно запустить ./network.sh up, если при первом запуске возникли проблемы.

Следующие шаги

Теперь, после развертывания примера сети Fabric на локальном компьютере, можно воспользоваться учебными руководствами для начала разработки собственных решений:

Полный список учебных руководств по сетям Fabric приводится на странице Учебные руководства.

Создание сети с помощью удостоверяющих центров

Сеть Hyperledger Fabric использует инфраструктуру открытых ключей (PKI) для проверки действий всех участников сети. Каждый узел, сетевой администратор и пользователь сети должен иметь открытый сертификат и закрытый ключ для идентификации. Идентификаторы должны иметь действительный корень доверия, который подтверждает, что сертификаты выданы организацией, входящей в состав сети. Перед созданием одноранговые узлы и узлы службы упорядочения, сценарий network.sh создает все криптографические ключи, которые требуются для развертывания и эксплуатации сети.

По умолчанию для создания сертификатов и ключей в сценарии используется инструмент cryptogen. Этот инструмент предусмотрен для разработки и тестирования. Он позволяет быстро создавать необходимые криптографические ключи для организаций сети Fabric с действительным корнем доверия. При запуске ./network.sh up можно увидеть, что инструмент cryptogen создает сертификаты и ключи для организаций Org1, Org2, а также организации службы упорядочения.

creating Org1, Org2, and ordering service organization with crypto from 'cryptogen'

/Usr/fabric-samples/test-network/../bin/cryptogen

##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################

##########################################################
############ Create Org1 Identities ######################
##########################################################
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations
org1.example.com
+ res=0
+ set +x
##########################################################
############ Create Org2 Identities ######################
##########################################################
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations
org2.example.com
+ res=0
+ set +x
##########################################################
############ Create Orderer Org Identities ###############
##########################################################
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations
+ res=0
+ set +x

Cценарий примера сети также предоставляет возможность запустить сеть с использованием удостоверяющих центров. В производственной сети каждая организация имеет собственный удостоверяющий центр (или множественных промежуточных центров), который создает идентификаторы для этой организации. Все идентификаторы удостоверяющего центра организации имеют общий корень доверия. Несмотря на большее количество времени в сравнении с инструментом cryptogen, создание сети на основе удостоверяющих центров — это пример развертывания реальной производственной сети. Развертывание удостоверяющих центров также позволяет регистрировать идентификаторы клиентов с помощью комплекта разработчика Fabric, а также создавать сертификаты и закрытые ключи для собственных приложений.

Для создания сети с помощью удостоверяющих центров Fabric, сперва используйте следующую команду, чтобы остановить любые запущенные сети:

./network.sh down

Затем можно создать сеть с флагом удостоверяющего центра:

./network.sh up -ca

После выполнения команды, сценарий создаст три удостоверяющих центра — по одному на организацию.

##########################################################
##### Generate certificates using Fabric CA's ############
##########################################################
Creating network "net_default" with the default driver
Creating ca_org2    ... done
Creating ca_org1    ... done
Creating ca_orderer ... done

После выполнения сценария ./network.sh и развертывания удостоверяющих центров рекомендуется просмотреть содержимое журналов. В примере сети используется клиент удостоверяющего центра Fabric для регистрации идентификаторов узлов и пользователей с помощью удостоверяющих центров каждой организации. Затем в сценарии используется команда регистрации для создания каталогов провайдера службы членства для каждого идентификатора. В каталоге провайдера службы членства содержится сертификаты и закрытые ключи идентификаторов, а также указывается роль и членство в организации, которая управляет удостоверяющим центром. Для изучения содержимого каталога провайдера службы членства пользователя admin организации Org1 можно использовать следующую команду:

tree organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/

Эта команда позволяет просмотреть структуру каталога провайдера службы членства и файл конфигурации:

organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/
└── msp
    ├── IssuerPublicKey
    ├── IssuerRevocationPublicKey
    ├── cacerts
    │   └── localhost-7054-ca-org1.pem
    ├── config.yaml
    ├── keystore
    │   └── 58e81e6f1ee8930df46841bf88c22a08ae53c1332319854608539ee78ed2fd65_sk
    ├── signcerts
    │   └── cert.pem
    └── user

Сертификат пользователя admin находится в каталоге signcerts, а закрытый ключ — в каталоге keystore. Более подробно о провайдерах службы членства рассказано в разделе Провайдер службы членства.

Инструмент cryptogen и удостоверяющие центры Fabric генерируют криптографические ключи для каждой организации из каталога organizations. Команды для настройки сети указаны в сценарии registerenroll.sh в каталоге organizations/fabric-ca. Дополнительная информация об использовании удостоверяющих центров Fabric для развертывания сети приведена в Руководстве по использованию удостоверяющих центров Fabric. Больше об использовании инфраструктуры открытых ключей в Fabric можно прочесть в разделах Идентификация и Членство.

Что происходит за кулисами

Для более глубокого понимания работы примера сети рекомендуем изучить файлы и сценарии в каталоге test-network. Ниже рассказано о том, что происходит при запуске команды ./network.sh up.

  • Сценарий . / network.sh создает сертификаты и ключи для двух организаций с одноранговыми узлами и организации службы упорядочения. По умолчанию сценарий использует инструмент cryptogen и файлы конфигурации, расположенные в каталоге organizations/cryptogen. При использовании флага -ca для создания удостоверяющего центра, сценарий использует файлы конфигурации сервера Fabric, а также сценарий registerEnroll.sh, расположенный в каталоге organizations/fabric-ca. Инструмент cryptogen и удостоверяющие центры Fabric создают каталоги с криптографическими ключами и подкаталоги провайдеров службы членства для всех трех организаций в каталоге organizations.
  • Сценарий использует инструмент configtxgen для создания первичного блока системного канала. Инструмент configtxgen использует профиль канала TwoOrgsOrdererGenesis из файла configtx/configtx.yaml для создания первичного блока. Этот блок хранится в каталоге system-genesis-block.
  • После создания криптографических ключей организаций и первичного блока системного канала, сценарий network.sh может создать узлы сети. Для создания одноранговых узлов и узлов службы упорядочения сценарий использует файл docker-compose-test-net.yaml из каталога docker. Каталог docker также содержит файл docker-compose-e2e.yaml, который создает узлы сети, а также три удостоверяющих центра. Этот файл предназначен для выполнения сквозного тестирования с помощью комплекта разработчика Fabric. Смоотрите раздел Комплект разработчика Node SDK для получения подробной информации о выполнении сквозного тестирования.
  • При использовании подкоманды сreateChannel, сценарий ./network.sh запускает сценарий сreateChannel.sh из каталога scripts для создания канала с указанным названием. Сценарий использует файл configtx.yaml для создания транзакции создания канала, а также двух транзакции обновления якорных одноранговых узлов. Сценарий использует интерфейс командной строки одноранговых узлов для создания канала, присоединения узлов peer0.org1.example.com и peer0.org2.example.com к каналу и назначение этим узлам роли якорных узлов.
  • При использовании команды deployCC сценарий ./network.sh запустит сценарий deployCC.sh для установки чейнкода fabcar на обоих одноранговых узлах, а затем запишет определение чейнкода в канале. После записи определения чейнкода в канале, с помощью команды init через интерфейс командной строки чейнкод инициализируется и вызывается для записи указанных исходных данных в реестр.

Устранение ошибок

Если возникают проблемы при выполнении команд из этого обучающего примера, проверьте следующее:

  • Всегда следует создавать новую сеть. Можно использовать следующую команду для удаления оставшихся артефактов, криптографических ключей, контейнеров, томов и образов чейнкода:

    ./network.sh down
    

    Ошибки будут возникать, если не удалить старые контейнеры, образы и тома.

  • Если возникают ошибки Docker, следует проверить используемую версию Docker (Предварительные требования) и затем попробовать перезапустить процесс Docker. Зачастую проблемы с Docker не сразу можно распознать. Например, ошибки могут возникать из-за того, что узел не в состоянии получить доступ к криптографическим ключам, установленным в контейнере.

    Если проблемы не устраняются, можно удалить образы и начать с нуля:

    docker rm -f $(docker ps -aq)
    docker rmi -f $(docker images -q)
    
  • Если ошибки возникают при выполнении команд создания, одобрения, записи, вызова или запроса, убедитесь, что названия канала и чейнкода указаны правильно. В примерах команд используются стандартные названия.

  • Если возникает следующая ошибка:

    Error: Error: Error endorsing chaincode: rpc error: code = 2 desc = Error installing chaincode code mycc:1.0(chaincode /var/hyperledger/production/chaincodes/mycc.1.0 exits)
    

    Скорее всего остались образы чейнкода от предыдущих запусков сети (например, dev-peer1.org2.example.com-fabcar-1.0 или dev-peer0.org1.example.com-fabcar-1.0). Удалите их попробуйте заново

    docker rmi -f $(docker images | grep dev-peer[0-9] | awk '{print $3}')
    
  • Если возникает следующая ошибка:

    [configtx/tool/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type ""
    panic: Error reading configuration: Unsupported Config Type ""
    

    Это означает, что вы неправильно задали переменную среду FABRIC_CFG_PATH. Инструмент configtxgen использует эту переменную для нахождения пути к файлу configtx.yaml. Вернитесь к соответствующему шагу и выполните export FABRIC_CFG_PATH=$PWD/configtx/configtx.yaml, после чего заново создайте артефакты канала.

  • При возникновении ошибки, сообщающей о наличии активных конечных точек (active endpoints) следует удалить сети Docker с использование команды prune. Это позволить очистить среду от предыдущих сетей:

    docker network prune
    

    Появится следующее сообщение:

    WARNING! This will remove all networks not used by at least one container.
    Are you sure you want to continue? [y/N]
    

    Нажмите y.

  • При возникновении следующей ошибки (или схожей):

    /bin/bash: ./scripts/createChannel.sh: /bin/bash^M: bad interpreter: No such file or directory
    

    Убедитесь, что файл (createChannel.sh в примере) указан в формате Unix. Скорее всего это происходит из-за того, что для опции core.autocrlf в конфигурации Git не установлено значение false (см. Дополнительно для ОС Windows). Есть несколько способов устранения этой ошибки. Например, откройте файл при наличии редактора vim:

    vim ./fabric-samples/test-network/scripts/createChannel.sh
    

    Затем измените его формат с помощью следующей команды vim:

    :set ff=unix
    
  • Если узел службы упорядочения завершает работу после создания или при неуспешном выполнении команды создания канала из-за невозможности подключения к службе упорядочения, используйте команду docker logs, чтобы посмотреть содержимое журнала узла службы упорядочения. Возможно встретится следующее сообщение:

    PANI 007 [channel system-channel] config requires unsupported orderer capabilities: Orderer capability V2_0 is required but not supported: Orderer capability V2_0 is required but not supported
    

    Такая ошибка возникает при попытке запустить сеть, используя образы Docker версии Fabric 1.4.x. Пример сети рассчитан на работу с версией Fabric 2.x.

Если ошибки продолжают возникать, выложите журналы в канале fabric-questions чата Hyperledger Rocket или на сайте StackOverflow.