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

By Matt Zand and Abhik Banerjee

Recap

The first part of our article series discussed the Azure cloud platform offering for blockchain development, as well as differences between Azure marketplace template and manual configuration. We also took our first step toward building Hyperledger Fabric blockchain applications on Azure by deploying Orderer and Peer organizations. We continue our journey by covering how to set up the development environment, configure Orderer and Peer, and setting pods and volume mounts for our Fabric application in this article.

In this next article, we 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.

4- Setting Up the Development Environment

In this section we will see how a development environment can be set up for Node related activities. We will be using Azure Shell (Bash) for this task. Before we install Hyperledger Fabric, we need to make sure that it has the prerequisites in place. This includes the programming language of the chaincode, Docker, and JQ. Azure Shell should have Docker installed already so we can just install Go (our preferred language here) and JQ. Be sure to set the GOPATH, PATH and GOROOT env variables otherwise Go won’t function properly. Follow the commands below if you are unsure.

wget https://dl.google.com/go/go1.12.17.linux-amd64.tar.gz -O /tmp/go1.12.17.linux-amd64.tar.gz
tar -C /usr/local -xzf /tmp/go1.12.17.linux-amd64.tar.gz
export PATH=/usr/local/go/bin:$PATH
export GOROOT=/usr/local/go
export GOPATH=$PWD

The first two commands will install Go in /usr/local directory and the path to it will be set in the third. GOROOT and GOPATH are essential to compile Go Programs and set in consecutive lines. While on a local PC you might put it in ~/.bashrc file, Azure Shell provides ephemeral storage so it will be gone after some time. There’s a way to make this permanent by using Docker containers as we will see in this section. In the next steps we install Hyperledger Fabric by downloading the Hyperledger binaries from its GitHub Repo and place it in /usr/local.

mkdir /usr/local/hyperledger
cd /usr/local/hyperledger
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | sudo bash -s — 1.4.4 1.4.4 0.4.18 -d -s
export PATH=/usr/local/hyperledger/bin:$PATH

As a last step we set the PATH env variable to point also to the /usr/local/hyperledger directory so we can easily invoke commands without always setting a path to the binary of that command. Before we proceed, it might be wise to create a Docker image. This would be really helpful for developing without always having to start from ground zero when you are developing inside the Orderer and Peer Clusters (you might want to refer to 5.1 and 5.2 to understand why we are also including extra files for config of Orderer and Peer organization). We encourage you to create a Dockerfile and then an image. You can publish this image to dockerhub (or Azure Container Registry if you are an expert in Azure) and use it in our upcoming sections.

5- Setting Up Configurations for Orderer and Peer

In this section we will be setting up the configuration for development on the cluster pods. You might think at this point “why would we require development on the pods when we already have deployed the cluster with required information?” The thing is these clusters of Orderers and Peer Organization are not connected as we mentioned in the previous section. Furthermore, we may require to deploy specific chaincode on Peer as we will see in the upcoming sections on chaincode management. For these reasons, it is helpful to have a dev env inside the cluster.

Orderer Setup

Next step to take at this point is to have our custom setup for Orderer. This setup has been derived from the sample setup available from the Hyperledger Fabric Test Network. It helps us to avoid writing out a YAML config for the Orderer from scratch. It will also be helpful for our development environment. It may be noted here that the configuration that we are going to use here serves our purpose for a demo. If you want a production environment, please use a different and more refined configuration as per your needs. The Orderer Config file used for this deployment has been provided in the code section associated with the book filename Orderer.yaml at the hosted link.

Peer Setup

To set up the Peer, the core.yaml file provided with the book’s hosted code can be used. The configuration file contains the configuration needed to make sure the Orderer can locate and communicate with the node cluster associated with Org01. You may notice that this YAML file contains sections for Peer, Chaincode, and Ledger among other sections. These are used for defining properties of the Peer, chaincode and the type of database that will be used as the ledger respectively. At the time of writing the third section supports “goleveldb” and “CouchDB” options.

You can copy the configtx.yaml, Orderer.yaml and core.yaml files to the Azure Shell by uploading them to the directory of your choice in the shell. This will be a step you might want to remember since this location will be used in the next section.

Creating a Docker Image for Dev Pods

Before we proceed further, it would be beneficial to create a Docker image out of the instructions we have executed thus far. This Docker image could be used to spin up pods which would provide an easy development environment with Hyperledger Fabric Binaries already included. As we will see in the next section, we shall use this image as the base image for volume mount related configs.

The Dockerfile provided with the hosted code section will help you create an image. The image will be based on Ubuntu 18.04 since that is the latest version HF supports at this time. Up to line number 22, the steps should seem familiar as we install Go, JQ, Hyperledger Fabric (from the repo) and set the respective paths. At lines 24 and 25, we copy our custom config and then in the last line we set the value of env variable FABRIC_CFG_PATH to /etc/hyperledger/fabric (the directory we copy the files to). Publish this image to Dockerhub.

6- Setting Up Pods and Volume Mounts for Development

Before we go and create a channel and make the Orderer and Peer organization join up, we need to finish up one final detail – creating proper volume mounts for our development pods. In the previous steps we have created a base image which the pods will be made from. Now to let the pods actually communicate with the cluster we need it to access the secret volumes which store the security keys in the respective clusters. This can be easily done by introducing a YAML file for each of the cluster types.

The table below tells of the secret mounting volumes we need the pods to know of and use. It may be noted here that these volumes would be separate for Peer and Orderer clusters and so will contain different values and are automatically created when the clusters were created on AKS. However, we only need to have these mounted onto the pod.

Secret	Mount
hlf-admin-idcert	/var/hyperledger/admin/msp/admincerts /var/hyperledger/admin/msp/signcerts
hlf-ca-idcert	/var/hyperledger/admin/msp/cacerts
hlf-admin-idkey	/var/hyperledger/admin/msp/keystore
hlf-tlsca-idcert	/var/hyperledger/admin/msp/tlscacerts
hlf-admin-tls-idkey	/var/hyperledger/admin/tls
hlf-admin-tls-idcert	/var/hyperledger/admin/tls

You may use the dev_pod.yaml for this purpose. Please note that this YAML file is mostly the same for Orderer and Peer pods in respective clusters. It sets the volume mounts and environment variables required by the pod for proper development. The YAML sets required env variables for adding new nodes into a channel among others.

The file also needs some modification at your end. The lines 33 and 76 through 79 have been commented out. The former is where you need to place the name of your image that you built in the previous section while the latter section contains pod type specific details like name of the organization and the URL of the cluster.

The pods can be created by the following steps:

1. az aks get-credentials –resource-group <Resource Group Name> –name <Cluster Name> –subscription <Azure Subscription ID>

kubectl -n hlf-admin apply -f ./dev_pod.yaml

The first command when executed in the Azure Shell tells the kubectl to point towards the cluster specified by it. In the next step we provide the YAML in the hlf-admin namespace in that cluster. The first command would contain Orderer and Peer specific values for Resource Group and Cluster names (here these are RG-HLF-AzureOrd & RG-HLF-AzureOrg for resource groups and OrdererOrg and Org01 respectively). Once the pods are provisioned, you can access them by:

kubectl exec -n hlf-admin -it devenv /bin/bash

This will give you the bash shell inside the development pod of the cluster to which kubectl is currently pointing to.

Summary

We finished the second part of our article series where we covered how to set up the development environment, configure the Orderer and Peer, and setting pods and volume mounts for our Fabric application.

In our next and final article in this series, we will build on top of what we finished in this article. Specifically, we will create a channel, add a Peer to network, channel and nodes. At the last and final step, we will show you how to deploy and operate Fabric chaincode on Azure.

Resources

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