Shulou(Shulou.com)06/01 Report--

The editor will share with you an example analysis of the startup process of the Fabric network environment. I hope you will gain something after reading this article. Let's discuss it together.

Detailed explanation of the startup process of fabric network environment

Earlier we talked about the startup testing of fabric network environment, mainly using the command. / network_setup.sh up, so the focus of fabric network environment startup is in the network_setup.sh file. Next, let's analyze the network_setup.sh file network_setup.sh, which consists of two parts, one is to configure the organization relationship and issue certificates, public / private keys, channel certificates, etc., using the generateArtifacts.sh script file, and the other is the sample code that docker-compose-cli.yaml uses to start the cluster and test chaincode according to the configuration.

First take a look at the generateArtifacts.sh script file, which contains three functions, namely:

1.generateCerts: this function uses the cryptogen tool to generate public and private keys and certificate information based on crypto-config.yaml. 2.replacePrivateKey: replace the ca private key in the docker-compose-e2e-template.yaml document with a specific private key. 3.generateChannelArtifacts: use the configtxgen tool to generate information about creation blocks and channels and update anchor nodes based on configtx.yaml files.

Next comes the docker-compose-cli.yaml file docker-compose-cli.yaml file starts the docker cluster according to the organization relationship, and executes the command command in the cli container to run the. / scripts/script.sh script file. So what exactly does the. / scripts/script.sh script do?

1.createChannel: create a channel. 2. JoinChannel: add each peer node to the channel. 3. UpdateAnchorPeers: update anchor node 4. InstallChaincode: deploy chaincode. 5. InstantiateChaincode: initialize chaincode. 6. ChaincodeQuery:chaincode query

In addition, there is another configuration item in the docker-compose-cli.yaml file that needs to be paid attention to, that is:

File: base/docker-compose-base.yaml

Docker-compose-base.yaml here is actually the basic configuration file for Orderer and peer, including designated ports, and so on.

Several important configuration files 1.crypto-config.yaml

Generate public and private key and certificate information based on crypto-config.yaml (this file is in.. / fabric/examples/e2e_ client) and save it in the crypto-config folder. In addition, crypto-config.yaml also defines the members of the organization and the number of peer nodes under the organization. Crypto-config.yaml file description: the fields Name and Domain are about the organization's name and domain name, which is mainly used to generate certificates, which will contain this information. Template.Count=2 means that we need to generate two sets of public and private keys and certificates, one for peer0.org1 and the other for peer1.org1 (that is, two nodes, peer0 and peer1, are specified in org). Finally, Users.Count=1 means that there will be several ordinary User under each Template (note that Admin is Admin and is not included in this count). Here, 1 is configured, which means that we only need an ordinary user User1@org1.example.com. We can adjust this configuration file according to the actual needs, add or delete Org Users, and so on. The contents of the document are as follows:

#-# Orderer #-- -Name: Orderer Domain: example.com #- -# "Specs"-See PeerOrgs below for complete description #-Specs:-Hostname: orderer#- -# "PeerOrgs"-Definition of organizations managing peer nodes#- -PeerOrgs: # # Org1 #-Name: Org1 Domain: org1.example.com #- -# "Specs" # -# Uncomment this section to enable the explicit definition of hosts in your # configuration. Most users will want to use Template, below # # Specs is an array of Spec entries. Each Spec entry consists of two fields: #-Hostname: (Required) The desired hostname, sans the domain #-CommonName: (Optional) Specifies the template or explicit override for # the CN By default, this is the template: # # "{{.Hostname}}. {{.Domain}}" # # which obtains its values from the Spec.Hostname and # Org.Domain, respectively. #-# Specs: #-Hostname: foo # implicitly "foo.org1.example.com" # CommonName: foo27.org5.example.com # overrides Hostname- Based FQDN set above #-Hostname: bar #-Hostname: baz #-# "Template" #- -# Allows for the definition of 1 or more hosts that are created sequentially # from a template. By default, this looks like "peer%d" from 0 to Count-1. # You may override the number of nodes (Count), the starting index (Start) # or the template used to construct the name (Hostname). # # Note: Template and Specs are not mutually exclusive. You may define both # sections and the aggregate nodes will be created for you. Take care with # name collisions #-Template: Count: 2 # Start: 5 # Hostname: {{.prefix}} {. Index}} # default #-# "Users" # -# Count: The number of user accounts _ in addition_ to Admin #- -Users: Count: 1 #-# Org2: See " Org1 "for full specification #-Name: Org2 Domain: org2.example.com Template: Count: 2 Users: Count: 1

Note: peer: a node in a Fabric network that behaves as a running docker container. You can communicate with other peer in the network, and each peer keeps a local copy of the ledger. It is a member of the organization under org. Org: an organization that can consist of one or more peer. Orderer: a centralized node shared by federation members. It is used to sort transactions and is an important part of Fabric consensus mechanism.

2.configtx.yaml

Generate information about creation blocks and channels based on configtx.yaml (this file is in.. / fabric/examples/e2e_ clips) and save it in the channel-artifacts folder. You can also specify an endorsement policy. Configtx.yaml file explanation: 1. The official examples/e2e_cli/configtx.yaml file is configured with two Org participating Orderer consensus configuration TwoOrgsOrdererGenesis and two Org participating Channel configuration: TwoOrgsChannel. two。 In addition, we can set the consensus algorithm in the Orderer section of this file is Solo or Kafka, as well as the consensus block size, timeout, and so on. We can use the default value without changing it. The configuration of Peer node includes the configuration of MSP and the configuration of anchor node. If we have more Org, or more Channel, then we can modify it according to the template. 3.Policies configuration should also pay special attention. This configuration item defines the permissions of different roles. Reader,Writer and Admin correspond to read, write, and admin permissions respectively. Read permission roles can only synchronize accounts from other peer nodes but cannot initiate transactions. Only the roles under the writer definition have the permission to initiate transactions, that is, to call the invoke method of chaincode (not necessarily invoke scheme, as long as the method of state modification in chaincode is involved. Can only be called by roles with writer or admin permissions. Take the Org1 configuration under the Organizations configuration of this configuration as an example, "OR ('Org1MSP.admin',' Org1MSP.client')", which means that the admin or client role in org1's msp service has permission to initiate a transaction. The contents of the document are as follows:

# Copyright IBM Corp. All Rights Reserved.## SPDX-License-Identifier: Apache-2.0#---#### Profile##-Different configuration profiles may be Encoded here to be specified# as parameters to the configtxgen tool####Profiles: TwoOrgsOrdererGenesis: Orderer:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.