Procédure de test de script de réseau – KC Tam

J’ai commencé mon parcours d’apprentissage de Hyperledger Fabric en étudiant Premier réseau il y a deux ans. C’était un très bon exemple de configuration à partir duquel j’ai beaucoup appris sur cette plate-forme. Je sais que beaucoup de gens empruntent la même voie. Ceci écrit il y a plus d’un an est toujours l’un de mes articles les plus lus.

Fabric v2.0 est venu avec un nouvel exemple de réseau: Réseau de test. Dans un, j’ai déjà souligné la différence entre ces deux exemples de réseaux. Ici, je viens de cet article sur Test Network. Mon travail précédent sur First Network montrait une exécution pas à pas du script byfn.sh. J’ai adopté une approche similaire dans cet article comme une autre exécution manuelle étape par étape du script network.sh. Au cours du processus, je ferai quelques explications et discussions sur les éléments pertinents.

Je souhaite que cela puisse également vous fournir une image plus complète de Test Network. Grâce à cela, vous pouvez saisir une opération de base consistant à mettre en place un réseau de consortium et à déployer le code de chaîne dans Fabric v2.0.

Sans répéter ce qui est dans l’article précédent, voici quelques informations rapides sur Test Network,

• Une configuration à trois organisations
• Une organisation de commande: example.com, avec une seule commande
• Deux organisations homologues: org1.example.com et org2.example.com, dont chacun a un homologue (peer0)
• Un canal ma Chaîne est créé et rejoint par des pairs des deux organisations homologues.

Voici à quoi ressemble Test Network.

Test Network est livré avec un script network.sh. Et voici les commandes

• network.sh up: afficher les composants réseau, un ordonnateur et un homologue pour chaque organisation homologue.
• network.sh up createChannel: affichez les composants réseau, créez mychannel et demandez à tous les pairs de rejoindre mychannel.
• network.sh createChannel: créez mychannel et demandez à tous les pairs de rejoindre mychannel. applicable après network.sh up est exécuté.
• network.sh deployCC: déployer et interagir avec Fabcar chaincode. exécutable après la création du canal avec network.sh up createChannel ou network.sh createChannel.

Notez que le matériel cryptographique par défaut est généré via cryptogen. Test Network prend également en charge une autre façon d’afficher du matériel cryptographique à l’aide de Fabric CA Server. Dans cet article, j’utilise cryptogen. Pour plus d’informations sur l’utilisation de Fabric CA Server, vous pouvez vous référer à my.

Tandis que network.sh est livré avec plusieurs commandes comme indiqué ci-dessus, je casse l’exécution de network.sh script en plusieurs étapes, montrant comment les choses sont faites manuellement. Voici les étapes:

1. Générez du matériel cryptographique avec cryptogen
2. Générer le bloc Genesis du consortium
3. Afficher les composants réseau de test
4. Rejoignez les pairs des deux organisations sur mychannel
5. Déployer Fabric sur mychannel
6. Interagir avec les fonctions de code de chaîne de tissu

L’étape 1 à 3 équivaut à exécuter la commande ./network.sh up.

Étape 1: Générez du matériel cryptographique avec cryptogen

Fichiers de configuration

Nous générons du matériel cryptographique en utilisant cryptogen dans ce tutoriel. Le fichier de configuration indique cryptogen quel type de composants et d’utilisateurs sont nécessaires. Dans Test Network, il y a trois cryptogen fichiers de configuration à l’intérieur organizations/cryptogen/.

Pour l’organisation de la commande, organizations/cryptogen/crypto-config-orderer.yaml

Pour l’organisation par les pairs Org1, organizations/cryptogen/crypto-config-org1.yaml

Pour l’organisation par les pairs Org2, organizations/cryptogen/crypto-config-org2.yaml

Outils binaires

Tous les outils et commandes (cryptgen, configtxgen, peer, etc.) sont stockés dans fabric-samples/bin/. Mettez à jour le PATH pour inclure ce répertoire.

cd fabric-samples/test-network
export PATH=${PWD}/../bin:${PWD}:$PATH

Génération de matériel cryptographique pour toutes les organisations

Les matériaux résultants sont tous placés à l’intérieur organizations/. L’organisation du donneur d’ordre est stockée dans organizations/ordererOrganizations/et les organisations organizations/peerOrganizations/.

cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output="organizations"cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output="organizations"

Matériel cryptographique dans les composants réseau

Ces matériaux cryptographiques générés seront placés dans les composants de réseau correspondants. Cela se fait via le fichier Docker compose. Voici la docker/docker-compose-test-net.yaml.

Étape 2: Générer le bloc Genesis du consortium

Fichier de configuration

La configuration du consortium est en configtx/configtx.yaml. Ici, nous ne montrons que la partie pertinente pour le bloc de genèse du consortium.

Génération de blocs de genèse de consortium

Voici comment nous générons ce bloc de genèse de consortium. Nous précisons le profil TwoOrgsOrdererGenesis. Le résultat est conservé dans system-genesis-block/.

export FABRIC_CFG_PATH=${PWD}/configtxconfigtxgen -profile TwoOrgsOrdererGenesis -channelID system-channel -outputBlock ./system-genesis-block/genesis.block

Bloc de genèse du consortium dans l’ordre

Ce bloc de genèse du consortium n’apparaît que dans les commandes. Dans Test Network, il apparaît uniquement dans orderer.example.com. Voici un extrait de docker/docker-compose-test-net.yaml.

Étape 3: faire apparaître des composants réseau de test

Fichier de configuration

Utilisez docker-compose pour afficher les trois composants réseau de Test Network. Le fichier de configuration de docker compose à utiliser est docker/docker-compose-test-net.yaml.

Affichez tous les composants du réseau

IMAGE_TAG=latest docker-compose -f docker/docker-compose-test-net.yaml up -d

Voici comment les trois conteneurs s’exécutent dans localhost.

L’étape 4 équivaut à exécuter la commande ./network.sh createChannel.

Étape 4: Rejoignez les pairs des deux organisations sur mychannel

Dans Test Network, création et adhésion ma Chaîne implique trois étapes

1. utilisation configtxgen pour générer des transactions pour mychannel, y compris les transactions de configuration et les transactions de mise à jour des pairs d’ancrage
2. préparer un bloc de genèse de canal pour ma Chaîne, qui est un fichier
3. rejoindre le canal à l’aide du fichier de blocage de canal genesis

Remarque: Ne vous mélangez pas avec cela fichier de bloc de genèse de canal avec le fichier de bloc de la genèse du consortium à l’étape 2. Le fichier de bloc de la genèse du consortium contient la configuration de l’ensemble du consortium des organisations membres. Un canal est un sous-ensemble (ou un ensemble complet) du consortium. Il peut y avoir plus d’un canal défini dans un consortium, pour refléter la vraie relation d’affaires et la logique. Chaque canal commence par un fichier de bloc de genèse de canal. Dans Test Network, nous n’avons qu’un seul canal, ma Chaîneet tous les membres du consortium, org1 et org2, rejoignent ce ma Chaîne.

Contrairement à First Network, Test Network n’est pas fourni avec CLI récipient. Les artefacts de canal sont générés et stockés dans localhost, et peer les commandes sont émises directement depuis localhost.

Générer des artefacts de canal

Les artefacts de canal pour mychannel incluent une transaction de configuration et une transaction de mise à jour des pairs d’ancrage pour chaque organisation homologue. Notez que nous utilisons le profil TwoOrgsChannel spécifié dans configtx/configtx.yaml.

mkdir -p channel-artifactsconfigtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/mychannel.tx -channelID mychannelconfigtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSPconfigtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP

Les matériaux générés sont tous conservés dans channel-artifacts/.

Fichier de blocage de la genèse des canaux

Le fichier de bloc de genèse de canal, bloc # 0 pour ma Chaîne, est généré à l’aide de la transaction de configuration générée précédemment.

Comme nous avons besoin de certificats d’autorité de certification TLS pour atteindre les composants, nous pouvons définir ces variables d’environnement pour un affichage soigné.

export ORDERER_CA=${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pemexport PEER0_ORG1_CA=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crtexport PEER0_ORG2_CA=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

Nous ciblons cette commande de pair à partir de peer0.org1.example.com. Notez les variables (en italique) appliqué au début de cette commande. Nous allons l’utiliser pour spécifier où la commande homologue est émise.

export FABRIC_CFG_PATH=$PWD/../config/CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer channel create -o localhost:7050 -c mychannel --ordererTLSHostnameOverride orderer.example.com -f ./channel-artifacts/mychannel.tx --outputBlock ./channel-artifacts/mychannel.block --tls true --cafile $ORDERER_CA

Nous précisons ce qui suit dans ce peer commander

• localhost:7050 comme commandeur. Utilisation ordererTLSHostnameOverride pour remplacer par le nom orderer.example.com. Plus le matériau TLS (commanditaire CA)
• nom du canal mychannel
• fichier de configuration de canal ./channel-artifacts/mychannel.tx
• bloc de genèse du canal de sortie sous forme de fichier: ./channel-artifacts/mychannel.block.

Maintenant, nous avons le fichier mychannel.block. Nous l’utiliserons pour rejoindre des pairs des deux organisations homologues.

Rejoignez vos pairs sur mychannel

Les pairs des deux organisations se joignent ma Chaîne en utilisant le fichier de blocage.

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer channel join -b ./channel-artifacts/mychannel.blockCORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG2_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=localhost:9051 peer channel join -b ./channel-artifacts/mychannel.block

Et les deux partagent la même blockchain, avec une hauteur de 1 (seul le bloc # 0 existe).

Mettre à jour les pairs d’ancrage

Appliquez la transaction de mise à jour.

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer channel update -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx --tls true --cafile $ORDERER_CACORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG2_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=localhost:9051 peer channel update -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f ./channel-artifacts/Org2MSPanchors.tx --tls true --cafile $ORDERER_CA

Nous précisons ce qui suit dans ce peer commander

• localhost:7050 comme commandeur. Utilisation ordererTLSHostnameOverride pour remplacer par le nom orderer.example.com. Plus le matériau TLS (commanditaire CA)
• nom du canal mychannel
• mettre à jour le fichier de configuration ./channel-artifacts/OrgnMSPanchors.tx, que nous générons au début de cette étape

Vérifiez la blockchain des deux pairs: elle doit maintenant être de hauteur 3 (un nouveau bloc est validé après chaque mise à jour du pair d’ancrage). Le contenu de la blockchain (hachage) dans les deux homologues reste identique.

Avec cela, mychannel est créé et rejoint par des pairs de toutes les organisations.

Les étapes 5 à 6 équivalent à l’exécution de la commande ./network.sh deployCC.

Étape 5: Déployer Fabcar sur mychannel

Nous suivons le processus de chaincode du cycle de vie à déployer Fabcar sur mychannel. Dans Fabric v2.0, le déploiement du code de chaîne se fait à l’aide du code de chaîne du cycle de vie. Pour plus de détails sur le code de chaîne du cycle de vie, vous pouvez vous référer à mon.

Paquet Fabinc chaincode

Nous installons d’abord la dépendance sur le code de chaîne s’il n’est pas encore fait.

# install dependence if not done before
pushd ../chaincode/fabcar/go
GO111MODULE=on go mod vendor
popdCORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer lifecycle chaincode package fabcar.tar.gz --path ../chaincode/fabcar/go/ --label fabcar_1

Le résultat est le fichier de package chaincode stocké localement.

Installer Fabcar aux pairs des deux organisations

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer lifecycle chaincode install fabcar.tar.gzCORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG2_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=localhost:9051 peer lifecycle chaincode install fabcar.tar.gz

Nous récupérerons l’ID du package après l’installation du package chaincode. Notez qu’ils sont les mêmes dans ce tutoriel, mais ce n’est pas nécessaire car v2.0 ce processus est effectué par chaque organisation séparément. Il y a des chances que l’organisation individuelle étend le code de chaîne. Voir ceci pour plus de détails.

Nous pouvons vérifier si l’installation est réussie.

Pendant ce temps, une nouvelle image de conteneur de code de chaîne est créée, une pour chaque homologue. Ils ne sont pas encore instanciés (ne s’exécutant pas encore comme conteneur Docker). C’est aussi pourquoi cela prend du temps lors de la construction des images.

Pour ceux qui sont intéressés par le conteneur chaincode dans Fabric v2.0, vous pouvez vous référer à mon autre à ce sujet.

C’est à quoi ressemble la configuration. Deux images de conteneur de chaincode sont construites, mais ne fonctionnent pas encore comme conteneur.

Approuver la définition du code de chaîne pour les deux organisations

Nous approuvons d’abord Org1.

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile $ORDERER_CA --channelID mychannel --name fabcar --version 1 --init-required --package-id fabcar_1:2939b5f219f516bc94df2253438bad440d6a91432f6b5bbd17ef05d2228766e8 --sequence 1

Avec cela, nous pouvons vérifier la disponibilité de la validation du code de chaîne des deux organisations. L’approbation est enregistrée et les deux organisations voient le même résultat.

Maintenant, nous approuvons Org2.

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG2_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=localhost:9051 peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile $ORDERER_CA --channelID mychannel --name fabcar --version 1 --init-required --package-id fabcar_1:2939b5f219f516bc94df2253438bad440d6a91432f6b5bbd17ef05d2228766e8 --sequence 1

Et vérifiez à nouveau l’état de préparation du commit chaincode. Désormais, les deux organisations approuvent la définition du code de chaîne.

Valider la définition du code de chaine sur mychannel

Comme cela satisfait la politique d’approbation du cycle de vie (majorité), la définition du code de chaîne peut être validée sur mychannel.

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer lifecycle chaincode commit -o localhost:7050 --tls true --cafile $ORDERER_CA --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA --channelID mychannel --name fabcar --version 1 --sequence 1 --init-required

Et nous pouvons vérifier le code de chaîne engagé.

Et nous voyons que les conteneurs de chaincode pour les deux pairs sont instanciés.

Il y a maintenant au total cinq conteneurs en cours d’exécution dans localhost, avec les deux nouveaux conteneurs chaincode, un pour chaque homologue.

Le code de chaîne est maintenant prêt à l’emploi.

Étape 6: interagir avec les fonctions Fabinc Chaincode

Invoke Chaincode Function

Nous invoquons initLedger () fonctions, en précisant les pairs des deux organisations comme endosseurs. (Remarque: dans configtx/configtx.yaml, la politique d’approbation par défaut est majoritaire. Par conséquent, les deux organisations sont requises.)

CORE_PEER_TLS_ENABLED=true CORE_PEER_LOCALMSPID="Org1MSP" CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp CORE_PEER_ADDRESS=localhost:7051 peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile $ORDERER_CA -C mychannel -n fabcar --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA --isInit -c '{"function":"initLedger","Args":[]}'

Fonction Query Chaincode

Ensuite, nous interrogeons la fonction queryAllCars () des deux pairs.

Nous avons parcouru le script network.sh pour Test Network, montrant comment préparer du matériel cryptographique et des artefacts de canal pour un réseau simple à trois organisations. Nous déployons également Fabcar chaincode utilisant le cycle de vie chaincode et après le déploiement, a appelé les fonctions chaincode pour vérifier si tout fonctionne bien.

J’espère que ce didacticiel vous aidera à mieux comprendre Test Network et que vous pourrez l’utiliser pour tester votre propre configuration réseau ou le développement de code de chaîne.