Centos7 Fabric2.4 网络搭建
Posted Big. boss
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Centos7 Fabric2.4 网络搭建相关的知识，希望对你有一定的参考价值。
提示：上一篇文章讲到用cryptogen为组织内的orderer、peer颁发证书后，再用docker启动orderer和peer，接着是创建通道。
目录
2.2 使用 osnadmin CLI 将 orderer 添加到通道
前言
第一部分：Centos7 Fabric2.4 网络搭建（一）_Big. boss的博客-CSDN博客
提示：用的是官方的例子学习搭建自己的网络，本次是用cryptogen生成证书，单机多节点部署
一、主脚本中创建通道
为了简化channel创建过程并增强channel的隐私性和可伸缩性，现在可以创建应用程序channel（涉及资产的交易发生的地方），而无需首先创建由orderer管理的“system channel”。本案例是在没有system channel的情况下创建新channel，方法是使用configtxgen工具创建genesis块，并使用osnadmin CLI（它运行在每个orderer节点公开的REST API上）将orderer节点连接到channel。这个过程允许orderer节点根据需要加入（或离开）任意数量的channel，类似于peer节点可以参与多个channel的方式。
# Step4 创建通道
function createChannel()
# 如果网络尚未启动，请启动网络
bringUpNetwork="false"
if ! $CONTAINER_CLI info > /dev/null 2>&1 ; then
fatalln "$CONTAINER_CLI network is required to be running to create a channel"
fi
# 检查是否所有容器是否准备好
CONTAINERS=($($CONTAINER_CLI ps | grep hyperledger/ | awk 'print $2'))
len=$(echo $#CONTAINERS[@])
if [[ $len -ge 8 ]] && [[ ! -d "organizations/peerOrganizations" ]]; then
echo "Bringing network down to sync certs with containers"
networkDown
fi
[[ $len -lt 8 ]] || [[ ! -d "organizations/peerOrganizations" ]] && bringUpNetwork="true" || echo "Network Running Already"
if [ $bringUpNetwork == "true" ]; then
infoln "Bringing up network"
networkUp
fi
# 现在运行创建频道的脚本。此脚本使用configtxgen一次性创建通道创建事务和锚节点对等更新
scripts/createChannel.sh $CHANNEL_NAME $CLI_DELAY $MAX_RETRY $VERBOSE
二、createChannel.sh
2.1 创建通道创世区块
创建新通道的过程首先为通道生成创世块，稍后将在请求中提交给orderer。只需要一个orderer需要创建创世块，并且可以与通道上的其他成员进行带外共享，这些成员可以检查它以确保他们同意通道配置，然后由排序服务中的每个排序者使用。
FABRIC_CFG_PATH=$PWD/configtx
## Create channel genesis block
infoln "Generating channel genesis block '$CHANNEL_NAME.block'"
createChannelGenesisBlock
# 函数 - 创建通道创世区块
createChannelGenesisBlock()
# 搜索configtxgen命令，判断是否存在此二进制文件，若不存在，打印错误信息，程序终止
which configtxgen
if [ "$?" -ne 0 ]; then
fatalln "configtxgen tool not found."
fi
set -x #脚本调试，会将下面执行的命令输出到屏幕上
# 创建创世区块：生成创世区块mychannel.block文件，根据配置文件../configtx/configtx.yaml来创建Orderer系统通道的创世块
configtxgen -profile TwoOrgsApplicationGenesis -outputBlock ./channel-artifacts/$CHANNEL_NAME.block -channelID $CHANNEL_NAME
res=$?
set +x; 2>/dev/null
verifyResult $res "Failed to generate channel configuration transaction..."
涉及到一个重要的文件configtx.yaml，详细内容参考Hyperledger Fabric 配置文件解析——configtx.yaml_Big. boss的博客-CSDN博客
与Fabric2.2流程不同：
1.不再需要系统通道：除了代表一个额外步骤的系统通道的建立，创建了一个额外的管理层，对于某些用例没有体统任何切实的好处。
2.不再需要联盟：在configtx.yaml不再需要定义一组组织（“consortium”），允许在特定的orderer上创建通道。新的流程中，所有的通道都是application channels，不再需要创建通道的组织列表这个概念。任何一组组织都可以聚集在一起并使用一组定义的排序节点来创建通道。
3.简化orderer节点创建过程：在创建orderer节点之前，系统通道的genesis块不再需要，admin现在可以专注于基础设置的过程，并在加入特定application channel之前确保其节点正常工作。
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
# 组织名称
Name: OrdererOrg
# ID to load the MSP definition as
# 组织ID，ID是引用组织的关键
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
# 组织的MSP证书路径
MSPDir: ../organizations/ordererOrganizations/hmw.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
# 定义本层级的组织策略，其权威路径为 /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer0.hmw.com:7050
- orderer1.hmw.com:7052
- orderer2.hmw.com:7054
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
MSPDir: ../organizations/peerOrganizations/org1.hmw.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
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')"
- &Org2
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org2MSP
# ID to load the MSP definition as
ID: Org2MSP
MSPDir: ../organizations/peerOrganizations/org2.hmw.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org2MSP.admin', 'Org2MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org2MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org2MSP.peer')"
################################################################################
#
# SECTION: Capabilities
#
# - This section defines the capabilities of fabric network. This is a new
# concept as of v1.1.0 and should not be utilized in mixed networks with
# v1.0.x peers and orderers. Capabilities define features which must be
# present in a fabric binary for that binary to safely participate in the
# fabric network. For instance, if a new MSP type is added, newer binaries
# might recognize and validate the signatures from this type, while older
# binaries without this support would be unable to validate those
# transactions. This could lead to different versions of the fabric binaries
# having different world states. Instead, defining a capability for a channel
# informs those binaries without this capability that they must cease
# processing transactions until they have been upgraded. For v1.0.x if any
# capabilities are defined (including a map with all capabilities turned off)
# then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
# V2_0 capability ensures that orderers and peers behave according
# to v2.0 channel capabilities. Orderers and peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 capability.
# Prior to enabling V2.0 channel capabilities, ensure that all
# orderers and peers on a channel are at v2.0.0 or later.
V2_0: true
# Orderer capabilities apply only to the orderers, and may be safely
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
# V2_0 orderer capability ensures that orderers behave according
# to v2.0 orderer capabilities. Orderers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 orderer capability.
# Prior to enabling V2.0 orderer capabilities, ensure that all
# orderers on channel are at v2.0.0 or later.
V2_0: true
# Application capabilities apply only to the peer network, and may be safely
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
# V2_0 application capability ensures that peers behave according
# to v2.0 application capabilities. Peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 application capability.
# Prior to enabling V2.0 application capabilities, ensure that all
# peers on channel are at v2.0.0 or later.
V2_0: true
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
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
################################################################################
#
# SECTION: Orderer
#
# - This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start
# 定义order共识机制
OrdererType: etcdraft
# Addresses used to be the list of orderer addresses that clients and peers
# could connect to. However, this does not allow clients to associate orderer
# addresses and orderer organizations which can be useful for things such
# as TLS validation. The preferred way to specify orderer addresses is now
# to include the OrdererEndpoints item in your org definition
Addresses:
- orderer0.hmw.com:7050
- orderer1.hmw.com:7052
- orderer2.hmw.com:7054
EtcdRaft:
Consenters:
- Host: orderer0.hmw.com
Port: 7050
ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer0.hmw.com/tls/server.crt
ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer0.hmw.com/tls/server.crt
- Host: orderer1.hmw.com
Port: 7052
ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer1.hmw.com/tls/server.crt
ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer1.hmw.com/tls/server.crt
- Host: orderer2.hmw.com
Port: 7054
ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer2.hmw.com/tls/server.crt
ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer2.hmw.com/tls/server.crt
# Batch Timeout: The amount of time to wait before creating a batch
# 区块生成超时时间
BatchTimeout: 2s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
# 区块消息数量
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
# 区块绝对最大字节数
AbsoluteMaxBytes: 99 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
# 建议消息字节数
PreferredMaxBytes: 512 KB
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Orderer policies, their canonical path is
# /Channel/Orderer/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# BlockValidation specifies what signatures must be included in the block
# from the orderer for the peer to validate it.
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
################################################################################
#
# CHANNEL
#
# This section defines the values to encode into a config transaction or
# genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Policies:
# Who may invoke the 'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Who may invoke the 'Broadcast' API
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# By default, who may modify elements at this config level
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# Capabilities describes the channel level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<: *ChannelCapabilities
################################################################################
#
# Profile
#
# - Different configuration profiles may be encoded here to be specified
# as parameters to the configtxgen tool
#
################################################################################
Profiles:
TwoOrgsApplicationGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities: *ApplicationCapabilities
2.2 使用 osnadmin CLI 将 orderer 添加到通道
现在已经创建了 Genesis 块，接收 osnadmin 通道连接命令命令的第一订购节点有效地“激活”通道，尽管频道未完全运行，直到建立了仲裁频率（如果您的策略列出了三个同意，则至少一个节点总共两个，必须使用osnadmin通道连接命令加入）
# 函数 - 激活通道
createChannel()
# 调用脚本 envVar.sh中的函数setGlobals，为org1或org2的peer节点设置环境变量，参数01对应的是org1，02对应org2
# 设置环境变量为org1
setGlobals 01
# Poll in case the raft leader is not set yet
local rc=1
local COUNTER=1
# 创建通道若未成功，可尝试5次
while [ $rc -ne 0 -a $COUNTER -lt $MAX_RETRY ] ; do
sleep $DELAY
set -x
# 创建通道，将执行结果信息记录到log.txt文件中
infoln "Orderer0 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o localhost:7051 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer1 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o localhost:7053 --ca-file "$ORDERER_CA" --client-cert "$ORDERER1_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER1_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer2 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o localhost:7055 --ca-file "$ORDERER_CA" --client-cert "$ORDERER2_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER2_ADMIN_TLS_PRIVATE_KEY" >&log.txt
res=$?
set +x; 2>/dev/null
let rc=$res
COUNTER=$(expr $COUNTER + 1)
done
# 打印log.txt，即打印创建通道结果信息
cat log.txt
# 调用脚本 envVar.sh 中的函数verifyResult，用来验证上面执行的命令是否报错，如果报错，则打印错误信息，程序终止
verifyResult $res "Channel creation failed"
成功后，orderer将加入带有leader height 为 1 的通道中，因为这个orderer是从创世区块加入的，所以显示 status 的状态时 "active"。并且orderer是通道的consenter，所以consensusRelation是"consenter"。
2.3 peer 加入通道
## Join all the peers to the channel
infoln "Joining peer0-org1 to the channel..."
joinChannel 01
infoln "Joining peer1-org1 to the channel..."
joinChannel 11
infoln "Joining peer0-org2 to the channel..."
joinChannel 02
infoln "Joining peer1-org2 to the channel..."
joinChannel 12
# joinChannel ORG
joinChannel()
FABRIC_CFG_PATH=$PWD/config/
ORG=$1
# 根据传递的参数设置环境变量，切换组织使用
setGlobals $ORG
local rc=1
local COUNTER=1
# peer节点加入通道若未成功，可尝试5次
while [ $rc -ne 0 -a $COUNTER -lt $MAX_RETRY ] ; do
sleep $DELAY
set -x
# 将节点加入通道，将执行结果信息记录到log.txt文件中
peer channel join -b $BLOCKFILE >&log.txt
res=$?
set +x; 2>/dev/null
let rc=$res
COUNTER=$(expr $COUNTER + 1)
done
cat log.txt
verifyResult $res "After $MAX_RETRY attempts, peer0.org$ORG has failed to join channel '$CHANNEL_NAME' "
2.4 设置锚节点
最后，在组织将其对等节点加入频道后，他们应至少选择其中一个对等节点成为锚节点。为了利用私有数据和服务发现等功能，需要锚节点。每个组织都应该在一个通道上设置多个锚节点以实现冗余。每个组织的锚节点的端点信息都包含在通道配置中。每个通道成员都可以通过更新通道来指定它们的锚节点。
## Set the anchor peers for each org in the channel
infoln "Setting anchor peer for org1..."
setAnchorPeer 01
infoln "Setting anchor peer for org2..."
setAnchorPeer 02
# 函数 - 设置锚节点
setAnchorPeer()
ORG=$1
$CONTAINER_CLI exec cli ./scripts/setAnchorPeer.sh $ORG $CHANNEL_NAME
每个通道成员都可以通过更新通道来指定它们的锚节点。我们将使用configtxlator 来为Org1 和Org2更新通道配置。
Org1设置环境变量
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=$PWD/organizations/peerOrganizations/org1.hmw.com/users/Admin@org1.hmw.com/msp
export CORE_PEER_ADDRESS=localhost:8051通过以下命令可以获取通道配置
infoln "Fetching the most recent configuration block for the channel"
set -x
# 获取通道配置
peer channel fetch config config_block.pb -o orderer0.hmw.com:7050 --ordererTLSHostnameOverride orderer0.hmw.com -c $CHANNEL --tls --cafile "$ORDERER_CA"
set +x; 2>/dev/null
res=$?
if [ $res -ne 0 ]; then
fatalln "Failed to fetch the most recent configuration block..."
fi由于最近的通道配置块是信道创世纪块，因此命令从通道返回块0
我们现在可以开始使用configtxlator工具开始使用通道配置。第一步是将来自protobuf的块解码为可以读取和编辑的json对象。我们还脱离了不必要的块数据，仅留下了通道配置。
# 将配置块protobuf格式转成json格式
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
jq .data.data[0].payload.data.config config_block.json >"$OUTPUT"这些命令将通道配置块转换为一个简化json，config.json，将作为我们更新的基准。
可以使用jq工具将org1锚节点添加到通道配置
set -x
# Modify the configuration to append the anchor peer
# 将锚节点添加至配置文件中
jq '.channel_group.groups.Application.groups.'$CORE_PEER_LOCALMSPID'.values += "AnchorPeers":"mod_policy": "Admins","value":"anchor_peers": ["host": "'$HOST'","port": '$PORT'],"version": "0"' $CORE_PEER_LOCALMSPIDconfig.json > $CORE_PEER_LOCALMSPIDmodified_config.json
set +x; 2>/dev/null在此步骤之后，我们在modified_config.json文件中以json格式更新了频道配置的更新版本。我们现在可以将原始和修改的通道配置转换回protobuf格式并计算它们之间的差异
# 将原始和修改的通道配置都转换回protobuf格式，并计算它们之间的差异
configtxlator proto_encode --input "$ORIGINAL" --type common.Config --output original_config.pb
configtxlator proto_encode --input "$MODIFIED" --type common.Config --output modified_config.pb
configtxlator compute_update --channel_id "$CHANNEL" --original original_config.pb --updated modified_config.pb --output config_update.pb
新的protobuf文件叫config_update.pb，包含了应用于通道配置的锚节点更新，我们可以在事务信封中包装配置更新以创建通道配置更新事务
# 将配置更新包装在交易Envelope中，以创建通道配置更新交易
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
echo '"payload":"header":"channel_header":"channel_id":"'$CHANNEL'", "type":2,"data":"config_update":'$(cat config_update.json)'' | jq . >config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output "$OUTPUT"
set +x; 2>/dev/null我们可以通过peer channel update指令提供新的通道配置来增加锚节点。
因为我们正在更新仅影响org1的通道配置的一部分，因此其他频道成员不需要批准通道更新
peer channel update -o orderer0.hmw.com:7050 --ordererTLSHostnameOverride orderer0.hmw.com -c $CHANNEL_NAME -f $CORE_PEER_LOCALMSPIDanchors.tx --tls --cafile "$ORDERER_CA" >&log.txt同样道理，设置好环境变量，为Org2添加锚节点
可以通过以下命令确认通道已经更新：
export FABRIC_CFG_PATH=$PWD/config/
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=$PWD/organizations/peerOrganizations/org1.hmw.com/users/Admin@org1.hmw.com/msp
export CORE_PEER_ADDRESS=localhost:8051
peer channel getinfo -c mychannel通过上述更新锚节点，向创世区块添加两个通道配置文件来更新通道，所以通道的区块高度变成3并且哈希值也被更新
相关代码请参考：https://blog.csdn.net/humingwei11/article/details/124128401
遇到的问题总结
1.Error: can't read the block: &SERVICE_UNAVAILABLE
这个问题困扰我好久，原来是因为在加入通道的时候，没有把所有的orderer加入通道 。2
set -x
# 创建通道，将执行结果信息记录到log.txt文件中
infoln "Orderer0 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o orderer0.hmw.com:7051 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer1 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o orderer1.hmw.com:7053 --ca-file "$ORDERER_CA" --client-cert "$ORDERER1_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER1_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer2 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/$CHANNEL_NAME.block -o orderer2.hmw.com:7055 --ca-file "$ORDERER_CA" --client-cert "$ORDERER2_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER2_ADMIN_TLS_PRIVATE_KEY" >&log.txt
res=$?
set +x; 2>/dev/null2.在orderer加入通道中，-o 我写localhost 出现tls证书握手失败
原因是之前在crypto-config-orderer.yaml中，Specs中忘记在每一个Hostname下加SANS
centos7搭建Fabric基础环境
一、首先升级centos最新内核
参考https://www.cnblogs.com/sky-cheng/p/12146054.html
二、卸载旧版本docker
[root@localhost ~]# rpm -qa|grep docker docker-client-1.13.1-103.git7f2769b.el7.centos.x86_64 docker-common-1.13.1-103.git7f2769b.el7.centos.x86_64 docker-1.13.1-103.git7f2769b.el7.centos.x86_64
[root@localhost ~]# yum remove docker [root@localhost ~]# yum remove docker-client [root@localhost ~]# yum remove docker-common
三、安装所需要的包
[root@localhost ~]# yum install -y yum-utils [root@localhost ~]# yum install -y device-mapper-persistent-data [root@localhost ~]# yum install -y lvm2
四、添加docker-ce的yum源
[root@localhost ~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo 已加载插件：fastestmirror adding repo from: https://download.docker.com/linux/centos/docker-ce.repo grabbing file https://download.docker.com/linux/centos/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo repo saved to /etc/yum.repos.d/docker-ce.repo [root@localhost ~]#
五、安装docker-ce
root@localhost ~]# yum install -y docker-ce
六、查看版本
[root@localhost ~]# docker version Client: Docker Engine - Community Version: 19.03.5 API version: 1.40 Go version: go1.12.12 Git commit: 633a0ea Built: Wed Nov 13 07:25:41 2019 OS/Arch: linux/amd64 Experimental: false Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? [root@localhost ~]#
七、安装docker-compose
根据github上最新的版本地址 https://github.com/docker/compose/releases，可以看到当前最新版本的下载地址
[root@localhost docker-compose]# mkdir /usr/local/src/docker-compose [root@localhost docker-compose]# cd /usr/local/src/docker-compose/ [root@localhost docker-compose]# wget https://github.com/docker/compose/releases/download/1.25.1-rc1/docker-compose-Linux-x86_64 [root@localhost docker-compose]# mv docker-compose-Linux-x86_64 /usr/local/bin/docker-compose [root@localhost docker-compose]# chmod +x /usr/local/bin/docker-compose [root@localhost docker-compose]# docker-compose version docker-compose version 1.25.1-rc1, build d92e9bee docker-py version: 4.1.0 CPython version: 3.7.4 OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019 [root@localhost docker-compose]#
八、安装go语言环境
[root@localhost docker-compose]# mkdir /usr/local/src/golang [root@localhost docker-compose]# cd /usr/local/src/golang/ [root@localhost golang]# curl -O https://storage.googleapis.com/golang/go1.9.3.linux-amd64.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 100M 100 100M 0 0 2182k 0 0:00:47 0:00:47 --:--:-- 2162k [root@localhost golang]# [root@localhost golang]# mv go/ /usr/local/ [root@localhost go]# echo "export PATH=$PATH:/usr/local/go/bin" >> /etc/profile [root@localhost go]# echo "export GOPATH=/opt/gopath" >> /etc/profile [root@localhost go]# source /etc/profile [root@localhost go]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/dell/srvadmin/bin:/opt/dell/srvadmin/sbin:/home/mysql-5.7.26/bin/:/root/bin:/usr/local/go/bin [root@localhost go]# go version go version go1.9.3 linux/amd64 [root@localhost go]#
至此整个Fabric所需的基础环境都已经搭建起来了。
以上是关于Centos7 Fabric2.4 网络搭建的主要内容，如果未能解决你的问题，请参考以下文章
超级账本区块链Fabric2.4.4版本搭建过程（完整过程）
hyperledger fabric v2.4环境搭建及区块链项目开发