Skip to main content

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

By May 26, 2021June 10th, 2021Announcements

By Matt Zand and Abhik Banerjee

Here is an outline of topics covered in this article series:

  1. Azure cloud for Blockchain Applications
  2. Fabric Marketplace Template versus Manual Configurations
  3. Deploy Orderer and Peer Organizations
  4. Setting Up the Development Environment
  5. Setting Up Configurations for Orderer and Peer
  6. Setting Up Pods and Volume Mounts for Development
  7. Create A Channel
  8. Adding  Peer to Network, Channel and Nodes
  9. Deploying and Operating Chaincode

This series is divided into 3 parts: 

In the first part, we cover item 1, 2, 3 of the outline. In the second part, we will cover items 4, 5 and 6 and in the last part we will cover the remaining items (7, 8 and 9). 

Introduction

By finishing this article series, you will gain and be able to put Hyperledger Fabric skills into practice through creating and deploying Fabric applications on Azure cloud platforms. As such, this article covers highly practical steps for those interested in moving their Fabric application from the pilot step to production. We start off by reviewing the Azure cloud platform and its features, and follow with hands-on steps for building and deploying Fabric applications on Azure. 

While managed blockchain solutions from Azure were limited to an enterprise Ethereum variant called Quorum, Hyperledger Fabric is now also supported. However, at the time of writing, Azure Blockchain Service only offers Quorum in General Availability. Support for Hyperledger Fabric is a part of offering Blockchain-As-A-Service (BAAS) solutions in the Azure platform..

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. If you have no experience with Fabric, The Linux Foundation’s free Introduction to Hyperledger Blockchain Technologies course is a good place to start. The topics and steps covered in this article are very useful for those interested in doing blockchain consulting and development.

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. It manages the deployment of Validator and Transaction Nodes in the network and can be easily used from the Azure Portal itself. 

  • Azure Blockchain Workbench (ABW)

Azure Blockchain Workbench takes the whole “managed” paradigm to another level. It introduces managed identity elements in the network. The participants in the network can have their addresses managed with the Azure Active Directory (AD). ABW also offers easy integration with Azure Services like Cosmos Database for storing off-chain data for analytics. However, like ABS, this too only supports Quorum at this time. Azure Blockchain Workbench is in “public preview” and can be a great way to test out Proof of Concepts quickly.

  • 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. ARM Templates are basically JSON files that contain details of the infrastructure you might want to deploy (say a VM with 3 vCores and 100 GB of SSD storage and CentOS). ARM takes in these templates and then provisions said resources as you want them. In our case, Azure Marketplace is where one can find the ARM Template for deploying Hyperledger Fabric on Azure. Azure Marketplace provides the option to use ARM Template for deploying Hyperledger Fabric Nodes using AKS. Azure makes it easier by allowing the option to deploy from the Azure Portal itself. The deployed nodes exist in an AKS cluster and can be managed from the portal, Azure Shell or command line or even your local PC through kubectl (Kubernetes control CLI). We will be going with the latter solution in this section.

In the following sections we briefly compare the marketplace template with AKS using manual configurations and then dive into a hands-on Hyperledger Fabric network deployment on Azure, while playing around with a custom chaincode on the deployed solution.

2- Fabric Marketplace Template versus Manual Configurations

Azure Marketplace is a great place to find pre-built solutions. In our case, we are looking for a particular solution named “Hyperledger Fabric on Azure Kubernetes Service”. Before we discuss using it, let’s explore why someone may prefer it over manually provisioning their own resources. 

Manual provisioning can be helpful when one cannot find the proper base to build their solution. However, it requires in-depth knowledge of the platform. This is true not only for Azure but for anything. If there is a need for manual configuration, the architect needs to have a thorough understanding of networking, security and compliance on Azure. By this we mean that the person who will configure the network manually needs to know how to put up VMs and link them in a network without making the resources like SSH Keys or storage open to attacks.

For this reason, it is better to follow Murphy’s Law – “if something can go wrong, it will”. If so,  wouldn’t it be better to let aspects of the network be handled by Azure itself? This would also help the blockchain developer/operator improve their use case and focus on the chaincode, Access Control Lists, Fabric network architecture, and peer policies. This also does not close off the path of managing nodes in the network manually as an outside node, regardless of the cloud platform it is running on, can be a participant in the Hyperledger Fabric Network deployed on Azure.

3- Deploy Orderer and Peer Organizations

To begin, open your Azure Portal 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 (K8s) clusters 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. 

Hint

Service principals are complex and important, with many best practices to consider. Since this is outside the scope of this article, we will focus on Fabric on AKS.

Someone who uses Azure regularly might ask “Doesn’t AKS automatically create a service principal  for me?” Normally, it does but this is an exception; you can easily create a service principal if you don’t have one already by running the following command in the Azure CLI:

az ad sp create-for-rbac –skip-assignment –name {Name of the Service Principal}

Once you run this, you will get the output which will give you an App ID and a Password among other things. These are the ones which you will need here.

Now let’s deploy an orderer node using the portal. In the first screen you’ll see the following options:

Subscription 

Select the subscription you would like to use at this time. 

Resource Group 

An Azure Resource Group is a handy way to keep multiple resources in the same “basket” so to speak. These can be categorized based on resource type (say one RG for compute resources like VMs, another for storage) or by solution/use case. In our case, we will create two resource groups–one for Orderer and another for Org01 resources. Click on “Create New” and enter your resource group name (here we go with RG-HLF-AzureOrderer).

Region 

The Azure Region you want to deploy your resources to. Here we go with the default Central US.

Resource Prefix 

This is a collection of at most 6 characters that would be prepended to the resources being provisioned by/for this AKS cluster. We use the prefix “order” here to denote that the resources belong to Orderer Service.

Click on “Next : Fabric settings >” to set your Hyperledger Fabric related information. Here you would be asked to fill the following details:

Organization Name 

This would be the name of the organization trying to join the network. As you may know by now, a Hyperledger Fabric network is always brought up with an Orderer at first. Following suit here we shall name it “OrdererOrg”.

Fabric network component: 

Next you select the type of service. This is a drop-down menu where you get to select from “Ordering Service” and “Peer Node”. We shall select it as “Ordering Service”.

Number of nodes 

If you select the above option as Ordering Service, you need to choose between having 3, 5, or 7 nodes. Since this is a demo, we are going with 3. (You may be wondering why the choices are like this; this is to get the number of ordering nodes in a number conformable with the Consensus Protocol).

Fabric CA username 

Certifying Authority is one of the central parts of the network. Without a CA, you cannot enroll new members or sign transactions which would be considered from a valid identity. Here we select the username as “ordca01”.

Fabric CA password 

Now you need to select a secure password to go with your CA username. Confirm this in the next option.

Certificates 

You get a choice of selecting between self-signed certificates which would be managed automatically or to upload your own custom ones to act for the Fabric Certifying Authority. Here we choose the managed option – “Fabric CA self-signed certificates”.

After deciding on your HF network specific parameters for Ordering Service, you need to select the settings for the AKS Cluster to which it will be deployed. We leave most of the options at this screen as defaults. The ones which might require attention are Node Size (the type of Azure VMs to use in your cluster), Node Count and the service principal related fields Service principal client ID, Service principal client secret, and Azure Monitor

Keep in mind the following:

  • The Node type you select at this stage will directly impact the cost of sustaining your HF Network.
  • Do not change the Node Count here. It has to be selected in the previous screen and it plays an important part in the consensus.
  • If you already have a service principal, you may use it to deploy this cluster. Otherwise refer to the beginning of this section on how to create one. Put in the service principal’s app ID and password in the respective fields.
  • You may choose to enable cluster wide monitoring with Azure Monitor (in fact it’s recommended that you do). This will help you analyze metrics like transaction count and rate of memory growth.

Deploy your Orderer Service Cluster on AKS. It should take about 10-15 minutes for the cluster to deploy. Meanwhile we can complete another important step – create a cluster for our organization which would be a part of this network. Most of the steps in this case would be the same as above. We will be starting again from the “Hyperledger Fabric on Azure Kubernetes Service” template in Azure Marketplace and then going over the same steps. The values which may differ in this case are listed in the below table. 

Field Value
Resource Group RG-HLF-AzureOrg (creating another new RG for peer)
Resource prefix org01 (for identifying all resources belonging to peer Org01)
Organization Name Org01
Fabric network component Peer nodes
Number of nodes 1 (can vary depending on your budget)
Peer node world state database CouchDB
Fabric CA username orgca01

Here we get an option to select between CouchDB and LevelDB. These two are natively offered from Hyperledger Fabric at this time. We go with CouchDB. Feel free to read up on the difference between the two if you are interested.

Now we have our clusters for Ordering Service and a sample organization Org01 in deployments and these will be up and running in a few moments. We have covered some ground, so let’s reflect on our future course of action – we have clusters for Orderers and Organization and now we need to create a network out of these two. We also need to create a channel where OrdererOrg will function as the ordering service and we need Org01 to join first and then record the nodes owned by it (basically the nodes in that cluster). While doing all this, we also need to set up a development environment which would provide common ground to develop from within the respective clusters as well as from outside clusters. We will do all these in the next article in the series.

Summary

We finished the first part of our article series where we discussed the Azure cloud platform offering for blockchain development as well as differences between Azure marketplace template and manual configuration. We also take our first step toward building Hyperledger Fabric blockchain applications on Azure by deploying Orderer and peer Organization. 

In our next article in this series, we will cover how to set up the development environment, configure the Orderer and peer, and set pods and volume mounts for our Fabric application. 

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

Thank you for your interest in Linux Foundation training and certification. We think we can better serve you from our China Training site. To access this site please click below.

感谢您对Linux Foundation培训的关注。为了更好地为您服务,我们将您重定向到中国培训网站。 我们期待帮助您实现在中国区内所有类型的开源培训目标。