Virtual currency, cottage currency development of multi-node cluster deployment (1)

Blockchain Enthusiast (qq:53016353)
Community users are looking forward to the unveiling of the virtual currency Fabric 1.0. In order to meet the release of Fabric 1.0, this article is divided into 3 installments, which describes how to build a multi-node distributed Fabric cluster, which can be downloaded in PDF version.


I. Overview


After awaited, the virtual currency Fabric 1.0 GA version of the pipa is about to be unveiled, and this version will be widely used by the Community users who are waiting for it. This article will show you how to use Docker container technology to build a multi-node Fabric cluster and describe how to perform basic operations on the cluster, such as Chaincode lifecycle maintenance. This article uses the end-to-end (E2E_CLI) Example of the Fabric 1.0 beta as a basis to illustrate the rationale. This article provides a manual approach to configuring the virtual currency using a container platform (such as k8s, etc.) to automatically deploy it.


Readers who need to understand the fabric infrastructure can refer to the post-article articles.




Figure 1.1 Fabric Network structure diagram under a single node


The Fabric source contains a simple e2e stand-alone deployment example that allows users to understand, research, and develop applications. As shown in Figure 1.1, a fabric network of 5 nodes is established through Docker-compose on a single machine node, each of which is simulated by a separate Docker container. Where Peer0 and Peer1 are nodes belonging to ORG1, Peer2 and Peer3 are nodes of the same org2, both of which are joined in the same channel and traded in the channel, while Orderer is the intersection of the channel Easy to provide sorting services.




Figure 1.2 Fabric network structure diagram under multi-node


Although the E2E_CLI example is simpler, it mixes multiple nodes together to differentiate which configuration corresponds to which node. In addition, in the actual scenario, the fabric node may be owned and maintained by different organizations, peers and Orderer must be distributed on different physical nodes, so multi-node fabric deployment becomes a problem to be solved, figure 1.2 is a multi-node fabric cluster topology diagram.


Note: Download the PDF version of this article to pay attention to this public number: Henry Notes, the background to send the message "Multi-node" or "DJD" can be. 】


Here are the approximate steps to change the single-node e2e_cli paradigm to multiple nodes:


1. Preparing the Environment


Running a fabric node relies on the following tools:


A. Docker: for managing fabric mirroring and running components such as peer and Orderer


B. Docker-compose: for configuring Fabric containers


C. Fabric Source code: Source provides tools and test code for generating certificates and configuring channel


D. Go language development environment: source code tool compilation relies on the Go language


2. Configuring a multi-node fabric cluster


In the single-node E2e_cli example, all nodes are deployed in the same docker-compose internal network, communicating through port 7051 of the container. However, in the case of multiple nodes, there is no direct communication between the containers, so it is necessary to map the container's 7051 port to the host, through the host's 7051 ports to achieve inter-node communication. We modify the service definitions in Docker-compose.yaml in each node, starting only the required service at different nodes. For example, only PEER0 service is started in Node 1, Orderer is only started in node 5, and so on.


3. Start a multi-node fabric cluster


After configuring the fabric's boot environment on each node, you need to log on to the node in turn to start the fabric node by docker-compose up. Because the boot environment has dependencies, such as Peer1 with PEER0 as the Discovery node, you need to start Peer0 peer1 first.


4. Configure Channel


In Fabric, the channel represents a private broadcast channel that guarantees the isolation and privacy of the message, which is managed by Orderer. Members of the channel share the channel's ledger, and only authenticated users can trade in the channel, and a channel-related attribute is recorded in the initial chunk of the channel and can be changed through reconfiguration transactions. The initial chunk of the channel is generated by the Create channel trade, which is the Config.tx file that the peer sends to Orderer when the transaction is sent, which defines the relevant properties of the channel.


5. Release Chaincode


Chaincode is a smart contract developed by a developer on a specific interface that, when installed and initialized on a Fabric network through the SDK or CLI, can access the shared ledger on the network.


The life cycle of the Chaincode is as follows:


A. Install (installation)


Chaincode to run on a Fabric network, you must first install the peer on the network and install a version control that also indicates the version number to be applied.


B. Instantiate (instantiation)


After installing Chaincode on peer, you also need to instantiate to actually activate the Chaincode. During instantiation, the Chaincode is compiled and packaged into a container image and then started to run. If Chaincode updates the state of the data during instantiation, if a variable is given an initial value, the state change is recorded in the shared ledger. Each app can only be instantiated once, and instantiation can be performed on any peer that has installed the Chaincode.


C. Invoke and query (calls and queries)


After the Chaincode is instantiated, the user can interact with it, where query queries the state associated with the application (that is, read-only), and invoke may change its state.


D. Upgrade (upgrade)


When a new feature is added to Chaincode or a bug needs to be upgraded, it can be done through upgrade transactions. The new code needs to be installed through the install transaction to a running Chaincode


Peer, the installation must be marked with a higher version number than the previous version, the next only need to send to any one of the new code peer sent upgrade transactions can be updated Chaincode, chaincode in the status before the update will be retained.