Tag Archives: Fabric

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


By Matt Zand and Abhik Banerjee

Recap

In our first article in this series, we learned about the below topics:

Azure cloud for Blockchain Applications
Fabric Marketplace Template versus Manual Configurations
Deploy Orderer and Peer Organizations

In our second article in this series, we discussed the following:

Setting Up the Development Environment
Setting Up Configurations for Orderer and Peer
Setting Up Pods and Volume Mounts for Development

In this final article in the series, we will 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

7- 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.

To create a channel you need to bring it up with one ordering service. Here that would be our OrdererOrg cluster. So to create a channel we need to first start from the Orderer cluster’s development pod. Assuming you are inside the said pod, you can easily create a channel by running:

configtxgen -profile SampleChannel  -outputCreateChannelTx ./channel.tx -channelID ch01 -configPath ./

The configtxgen tool is provided by default in the Hyperledger Fabric binaries and since the pod is based on the image which has HF already installed and the required paths set, this tool will create a new channel with name “ch01”. The SampleChannel profile will be used in this case for specific details.

The channel details will be saved inside the channel.tx transaction file. This, as you may know, is a very important file needed to create the genesis block for this channel. The following step will use this file to bring up the channel with the OrdererOrg as the provider of the ordering service:

Peer channel create -o <URL of your Orderer Cluster> -c <Channel Name/ID> -f ./channel.tx –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

Provide the URL of your Orderer’s AKS cluster for the -o flag and the channel ID (here ch01) in the -c flag. The -f flag will need the path to the channel.tx transaction file. These details are mostly the same no matter which cloud platform you use since these are the APIs provided by HF.

8- 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.

When it comes to Hyperledger Fabric, think of Peer Nodes and Orderers as VMs. Channels which facilitate a common chaincode as a subnet. Nodes which are part of more than one channel (like VMs part of different subnets) facilitate cross-channel communication and are known as “Anchor Nodes”. And just like the VPC which contains all the subnets, there is a channel for managing the whole network. This is “testchainid” by default (check the config files of HF for more). To add a new Peer to the network, one simply needs to propose a transaction which would take into account the changes in the system channel configuration on the Orderer node. The transaction would be recorded and the new Peer’s addition would be added onto the ledger. The role of Membership Service Provider (MSP) comes to play here as the MSP of the new Peer is what is recorded.

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 need to generate a configtx.yaml here. This config.yaml is similar to the configtx.yaml provided through the hosted code and we will only be needing till line 44 of that configtx.yaml which details Org01’s information. Once a new configtx.yaml has been derived/created, we will generate the Peer organization’s configuration as a JSON file using the configtxgen tool. 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. The following commands demonstrate how to do that:

configtxgen -printOrg Org01 -configPath ./ > Org01.json && exit
kubectl cp -n hlf-admin devenv:/var/hyperledger/admin/Org01.json Org01.json
az aks get-credentials –resource-group <Orderer Resource Group> –name <Orderer AKS Cluster Name> –subscription <Subscription ID>
kubectl cp -n hlf-admin Org01.json devenv:/var/hyperledger/admin/Org01.json
kubectl exec -n hlf-admin -it devenv /bin/bash

We generate a JSON of the Peer configuration and then exit to the Azure Shell. From there we copy the config of the Peer (here Org01.json) to the Azure shell. Then we get the kubectl to point at the Orderer Cluster from the Peer Cluster at step 3 and in subsequent steps copy the config to /var/hyperledger/admin in the Orderer Dev Pod. In the next steps we fetch the config of the system channel (channel name is testchainid) in a JSON file of name sys_config_block.json. In the subsequent steps we modify and save the changes onto a new file (called modified_sys_config.json).

Peer channel fetch config sys_config_block.pb -o <Replace with Orderer URL> -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input sys_config_block.pb –type common.Block > sys_config_block.json
jq .data.data[0].payload.data.config sys_config_block.json > original_sys_config.json
jq -s “.[0] * {”channel_group”:{”groups”:{”Consortiums”:{”groups”: {”SampleConsortium”: {”groups”: {”Org01”:.[1]}}}}}}}” original_sys_config.json Org01.json > modified_sys_config.json

What we are doing in the above steps is essentially creating a new file which contains a modification which states that there is a new organization in the network. The “Consortium” property modification reflects that in the modified_sys_config.json. This difference between the original and the new config would be recorded in the ledger of the network. This would provide an irrefutable proof of inclusion for the Peer Organization Org01. This is what we accomplish with the following:

configtxlator proto_encode –input original_sys_config.json –type common.Config > original_sys_config.pb
configtxlator proto_encode –input modified_sys_config.json –type common.Config > modified_sys_config.pb
configtxlator compute_update –channel_id testchainid –original original_sys_config.pb  –updated modified_sys_config.pb > differed_sys_config.pb
configtxlator proto_decode –input differed_sys_config.pb –type common.ConfigUpdate > differed_sys_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”testchainid”, “type”:2}},”data”:{“config_update”:’$(cat differed_sys_config.json)’}}}’ > modreqst_sys_config.json
configtxlator proto_encode –input modreqst_sys_config.json –type common.Envelope > modreqst_sys_config.pb

We calculate the difference between the two configurations using the configtxlator tool. This tool is also used to convert the JSONs to Protobufs as this is the preferred medium in HF. The difference is finally reflected as modreqst_sys_config.pb which will be used in the next command to create an update request through the Orderer (which is also technically a Peer).

Peer channel update -f modreqst_sys_config.pb -o <Orderer URL Here> -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

With this, the new Organization (Org01) is now a part of the network, and almost 70% of the work is done. In the next sections we will add Org01 to our channel ch01 and then add the nodes which Org01 owns (here the Peer cluster on AKS) as a trusted component in the network.

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. Instead of editing the config of the system channel (testchannelid) we will edit the config of our channel (ch01) and the difference between the original and the modified will be recorded as a transaction in the ledger. This will denote Org01’s inclusion in the channel. The following steps fetch the original ch01 config and store it in a JSON file for readability.

Peer channel fetch config ch01_config_block.pb -o <Orderer URL here> -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input ch01_config_block.pb –type common.Block > ch01_config_block.json
jq .data.data[0].payload.data.config ch01_config_block.json > original_ch01_config.json
jq -s “.[0] * {”channel_group”:{”groups”:{”Application”:{”groups”: {”Org01”:.[1]}}}}}” original_ch01_config.json Org01.json > modified_ch01_config.json

Once we get the original config, we create a modified config which reflects Org01’s inclusion in the channel ch01 in steps 3 and 4. Just as before, we now need to have the modified configuration be accounted for by calculating the difference between the new and the old config and that too is done in the protobuf format.

configtxlator proto_encode –input original_ch01_config.json –type common.Config > original_ch01_config.pb
configtxlator proto_encode –input modified_ch01_config.json –type common.Config > modified_ch01_config.pb
configtxlator compute_update –channel_id ch01 –original original_ch01_config.pb –updated modified_ch01_config.pb > differed_ch01_config.pb
configtxlator proto_decode –input differed_ch01_config.pb –type common.ConfigUpdate > differed_ch01_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”ch01″, “type”:2}},”data”:{“config_update”:’$(cat differed_ch01_config.json)’}}}’ > modreqst_ch01_config.json
configtxlator proto_encode –input modreqst_ch01_config.json –type common.Envelope > modreqst_ch01_config.pb

The above commands using the configtxlator tool should seem similar. We are literally doing the same thing here with ch01 instead of the testchainid channel. With the next command using the Peer API, the process of including the node into the channel gets completed.

Peer channel update -f modreqst_ch01_config.pb -o <Orderer URL here> -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

The above command creates an update transaction which gets recorded. This update reflects the inclusion of Org01 into the channel ch01. Now all we need to do is include the nodes owned by this Peer organization into the network.

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. We need the Orderer’s TLS certificate located at devenv:/var/hyperledger/admin/msp/tlscacerts/..data/ca.crt on the Orderer Dev Pod at devenv:/var/hyperledger/admin/ca_Orderer.crt on the Peer’s Dev Pod. You may think why would we be needing this. The logic behind this is that we can use the MSP of Org01 which we quite recently enrolled into the channel ch01 but we can only connect to the channel- the node itself is not validated.

The TLS certificate from Orderer will help in that. Assuming the TLS certificate has been copied to the Peer Node, we need to retrieve the configuration of the genesis block from the Orderer. You need to provide this here while connecting to the Orderer node from the Peer with the following command:

Peer channel fetch 0 ch01_config.block -o <Orderer URL Here>-c ch01 –tls –cafile /var/hyperledger/admin/ca_Orderer.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem  –keyfile /var/hyperledger/admin/tls/key.pem
Peer channel join -b ch01_config.block

And just like that the Node is now a part of the channel. The first line retrieves the channel’s genesis block configuration and stores it in a ch01_config.block file while the second uses this to let the node join the channel. Since the MSP of Org01 is already registered, this Peer node can now transact on the channel.

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. 

9- 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. Provided you have set the paths in the env variables, you can use commands like:

Peer chaincode install -p <Path to the Chaincode> -n <Name of the Chaincode> -v <Version of the Chaincode (Generally start of 1.0 for every chaincode)> -l <Language the chaincode is written in> 

To install the chaincode on the Peer and then go on with the lifecycle. An interesting point to note here is that most Peer API commands have a global flag of -o which denotes the address of the Orderer. This would be the Orderer that the channel is using. In our case, the value of this flag will be the URL of the OrdererOrg.

Summary

We have now finished part 3, which concludes our article series.  At a high level, 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. 

Resources

Free Training Courses from The Linux Foundation & Hyperledger

Blockchain: Understanding Its Uses and Implications (LFS170)
Introduction to Hyperledger Blockchain Technologies (LFS171)
Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
Becoming a Hyperledger Aries Developer (LFS173)
Hyperledger Sawtooth for Application Developers (LFS174)

eLearning Courses from The Linux Foundation & Hyperledger

Hyperledger Fabric Administration (LFS272)
Hyperledger Fabric for Developers (LFD272)

Certification Exams from The Linux Foundation & Hyperledger

Certified Hyperledger Fabric Administrator (CHFA)
Certified Hyperledger Fabric Developer (CHFD)

Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy
Review of three Hyperledger Tools- Caliper, Cello and Avalon
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact

Hands-On Smart Contract Development with Hyperledger Fabric V2 Book by Matt Zand and others.
Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
Intro to Blockchain Cybersecurity (Coding Bootcamps)
Intro to Hyperledger Sawtooth for System Admins (Coding Bootcamps)
Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
Intro blockchain development with Hyperledger Fabric (Coding Bootcamps)
How to build DApps with Hyperledger Fabric
Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level
Blockchain Management in Hyperledger for System Admins
Hyperledger Fabric for Developers (Coding Bootcamps)
Free White Papers from Hyperledger
Free Webinars from Hyperledger
Hyperledger Wiki

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

The post Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 3 appeared first on Linux Foundation – Training.

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:

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

Free Training Courses from The Linux Foundation & Hyperledger

Blockchain: Understanding Its Uses and Implications (LFS170)
Introduction to Hyperledger Blockchain Technologies (LFS171)
Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
Becoming a Hyperledger Aries Developer (LFS173)
Hyperledger Sawtooth for Application Developers (LFS174)

eLearning Courses from The Linux Foundation & Hyperledger

Hyperledger Fabric Administration (LFS272)
Hyperledger Fabric for Developers (LFD272)

Certification Exams from The Linux Foundation & Hyperledger

Certified Hyperledger Fabric Administrator (CHFA)
Certified Hyperledger Fabric Developer (CHFD)

Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy
Review of three Hyperledger Tools- Caliper, Cello and Avalon
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact
Hands-On Smart Contract Development with Hyperledger Fabric V2 Book by Matt Zand and others.
Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
Intro to Blockchain Cybersecurity (Coding Bootcamps)
Intro to Hyperledger Sawtooth for System Admins (Coding Bootcamps)
Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
Intro blockchain development with Hyperledger Fabric (Coding Bootcamps)
How to build DApps with Hyperledger Fabric
Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level
Blockchain Management in Hyperledger for System Admins
Hyperledger Fabric for Developers (Coding Bootcamps)
Free White Papers from Hyperledger
Free Webinars from Hyperledger
Hyperledger Wiki

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

The post Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 2 appeared first on Linux Foundation – Training.

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


By Matt Zand and Abhik Banerjee

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

Azure cloud for Blockchain Applications
Fabric Marketplace Template versus Manual Configurations
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

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

Free Training Courses from The Linux Foundation & Hyperledger

Blockchain: Understanding Its Uses and Implications (LFS170)
Introduction to Hyperledger Blockchain Technologies (LFS171)
Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
Becoming a Hyperledger Aries Developer (LFS173)
Hyperledger Sawtooth for Application Developers (LFS174)

eLearning Courses from The Linux Foundation & Hyperledger

Hyperledger Fabric Administration (LFS272)
Hyperledger Fabric for Developers (LFD272)

Certification Exams from The Linux Foundation & Hyperledger

Certified Hyperledger Fabric Administrator (CHFA)
Certified Hyperledger Fabric Developer (CHFD)

Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy
Review of three Hyperledger Tools- Caliper, Cello and Avalon
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact

Hands-On Smart Contract Development with Hyperledger Fabric V2 Book by Matt Zand and others.
Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
Intro to Blockchain Cybersecurity (Coding Bootcamps)
Intro to Hyperledger Sawtooth for System Admins (Coding Bootcamps)
Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
Intro blockchain development with Hyperledger Fabric (Coding Bootcamps)
How to build DApps with Hyperledger Fabric
Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level
Blockchain Management in Hyperledger for System Admins
Hyperledger Fabric for Developers (Coding Bootcamps)
Free White Papers from Hyperledger
Free Webinars from Hyperledger
Hyperledger Wiki

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

The post Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 1 appeared first on Linux Foundation – Training.

Software package and application requirements for Hyperledge Fabric installation on AWS | Linux.com


If you like to develop small to enterprise blockchain applications using Hyperledger tools, the first step is to learn what is Hyperledger and how it works. . Specifically, Hyperledger Fabric Architecture and Components for Blockchain Developers article is a great start. Once you learn the structure of transaction flow in Hyperledger, you can proceed with setting up your development environment. In this article, I show you the software package and application requirements for installing Hyperledge Fabric on Amazon

Web Services or AWS.

 

To install and run Hyperldger Fabric on AWS, the following software packages are needed:

  • cURL: A tool used to transfer data from or to a server, using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, DICT, TELNET, LDAP, or FILE). The command is designed to work without user interaction.
  • Docker: A tool to create, deploy, and run applications using containers. Containers allow developers to package applications with all of the parts it needs, such as libraries and other dependencies, and ship it out as one package.
  • Docker Compose: It is a tool which is used for defining and running Multi-container application. You can create and start all the services with help of a single command from your configuration YAML file.
  • Go: An open source programming language that makes it easy to build simple, reliable, andefficient software. Hyperledger Fabric is primarily developed using the Go language.
  • Node.js: A platform built on Chrome&#39;s JavaScript runtime to easily build fast and scalable network applications. Node.js is considered to be more lightweight and efficient since it uses event-driven, non-blocking I/O models, which make it more feasible for data-intensive real-time applications.
  • npm package manager: A tool that will allow you to install third-party libraries (other people’s code) using the command line.
  • Python: A general-purpose programming language for developing both desktop and web applications. Python is also used to develop complex scientific and numeric applications. It is designed with features to facilitate data analysis and visualization.

Also, installing the following applications are useful for learning the capabilities and operations of Hyperledger Fabric:

  • balance-transfer: A sample Node.js app to demonstrate fabric-client and fabric-ca-client Node.js SDK APIs.
  • basic-network: A basic network with certificates and key materials, predefined transactions, and one channel, mychannel.
  • bin: Binary and scripts for fabric-ca, orderer, and peer.
  • chaincode: Chaincode developed for fabcar, marbles, and a few other examples.
  • chaincode-docker-devmode: Develops chaincode in dev mode for rapid code/build/run/debug.
  • config: YAML files to define transaction, orderer, organization, and chaincode.
  • fabcar: A sample Node.js app to demonstrate the capabilities with chaincode deployment, query, and updating the ledger.
  • fabric-ca: Uses the Fabric CA client and server to generate all crypto material and learn how to use attribute-based access control.
  • first-network: Builds the first hyperledger fabric network with byfn.sh and eyfn.sh.
  • Jenkinsfile: Jenkins is a suite of plugins that supports implementing and integrating continuous-delivery pipelines. The definition of a Jenkins pipeline is typically written into a text file, Jenkinsfile, which in turn is checked into a project&#39;s source-control repository.
  • scripts: There are two scripts in this directory: bootstrap.sh and Jenkins_Scripts.
Now that you know the installation requirements, the next is to follow this article: Install Hyperledger Fabric on AWS that gives you step-by-step guide for installing Hyperledger Fabric on AWS.


About Authors
This article is written by Matt Zand (Founder of High School Technology Services) in collaboration with Brian Wu who is a senior blockchain instructor at Coding Bootcamps school in Virginia.

Click Here!

Software package and application requirements for Hyperledge Fabric installation on AWS | Linux.com


If you like to develop small to enterprise blockchain applications using Hyperledger tools, the first step is to learn what is Hyperledger and how it works. . Specifically, Hyperledger Fabric Architecture and Components for Blockchain Developers article is a great start. Once you learn the structure of transaction flow in Hyperledger, you can proceed with setting up your development environment. In this article, I show you the software package and application requirements for installing Hyperledge Fabric on Amazon

Web Services or AWS.

 

To install and run Hyperldger Fabric on AWS, the following software packages are needed:

  • cURL: A tool used to transfer data from or to a server, using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, DICT, TELNET, LDAP, or FILE). The command is designed to work without user interaction.
  • Docker: A tool to create, deploy, and run applications using containers. Containers allow developers to package applications with all of the parts it needs, such as libraries and other dependencies, and ship it out as one package.
  • Docker Compose: It is a tool which is used for defining and running Multi-container application. You can create and start all the services with help of a single command from your configuration YAML file.
  • Go: An open source programming language that makes it easy to build simple, reliable, andefficient software. Hyperledger Fabric is primarily developed using the Go language.
  • Node.js: A platform built on Chrome&#39;s JavaScript runtime to easily build fast and scalable network applications. Node.js is considered to be more lightweight and efficient since it uses event-driven, non-blocking I/O models, which make it more feasible for data-intensive real-time applications.
  • npm package manager: A tool that will allow you to install third-party libraries (other people’s code) using the command line.
  • Python: A general-purpose programming language for developing both desktop and web applications. Python is also used to develop complex scientific and numeric applications. It is designed with features to facilitate data analysis and visualization.

Also, installing the following applications are useful for learning the capabilities and operations of Hyperledger Fabric:

  • balance-transfer: A sample Node.js app to demonstrate fabric-client and fabric-ca-client Node.js SDK APIs.
  • basic-network: A basic network with certificates and key materials, predefined transactions, and one channel, mychannel.
  • bin: Binary and scripts for fabric-ca, orderer, and peer.
  • chaincode: Chaincode developed for fabcar, marbles, and a few other examples.
  • chaincode-docker-devmode: Develops chaincode in dev mode for rapid code/build/run/debug.
  • config: YAML files to define transaction, orderer, organization, and chaincode.
  • fabcar: A sample Node.js app to demonstrate the capabilities with chaincode deployment, query, and updating the ledger.
  • fabric-ca: Uses the Fabric CA client and server to generate all crypto material and learn how to use attribute-based access control.
  • first-network: Builds the first hyperledger fabric network with byfn.sh and eyfn.sh.
  • Jenkinsfile: Jenkins is a suite of plugins that supports implementing and integrating continuous-delivery pipelines. The definition of a Jenkins pipeline is typically written into a text file, Jenkinsfile, which in turn is checked into a project&#39;s source-control repository.
  • scripts: There are two scripts in this directory: bootstrap.sh and Jenkins_Scripts.

Now that you know the installation requirements, the next is to follow this article: Install Hyperledger Fabric on AWS that gives you step-by-step guide for installing Hyperledger Fabric on AWS.


About Authors
This article is written by Matt Zand (Founder of High School Technology Services) in collaboration with Brian Wu who is a senior blockchain instructor at Coding Bootcamps school in Virginia.

Click Here!