Deploying Hyperledger Fabric on Kubernetes

Hyperledger Fabric is an open source blockchain framework implementation and one of the Hyperledger projects hosted by The Linux Foundation. It is a platform for distributed ledger solutions.

This article aims to simplify Fabric operations by use of Kubernetes. This tool is ideal for the following reasons:

• It's easy to achieve high availability (HA) with Kubernetes.
• Fabric is built into container images, and Kubernetes is useful in orchestration, scaling, and managing containers.
• Kubernetes supports multi-tenancy, making it possible to develop and test blockchain applications.

Note: In this article, I assume the reader has a basic understanding of Kubernetes, Helm, Docker, and Hyperledger Fabric.

I'm going to deploy a network with one peer, one orderer, two organizations, and one channel.

Hyperledger Fabric use cases

1. Business-to-business (B2B) contract: This technology can be used to automate business contracts in a trusted way.

2. Asset depository: Assets can be dematerialized on a blockchain network, making it possible for all for all stakeholders of an asset type to have access to each asset without going through intermediaries or middlemen. Currently, assets are tracked in many ledgers, which must reconcile. Hyperledger Fabric replaces these multiple ledgers with a single decentralized ledger, providing transparency and removing intermediaries.

3. Loyalty: A loyalty rewards platform can be securely built on top of blockchain (for this case, Hyperledger Fabric) and smart contracts technology.

4. Distributed storage to increase trust between parties.

Advantages of Hyperledger Fabric

• Permissioned membership: all participants have known identities
• High performance and scalability
• Increased level of trust
• Data is always on a need-to-know basis
• Supports rich queries over an immutable ledger

Definition of terms

1. Peer: A peer is a node on the network maintaining the state of the ledger and managing chaincodes. Any number of peers may participate in a network. A peer can be an endorser or committer. Peers form a peer-to-peer gossip network.

2. Orderer: Manages a pluggable trust engine that performs the ordering of transactions.

3. Channel: A data-partitioning mechanism that limits transaction visibility only to stakeholders. Consensus takes place within a channel by members of the channel.

Configuration files

All the configuration files of the network can be found on GitHub.

1. configtx.yaml: The configtxgen tool generates a genesis block (a configuration block that initializes a blockchain network or a channel), according to this file, which is used to boot up orderer and restrict permission of channel creation. The genesis block is generated according to the definition of organizations in the crypto-config.yaml file.

2. crypto-config.yaml: The cryptogen tool generates certificates for Fabric members based on this file.

To generate the network artifacts, run network-artifacts-gen.sh. This will create a crypto-config and channel-artifacts folders. The contents will appear as shown below:

1. fabric-ca.yaml: This is the Kubernetes deployment template for the CA service of Fabric. It is used for certificate management in the organization.

2. fabric-orderer.yaml: Kubernetes deployment template of the orderer.

3. fabric-peer.yaml: Deployment template of peers

Deployment

1. Clone or fork the example configuration.

2. Change the directory into the HLF folder.

3. Install Composer (if you haven’t already) because we’re going to use it to import identities during the generation of network artifacts in step 4: npm install -g composer@0.13.0

4. If you want to generate new network artifacts, run the network-artifacts-gen.sh file: sh network-artifacts-gen.sh

5. If you regenerated the network artifacts, commit everything and push to a GitHub repository. You need to have cloned the repository, as stated in step 1.

6. Modify the org1.example.com.yaml file to match your repository details for this task.

7. Remember to go through the templates files and modify accordingly.

8. I’ll use Helm, which is a package manager for Kubernetes, to manage the deployment. Mac users can install this via brew install kubernetes-helm. Linux users: curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

9. Start a local Kubernetes environment by running this command: minikube start

10. Next, initialize Helm by using the command helm init. Give it ten seconds to finish up provisioning Helm. Then run:

    helm install --name test ./fabric-artifacts -f org1.example.com.yaml

    This deploys the orderer, peer, and CA.

    Confirm the deployment by listing the pods: kubectl get po

Or just start the Kubernetes dashboard: kubectl proxy, then visit the link http://localhost:8001/api/v1/namespaces/kube-system/services/http:kuber….

Now let's create and join the channel. Run channel.sh (i.e., sh channel.sh). This creates a channel called mychannel and joins our peer to the created channel. Check the logs to confirm that everything is okay.

Orderer logs

Peer logs

CA logs

The network is now ready for an application to process transactions. In your application, you will have a client, which will make requests to Fabric via a Fabric rest server. This means there should be a network configuration between the client in your application and Fabric. Applications could be mobile apps, web apps, etc. In this article, I just wanted to show how simple it is to use Kubernetes and Hyperledger Fabric.