Getting started with Hyperledger Fabric and Allied Tools

Since Bitcoin went past the $10K mark sometime last week, there’s a huge buzz in the media about the growth story of the Bitcoin. At Xebia, we’ve been keen followers of the Bitcoin for a while. As technologists, beyond the buzz what interests us immensely is the underlying Blockchain technology that makes the Bitcoin tick. We see tremendous potential in the Blockchain as a solution offering relevant for varied domains such as public services, healthcare, financial services, trades to name a few.

What is Blockchain?

HBR defines Blockchain as “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way”. For an even clearer explanation of the Blockchain you could refer to the plain english explanation of blockchain.


Hyperledger is the Linux Foundation’s umbrella project under which several Blockchain related projects such as Hyperledger Fabric, Hyperledger Sawtooth, Hyperledger Cello, Hyperledger Explorer, etc. are being incubated. We recently started exploring a few of these projects & have a Hyperledger Fabric based blockchain set-up locally for experimentation.

Building Hyperledger Fabric

Our dev environments are standard (old) Intel i5s, with 4 cores, 16GB ram, running Ubuntu 14.04. There are several pre-requisites for building hyperledger such as specific versions of docker, docker-compose, go, etc. as mentioned here in dev environment set-up doc. Please ensure that each of these are done correctly without any errors before proceeding further.

Go Docker

The recommended way to get started with Hyperledger is via Docker containers. Pre-built containers are readily available for download from dockerhub. The install binaries & docker images script located here downloads the necessary platform specific binaries & docker images to the local system.

Note: An alternate to Docker based set-up is to checkout fabric code locally & build it . We ran into a few flaky tests that would fail the build intermittently, though we were able to build by skipping tests. Getting to a clean build with tests remains a future goal for us.

Once Fabric was set-up, we started evaluating other developer tooling projects being incubated under the Hyperledger umbrella. We went on to install Hyperledger Composer, Hyperledger Explorer & Hyperledger Cello. Hyperledger Indy is also in our radar for secure identity management in the future.

Hyperledger Composer

Hyperledger Composer is a framework for developing Blockchain applications on top of the Hyperledger Fabric. Composer basically makes it very simple to get started with building Blockchain based applications. They even let you try composer online on their site.

As a first cut on the installation we went with the composer playground-local set-up. The set-up was breezy. We got started with the playground tutorial on our local, & had the trader network set-up very soon.

Persisting Networks Across Restarts of Hyperledger Fabric & Composer

One of the issues that we ran into was that our blockchain applications did not seem to survive playground or machine restarts. A look at the code made it clear that this was not a playground issue, rather the expected behaviour with the local set-up.

The playground local scripts was delegating to a script, with an explicit docker-compose down instruction. This ensured that each start of the composer playground local would do a fresh clean start of the blockchain fabric docker containers.

An alternative to playground local is to do the complete composer development environment set-up. The key difference being that the complete dev set-up has a seperate standalone hyperledger fabric installation running from the fabric-tools folder. However, the same docker-compose down command is still there in the script of fabric, & we had to make a few hacks to the script (there may be better ways):

*  docker-compose down changed to stop:

ARCH=$ARCH docker-compose -f “${DIR}”/composer/docker-compose.yml stop

* Commented out instructions to create & join composer channels (do this only after the composer application has been started once since they don’t exist initially):

# Create the channel

#docker exec peer channel create -o -c composerchannel -f /etc/hyperledger/configtx/composer-channel.tx

# Join to the channel.

#docker exec -e “CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/” peer channel join -b composerchannel.block

We gave the playground tutorial another run & found everything to be working perfectly. Next we wanted to see/ view the blocks that we just created & thus reached the next tool in our set the Hyperledger Explorer.

Hyperledger Explorer

Hyperledger Explorer provides a web based access on top of the Hyperledger Fabric blockchain. This was just what we needed to see the blocks that we just created via Hyperledger Composer.

The installation instructions for Blockchain explorer includes a mysql db installation & import, followed by a npm install of the codebase as given here here. As instructed, we updated the config.json with our mysql db credentials, changed the port to 9080 (default port 8080 was already in use by composer) & started explorer.

Even though the explorer ui was accessible on http://localhost:9080, we were unable to see details of any of the blocks created via composer. We needed to make two additional changes to the config.json file to finally get this working:

* Channel name

“channelsList”: [“composerchannel”],

* Disable tls


Note 1: Even though disabling tls made this work for now, this needs to be revisited for a more real world production grade set-up in the future.

Note 2: In trying to figure out the channel names being used by composer, we found that composer currently lacks multi-channel support.

At this point, we were able to perform a transaction on composer, that made it in to the fabric blockchain, which would then show up on the hyperledger explorer in real-time. This gave us a good end-to-end view of our own hyperlerledger based blockchain applications in action.

So far we had been running our docker containers locally, & as a next step wanted to experiement with a distributed set-up. This brought us to Hyperledger Cello.

Hyperledger Cello

Hyperledger Cello makes it easy to provision & manage Hyperledger Fabric (& potentially other) blockchain networks. Cello has a master-slave (master nodes & worker nodes) architecture, where the master manages the blockchain running from the worker nodes. The web dashboard & rest api’s are also provided on the master node.

There a two parts to the cello installation. Installation on the master node, requires code to be downloaded & installed via:

$ make setup-master

& to start services on the master:

$ make start

Cello Master Port Conflict Issue:

We ran into several port conflicts since cello services by default makes use of the ports 80 & 8080, which were already taken up by composer, etc. To fix this we changed the docker-compose.yml file being used by cello:

*  Cello Rest Service Exposed Port (changed to port 50):




– “50”

* Nginx Port Mapping (changed to 50:50 & 5080:5080)




– “50:50”

– “5080:5080”

* User Dashboard Port Mapping (changed to 5081:5080)




– “5081:5080”

With those changes all our services were now up.

Next we did the specified installation for the cello worker nodes. These included adding a few params (allow-cors & ulimit) on the docker daemon, & making some firewall settings on the nodes.

With that we were able to hit the cello dashboard on the master node on the (configured) port 5080, add nodes, view details, etc.

We have several other scenarios to try out on cello, fabric, & the other hyperledger components cutting across OS & container types, as well as evaluating its management & ops capabilities. We hope to keep sharing details on the same as we go long. Till then happy block chaining!

Leave a Reply

Your email address will not be published. Required fields are marked *