How you can run a Hyperledger Fabric v2 Chaincode Development Network
In this article I would like to introduce two possible ways to run a fabric test network for chaincode development. If you want to develop a chaincode for a certain business case, you need a way to quickly test your chaincode without the complexity of a running fabric network.
The first approach uses the binary version of one orderer and one peer. It is also described in the official hyperledger fabric documentation. The second proposed solution is based on docker containers. Unfortunately, there is no official guide for that path, yet.
This article describes the differences and similarities of these two approaches. Both are based on Fabric version 2. I have modified solution one and composed a guide for procedure two. In my github.com repro at github.com/samlinux you can find both approaches as a step-by-step tutorial.
Two Ways to Do the Same Thing
In the diagram below, you can see an abstraction of chaincode development. Starting with the fabric-contract-api there is an abstraction layer to interact with the ledger.
With Fabric it is possible to use different programming languages to write a chaincode. Actually, Go, Node.js and Java are stable supported languages. This unique ability in the blockchain world gives the Fabric developer the choice to write a chaincode in his favorite language.
Although Fabric is based on Docker, you can choose to run Fabric with binaries or with Docker containers. Both ways are possible and usable. In the diagram above you can see a comparison of these different approaches, based on the practical application of both.
The Binary-Edition runs the development network with go binaries. In this case, there is no need for Docker containers. However, you have to build the binaries before you use it. You also have to use some environment variables to control the location of the ledger storage for instance. Normally, you have to use four different terminals to work with — one for the orderer, the peer, the chaincode, and the test terminal to run your chaincode.
The Docker-Edition is more based on the test-network environment we know from the fabric-samples. You need at least three different terminals for the docker-composition — one for the orderer and peer, the chaincode, and the test terminal to use your chaincode. The docker-composition needs only the orderer and peer service.
Both versions have in common that the peer has to be started in a special modus — the — peer-chaincodedev modus. This is done with the command: peer node start — peer-chaincodedev=true.
After you have cloned the fabric repro you have to look into the sampleconfig folder within the cloned repo. There you will find a proper MSP (Membership Service Provider) folder with all the certificates and a suitable configtx.yaml, core.yaml and orderer.yaml file. configtx.yaml is particularly noteworthy at this point because it provides some predefined profiles. You can use the predefined SampleDevModeSolo profile to generate the orderer genesis block for the development network.
In both versions you have to start and stop the chaincode by yourself. So, what are the advantages of these approaches? To get both approaches running, you have to approve the chaincode and to start the chaincode by yourself. As you can start and stop the chaincode by yourself, you have the option to change and recreate the chaincode and then start the chaincode again. Normally, the chaincode is started and maintained by the peer as a separate chaincode container and not by the user, except the external chaincode scenario.
Note: Make sure in your development network that TLS (Transport Layer Security) is not used when running in dev mode.
Summarizing the workflow, the following steps can be used in the ongoing chaincode development network:
- remodify your chaincode in your editor
- build your chaincode again
- stop your running chaincode
- start your remodified chaincode
- test your running chaincode within the CLI (command line interface) commands
With this scenario you don’t have to repeat the chaincode installation and approval process to test a new version of your chaincode.
Comparison of the Process
To get a better overview of both approaches, you can find a process comparison divided by terminals in the diagram below.
Summary
In this article you have seen which possibilities you have as a chaincode developer to test your chaincode in a blockchain environment. Both compared versions are usable. It is up to you to use the appropriate approach for your environment and use case. I hope this article provides more insights to optimise your chaincode development.
