Deploying a Hyperledger Fabric template on Azure Kubernetes Service (AKS)
As reflected in the recent blog published by Swapnil Galgali, we’re planning to show how to integrate SAP business processes and applications to open-source Blockchain Technology hosted on Azure Cloud Platform.
This blog will describe a step-by-step approach to deploy a Hyperledger Fabric blockchain network based on an Azure Kubernetes Service template. It will add a few additional details to the official Azure deployment guide. Please refer to it to find out more information about the architecture and components of the template.
As a prerequisite you need to have an Azure Subscription. Please follow this link to create a free Microsoft Azure account.
Let’s go ahead and instantiate the templates. We are going to create two AKS clusters. One for orderers organisation and another for peers organisation.
Deploying an ordering service cluster
You should start by searching for ‘Hyperledger Fabric on Azure Kubernetes Service’ on the Azure Portal and creating a new instance:
- Subscription: Azure subscription that you will use to deploy the template. It groups and bills resources together;
- Resource group: A collection of resources with shared lifecycle that groups all the created instances together;
- Region: An Azure region, which is suitable for your customers to reach the resources. Beware that not every region contains every resource though;
- Resource prefix: Prefix for all the created resources.
Tip: This configuration process will require a lot of scripting. Which in turn requires you to know all the unique instance names that you’ve previously created. So it would be a good idea for you to save all the important identifiers into a text editor of your choice. E.g.:
Resource Group: RG_HL_Blog_O
Resource prefix: hlfblg
- Organization name: The name of the Hyperledger Fabric network organisation;
- Fabric network component: At this point we’re deploying the ordering cluster. We’re going to deploy a ‘Peer nodes’ template below as well;
- Number of nodes: Choose 3 at this point in order to save your budgets;
- Fabric CA username: Enter the username that will be used for the Fabric CA authentication;
- Fabric CA password: Enter the password and confirm it in the next input field;
- Certificates: Keep the default ‘self-signed’ option. You’ve got an option to provide your own self-signed root certificates.
- Kubernetes cluster name: You can leave the default prepopulated value based on the resource prefix input or enter your own value;
- Kubernetes version: Here the blank value meaning that the latest version available in the region will be used for deployment;
- DNS prefix: Again, the default value can be left as is. The Domain Name System prefix for AKS cluster is used at a later stage for managing containers via Kubernetes API;
- Node size: The default VM sizing with two vcpus can stay. However, I’ve chosen the minimum available power of VMs for this trial case;
- Networking configuration: Leave the basic options unless you’re aiming to manually manage the parameters of your subnets and hosts inside of the cluster’s virtual network.
- Service principal client ID: Enter the client ID of an existing service principal instance or create a new one according to the instruction. This step requires you to be an owner of the Azure subscription or seek for owner’s approval;
- Service principal client secret: Client secret of the service principal instance;
- Enable container monitoring: Having this option enabled would consume a lot of storage space used by logs and, hence, would also increase the overall cost for the running instances. I’d recommend you disable container monitoring unless you build mission critical systems.
Deploying a peer service cluster
- Number of nodes: If you’re only building a demo system, I’d recommend you choose 1 node to be created;
- Peer node world state database: Choose the LevelDB to be used.
Once all the validations passed, you can go ahead and create the cluster:
Congratulations! Deployment is done for both the Orderer and the Peer clusters.
This blog only contains the necessary preparations for the far more exciting topics. In the next blog we are going to configure a Hyperledger Fabric consortium in order to integrate it with SAP Business Technology Platform solutions.