Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 3

June 10, 2021

869

By Matt Zand and Abhik Banerjee

Recap

In our first article in this series, we learned about the below topics:

Azure cloud for Blockchain Applications
Fabric Marketplace Template versus Manual Configurations
Deploy Orderer and Peer Organizations

In our second article in this series, we discussed the following:

Setting Up the Development Environment
Setting Up Configurations for Orderer and Peer
Setting Up Pods and Volume Mounts for Development

In this final article in the series, we will cover the following:

Create A Channel
Adding Peer to Network, Channel and Nodes
Deploying and Operating Chaincode

It should be noted that while this article is intended to be beginner friendly, it would be helpful to have prior familiarity with Azure, Kubernetes APIs, and Azure Kubernetes Service (AKS). Also, a good knowledge of Hyperledger Fabric and its components is required to follow steps discussed in this article. The topics and steps covered in this article are very useful for those interested in doing blockchain consulting and development.

7- Create A Channel

Once the development pods are up and running, we can create a channel and then add in the clusters in consecutive steps.

To create a channel you need to bring it up with one ordering service. Here that would be our OrdererOrg cluster. So to create a channel we need to first start from the Orderer cluster’s development pod. Assuming you are inside the said pod, you can easily create a channel by running:

configtxgen -profile SampleChannel -outputCreateChannelTx ./channel.tx -channelID ch01 -configPath ./

The configtxgen tool is provided by default in the Hyperledger Fabric binaries and since the pod is based on the image which has HF already installed and the required paths set, this tool will create a new channel with name “ch01”. The SampleChannel profile will be used in this case for specific details.

The channel details will be saved inside the channel.tx transaction file. This, as you may know, is a very important file needed to create the genesis block for this channel. The following step will use this file to bring up the channel with the OrdererOrg as the provider of the ordering service:

Peer channel create -o <URL of your Orderer Cluster> -c <Channel Name/ID> -f ./channel.tx –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

Provide the URL of your Orderer’s AKS cluster for the -o flag and the channel ID (here ch01) in the -c flag. The -f flag will need the path to the channel.tx transaction file. These details are mostly the same no matter which cloud platform you use since these are the APIs provided by HF.

8- Adding the Peer to Network, Channel and Nodes

Channels can be understood as an analogue to Virtual Private Cloud (VPC) in a cloud platform. Generally on any cloud platform you have a default virtual private cloud (the offering name may differ from cloud platform to platform). Next there are subnets inside VPC that provide a layer of segregation between compute resources like VMs. VMs can have multiple vNICs and can be a part of more than one subnet.

When it comes to Hyperledger Fabric, think of Peer Nodes and Orderers as VMs. Channels which facilitate a common chaincode as a subnet. Nodes which are part of more than one channel (like VMs part of different subnets) facilitate cross-channel communication and are known as “Anchor Nodes”. And just like the VPC which contains all the subnets, there is a channel for managing the whole network. This is “testchainid” by default (check the config files of HF for more). To add a new Peer to the network, one simply needs to propose a transaction which would take into account the changes in the system channel configuration on the Orderer node. The transaction would be recorded and the new Peer’s addition would be added onto the ledger. The role of Membership Service Provider (MSP) comes to play here as the MSP of the new Peer is what is recorded.

Peer to the Network

First we start by logging into the development environment we created on Peer cluster. This can be done by making the kubectl point to that and then accessing the dev pod (refer to “Setting Up Pods and Volume Mounts” section ). Next we need to generate a configtx.yaml here. This config.yaml is similar to the configtx.yaml provided through the hosted code and we will only be needing till line 44 of that configtx.yaml which details Org01’s information. Once a new configtx.yaml has been derived/created, we will generate the Peer organization’s configuration as a JSON file using the configtxgen tool. Next we will need to copy it to the Azure Shell from where we will then copy it to the dev pod on Orderer Cluster. The following commands demonstrate how to do that:

configtxgen -printOrg Org01 -configPath ./ > Org01.json && exit
kubectl cp -n hlf-admin devenv:/var/hyperledger/admin/Org01.json Org01.json
az aks get-credentials –resource-group <Orderer Resource Group> –name <Orderer AKS Cluster Name> –subscription <Subscription ID>
kubectl cp -n hlf-admin Org01.json devenv:/var/hyperledger/admin/Org01.json
kubectl exec -n hlf-admin -it devenv /bin/bash

We generate a JSON of the Peer configuration and then exit to the Azure Shell. From there we copy the config of the Peer (here Org01.json) to the Azure shell. Then we get the kubectl to point at the Orderer Cluster from the Peer Cluster at step 3 and in subsequent steps copy the config to /var/hyperledger/admin in the Orderer Dev Pod. In the next steps we fetch the config of the system channel (channel name is testchainid) in a JSON file of name sys_config_block.json. In the subsequent steps we modify and save the changes onto a new file (called modified_sys_config.json).

Peer channel fetch config sys_config_block.pb -o <Replace with Orderer URL> -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input sys_config_block.pb –type common.Block > sys_config_block.json
jq .data.data[0].payload.data.config sys_config_block.json > original_sys_config.json
jq -s “.[0] * {”channel_group”:{”groups”:{”Consortiums”:{”groups”: {”SampleConsortium”: {”groups”: {”Org01”:.[1]}}}}}}}” original_sys_config.json Org01.json > modified_sys_config.json

What we are doing in the above steps is essentially creating a new file which contains a modification which states that there is a new organization in the network. The “Consortium” property modification reflects that in the modified_sys_config.json. This difference between the original and the new config would be recorded in the ledger of the network. This would provide an irrefutable proof of inclusion for the Peer Organization Org01. This is what we accomplish with the following:

configtxlator proto_encode –input original_sys_config.json –type common.Config > original_sys_config.pb
configtxlator proto_encode –input modified_sys_config.json –type common.Config > modified_sys_config.pb
configtxlator compute_update –channel_id testchainid –original original_sys_config.pb –updated modified_sys_config.pb > differed_sys_config.pb
configtxlator proto_decode –input differed_sys_config.pb –type common.ConfigUpdate > differed_sys_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”testchainid”, “type”:2}},”data”:{“config_update”:’$(cat differed_sys_config.json)’}}}’ > modreqst_sys_config.json
configtxlator proto_encode –input modreqst_sys_config.json –type common.Envelope > modreqst_sys_config.pb

We calculate the difference between the two configurations using the configtxlator tool. This tool is also used to convert the JSONs to Protobufs as this is the preferred medium in HF. The difference is finally reflected as modreqst_sys_config.pb which will be used in the next command to create an update request through the Orderer (which is also technically a Peer).

Peer channel update -f modreqst_sys_config.pb -o <Orderer URL Here> -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

With this, the new Organization (Org01) is now a part of the network, and almost 70% of the work is done. In the next sections we will add Org01 to our channel ch01 and then add the nodes which Org01 owns (here the Peer cluster on AKS) as a trusted component in the network.

Peer to the Channel

If we are going with the VPC analogy, then our new VM (Org01 Peer) has been turned on and included in the VPC but it is yet to be assigned a subnet. Until that point, it is virtually useless. Only after it gets a subnet would it be able to facilitate ingress and egress depending on its permissions.

Just like that we will also need to include the newly inducted Org01 into our channel ch01 that we created in our previous section. This too needs to be done from the Orderer Dev Pod. Instead of editing the config of the system channel (testchannelid) we will edit the config of our channel (ch01) and the difference between the original and the modified will be recorded as a transaction in the ledger. This will denote Org01’s inclusion in the channel. The following steps fetch the original ch01 config and store it in a JSON file for readability.

Peer channel fetch config ch01_config_block.pb -o <Orderer URL here> -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input ch01_config_block.pb –type common.Block > ch01_config_block.json
jq .data.data[0].payload.data.config ch01_config_block.json > original_ch01_config.json
jq -s “.[0] * {”channel_group”:{”groups”:{”Application”:{”groups”: {”Org01”:.[1]}}}}}” original_ch01_config.json Org01.json > modified_ch01_config.json

Once we get the original config, we create a modified config which reflects Org01’s inclusion in the channel ch01 in steps 3 and 4. Just as before, we now need to have the modified configuration be accounted for by calculating the difference between the new and the old config and that too is done in the protobuf format.

configtxlator proto_encode –input original_ch01_config.json –type common.Config > original_ch01_config.pb
configtxlator proto_encode –input modified_ch01_config.json –type common.Config > modified_ch01_config.pb
configtxlator compute_update –channel_id ch01 –original original_ch01_config.pb –updated modified_ch01_config.pb > differed_ch01_config.pb
configtxlator proto_decode –input differed_ch01_config.pb –type common.ConfigUpdate > differed_ch01_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”ch01″, “type”:2}},”data”:{“config_update”:’$(cat differed_ch01_config.json)’}}}’ > modreqst_ch01_config.json
configtxlator proto_encode –input modreqst_ch01_config.json –type common.Envelope > modreqst_ch01_config.pb

The above commands using the configtxlator tool should seem similar. We are literally doing the same thing here with ch01 instead of the testchainid channel. With the next command using the Peer API, the process of including the node into the channel gets completed.

Peer channel update -f modreqst_ch01_config.pb -o <Orderer URL here> -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

The above command creates an update transaction which gets recorded. This update reflects the inclusion of Org01 into the channel ch01. Now all we need to do is include the nodes owned by this Peer organization into the network.

Peer to the Nodes

Previously we copied a file from Peer Dev Pod to Azure Shell and then to Orderer Dev Pod. In this case, we need to do the reverse. We need the Orderer’s TLS certificate located at devenv:/var/hyperledger/admin/msp/tlscacerts/..data/ca.crt on the Orderer Dev Pod at devenv:/var/hyperledger/admin/ca_Orderer.crt on the Peer’s Dev Pod. You may think why would we be needing this. The logic behind this is that we can use the MSP of Org01 which we quite recently enrolled into the channel ch01 but we can only connect to the channel- the node itself is not validated.

The TLS certificate from Orderer will help in that. Assuming the TLS certificate has been copied to the Peer Node, we need to retrieve the configuration of the genesis block from the Orderer. You need to provide this here while connecting to the Orderer node from the Peer with the following command:

Peer channel fetch 0 ch01_config.block -o <Orderer URL Here>-c ch01 –tls –cafile /var/hyperledger/admin/ca_Orderer.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
Peer channel join -b ch01_config.block

And just like that the Node is now a part of the channel. The first line retrieves the channel’s genesis block configuration and stores it in a ch01_config.block file while the second uses this to let the node join the channel. Since the MSP of Org01 is already registered, this Peer node can now transact on the channel.

This concludes the construction of our Demo Network. At this point, the only thing remaining is deploying your required chaincode and invoking it when needed. In the next section we show chaincode management in this demo network.

9- Deploying and Operating Chaincode

Once the network has been built and the nodes have been included in the channel, the process afterward is the same regardless of the cloud platform. While we are at the end of the section, it might be useful if you save the Orderer’s public URL as a ENV variable in this pod. Since this value can vary for every deployment, it is recommended to set it after pod creation.

The task of installing a chaincode has to be done from a Peer first which is supposed to operate the chaincode (here Peer node of Org01). This means you will need to first make the kubectl point to the AKS cluster of the Peer and then access the bash shell of the dev pod of the Peer. Afterward, the process of operating a chaincode is fairly simple. Provided you have set the paths in the env variables, you can use commands like:

Peer chaincode install -p <Path to the Chaincode> -n <Name of the Chaincode> -v <Version of the Chaincode (Generally start of 1.0 for every chaincode)> -l <Language the chaincode is written in>

To install the chaincode on the Peer and then go on with the lifecycle. An interesting point to note here is that most Peer API commands have a global flag of -o which denotes the address of the Orderer. This would be the Orderer that the channel is using. In our case, the value of this flag will be the URL of the OrdererOrg.

Summary

We have now finished part 3, which concludes our article series. At a high level, we learned how to deploy Fabric on Azure cloud platforms. We started out with a discussion on the Blockchain as a Service offerings of Azure and then moved onto demonstrating how easily the Azure Marketplace AKS offering for Fabric can be used to deploy clusters of Peers and Orderers. Further, we did a brief look at using chiancode once you have your network and nodes up and running as well as showing you how to expand the network and introduce more members in the channel after you have the initial setup done.

Resources

Free Training Courses from The Linux Foundation & Hyperledger

Blockchain: Understanding Its Uses and Implications (LFS170)
Introduction to Hyperledger Blockchain Technologies (LFS171)
Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
Becoming a Hyperledger Aries Developer (LFS173)
Hyperledger Sawtooth for Application Developers (LFS174)

eLearning Courses from The Linux Foundation & Hyperledger

Hyperledger Fabric Administration (LFS272)
Hyperledger Fabric for Developers (LFD272)

Certification Exams from The Linux Foundation & Hyperledger

Certified Hyperledger Fabric Administrator (CHFA)
Certified Hyperledger Fabric Developer (CHFD)

Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy
Review of three Hyperledger Tools- Caliper, Cello and Avalon
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact

About the Authors

Matt Zand is a serial entrepreneur and the founder of 4 tech startups: DC Web Makers, Hash Flow, Coding Bootcamps and High School Technology Services. He is a leading author of Hands-on Smart Contract Development with Hyperledger Fabric book by O’Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. At Hash Flow, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master’s degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, investor, business advisor for a few startup companies. You can connect with him on LI: https://www.linkedin.com/in/matt-zand-64047871

Abhik Banerjee is a researcher, an avid reader and also an anime fan. In his free time you can find him reading whitepapers and building hobby projects ranging from DLT to Cloud Infra. He has multiple publications in International Conferences and Book Titles along with a couple of patents in Blockchain. His interests include Blockchain, Quantum Information Processing and Bioinformatics. You can connect with him on LI: https://in.linkedin.com/in/abhik-banerjee-591081164

The post Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 3 appeared first on Linux Foundation – Training.

Recap

7- Create A Channel

8- Adding the Peer to Network, Channel and Nodes

Peer to the Network

Peer to the Channel

Peer to the Nodes

9- Deploying and Operating Chaincode

Summary

Resources

About the Authors

RELATED ARTICLESMORE FROM AUTHOR

Project Tazama, A Project Hosted by LF Charities With Support From the Gates Foundation, Receives Digital Public Good Designation.

Xen 4.19 is released

Advancing Xen on RISC-V: key updates

Linux Foundation Announces OpenSearch Software Foundation to Foster Open Collaboration in Search and Analytics

AI Produces Data-driven OpenFOAM Speedup (HPC Wire)

RELATED ARTICLES MORE FROM AUTHOR