提示：记录自己学习Fabric的过程

目录

前言

一、设计联盟

二、设计联盟成员

三、设计crypto-config.yaml

1.crypto-config-org1.yaml

2.crypto-config-org2.yaml

3.crypto-config-orderer.yaml

四、启动脚本

五、自我总结

5.1 ordererOrganizations

5.2peerOrganizations

遇到的问题总结

前言

如何在Centos7 上部署 Fabric

请参考Centos7部署Fabric2.3_Big. boss的博客-CSDN博客

提示：用的是官方的例子学习搭建自己的网络，本次是用cryptogen生成证书，单机多节点部署

一、设计联盟

联盟域名：hmw.com

设计两个组织：org1.hmw.com、org2.hmw.com

二、设计联盟成员

2.1 三个orderer节点

2.2 每个组织设计两个peer节点

因为用的是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.comTemplate: # 组织中peer节点的数目Count: 2SANS:- 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目录下，# 生成两个文件，分别是Admin@org1.hmw.com和User1@org1.hmw.com# 如果改为2，那么会多一个User2@org1.hmw.comUsers: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 #这个组织的名字叫 OrdererDomain: 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.comnSpecs:- Hostname: orderer0SANS:- localhost- Hostname: orderer1SANS:- localhost- Hostname: orderer2SANS:- 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" ]]; thenerrorln "Peer binary and configuration files not found.."errorlnerrorln "Follow the instructions in the Fabric docs to install the Fabric Binaries:"errorln "https://hyperledger-fabric.readthedocs.io/en/latest/install.html"exit 1fi# 用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" ]; thenwarnln "Local fabric binaries and docker images are out ofsync. This may cause problems."fi# 若为版本为1.4及之前版本，则抛出错误信息（不支持1.4及之前版本）for UNSUPPORTED_VERSION in $NONWORKING_VERSIONS; doinfoln "$LOCAL_VERSION" | grep -q $UNSUPPORTED_VERSIONif [ $? -eq 0 ]; thenfatalln "Local Fabric binary version of $LOCAL_VERSION does not match the versions supported by the test network."fiinfoln "$DOCKER_IMAGE_VERSION" | grep -q $UNSUPPORTED_VERSIONif [ $? -eq 0 ]; thenfatalln "Fabric Docker image version of $DOCKER_IMAGE_VERSION does not match the versions supported by the test network."fidone}# Step2 -> 使用cryptogen创建组织及证书function createOrgs() {# 清除残留的证书文件夹if [ -d "organizations/peerOrganizations" ]; thenrm -Rf organizations/peerOrganizations && rm -Rf organizations/ordererOrganizationsfi# 使用 cryptogen 创建加密材料if [ "$CRYPTO" == "cryptogen" ]; then# 搜索cryptogen命令是否存在，存在则输出所在路径及别名，否则抛出错误信息，程序终止which cryptogenif [ "$?" -ne 0 ]; thenfatalln "cryptogen tool not found. exiting"fiinfoln "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 ]; thenfatalln "Failed to generate certificates..."fiinfoln "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 ]; thenfatalln "Failed to generate certificates..."fiinfoln "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 ]; thenfatalln "Failed to generate certificates..."fifi#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" ]; thencreateOrgsfiCOMPOSE_FILES="-f compose/${COMPOSE_FILE_BASE} -f compose/${CONTAINER_CLI}/${CONTAINER_CLI}-${COMPOSE_FILE_BASE}"if [ "${DATABASE}" == "couchdb" ]; thenCOMPOSE_FILES="${COMPOSE_FILES} -f compose/${COMPOSE_FILE_COUCH} -f compose/${CONTAINER_CLI}/${CONTAINER_CLI}-${COMPOSE_FILE_COUCH}"fi# Step3 -> docker启动peer、ordererDOCKER_SOCK="${DOCKER_SOCK}" ${CONTAINER_CLI_COMPOSE} ${COMPOSE_FILES} up -d 2>&1$CONTAINER_CLI ps -aif [ $? -ne 0 ]; thenfatalln "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#存放属于该组织的用户的实体└── Admin@hmw.com#管理员用户的信息，其中包括msp证书和tls证书两类├── msp│ ├── admincerts│ ├── cacerts#存放组织根证书，与CA目录里一致│ │ └── ca.hmw.com-cert.pem│ ├── config.yaml│ ├── keystore#本用户的身份私钥，用来签名│ │ └── priv_sk│ ├── signcerts#验证本用户的身份验证证书，被根证书签名，要被某个Orderer认可，则必须放到该 Orderer 的msp/admincerts目录下│ │ └── Admin@hmw.com-cert.pem│ └── tlscacerts #TLS连接用的身份证书，与 msp.tlscacerts 保持一致│ └── tlsca.hmw.com-cert.pem└── tls├── ca.crt#组织根证书├── client.crt#管理员身份验证证书，被根证书签名└── client.key#管理员的身份私钥，用来签名

5.2peerOrganizations

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│ ├── Admin@org1.hmw.com│ │ ├── msp│ │ │ ├── admincerts│ │ │ ├── cacerts│ │ │ │ └── ca.org1.hmw.com-cert.pem│ │ │ ├── config.yaml│ │ │ ├── keystore│ │ │ │ └── priv_sk│ │ │ ├── signcerts│ │ │ │ └── Admin@org1.hmw.com-cert.pem│ │ │ └── tlscacerts│ │ │ └── tlsca.org1.hmw.com-cert.pem│ │ └── tls│ │ ├── ca.crt│ │ ├── client.crt│ │ └── client.key│ └── User1@org1.hmw.com│ ├── msp│ │ ├── admincerts│ │ ├── cacerts│ │ │ └── ca.org1.hmw.com-cert.pem│ │ ├── config.yaml│ │ ├── keystore│ │ │ └── priv_sk│ │ ├── signcerts│ │ │ └── User1@org1.hmw.com-cert.pem│ │ └── 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├── Admin@org2.hmw.com│ ├── msp│ │ ├── admincerts│ │ ├── cacerts│ │ │ └── ca.org2.hmw.com-cert.pem│ │ ├── config.yaml│ │ ├── keystore│ │ │ └── priv_sk│ │ ├── signcerts│ │ │ └── Admin@org2.hmw.com-cert.pem│ │ └── tlscacerts│ │ └── tlsca.org2.hmw.com-cert.pem│ └── tls│ ├── ca.crt│ ├── client.crt│ └── client.key└── User1@org2.hmw.com├── msp│ ├── admincerts│ ├── cacerts│ │ └── ca.org2.hmw.com-cert.pem│ ├── config.yaml│ ├── keystore│ │ └── priv_sk│ ├── signcerts│ │ └── User1@org2.hmw.com-cert.pem│ └── 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-completionyum install -y bash-completion#刷新文件source /usr/share/bash-completion/completions/dockersource /usr/share/bash-completion/bash_completion