Add a Peer to an Organization in Test Network (Hyperledger Fabric v2.3)
Last updated
Last updated
Test Network comes as a sample network since Fabric v2.0, and in v2.3 we see a more comprehensive set of scripts for flexible channel creation and chaincode deployment. Test Network architecture is very simple, a three-organization network setup, one for ordering service and two for peer organizations. Inside each peer organization, we have one peer and an optional CA.
While it is good and basic enough for testing channels and chaincode, it does not give us some network architectures for learning or testing purposes. For example, if we wish to take a look at the high availability behaviour inside an organization, we need one more peer. Thanks to the CA option, we can easily add additional peers on the existing network and join it to an existing channel.
We use script network.sh to bring up the Test Network and mychannel (steps 1–5 in the previous session).
Total of six containers are running:
3 CAs, one for each organization
1 orderer
2 peers, one for Org1 and one for Org2
We also use network.sh to deploy sacc (step 6 in the previous session).
After deployment, we take a look on the output of service discovery about endorsement. We see endorsing policy requires both organizations, and each organization has one peer currently. We will see this again after we complete the addition of peer1.org1.example.com.
After deployment, we perform an invoke and query from both peers.
Invoke from Org1
Query from both Org1 and Org2. And we see the same state value for asset name. The network is running well.
Use CA of Org1 to generate crypto material for peer1.org1.example.com. Here we largely follow the script ./organizations/fabric-ca/registerEnroll.sh.
Let’s check the directory structure for peer1.org1.example.com. We see the msp/ directory structure, and the three files required in tls/, that is, ca.crt, server.crt and server.key.
Here is step 4 in the previous session. We keep the docker-compose file inside docker/ directory. The file is adopted from docker-compose-test-net.yaml, with the proper host, directory and port modified for peer1.org1.example.com.
Let's start the peer
The container for peer1.org1.example.com is running. It is not part of the channel yet. Here we perform the 5c in the previous session, joining this new peer to mychannel.
We are accessing both peer0.org1.example.com and peer1.org1.example.com with the same terminal for Org1. To specify peer1.org1.example.com, we set the variable CORE_PEER_ADDRESS=localhost:8051 before any peer commands.
First, let’s check the channel both peers of Org1 have joined.
We see peer1.org1.example.com has not joined any channel yet.
To join the channel, we need the channel genesis block. It was generated during channel creation when we first executed the ./network.sh script, and the block file is kept in channel-artifacts/mychannel.block.
Now we see peer1.org1.example.com has joined mychannel
As we know, peer joining the same channel is holding a copy of ledger. And we see they have the same ledger (same blockchain height and hash). The “missing” blocks have been collected from other peers in the channel.
And for sake of completeness, we see the same ledger in peer0.org2.example.com as well.
Now all three peers are in the same channel, and have a common ledger.
We first check if we can use peer1.org1.example.com in chaincode query.
We see that, even though the ledger is already there, we cannot query peer1.org1.example.com. The reason is that a chaincode is not installed on this peer and a chaincode container is not there yet.
Before installing chaincode on the new peer, we first take a look at the chaincode containers. We see two, one for each peer.
And these two chaincode containers are instantiated by two images, one for each peer.
Now we install the chaincode package on peer1.org1.example.com. According to the script, the chaincode package mycc.tar.gz is created and kept in the test-network/ directory.
After installation completes, we see a new chaincode container running for this peer, instantiated from a new image.
If we take a look on the service discovery on endorsement, now we have two peers for Org1. Either one is good enough to handle the endorsement for Org1. We will test this in the next step.
First, we query the state of an existing asset. Now we get back the result from peer1.org1.example.com.
Then we invoke chaincode function, with peer1.org1.example.com as one endorser for Org1. Remember that the default chaincode endorsement policy is majority, which means one endorsement is needed from both organizations. In this chaincode invocation we specify peer1.org1.example.com for Org1, and peer0.org2.example.com for Org2.
The chaincode invocation is successful. Now we query the result from all peers.
Through this exercise, we know the steps required to add new peers to a peer organization. It is not complicated once we understand the overall flow. As First Network is no longer in v2.2+, we can use this simple process to set up a multiple-peer environment when needed.