By finishing this article, you would be able to put your Fabric skills into practice through creating and deploying Fabric applications on the Azure cloud platforms. As such, this article covers highly practical steps for those interested in moving their Fabric application from the pilot step to the production. In short, we start off by reviewing the Azure cloud platform and its features, and following by hands-on steps for building and deploying Fabric applications on Azure.
While the managed blockchain solutions offerings from Azure were limited to an enterprise Ethereum variant called Quorum, Hyperledger Fabric is now supported. However, at the time of writing, Azure Blockchain Service offers only Quorum in General Availability. The support for Hyperledger Fabric is in private preview with plans to increase their ground for the whole Blockchain-As-A-Service (BAAS) paradigm.
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.
Here is an outline of topics covered in this article:
- Azure cloud for Blockchain Applications
- Deploy Orderer and Peer Organizations
- Setting Up the Development Environment
- Setting Up Configurations for Orderer and Peer
- Setting Up Pods and Volume Mounts for Development
- Create A Channel
- Adding Peer to Network, Channel and Nodes
- Deploying and Operating Chaincode
1- Azure cloud for Blockchain Applications
Before we dive head first into building a blockchain network on Azure, it would be beneficial to look at the three main blockchain options provided by Microsoft Azure. These are:
- Azure Blockchain Service (ABS)
Azure Blockchain Service is a managed service from Microsoft Azure that aims to help organizations get started quickly with their blockchain solutions.
- Azure Blockchain Workbench (ABW)
Azure Blockchain Workbench takes the whole “managed” paradigm to another level. It introduces managed identity elements in the network.
- Azure Resource Manager Templates (ARM templates)
Azure Resource Manager (ARM) can be thought of as a creator and a shepherd for your Microsoft Azure Resources. It is as simple as handing a JSON object to ARM.
2- Deploy Orderer and Peer Organizations
To begin, open your Azure Portal (go to portal.azure.com) and then click on “Create a Resource” (the big + sign) which will take you to Azure Marketplace. From the list on the left find the option titled “Blockchain”. Once you click on it, you will see options like ‘Azure Blockchain Service’, ‘Azure Blockchain Workbench’, ‘Ethereum Studio’ and more. Click on “Hyperledger Fabric on Azure Kubernetes Service”.
At this point you might want to have a pre-created Azure Service Principal. Service Principals are needed for deploying Kubernetes Cluster on Azure. The logic behind this is – you cannot do anything in Azure without Permissions! But instead of attaching permissions to your person, you have service principals. The permissions to create a K8s node in Azure, for example, gets attached to this service principal along with any other required permissions. Every time you want to deploy an AKS cluster you get to use this service principal.
3- 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 already. 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.
4- 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 to develop on the pods when we already have deployed the cluster with required information?” but 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 would see in the upcoming sections on chaincode management. For these reasons, it is helpful to have a dev env inside the cluster.
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 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 of 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.
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 just 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 this 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.
5- 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 on 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.
6- 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.
7- 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.
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 will need to copy it to the Azure Shell from where we will then copy it to the dev pod on Orderer Cluster. We generate a JSON of the peer configuration and then exit to the Azure Shell.
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.
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.
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.
8- 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.
In this article 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.
This article is written by Matt Zand in collaboration with Abhik Banerjee.