layout: fabric
title: solo node test
date: 2021-03-25 19:18:57
categories:
- Hyperledger Fabric
tags: - Hyperledger Fabric
Generate Fabric certificate
Hyperledger Fabric configures organizations, nodes, and users through certificate files. The standard of certificate file (in fact, digital certificate is the public key authenticated by CA) is X.509, and the encoding format is PEM, starting with - – BEGIN and ending with - – END. 10. The 509 digital certificate includes not only the user name and public key, but also other information about the user. In addition to the PEM extension, there are the following:
- CRT: should it be the three letters of certificate or the meaning of certificate. It is also a PEM encoding format.
- KEY: used to store a public KEY or private KEY, not an X.509 certificate. Open to see PEM format.
The default signature algorithm of the certificate is ECDSA and the Hash algorithm is SHA-256. Three types of certificates are considered in Fabric design:
- Registration Certificate (ECert): issued to the user or node entity that provided the registration certificate. It is valid for a long time. (mainly the entity identity verification through ECert)
- Communication Certificate (TLSCert): TLS certificate is used to ensure the security of communication links, control access to the network layer, verify the identity of remote entities and prevent eavesdropping.
- Transaction certificate (TCert): issued to users to control the authority of each transaction. It is generally valid for a transaction for a short time.
1. Preparation of certificate documents
First, we use the following command to enter the ~ / hyperledger directory and create a project directory solotest.
cd ~/hyperledger mkdir solotest cd solotest
We can use the following command to view the template file that generated the certificate file.
cryptogen showtemplate
Use the following command to copy the template file to the current directory.
cryptogen showtemplate > crypto-config.yaml
The template of the configuration file is as follows:
OrdererOrgs:
- Name: Orderer
Domain: example.com
Specs:
- Hostname: orderer
- Hostname: orderer2
PeerOrgs:
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 2
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Specs:
- Hostname: hello
Users:
Count: 1
-
OrdererOrgs sorting node organization information
- Name: the name of the orderer sorting node organization
- Domain: example.com root domain name, which sorts the root domain names of node organizations
- Specs:
- Hostname: orderer the domain name corresponding to this orderer is: orderer example. com
- Hostname: order2 the domain name corresponding to this orderer is order2 example. com
-
PeerOrgs: peer organization information
-
Name: Org1 the name of the first organization. Specify it yourself
-
Domain: org1.example.com visit the root domain used by the first organization
-
EnableNodeOUs: true whether node is supported JS, which is usually filled in as true
-
Template template, which generates a peer node for storing data according to the default rules
- Count: 2 the number of generated nodes is the names of two nodes, which are sorted in numerical order, such as: 1 peer0. org1. example. com 2. peer1. org1. example. com
-
Users number of ordinary users created
- Count: the number of ordinary users created is 2
-
In this part of the course, we create a single node network, so we only need to configure an organization under PeerOrgs. Fill in 1 under Template to indicate that the organization has only one node, and fill in 1 under Users to indicate that there is only one user. In vim, modify the configuration file crypto config. In the current directory Yaml is as follows:
OrdererOrgs:
- Name: Orderer
Domain: test.com
EnableNodeOUs: true
Specs:
- Hostname: orderer
PeerOrgs:
- Name: org1
Domain: org1.test.com
EnableNodeOUs: true
Template:
Count: 1
Users:
Count: 1
2. Generation of certificate file
Use the following command to generate a certificate file.
cryptogen generate --config=crypto-config.yaml
Use the ls command to view the generated file. You can see that the crypto config file is generated, where all the certificate files are stored.
ls
crypto-config crypto-config.yaml
Use the ls command to view the files in the crypto config directory. You will find that the folders of two organizations are the order organization and the peer organization.
ls crypto-config
ordererOrganizations peerOrganizations
Let's take the peer organization as an example and check the directory under its folder. Since we have only created one organization, we see only org1 test. com.
cd crypto-config ls peerOrganizations
org1.test.com
Continue viewing org1 test. COM, you can see that there are five folders: ca msp peers tlsca users.
cd peerOrganizations ls org1.test.com
ca msp peers tlsca users
-
ca: it stores the root certificate of the organization and the corresponding private key file. It adopts the EC algorithm. The number of certificates is self signed (issuing their own public key). Entities in the organization will take this number of certificates as the root of the number of certificates.
-
msp: store the identity information representing the organization. There are also three directories under the msp folder:
-
admincerts: the authentication certificate of the organization administrator signed by the root certificate.
-
cacerts: the root certificate of the organization, which is the same as the file in the ca directory.
-
tlscacerts: CA certificate for TLS. The certificate is self signed.
-
-
Peers: store the certificates of all peer nodes under the organization. We only created one organization, so there is only peer0.0 in the peers file org1. test. Com directory. There are two directories under this directory:
-
msp, which has five directories:
- admincerts: the authentication certificate of the organization administrator, which is used to verify whether the transaction signer is an administrator.
- cacerts: stores the organization's root certificate.
- keystore: the identity private key of this node, which is used for signature.
- Signerts: verify the certificate signed by this node and signed by the organization's root certificate.
- tlscacerts: the identity certificate used for TLS connection, that is, the organization TLS certificate.
-
TLS: stores TLS related certificates and private keys. There are three files under it:
- ca.crt: the root certificate of the organization.
- server.crt: verify the certificate signed by this node and signed by the organization's root certificate.
- server.key: the identity private key of this node, which is used for signature.
-
-
users: stores the user entities belonging to the organization. There are two folders under them, namely Admin@org1.test.com as well as User1@org1.test.com (we only created one user), where Admin@org1.test.com Is to save the information of the administrator user, including its MSP certificate and TLS certificate. User1@org1.test.com Save the information of the first user in the same structure as admin, including MSP certificate and TLS certificate, which will not be repeated. Let's take admin as an example:
-
msp includes:
-
admincerts: administrator identity certificate.
-
cacerts: stores the organization's root certificate.
-
keystore: the identity private key of the user, which is used for signature.
-
Signerts: the authentication certificate of the administrator user. It is signed by the organization root certificate. It will be recognized by the Peer only after it is placed under the Peer's msp/admincerts.
-
tlscacerts: the identity certificate used for TLS connection, that is, the organization TLS certificate.
-
-
Under tls: (it can be seen that it is the same as the directory under our tls file above)
-
ca.crt: the root certificate of the organization.
-
server.crt: the authentication certificate of the administrator user, signed by the organization root certificate.
-
server.key: the identity private key of the administrator, which is used to sign.
-
-
Finally, we use the following command to return to the project path.
cd ~/hyperledger/solotest
Genesis block files and channel files
yaml related syntax: < < merge to current data, - array, * alias (similar to pointer), & anchor (similar to addressing).
1. Preparation of initial block file
First, we can refer to configtx. Net in the official sample project test network Yaml configuration file, enter its directory using the following command.
CD /root/hyperledger/fabric-samples/test-network/configtx
Use the ls command to view the file.
ls
configtx.yaml
Use the following command to copy this configuration file to our project path.
cp * ~/hyperledger/solotest
Use the following command to return to our project path.
cd ~/hyperledger/solotest
You can use the cat command to view configtx Yaml configuration file.
cat configtx.yaml
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: ../organizations/ordererOrganizations/example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer.example.com:7050
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: ../organizations/peerOrganizations/org1.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.peer')"
AnchorPeers:
- Host: peer0.org1.example.com
Port: 7051
-
Organizations configuration section, which defines different organizational identities, including orderer and other organizations
-
Name: organization name
-
ID: the ID of the MSP
-
Mspdir: the path to the MSP configuration file
-
Policies: organization policy, where Rule defines rules, OR is OR, AND is AND
-
AnchorPeers: anchor node
-
Capabilities:
Channel: &ChannelCapabilities
V2_0: true
Orderer: &OrdererCapabilities
V2_0: true
Application: &ApplicationCapabilities
V2_0: true
- In the Capabilities configuration section, the direct translation of capability is the capability, which can be understood as the version control of components in the Fabric network, and then the corresponding characteristics can be controlled through the version. If the newly updated features are not supported by the components of the old version, the transaction may not be verified or submitted, resulting in different ledgers on nodes of different versions. Therefore, use Capabilities to terminate the transaction processing of the old components that do not support the features until they are updated and upgraded. Channel means that both orders and peers need to be satisfied at the same time. Orderer only needs orders to be satisfied, and Application only needs peers to be satisfied.
Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Capabilities:
<<: *ApplicationCapabilities
- In the Application configuration section, some Application related parameters will be programmed into the genesis block or the Application related parameters for configuring the transaction. organizations: not configured here. In the following profiles configuration section, configure according to the file type to be generated.
Orderer: &OrdererDefaults
OrdererType: etcdraft
Addresses:
- orderer.example.com:7050
EtcdRaft:
Consenters:
- Host: orderer.example.com
Port: 7050
ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
-
Orderer configuration section, some parameters about orderer
-
OrdererType: consensus mechanism sorting algorithm solo or raft
-
Addresses: Orderer address
-
BatchTimeout: block generation time (blocks will be generated when the time is reached)
-
MaxMessageCount: number of block messages (the maximum amount of data in the transaction. Blocks will be generated after the number reaches)
-
AbsoluteMaxBytes: the absolute maximum number of bytes in a block (when the amount of data reaches this value, a block will be generated)
-
PreferredMaxBytes: recommended message bytes
-
Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ChannelCapabilities
- Channel configuration segment
Profiles:
TwoOrgsOrdererGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities:
<<: *OrdererCapabilities
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities:
<<: *ApplicationCapabilities
- The profiles configuration section is equivalent to the unified entry of the configtxgen tool. You can set different configtxgen -profile parameters to determine what files to generate using configtxgen, The profiles configuration section configures different files as needed by using the above prepared configuration section (although the configuration can be displayed, it is best to reference the default configuration, which means encapsulation). The corresponding configuration segments in the first network case are as follows.
Now we can modify the configuration file as follows: (the main modifications are MSP file path and organization node name, and the policy does not need to be changed).
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/test.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer.test.com:7050
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.test.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin','Org1MSP.peer','Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin','Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.peer')"
AnchorPeers:
- Host: peer0.org1.test.com
Port: 7051
Capabilities:
Channel: &ChannelCapabilities
V2_0: true
Orderer: &OrdererCapabilities
V2_0: true
Application: &ApplicationCapabilities
V2_0: true
Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Capabilities:
<<: *ApplicationCapabilities
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.test.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ChannelCapabilities
Profiles:
soloOrgsOrdererGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities:
<<: *OrdererCapabilities
Consortiums:
SampleConsortium:
Organizations:
- *Org1
soloOrgsChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
Capabilities:
<<: *ApplicationCapabilities
2 creation block file and channel file generation
Command introduction
configtxgen --help # Output the path and name of the start block file `-outputBlock string` # Specify the name of the created channel. If not specified, the system will provide a default name `-channelID string` # Indicates the path and name of the transport channel file `-outputCreateChannelTx string` # Specify the nodes in the configuration file `-profile string` # Update channel configuration information `-outputAnchorPeersUpdate string` # Specify the name of the organization to which you belong `-asOrg string`
Generate a creation block file, where the name defined in the previous configuration file corresponds to the name after - profile, - outputBlock specifies the path and name of the generated creation block file, and - channelID is the name of the channel (the name of the channel is optional, but it should be different from the channel name when generating the channel file below). Use the following command to get a file genesis. In the channel artifacts directory of the current directory block.
configtxgen -profile soloOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block -channelID fabric-channel
Generate a channel file, where - profile corresponds to the name defined in the previous configuration file, - outputBlock specifies the path and name of the generated channel file, and - channelID is the name of the channel. The name of the channel is optional, but it should be different from the channel name when the creation block file is generated above). Use the following command to get a file channel. In the channel artifacts directory of the current directory tx.
configtxgen -profile soloOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID mychannel
Generate an anchor node update file, where - profile corresponds to the name defined in the previous configuration file, - outputBlock specifies the path and name of the generated anchor node file, and - channelID is the name of the channel (to be the same as the channel name when generating the channel file above). Use the following command to get a file org1mspanchors.com in the channel artifacts directory of the current directory tx.
configtxgen -profile soloOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP
Use the ls command to view the file you just generated.
ls channel-artifacts
channel.tx Org1MSPanchors.tx genesis.block
Preparation of docker compose file
The nodes of Hyperledger Fabric run in the Docker container. We use the Docker compose file to configure the communication network, Mount directory and other information of each node, and then open all nodes.
First, we can refer to docker-compose-test-net in the official sample project test network Yaml configuration file, enter its directory using the following command.
cd /root/hyperledger/fabric-samples/test-network/docker
Use the ls command to view the files in the path.
ls
docker-compose-ca.yaml docker-compose-test-net.yaml docker-compose-couch.yaml
Use the cp command to set docker-compose-test-net Copy yaml configuration file to our project path.
cp docker-compose-test-net.yaml ~/hyperledger/solotest
Use the following command to return to our project directory.
cd ~/hyperledger/solotest
1 environment variables required for client roles
- GOPATH=/opt/gopath - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock - CORE_LOGGING_LEVEL=INFO - CORE_PEER_ID=cli - CORE_PEER_ADDRESS=peer0.org1.example.com:7051 - CORE_PEER_LOCALMSPID=Org1MSP - CORE_PEER_TLS_ENABLED=true - CORE_PEER_TLS_CERT_FILE= /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt - CORE_PEER_TLS_KEY_FILE= /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key -CORE_PEER_TLS_ROOTCERT_FILE= /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt - CORE_PEER_MSPCONFIGPATH= /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
- GOPATH: after the client docker container is started, the working directory of go does not need to be modified
- CORE_ VM_ Endpoint: after the docker container is started, the local socket of the corresponding daemon does not need to be modified
- CORE_LOGGING_LEVEL: log level
- CORE_PEER_ID: the ID of the current client node. Specify it yourself
- CORE_PEER_ADDRESS: the peer node address of the client connection
- CORE_PEER_LOCALMSPID: Organization ID
- CORE_PEER_TLS_ENABLED: does the communication use tls encryption
- CORE_PEER_TLS_CERT_FILE: certificate file path
- CORE_PEER_TLS_KEY_FILE: private key file path
- CORE_PEER_TLS_ROOTCERT_FILE: root certificate file path
- CORE_PEER_MSPCONFIGPATH:MSP profile path
2. Environment variables to be used by the orderer node
- ORDERER_GENERAL_LOGLEVEL=INFO - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0 - ORDERER_GENERAL_GENESISMETHOD=file - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block - ORDERER_GENERAL_LOCALMSPID=OrdererMSP - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp - ORDERER_GENERAL_TLS_ENABLED=true - ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- CORE_LOGGING_LEVEL: log level
- ORDERER_ GENERAL_ Listenaddress: the address that the orderer node listens to
- ORDERER_ GENERAL_ Genesis method: the source of the starting block
- ORDERER_GENERAL_GENESISFILE: the file path corresponding to the starting block
- ORDERER_ GENERAL_ Localmspid: ID of the group to which the orderer node belongs
- ORDERER_GENERAL_LOCALMSPDIR: msp account path of the current node
- ORDERER_GENERAL_TLS_ENABLED: does the communication use tls encryption
- ORDERER_GENERAL_TLS_CERTIFICATE: certificate file path
- ORDERER_GENERAL_TLS_PRIVATEKEY: private key file path
- ORDERER_GENERAL_TLS_ROOTCAS: root certificate file path
3 environment variables to be used by the peer node
- CORE_PEER_ID=peer0.org1.example.com.com - CORE_PEER_ADDRESS=peer0.org1.example.com:7051 - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051 - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051 - CORE_PEER_LOCALMSPID=Org1MSP - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=network_default - CORE_LOGGING_LEVEL=INFO - CORE_PEER_TLS_ENABLED=true - CORE_PEER_GOSSIP_USELEADERELECTION=true - CORE_PEER_GOSSIP_ORGLEADER=false - CORE_PEER_PROFILE_ENABLED=true - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
-
CORE_PEER_ID: the ID of the current client node. Specify it yourself
-
CORE_PEER_ADDRESS:peer node address
-
CORE_PEER_GOSSIP_BOOTSTRAP: Specifies the address of the connection at startup. It is usually written by itself
-
CORE_ PEER_ GOSSIP_ External point: in order to be perceived by other nodes, if other nodes are not set, the node does not exist
-
CORE_PEER_LOCALMSPID: Organization ID
-
CORE_ VM_ Endpoint: the local socket address of the docker
-
CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE: the name of the network created
-
CORE_LOGGING_LEVEL: log level
-
CORE_PEER_TLS_ENABLED: does the communication use tls encryption
-
CORE_PEER_GOSSIP_USELEADERELECTION: release the automatic election leader node
-
CORE_ PEER_ GOSSIP_ Order: whether the current leader node
-
CORE_PEER_PROFILE_ENABLED: there is a profile service in the peer node
-
CORE_PEER_TLS_CERT_FILE: certificate file path
-
CORE_PEER_TLS_KEY_FILE: private key file path
-
CORE_PEER_TLS_ROOTCERT_FILE: root certificate file path
4 related configuration files
Set docker compose The yaml file is modified as follows. It mainly needs to modify the container name, Mount directory and network port number.
version: '2'
volumes:
orderer.test.com:
peer0.org1.test.com:
networks:
test:
services:
orderer.test.com:
container_name: orderer.test.com
image: hyperledger/fabric-orderer:latest
environment:
- FABRIC_LOGGING_SPEC=INFO
- ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
- ORDERER_GENERAL_LISTENPORT=7050
- ORDERER_GENERAL_GENESISMETHOD=file
- ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
- ORDERER_GENERAL_LOCALMSPID=OrdererMSP
- ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
# enabled TLS
- ORDERER_GENERAL_TLS_ENABLED=true
- ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
- ORDERER_KAFKA_VERBOSE=true
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
working_dir: /opt/gopath/src/github.com/hyperledger/fabric
command: orderer
volumes:
- ./channel-artifacts/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
- ./crypto-config/ordererOrganizations/test.com/orderers/orderer.test.com/msp:/var/hyperledger/orderer/msp
- ./crypto-config/ordererOrganizations/test.com/orderers/orderer.test.com/tls:/var/hyperledger/orderer/tls
- orderer.test.com:/var/hyperledger/production/orderer
ports:
- 7050:7050
networks:
- test
peer0.orggo.test.com:
container_name: peer0.org1.test.com
image: hyperledger/fabric-peer:latest
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=solotest_test
- FABRIC_LOGGING_SPEC=INFO
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
- CORE_PEER_ID=peer0.org1.test.com
- CORE_PEER_ADDRESS=peer0.org1.test.com:7051
- CORE_PEER_LISTENADDRESS=0.0.0.0:7051
- CORE_PEER_CHAINCODEADDRESS=peer0.org1.test.com:7052
- CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.test.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.test.com:7051
- CORE_PEER_LOCALMSPID=Org1MSP
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.test.com/peers/peer0.org1.test.com/msp:/etc/hyperledger/fabric/msp
- ./crypto-config/peerOrganizations/org1.test.com/peers/peer0.org1.test.com/tls:/etc/hyperledger/fabric/tls
- peer0.org1.test.com:/var/hyperledger/production
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
ports:
- 7051:7051
- 7053:7053
networks:
- test
cli:
container_name: cli
image: hyperledger/fabric-tools:latest
tty: true
environment:
- GOPATH=/opt/gopath
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- FABRIC_LOGGING_SPEC=INFO
- GODEBUG=netdns=go
- CORE_PEER_ID=cli
- CORE_PEER_ADDRESS=peer0.org1.test.com:7051
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.test.com/peers/peer0.org1.test.com/tls/server.crt
- CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.test.com/peers/peer0.org1.test.com/tls/server.key
- CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.test.com/peers/peer0.org1.test.com/tls/ca.crt
- CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.test.com/users/Admin@org1.test.com/msp
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
volumes:
- /var/run/:/host/var/run/
- ./chaincode:/opt/gopath/src/github.com/chaincode
- ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
networks:
- test
5 start docker compose
Start docker compose with the following command and start the daemon with - d.
docker-compose up -d
If it is started successfully, it will output:
Creating network "solotest_test" with the default driver Creating cli ... done Creating peer0.org1.test.com ... done Creating orderer.test.com ... done
Use the following command to check whether the network is started normally:
# Execute the following command under the current file directory
docker-compose ps
Name Command State Ports
--------------------------------------------------------------------------------
cli /bin/sh Up
orderer.test.com orderer Up 0.0.0.0:7050->7050/tcp
peer0.org1.test.com peer node start Up 0.0.0.0:7051->7051/tcp,
0.0.0.0:7053->7053/tcp
Note: after that, I changed all tests to example, such as orderer test. com-orderer. example. The actual operation does not need to be changed. Www. 68mn.
Channel operation
This section mainly introduces the peer channel command. The peer channel command is mainly used to create channels and join channels for nodes.
1 create channel
Use the docker exec command to enter the client container.
docker exec -it cli bash
Use the following command to create a channel in the client container.
peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem
- -o. -- orderer: the address of the orderer node
- -c. -- channelid: the ID of the channel to be created must be lower case and within 250 characters
- -f. - file: the channel file generated by configtxgen, which is used to submit to the orderer
- -t. -- timeout: timeout length of channel creation. The default value is 5s
- --tls: whether tls encryption is used for communication
- --cafile: the tls certificate file in pem format of the current orderer node. The absolute path should be used
- The path of tls certificate file in PEM format of orderer node is: crypto config / ordererorganizations / test com/orderers/orderer. test. com/msp/tlscacerts/tlsca. test. com-cert.pem
Use the ls command to view the generated file,
ls
channel-artifacts crypto mychannel.block
2 join channel
Adding each node of each organization to the channel requires a client. A client can only connect to one peer node at the same time. If you want the client to connect to other nodes, you must modify the relevant environment variables in the current client. We are currently at docker compose The cli configured in the yaml file is connected to the peer0 node of the Go organization.
Use the following command to join the peer0 node to the channel.
peer channel join -b mychannel.block
-b. -- blockpath: block file path (channel file generated by peer channel create command)
The output is as follows. At this time, peer0 of Org1 organization has been added to the channel.
-> INFO 002 Successfully submitted proposal to join channel
3 Update anchor node
Use the following command to update the anchor node.
peer channel update -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
-
-o. -- orderer: the address of the orderer node
-
-c. -- channelid: the ID of the channel to be created must be lower case and within 250 characters
-
-f. - file: anchor node file generated by cryptogen
exit Quit. When you're done, go back to solotest catalogue
Install call smart contract
Starting from hyperledger fabric version 2.0, the chain code installation command and process are slightly different from those in the previous version. The chain code installation command is introduced into lifecycle from version 2.0. The overall installation process can be divided into four steps: packaging, installation, agency approval and chain code submission.
1. Package smart contract
First, we use the following command to create a folder named chaincode under the project path
mkdir chaincode
Then use the following command to copy the smart contract of the official example to the chain code folder we just created
cd ~/hyperledger/fabric-samples/chaincode cp -r sacc ~/hyperledger/solotest/chaincode
We go back to the client container and enter the directory where the chain code is located
cd /opt/gopath/src/github.com/chaincode/sacc
Use the following command to set the go language dependency package
go env -w GOPROXY=https://goproxy.cn,direct go env -w GO111MODULE=on go mod init sacc go mod tidy go mod vendor go env -w GO111MODULE=off
Go back to the peer directory
cd /opt/gopath/src/github.com/hyperledger/fabric/peer
The Fabric life cycle packages the chaincode in an easy to read tar file to facilitate the coordination of installations across multiple organizations. Use the following command to package the chain code
peer lifecycle chaincode package sacc.tar.gz \ --path github.com/chaincode/sacc/ \ --label sacc_1
- sacc.tar.gz is the package file name
- Path: smart contract path
- lang: smart contract language, supporting Golang, NodeJs and Java
- Label: smart contract label, which can mark the version of chaincode source code
Use the ls command to view the generated compressed file
ls
channel-artifacts crypto sacc.tar.gz
2. Install smart contract
Use the following command to install the smart contract.
peer lifecycle chaincode install sacc.tar.gz
Use the following command to query the installed chain code.
peer lifecycle chaincode queryinstalled
Installed chaincodes on peer: Package ID: sacc_1:0b6ac7f5af4b129ec288b71b14dcd05e55b04f252cfabb7747781332bd073e96, Label: sacc_1
According to the default policy, more than half of the organizations need to approve the chain code before submitting the chain code to the channel. Use the following command to apply to the organization for approval.
peer lifecycle chaincode approveformyorg --channelID mychannel --name sacc --version 1.0 --init-required --package-id sacc_1:0b6ac7f5af4b129ec288b71b14dcd05e55b04f252cfabb7747781332bd073e96 --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
- Does tls start tls
- ca certificate path of cafile orderer
- channelID smart contract installed channel
- Name contract name
- Version contract version
- Whether the init required contract must execute init
- Package ID queryinstalled query contract ID
- sequence serial number
- waitForEvent waits for the transaction submitted by peer to return
4. Check whether the smart contract is ready
The life cycle endorsement policy of the contract is defined in the channel configuration and requires the consent of most organizations. Use the following command to view it.
peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name sacc --version 1.0 --init-required --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --output json
"approvals": {
"Org1MSP": true
}
5. Submit smart contract definition
peer lifecycle chaincode commit -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --channelID mychannel --name sacc --version 1.0 --sequence 1 --init-required
- Peer addresses node addresses
- tlsRootCertFiles node ca root certificate path (– peeraddress -- tlsRootCertFiles can use multiple nodes to deploy contracts to these nodes)
6. Call smart contract
Use the following command to call the Init method of chaincode to set the initial value:
peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n sacc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --isInit -c '{"Args":["name","ab"]}' --waitForEvent
Use the following command to query the chain code.
peer chaincode query -C mychannel -n sacc -c '{"Args":["get","name"]}'
Output:
ab