章节目录
1.hyperledger-fabric 介绍和资料整理
2.服务环境准备
3.安装fabric 二进制源码程序
4.生成fabric身份信息文件（证书）
5.生成系统通道初始区块文件
6.启动配置网络节点 docker-compose启动文件
7.将组织加入通道
8.安装合约
configtx.yaml 详解
crypto-config.yaml配置详解
1. 相关配置文件介绍
-
crypto-config.yaml，用于生成相关组织的私钥和证书
-
configtx.yaml
- 对相关组织进行配置
- 配置orderer，用以生成orderer端初始化时所需的block（Genesis Block）
- 配置channel，用以生成创建channel时所需的tx文件
-
core.yaml，peer端的配置文件
-
orderer.yaml，orderer端的配置文件
-
docker-compose.yaml，用以配置fabric网络的相关容器
下文中所有的配置文件解析，都以 fabric-samples/first-network 中的配置来解析，如果需要可以克隆仓库：fabric-samples
2. 私钥证书配置文件crypto-config.yaml
先来理解一下，私钥与证书的相关概念
- 使用公钥和私钥就是所谓的非对称加密方式
- 公钥：是公布出去的给别人使用的，可以被很多人获取。用来加密和验章
- 私钥：私钥只能自己持有，并且不可以被别人知道。用来解密和签章
- 证书：是为公钥做认证，为了使公钥真实可信，防止他人伪造公钥；证书颁发机构（CA）会用自己的私钥对用户的公钥和相关信息进行加密，生成“数字证书”，然后证书中心会公布自己的公钥给所有人，用来让别人使用此公钥验证“数字证书”是否由CA颁发，即是否真实可信。
Fabric 中会有两种类型的公私钥和证书
- 给节点之间通讯安全而准备的TLS证书
- 用户登录和权限控制的用户证书。
来看下first-network/crypto-config.yaml中的配置信息
原始文件注释信息较多，下面我用自己的理解中文表示代替了原始的英文注释，之后的文件解析也会是这样
OrdererOrgs: ## 定义管理orderer节点的组织
- Name: Orderer ## 这个组织的名字叫 Orderer
Domain: example.com ## 这个组织的域名是 example.com
# 生成证书的时候，证书内会包含Name和Domain信息,orderer.example.com就是这个组织的地址
EnableNodeOUs: true ## 如果设置了 EnableNodeOUs ，就在msp下生成config.yaml文件
# 对于一个Spec来说，配置了CommonName，那么文件夹则命名为CommonName
# 如果没有配置CommonName，则文件名为：{{.Hostname}}.{{Domain}}
# 在下面的例子中,在 crypto-config/ordererOrganizations/example.com/orderers 目录下
# 则会产生两个文件orderer.test.com和orderer5.test.com，
# 如果没有加CommonName，则目录名为order.example.com与order5.example.comn
Specs:
- Hostname: orderer
CommonName: orderer.test.com
# - Hostname: orderer2
# - Hostname: orderer3
# - Hostname: orderer4
- Hostname: orderer5
CommonName: orderer5.test.com
PeerOrgs: ## 定义管理peer节点的组织
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
# Template是按照Template模板生成多个文件，数量由Count决定，起始编号由Start决定
# 如下配置会在crypto-config/peerOrganizations/org1.example.com/peers目录下，
# 生成两个文件，分别是 peer0.org1.example.com 和 peer1.org1.example.com
# 如果把Start注释去掉，那么会生成 peer5.org1.example.com 和 peer6.org1.example.com
Template:
Count: 2
# Start: 5
# Users是生成除了Admin之外多少个user，数量由Count决定
# 对于orderer组织，这个值设置了也没有效果
# 如果配置会在crypto-config/peerOrganizations/org1.example.com/users目录下，
# 生成两个文件，分别是Admin@org1.example.com和User1@org1.example.com
# 如果改为2，那么会多一个User2@org1.example.com
Users:
Count: 1
# 如下如果在这里加入一个Specs，那么会在peers目录下生成3个文件了
# 包括，peer0.org2.example.com, peer1.org2.example.com 和 test.org2.example.com
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
# Specs:
# - Hostname: test
Template:
Count: 2
Users:
Count: 1
通常来说
- Name和Domain是必须要有的
- Specs中的配置和Template里的Count共同决定了，orderers或者是peers目录下的子目录数
- 对于peer组织来说，Users里的count决定users目录下除了Admin以外的子目录数目
Fabric使用了cryptogen工具用来调用上面的配置文件生成私钥和证书
| cryptogen generate --config=./crypto-config.yaml |
|---|
执行完以后，会在当前目录生成一个 crypto-config 目录，当然也可以在命令中添加 --output 选项来指定输出的目录。在这个目录下就会根据 Orderer 和Peer 各自生成两个文件夹：
- ordererOrganizations
- peerOrganizations
它们分别代表着orderer和peer的组织及对应目录下的证书文件。
每个组织下都有ca，tlsca，msp，orderers（或者peers），users等5个文件，下面通过tree命令的输出结果，分别解释一下各个目录的作用。
为了方便观看，部分重复的结构我就用省略号省去了
crypto-config
├── ordererOrganizations ## 组织配置
│ └── example.com ## 组织根域名
│ ├── ca ## 存放组织根证书及私钥
│ │ ├── ca.example.com-cert.pem ## 组织根证书，自签名
│ │ └── fe78d606843ca608b5eab2af24d09c51ebeac6fc6a31690c3ad77e55c2840835_sk ## 私钥
│ ├── msp ## 存放该组织身份信息
│ │ ├── admincerts ## 组织管理员
│ │ │ └── Admin@example.com-cert.pem ## 管理员身份验证证书，被根证书签名
│ │ ├── cacerts ## 组织的根证书
│ │ │ └── ca.example.com-cert.pem ## 组织的根证书，与ca里面的一致
│ │ ├── config.yaml ## 配置文件中加了 EnableNodeOUs 参数生成的config.yaml文件，记录 OrganizationalUnitIdentitifiers 信息，包括根证书位置和ID信息
│ │ └── tlscacerts ## 用于TLS的CA证书
│ │ └── tlsca.example.com-cert.pem ## 用于TLS的CA证书，自签名
│ ├── orderers ## 存放所有 Orderer 的身份信息
│ │ ├── orderer.example.com ## 第一个orderer的信息，msp与TLS
│ │ │ ├── msp
│ │ │ │ ├── admincerts ## 组织管理员的身份验证证书，与 msp.admincerts 保持一致
│ │ │ | | └── Admin@example.com-cert.pem ## orderer被给予这些证书来确认交易签名是否为管理员签名
│ │ │ │ ├── cacerts ## 存放组织根证书，与CA目录里一致
│ │ │ │ │ └── ca.example.com-cert.pem
│ │ │ │ ├── config.yaml
│ │ │ │ ├── keystore ## 本节点的身份私钥，用来签名
│ │ │ │ │ └── 0396add7d5658fcae2bb73c34af1b8b459d88839b30cd61fab1d60d1c4c0b703_sk
│ │ │ │ ├── signcerts ## 验证本节点签名的证书，被根证书签名
│ │ │ │ │ └── orderer.example.com-cert.pem
│ │ │ │ └── tlscacerts ## TLS连接用的身份证书，与 msp.tlscacerts 保持一致
│ │ │ │ └── tlsca.example.com-cert.pem
│ │ │ └── tls ## TLS的相关信息
│ │ │ ├── ca.crt ## 组织的根证书
│ │ │ ├── server.crt ## 验证本节点签名的证书，被根证书签名
│ │ │ └── server.key ## 本节点的身份私钥，用来签名
##############################################
# orderer2 到 orderer5 的信息，具体意义与orderer一致
##############################################
│ ├── tlsca ## 存放tls相关的证书和私钥
│ │ ├── 4dbdd5747a94468bd84e0e8bbc39935e894d4c62de1c66a77d6ca66853a24e14_sk ## tls私钥
│ │ └── tlsca.example.com-cert.pem ## tls证书
│ └── users ## 存放属于该组织的用户的实体
│ └── Admin@example.com ## 管理员用户的信息，其中包括msp证书和tls证书两类
│ ├── msp
│ │ ├── admincerts ## 组织管理员的身份验证证书，与 msp.admincerts 保持一致
│ | | └── Admin@example.com-cert.pem
│ │ ├── cacerts ## 存放组织根证书，与CA目录里一致
│ │ │ └── ca.example.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore ## 本用户的身份私钥，用来签名
│ │ │ └── ceefe40caaf06d02d09b1c5776f5dbf0749e056d49fb12fbab23f32b470b4645_sk
│ │ ├── signcerts ## 验证本用户的身份验证证书，被根证书签名，要被某个Orderer认可，则必须放到该 Orderer 的msp/admincerts目录下，因此上面orderer的msp/admincerts目录下的证书应该要是从这里复制一份过去
│ │ │ └── Admin@example.com-cert.pem
│ │ └── tlscacerts ## TLS连接用的身份证书，与 msp.tlscacerts 保持一致
│ │ └── tlsca.example.com-cert.pem
│ └── tls ## TLS的相关信息
│ ├── ca.crt
│ ├── client.crt ## 管理员身份验证证书，被根证书签名
│ └── client.key ## 管理员的身份私钥，用来签名
└── peerOrganizations ## peer组织
├── org1.example.com ## 第一个组织的所有身份证书
│ ├── ca ## 存放私钥与组织根证书
│ │ ├── ca.org1.example.com-cert.pem
│ │ └── e693ef19f57ec58c0c33b51ccf04d12871a793f01c513affacea685e26bbcacc_sk
│ ├── msp ## msp信息与order组织类似
│ │ ├── admincerts
│ | | └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── config.yaml
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ ├── peers ## peers目录与order组织的orderers目录类似
│ │ ├── peer0.org1.example.com
│ │ │ ├── msp
│ │ │ │ ├── admincerts
│ | │ │ | └── Admin@org1.example.com-cert.pem
│ │ │ │ ├── cacerts
│ │ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ │ ├── config.yaml
│ │ │ │ ├── keystore
│ │ │ │ │ └── a77da4f8c714456e7518c5d72346d96954264a5e056c05615b8492c90ce1d90c_sk
│ │ │ │ ├── signcerts
│ │ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ │ └── tlscacerts
│ │ │ │ └── tlsca.org1.example.com-cert.pem
│ │ │ └── tls
│ │ │ ├── ca.crt
│ │ │ ├── server.crt
│ │ │ └── server.key
│ │ └── peer1.org1.example.com
│ │ ├── msp
│ │ │ ├── admincerts
| | │ | └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── 97db71f3465954ed6822cfdc22879350fd3cf120442449c3053a56d6d3ab5241_sk
│ │ │ ├── signcerts
│ │ │ │ └── peer1.org1.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ ├── tlsca ## 存放tls相关的证书和私钥
│ │ ├── e72ab83e95bd44cf98029e1b0fb1afb616295ce0cf82924daaa20a8d37988d70_sk
│ │ └── tlsca.org1.example.com-cert.pem
│ └── users
│ ├── Admin@org1.example.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ | └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── config.yaml
│ │ │ ├── keystore
│ │ │ │ └── b919e8acaad2e62f8dce761b7e282bfbf5f427626457069effc44cd44b2db287_sk
│ │ │ ├── signcerts
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── client.crt
│ │ └── client.key
│ └── User1@org1.example.com
│ ├── msp
│ │ ├── admincerts
│ │ | └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── config.yaml
│ │ ├── keystore
│ │ │ └── 3700db6a19f25b2e22e0315b9fb15ecc3b3a18a14ef463f4b4f2f98e43240ef6_sk
│ │ ├── signcerts
│ │ │ └── User1@org1.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── org2.example.com
###########################
# 以下内容与org1.example.com类似
###########################
做一个补充说明
- 在一个组织内部（orderer的example.com，peer的org1.example.com，或peer的org2.example.com），所有的admincerts是一样的。admin的私钥在Users的Admin文件夹下
- 在一个组织内部，所有的cacerts是一样的，ca的私钥在ca文件夹下
- 在一个组织内部，所有的tlscacerts是一样的，且和tls文件夹下的ca.crt文件一样。tlsca的私钥在tlsca文件夹下
对于peer/orderer以及users来说，msp/keystore下是私钥，msp/signcerts下是证书。
tls下的server.key（peer下是client.key）和server.crt是私钥和证书
相关的证书配置
- configtx.yaml，配外层的msp文件夹
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- peer的core.yaml文件，使用peers下面的msp文件夹
mspConfigPath: ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp
- orderer的orderer.yaml文件，使用orderer下面的msp文件夹
LocalMSPDir: ../crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp
- client和sdk端，使用users下面的msp文件夹
mspConfigPath: ../crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
