提示：记录自己学习Fabric的过程
目录
前言
如何在Centos7 上部署 Fabric
请参考Centos7部署Fabric2.3_Big. boss的博客-CSDN博客
提示：用的是官方的例子学习搭建自己的网络，本次是用cryptogen生成证书，单机多节点部署
一、设计联盟
联盟域名：hmw.com
设计两个组织：org1.hmw.com、org2.hmw.com
二、设计联盟成员
2.1 三个orderer节点
| 域名 | 配置 | 端口 |
| orderer0.hmw.com | ORDERER_GENERAL_LISTENPORT=7050 ORDERER_ADMIN_LISTENADDRESS=0.0.0.0:7051 ORDERER_OPERATIONS_LISTENADDRESS=orderer0.hmw.com:9443 |
7050:7050 7051:7051 9443:9443 |
| orderer1.hmw.com | ORDERER_GENERAL_LISTENPORT=7052 ORDERER_ADMIN_LISTENADDRESS=0.0.0.0:7053 ORDERER_OPERATIONS_LISTENADDRESS=orderer1.hmw.com:9444 |
7052:7052 7053:7053 9444:9444 |
| orderer2.hmw.com | ORDERER_GENERAL_LISTENPORT=7054 ORDERER_ADMIN_LISTENADDRESS=0.0.0.0:7055 ORDERER_OPERATIONS_LISTENADDRESS=orderer2.hmw.com:9445 |
7054:7054 7055:7055 9445:9445 |
2.2 每个组织设计两个peer节点
| 域名 | 配置 | 端口 |
| peer0.org1.hmw.com | CORE_PEER_ADDRESS=peer0.org1.hmw.com:8051 CORE_PEER_LISTENADDRESS=0.0.0.0:8051 CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.hmw.com:8051 CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.hmw.com:8051 CORE_PEER_CHAINCODEADDRESS=peer0.org1.hmw.com:8052 CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:8052 CORE_OPERATIONS_LISTENADDRESS=peer0.org1.hmw.com:9446 |
8051:8051 9446:9446 |
| peer1.org1.hmw.com | CORE_PEER_ADDRESS=peer1.org1.hmw.com:8053 CORE_PEER_LISTENADDRESS=0.0.0.0:8053 CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.hmw.com:8053 CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.hmw.com:8053 CORE_PEER_CHAINCODEADDRESS=peer1.org1.hmw.com:8054 CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:8054 CORE_OPERATIONS_LISTENADDRESS=peer1.org1.hmw.com:9447 |
8053:8053 9447:9447 |
| peer0.org2.hmw.com | CORE_PEER_ADDRESS=peer0.org2.hmw.com:8055 CORE_PEER_LISTENADDRESS=0.0.0.0:8055 CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org2.hmw.com:8055 CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org2.hmw.com:8055 CORE_PEER_CHAINCODEADDRESS=peer0.org2.hmw.com:8056 CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:8056 CORE_OPERATIONS_LISTENADDRESS=peer0.org2.hmw.com:9448 |
8055:8055 9448:9448 |
| peer1.org2.hmw.com | CORE_PEER_ADDRESS=peer1.org2.hmw.com:8057 CORE_PEER_LISTENADDRESS=0.0.0.0:8057 CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org2.hmw.com:8057 CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org2.hmw.com:8057 CORE_PEER_CHAINCODEADDRESS=peer1.org2.hmw.com:8058 CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:8058 CORE_OPERATIONS_LISTENADDRESS=peer1.org2.hmw.com:9449 |
8057:8057 9449:9449 |
因为用的是cryprtogen，所以没有CA。
三、设计crypto-config.yaml
crypto-config.yaml，用于生成相关组织的私钥和证书
3.1 crypto-config-org1.yaml
# ---------------------------------------------------------------------------
# "PeerOrgs" - 管理对等节点的组织的定义
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# 定义Org1组织
# ---------------------------------------------------------------------------
- Name: Org1 #组织名称
Domain: org1.hmw.com #域名称
EnableNodeOUs: true
# 如果设置了 EnableNodeOUs ，就在msp下生成config.yaml文件
# ---------------------------------------------------------------------------
# "Template"
# ---------------------------------------------------------------------------
# Template是按照Template模板生成多个文件，数量由Count决定，起始编号由Start决定
# 如下配置会在 organizations/peerOrganizations/org1.hmw.com/peers目录下，
# 生成两个文件，分别是 peer0.org1.hmw.com 和 peer1.org1.hmw.com
# 如果把Start注释去掉，那么会生成 peer5.org1.hmw.com 和 peer6.org1.hmw.com
Template: # 组织中peer节点的数目
Count: 2
SANS:
- localhost
# Start: 5
# Hostname: {
{.Prefix}}{
{.Index}} # default
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
# Users是生成除了Admin之外多少个user，数量由Count决定
# 对于orderer组织，这个值设置了也没有效果
# 如果配置会在 organizations/peerOrganizations/org1.hmw.com/users目录下，
# 生成两个文件，分别是[email protected]和[email protected]
# 如果改为2，那么会多一个[email protected]
Users:
Count: 1 #除Admin之外的用户账户数目
3.2 crypto-config-org2.yaml
同crypto-config-org1.yaml
3.3 crypto-config-orderer.yaml
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# ---------------------------------------------------------------------------
# "OrdererOrgs" - 管理orderer节点的组织的定义
# ---------------------------------------------------------------------------
OrdererOrgs: # 定义管理orderer节点的组织
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer #这个组织的名字叫 Orderer
Domain: hmw.com #这个组织的域名是 hmw.com
# 生成证书的时候，证书内会包含Name和Domain信息,orderer.hmw.com就是这个组织的地址
EnableNodeOUs: true
# ---------------------------------------------------------------------------
# "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.
# ---------------------------------------------------------------------------
# - Hostname: foo # implicitly "foo.org1.example.com"
# CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
# - Hostname: bar
# - Hostname: baz
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs for complete description
# ---------------------------------------------------------------------------
# 对于一个Spec来说，配置了CommonName，那么文件夹则命名为CommonName
# 如果没有配置CommonName，则文件名为：{
{.Hostname}}.{
{Domain}}
# 在下面的例子中,在 organizations/ordererOrganizations/hmw.com/orderers 目录下
# 则会产生两个文件orderer0.hmw.com、orderer1.hmw.com、orderer2.hmw.com，
# 如果没有加CommonName，则目录名为order.example.com与order5.example.comn
Specs:
- Hostname: orderer0
SANS:
- localhost
- Hostname: orderer1
SANS:
- localhost
- Hostname: orderer2
SANS:
- localhost
# CommonName: orderer0.hmw.com
#- Hostname: orderer1
# CommonName: orderer1.hmw.com
# Hostname: orderer2
# CommonName: orderer2.hmw.com
四、启动脚本
参考官方给的例子进行自我修改
# Step1 -> 检查二进制文件是否存在
function checkPrereqs() {
# 检查二进制文件和配置文件是否克隆下来
# 通过使用peer命令来检查fabric二进制文件是否存在
peer version > /dev/null 2>&1
# 如果二进制文件不存在 或 config目录不存在，则显示错误信息并退出
if [[ $? -ne 0 || ! -d "./config" ]]; then
errorln "Peer binary and configuration files not found.."
errorln
errorln "Follow the instructions in the Fabric docs to install the Fabric Binaries:"
errorln "https://hyperledger-fabric.readthedocs.io/en/latest/install.html"
exit 1
fi
# 用fabric tool 容器 查看网络和二进制的版本是否匹配你的docker镜像
LOCAL_VERSION=$(peer version | sed -ne 's/^ Version: //p')
DOCKER_IMAGE_VERSION=$(${CONTAINER_CLI} run --rm hyperledger/fabric-tools:latest peer version | sed -ne 's/^ Version: //p')
infoln "LOCAL_VERSION=$LOCAL_VERSION"
infoln "DOCKER_IMAGE_VERSION=$DOCKER_IMAGE_VERSION"
# 若fabric二进制文件版本与镜像版本不一致，则输出警告信息
if [ "$LOCAL_VERSION" != "$DOCKER_IMAGE_VERSION" ]; then
warnln "Local fabric binaries and docker images are out of sync. This may cause problems."
fi
# 若为版本为1.4及之前版本，则抛出错误信息（不支持1.4及之前版本）
for UNSUPPORTED_VERSION in $NONWORKING_VERSIONS; do
infoln "$LOCAL_VERSION" | grep -q $UNSUPPORTED_VERSION
if [ $? -eq 0 ]; then
fatalln "Local Fabric binary version of $LOCAL_VERSION does not match the versions supported by the test network."
fi
infoln "$DOCKER_IMAGE_VERSION" | grep -q $UNSUPPORTED_VERSION
if [ $? -eq 0 ]; then
fatalln "Fabric Docker image version of $DOCKER_IMAGE_VERSION does not match the versions supported by the test network."
fi
done
}
# Step2 -> 使用cryptogen创建组织及证书
function createOrgs() {
# 清除残留的证书文件夹
if [ -d "organizations/peerOrganizations" ]; then
rm -Rf organizations/peerOrganizations && rm -Rf organizations/ordererOrganizations
fi
# 使用 cryptogen 创建加密材料
if [ "$CRYPTO" == "cryptogen" ]; then
# 搜索cryptogen命令是否存在，存在则输出所在路径及别名，否则抛出错误信息，程序终止
which cryptogen
if [ "$?" -ne 0 ]; then
fatalln "cryptogen tool not found. exiting"
fi
infoln "Generating certificates using cryptogen tool"
infoln "Creating Org1 Identities"
set -x # 脚本调试命令，将会把下面命令打印到屏幕
# 生成组织org1且为其生成证书
cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"
res=$?
{ set +x; } 2>/dev/null # 关闭脚本调试命令，之后的命令不会打印到屏幕了
# 若创建组织生成证书失败，则抛出错误信息，程序终止
if [ $res -ne 0 ]; then
fatalln "Failed to generate certificates..."
fi
infoln "Creating Org2 Identities"
set -x
# 生成组织org2且为其生成证书
cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output="organizations"
res=$?
{ set +x; } 2>/dev/null
# 若创建组织生成证书失败，则抛出错误信息，程序终止
if [ $res -ne 0 ]; then
fatalln "Failed to generate certificates..."
fi
infoln "Creating Orderer Org Identities"
set -x
# 生成组织orderer且为其生成证书
cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output="organizations"
res=$?
{ set +x; } 2>/dev/null
# 若创建组织生成证书失败，则抛出错误信息，程序终止
if [ $res -ne 0 ]; then
fatalln "Failed to generate certificates..."
fi
fi
#infoln "Generating CCP files for Org1 and Org2" #生成调用nodejs SDK的相关区块配置文件。
# 生成通用连接配置文件（CCP）
# 执行脚本文件，生成通用连接配置文件，json与yaml文件格式
#./organizations/ccp-generate.sh
}
# 网络启动
function networkUp() {
# Step1 -> 检查文件和版本
checkPrereqs
# Step2 -> 使用cryptogen创建组织加密材料
if [ ! -d "organizations/peerOrganizations" ]; then
createOrgs
fi
COMPOSE_FILES="-f compose/${COMPOSE_FILE_BASE} -f compose/${CONTAINER_CLI}/${CONTAINER_CLI}-${COMPOSE_FILE_BASE}"
if [ "${DATABASE}" == "couchdb" ]; then
COMPOSE_FILES="${COMPOSE_FILES} -f compose/${COMPOSE_FILE_COUCH} -f compose/${CONTAINER_CLI}/${CONTAINER_CLI}-${COMPOSE_FILE_COUCH}"
fi
# Step3 -> docker启动peer、orderer
DOCKER_SOCK="${DOCKER_SOCK}" ${CONTAINER_CLI_COMPOSE} ${COMPOSE_FILES} up -d 2>&1
$CONTAINER_CLI ps -a
if [ $? -ne 0 ]; then
fatalln "Unable to start network"
fi
# Step4 -> 创建通道
#createChannel
}五、自我总结
cryptogen是 fabric 产生证书的工具，但是这个产生的是静态。和 cryptogen 工具对等的就是 CA服务，CA就是一种动态的证书生产方式，一般来说，cryptogen 用于开发和测试阶段，在实际生产中，还是需要用CA服务来动态分配证书。
本次 cryptogen 目录结构如下：
cryptogen配合crypto-config.yaml 文件来为网络中的实体颁发证书和密钥。
cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"通过上述脚本会在 organizations 文件夹底下生成 orderer 和 peer 各自的文件夹，里面包含各自组织的成员和相关证书。每个组织下都有ca、tlsca、msp、orderers（或者peers），users这五个文件夹，通过tree指令可以查看具体文件情况。
5.1 ordererOrganizations
现在具体看ordererOrganizations文件夹里都有哪些东西。
./ordererOrganizations/
└── hmw.com #组织根域名
├── ca #存放组织根证书以及私钥
│ ├── ca.hmw.com-cert.pem #组织的根证书，自签名
│ └── priv_sk #私钥
├── msp #存放该组织的身份信息
│ ├── admincerts #组织管理员
│ ├── cacerts #组织的根证书
│ │ └── ca.hmw.com-cert.pem #组织的根证书，与ca里面的一样
│ ├── config.yaml #配置文件中加了 EnableNodeOUs 参数生成的config.yaml文件，记录OrganizationalUnitIdentitifiers 信息，包括根证书位置和ID信息
│ └── tlscacerts #用于TLS的CA证书
│ └── tlsca.hmw.com-cert.pem #用于TLS的CA证书，自签名
├── orderers #存放所有orderer的身份信息
│ ├── orderer0.hmw.com #orderer0的信息，存放着msp和TLS
│ │ ├── msp
│ │ │ ├── admincerts #组织管理员
│ │ │ ├── cacerts #组织的根证书，与ca里面的一样
│ │ │ │ └── ca.hmw.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore #本节点的身份私钥，用来签名
│ │ │ │ └── priv_sk
│ │ │ ├── signcerts #验证本节点签名的证书，被根证书签名
│ │ │ │ └── orderer0.hmw.com-cert.pem
│ │ │ └── tlscacerts #TLS连接用的身份证书，与 msp.tlscacerts 保持一致
│ │ │ └── tlsca.hmw.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt #组织的根证书
│ │ ├── server.crt #验证本节点签名的证书，被根证书签名
│ │ └── server.key #本节点的身份私钥，用来签名
│ ├── orderer1.hmw.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ ├── cacerts
│ │ │ │ └── ca.hmw.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── priv_sk
│ │ │ ├── signcerts
│ │ │ │ └── orderer1.hmw.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.hmw.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ └── orderer2.hmw.com
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ │ └── ca.hmw.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore
│ │ │ └── priv_sk
│ │ ├── signcerts
│ │ │ └── orderer2.hmw.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.hmw.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── server.crt
│ └── server.key
├── tlsca #tls相关信息
│ ├── priv_sk #tls私钥
│ └── tlsca.hmw.com-cert.pem #tls证书
└── users #存放属于该组织的用户的实体
└── [email protected] #管理员用户的信息，其中包括msp证书和tls证书两类
├── msp
│ ├── admincerts
│ ├── cacerts #存放组织根证书，与CA目录里一致
│ │ └── ca.hmw.com-cert.pem
│ ├── config.yaml
│ ├── keystore #本用户的身份私钥，用来签名
│ │ └── priv_sk
│ ├── signcerts #验证本用户的身份验证证书，被根证书签名，要被某个Orderer认可，则必须放到该 Orderer 的msp/admincerts目录下
│ │ └── [email protected]
│ └── tlscacerts #TLS连接用的身份证书，与 msp.tlscacerts 保持一致
│ └── tlsca.hmw.com-cert.pem
└── tls
├── ca.crt #组织根证书
├── client.crt #管理员身份验证证书，被根证书签名
└── client.key #管理员的身份私钥，用来签名
5.2 peerOrganizations
peerOrganizations/ #peer组织
├── org1.hmw.com #第一个组织的所有身份证书
│ ├── ca #存放私钥与组织根证书
│ │ ├── ca.org1.hmw.com-cert.pem
│ │ └── priv_sk
│ ├── msp #msp信息与order组织类似
│ │ ├── admincerts
│ │ ├── cacerts
│ │ │ └── ca.org1.hmw.com-cert.pem
│ │ ├── config.yaml
│ │ └── tlscacerts
│ │ └── tlsca.org1.hmw.com-cert.pem
│ ├── peers #peers目录与order组织的orderers目录类似
│ │ ├── peer0.org1.hmw.com
│ │ │ ├── msp
│ │ │ │ ├── admincerts
│ │ │ │ ├── cacerts
│ │ │ │ │ └── ca.org1.hmw.com-cert.pem
│ │ │ │ ├── config.yaml
│ │ │ │ ├── keystore
│ │ │ │ │ └── priv_sk
│ │ │ │ ├── signcerts
│ │ │ │ │ └── peer0.org1.hmw.com-cert.pem
│ │ │ │ └── tlscacerts
│ │ │ │ └── tlsca.org1.hmw.com-cert.pem
│ │ │ └── tls
│ │ │ ├── ca.crt
│ │ │ ├── server.crt
│ │ │ └── server.key
│ │ └── peer1.org1.hmw.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.hmw.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── priv_sk
│ │ │ ├── signcerts
│ │ │ │ └── peer1.org1.hmw.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.hmw.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ ├── tlsca #存放tls相关的证书和私钥
│ │ ├── priv_sk
│ │ └── tlsca.org1.hmw.com-cert.pem
│ └── users
│ ├── [email protected]
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.hmw.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── priv_sk
│ │ │ ├── signcerts
│ │ │ │ └── [email protected]
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.hmw.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── client.crt
│ │ └── client.key
│ └── [email protected]
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ │ └── ca.org1.hmw.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore
│ │ │ └── priv_sk
│ │ ├── signcerts
│ │ │ └── [email protected]
│ │ └── tlscacerts
│ │ └── tlsca.org1.hmw.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── org2.hmw.com
├── ca
│ ├── ca.org2.hmw.com-cert.pem
│ └── priv_sk
├── msp
│ ├── admincerts
│ ├── cacerts
│ │ └── ca.org2.hmw.com-cert.pem
│ ├── config.yaml
│ └── tlscacerts
│ └── tlsca.org2.hmw.com-cert.pem
├── peers
│ ├── peer0.org2.hmw.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ ├── cacerts
│ │ │ │ └── ca.org2.hmw.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── priv_sk
│ │ │ ├── signcerts
│ │ │ │ └── peer0.org2.hmw.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org2.hmw.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ └── peer1.org2.hmw.com
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ │ └── ca.org2.hmw.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore
│ │ │ └── priv_sk
│ │ ├── signcerts
│ │ │ └── peer1.org2.hmw.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org2.hmw.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── server.crt
│ └── server.key
├── tlsca
│ ├── priv_sk
│ └── tlsca.org2.hmw.com-cert.pem
└── users
├── [email protected]
│ ├── msp
│ │ ├── admincerts
│ │ ├── cacerts
│ │ │ └── ca.org2.hmw.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore
│ │ │ └── priv_sk
│ │ ├── signcerts
│ │ │ └── [email protected]
│ │ └── tlscacerts
│ │ └── tlsca.org2.hmw.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── [email protected]
├── msp
│ ├── admincerts
│ ├── cacerts
│ │ └── ca.org2.hmw.com-cert.pem
│ ├── config.yaml
│ ├── keystore
│ │ └── priv_sk
│ ├── signcerts
│ │ └── [email protected]
│ └── tlscacerts
│ └── tlsca.org2.hmw.com-cert.pem
└── tls
├── ca.crt
├── client.crt
└── client.key
说明：
1、在一个组织内部（orderer的hmw.com，peer的org1.hmw.com或者org2.hmw.com），所有的admincerts是一样的，admin的私钥在Users的Admin文件夹下
2、在一个组织内部，所有的cacerts是一样的，ca的私钥在ca文件夹下
3、在一个组织内部，所有的tlscerts是一样的，且和tls文件夹下的ca.cert一样，tlsca的私钥在tlsca文件夹下。
对于peer、orderer以及users来说，msp/keystore下是私钥，msp/signcerts下是证书。tls下的server.key（peer下是client.key）和server.crt是私钥和证书
MSP证书说明：
- admincerts：admincerts：管理员证书，它比普通的证书有一些特殊的权限，比如对节点的修改或者配置等操作
- cacerts：里面放的是对这个颁发证书的ca是谁，里面放的是ca的公钥
- keystore：是这个节点msp的自己的私钥
- signcerts：里面放的是这个organization的ca给这个节点颁发的证书
- tlscacerts：里面放的是对这个节点TLS证书的ca是谁，里面放的是TLS ca的公钥
admincerts和signcerts都是签发之后的证书，只是他们的角色不同，admincerts对该节点有一些特殊的管理权限，但signcerts只是一个普通的certs
TLS证书解释：
- ca.crt：TLS安全认证过程的时候验证证书的ca
- server.crt：节点本身的TLS证书
- server.key：节点本身的TLS私钥
遇到的问题总结
1.我是在阿里云服务器上部署的fabric，在使用docker的时候发现命令按TAB键无法自动补全，
解决方案：
#安装bash-completion
yum install -y bash-completion
#刷新文件
source /usr/share/bash-completion/completions/docker
source /usr/share/bash-completion/bash_completion