IoT + Hyperledger Development from scratch within 21 days — Day 8

Hello, everybody! In the previous article IoT + Hyperledger Development from scratch within 21 days — Day 7 we explain how to create artifacts for our network with the configtx.yaml.

The next step is to run our network, for this we will use the docker-compose.yaml file. Upon completion of the configuration, we will run containers based on Docker images. Each container will represent the network component.

Basically, we will define the topology of the network. It’s important to remember that the generated certificates and artifacts that we have created in the previous step, will now be used in the docker-compose.yaml file.

If you are not familiar with the docker, that is a tool designed to make it easier to create, deploy, and run applications by using containers.

We will have base.yaml and docker-compose.yaml files. The first file is to set the configuration of the peers, second is to wrap all components of the network and start up the network.

This is a quite convenient setup where various aspects of the configuration are defined in separate files — together they make the configuration for docker-compose. This allows, for example, to change particular attribute related to all peers on the single place rather than in the definition of each particular peer.

It is very important to understand the mounting process. This is a process where files from a local computer are placed inside a docker container. The files that are uploaded are called volumes and represent persisted data.
In our case, we will put the certificates as the volumes.

base.yaml

This file is used to configure all peers in our network, also we will have TLS enabled for our network. We will explain the most important part of this file, the reason for that is that the many environment variables are self-explanatory. You can see the full sections in the below of these texts.

base.yaml

• VERSION — corresponding on the docker-compose version of the YAML file
• IMAGE — correspond to your system images are downloaded and which version of Hyperldger Fabric(newest 1.4.1)
• CORE_VM_ENDPOINT — used by the peer to create/run Docker containers for running chaincode.
• CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE — sets the network
• CORE_LEDGER_STATE_STATEDATABASE — -sets the database for the ledger state(default is LevelDB)
• CORE_PEER_GOSSIP_USELEADERELECTION — responsible to maintain the highly available connection with ordering service to guarantee cluster of peers will be able to make a progress and receive new blocks.
• CORE_PEER_TLS_ENABLED — set the network with TSL configuration(mount the crypto materials for the TLS configuration)
• CORE_PEER_MSPCONFIGPATH — sets the path for the certificates in the docker containers
• working_dir — place where will be store all necessary files for the network peers in the docker container
• command — start the peer's containers

Next file that we will examine is docker-compose.yaml file. For the length of the article, we will provide an explanation about one central authority of buyer organization, buyer peer, ledger state and the orderer. The concept is the same for other network components, the whole file can be found below.

docker-compose.yaml

• FABRIC_CA_HOME — the path where will be store everything for the Central Authority for the buyer organization in the docker container
• FABRIC_CA_SERVER_CA_NAME — the name of the CA
• FABRIC_CA_SERVER_CA_CERTFILE — sets buyer certificates from the local buyer folder (/crypto-config/peerOrganizations/buyer.iot-logistic.com/ca) into the container
• FABRIC_CA_SERVER_CA_KEYFILE — sets buyer keys from the local buyer folder (/crypto-config/peerOrganizations/buyer.iot-logistic.com/ca/_sk) into the container
• FABRIC_CA_SERVER_TLS_ENABLED — enable TLS configuration (the same certs are for the TLS)
• ports — define ports for the CA for(default is 7054, for example, the next container is 8054:7054, etc…)
• command — start the CA container for the buyer organization(pass the username, password, and certificates)
• volumes — mount the local generate certificates to the CA docker container
• container_name — the name of the docker container

This is environmental variables for the Central Authority for the Buyer organization. Next thing that we will discuss is the orderer section in the file.

• ORDERER_GENERAL_GENESISMETHOD — utilize this genesis block, before starting the orderer
• ORDERER_GENERAL_GENESISFILE — sets the path in the container for the genesis block
• ORDERER_GENERAL_LOCALMSPID — id to load MSP (defined in the configtx.yaml)
• ORDERER_GENERAL_LOCALMSPDIR — set the path for the certificates in orderer container
• ORDERER_GENERAL_TLS_ENABLED — sets to the true(in it must be provided private key and certificates)

In our network TLS is enabled so we must tell to orderer that our peers have TLS certificates, so we specify in the (ORDERER_GENERAL_TLS_ROOTCAS) variable as an array of organizations peers certification. Also, we must in the section volumes mount all network peers. Reason for that is that orderer is in charge of messaging through the network and must know who is valid in the network, the orderer must know which certificates belong to each peer, and to stop compromising peer to be part of the network.

Each peer in the network has a ledger state where is stored all data, which concerns for that peer. The default database for peers in the Hyperldger Fabric is LevelDB, but for the for ease of viewing, simplicity and to perform the rich queries we using the CouchDB.

It is very easy to create a container for a ledger state of each peer. First, you need to define the container image that will be used, after that define container ports (default 5984: 5984, for the next container, is 6984: 5984, etc …), and set the variable environment (user and password) if you want to prevent “ Admin Party “.

Next thing that we will examine is the buyer peer section. Define the name for the peer( check the name in configtx), in our case that is peer0.buyer.iot-logistic.com. We explain in the above section why we use two separate files to define network components. So we extend base.yaml file where we define the configuration for all peers, but that is not whole.

• CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS — sets the CouchDB with the name of CouchDB container for that peer, where is defined earlier in the docker-compose.yaml.
• CORE_PEER_ID — sets the id for the peer(crypto-config.yaml)
• CORE_PEER_LOCALMSPID —id to load MSP (defined in the configtx.yaml)
• CORE_PEER_ADDRESS — set the peer address(host+port defined in the configtx.yaml default is 7051)
• CORE_PEER_GOSSIP_EXTERNALENDPOINT — in order for peers to communicate across organizations
• CORE_PEER_CHAINCODELISTENADDRESS — sets separate service to communicate with chaincode container
• ports —7051:7051(default), 7052:7052(for the chaincode), 7053:7053(for handling the events)
• volumes — mount the local certificates into peer container
• depends_on — sets that container can’t work if order.iot-logistic.com and ledger.state.regulator not exist

To start up the network we create start-network. sh script that will read docker-compose and sets all components of our network.

start-network.sh

In the process of development, we often had to change the different files so we created this script to automate the entire process. For the sake of understanding this file, the minimum knowledge of shell scripting is required. Here you can find the script.

start-network.sh

We will not explain the entire file, but we will mention the steps that are being taken within this file:

• list docker containers and remove it
• list docker images and remove it
• tear down the network
• start the network up

Finally, we can start the network with the command ./start-network.sh.

The output of this script will be:

network_default

If you see the same output, that means that you successfully deploy Hyperldger Fabric network (network_default). You can list all containers from the terminal with command docker ps. Our network consists of:

• Four Central Authority (for each organization)
• Four Peers
• Four CouchDB’s for the ledger state of peers
• One orderer

If one of the containers does not set up, you can check its logs with this command docker logs name-of-container (for example docker logs peer0.regulator.iot-logistic.com), the mistakes are usually related to the wrong mounting of the certificates in your docker-compose.yaml file.

Conclusion

I hope that you have successfully set up your blockchain network and that you are currently dedicating a certain amount of time to track logs within certain docker containers to try to understand the Hyperldger Fabric networking mechanism and the dependence of the docker-compose file with crypto-config and configtx. In this learning phase, it is very desirable that you have errors :). The whole repo you can find here.

Stay sharp, and see ya in the next article!

Work with us!

Beyondi offers high-quality services: Web Development and Design, Mobile Development and Design, Embedded Solutions, Blockchain Solutions, Digital Marketing, SEO, Growth and Team Augmentation? You can find more about our services on our website.

Beyondi | Full Stack Development Solutions