Michael.W谈hyperledger Fabric第4期-手动搭建Fabric网络之Fabric证书的生成 - Go语言中文社区

Michael.W谈hyperledger Fabric第4期-手动搭建Fabric网络之Fabric证书的生成


Michael.W谈hyperledger Fabric第4期-手动搭建Fabric网络之Fabric证书的生成


接下来我会利用多个帖子来相信介绍一下如何自己手动搭建一个自己的Fabric网络。

1 网络中的组件介绍

一个Fabric网络中最起码要保证一下五个组件:

  • Fabric证书的颁发机构
  • 账本
  • 链码(智能合约)
  • 排序服务器
  • peer节点
  • 通道

Fabric证书颁发机构:由于Fabric的网络是私有化网络,每个参与其中的人都必须事先注册身份并且通过网络内的身份管理验证。每个“合法”的身份就是由Fabric证书颁发机构(MSP)来创建和确认的。Fabric证书颁发机构会给每个通过身份管理注册的用户生成一个秘钥对和数字证书。
MSP是Fabric网络中自带的一个模块。由于Fabric网络模块可插拔的特性。后面我们还可以自己手动再插进去一个MSP模块。

账本:peer节点被创建出的时候会自带账本。

链码(智能合约):由程序开发人员编写,然后需要手动安装到peer节点上。

peer节点:运行在docker里面。通过从网上拉取的IMAGE文件按照特定的参数启动即可。

排序服务器:同样运行在docker中。它被orderer节点调用,继而执行对模拟数据的排序工作。

通道:需要程序员创建。

2 搭建Fabric网络的步骤

  1. 生成组织、节点和用户的证书。这个证书可以理解为进入网络的账号。(需要编写一个yaml文件)
  2. 生成创世区块和通道依赖的文件。(需要编写一个yaml文件)
  3. 启动节点,包括orderer节点、peer节点和客户端。(这些节点都运行在docker容器里。为了方便管理多个容器,所以需要编写一个docker-compose配置文件)
  4. 通过当前组织的客户端,依次连接到当前组织的peer节点上。
  5. 创建通道。注意:通道只需要创建一次
  6. 将每个节点依次加入通道安装链码并对链码进行初始化。注意:对链码的初始化只需要做一次,可以在任意节点上做初始化。一个节点的链码被初始化之后,网络会将其自动同步到其他节点上。
  7. 利用客户端调用链码做测试。分别做读数据写数据的测试。

3 生成Fabric证书

该yaml文件的文件名可随意自定义,但是建议起:crypto-config.yaml。因为官方的测试文件里面就叫这个名字。
该文件配置了网络内组织的信息。其中每个组织信息内还包括了该组织的peer节点信息以及用户信息。
这个配置文件是不需要我们自己手写,用Fabric提供的模板修改即可。

	# 创建一个空目录
	$ mkdir ~/test
	$ cd ~/test
	# 利用指令生成有关证书的yaml配置文件模板
	$ cryptogen showtemplate > crypto-config.yaml

我先对这个模板导读一下:

	# ---------------------------------------------------------------------------
	# "OrdererOrgs" - Definition of organizations managing orderer nodes
	# ---------------------------------------------------------------------------
	OrdererOrgs:   # 关键字,不能修改,表示排序节点组织信息
	  # ---------------------------------------------------------------------------
	  # Orderer
	  # ---------------------------------------------------------------------------
	  - Name: Orderer	# 排序节点组织的名字
	    Domain: example.com	# 访问排序节点组织的域名。这个在我们测试环境中可以随便写,但是真实网络这个域名要写已注册的域名
	    # ---------------------------------------------------------------------------
	    # "Specs" - See PeerOrgs below for complete description
	    # ---------------------------------------------------------------------------
	    Specs:
	      - Hostname: orderer	# orderer组织中的orderer节点的名字。solo模式中只有一个,在之后的kafka模式下可以挂载多个orderer节点。
		# 当order节点的名字被你设定之后,这个节点的域名也就自然生成了(一个二级域名):orderer节点名+orderer组织的域名,即orderer.example.com
	# ---------------------------------------------------------------------------
	# "PeerOrgs" - Definition of organizations managing peer nodes
	# ---------------------------------------------------------------------------
	PeerOrgs:	# 关键字,不能修改,表示peer节点组织信息。peer组织根据职能划分可以有多个。
	  # ---------------------------------------------------------------------------
	  # Org1
	  # ---------------------------------------------------------------------------
	  - Name: Org1	# 第一个peer组织的名字
	    Domain: org1.example.com	# 第一个peer组织的域名
	    EnableNodeOUs: false	# 是否在该peer组织下的msp目录中生成一个config.yaml文件。该文件用于身份识别。
	
	    # ---------------------------------------------------------------------------
	    # "CA"
	    # ---------------------------------------------------------------------------
	    # Uncomment this section to enable the explicit definition of the CA for this
	    # organization.  This entry is a Spec.  See "Specs" section below for details.
	    # ---------------------------------------------------------------------------
	    # CA:
	    #    Hostname: ca # implicitly ca.org1.example.com
	    #    Country: US
	    #    Province: California
	    #    Locality: San Francisco
	    #    OrganizationalUnit: Hyperledger Fabric
	    #    StreetAddress: address for org # default nil
	    #    PostalCode: postalCode for org # default nil
	
	    # ---------------------------------------------------------------------------
	    # "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.
	    #   - SANS:       (Optional) Specifies one or more Subject Alternative Names
	    #                 to be set in the resulting x509. Accepts template
	    #                 variables {{.Hostname}}, {{.Domain}}, {{.CommonName}}. IP
	    #                 addresses provided here will be properly recognized. Other
	    #                 values will be taken as DNS names.
	    #                 NOTE: Two implicit entries are created for you:
	    #                     - {{ .CommonName }}
	    #                     - {{ .Hostname }}
	    # ---------------------------------------------------------------------------
	    # Specs:
	    #   - Hostname: foo # implicitly "foo.org1.example.com"
	    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
	    #     SANS:
	    #       - "bar.{{.Domain}}"
	    #       - "altfoo.{{.Domain}}"
	    #       - "{{.Hostname}}.org6.net"
	    #       - 172.16.10.31
	    #   - Hostname: bar
	    #   - Hostname: baz
	
	    # ---------------------------------------------------------------------------
	    # "Template"
	    # ---------------------------------------------------------------------------
	    # Allows for the definition of 1 or more hosts that are created sequentially
	    # from a template. By default, this looks like "peer%d" from 0 to Count-1.
	    # You may override the number of nodes (Count), the starting index (Start)
	    # or the template used to construct the name (Hostname).
	    #
	    # Note: Template and Specs are not mutually exclusive.  You may define both
	    # sections and the aggregate nodes will be created for you.  Take care with
	    # name collisions
	    # ---------------------------------------------------------------------------
	    Template:	# 关键字,表示在该peer组织下使用模板生成peer节点
	      Count: 1	# 使用模板生成peer节点的个数
	  # 注:利用模板生成的第一个peer节点的域名,默认为peer0.org1.example.com 。即peer0.该peer组织的域名,是一个二级域名。第二个peer节点为peer1,以此类推。
	   

		  # Start: 5
	      # Hostname: {{.Prefix}}{{.Index}} # default
	      # SANS:
	      #   - "{{.Hostname}}.alt.{{.Domain}}"
	
	    # ---------------------------------------------------------------------------
	    # "Users"
	    # ---------------------------------------------------------------------------
	    # Count: The number of user accounts _in addition_ to Admin
	    # ---------------------------------------------------------------------------
	    Users:	# 关键字,表示该peer组织内的用户信息
	      Count: 1	# 生成用户的个数。同时系统还会额外生成一个管理员用户。
	      # 注:根据Count个数生成的用户都是普通用户。即,生成1个普通用户,1个管路员。
	
	  # ---------------------------------------------------------------------------
	  # Org2: See "Org1" for full specification
	  # ---------------------------------------------------------------------------
	  - Name: Org2	# 第二个peer组织信息,跟前面的一样。
	    Domain: org2.example.com
	    EnableNodeOUs: false
	    Template:
	      Count: 1
	    Users:
	      Count: 1

这个配置文件是为你即将要搭建的网络里面所涉及的成员生成证书的,所以在编写之前你心中要对你搭建的这个网络的组成有个框架。比如说:有几个orderer节点,有几个peer组织等。

我构建的网络中包含:
1个orderer组织,该组织中包含1个orderer节点。同时有2个peer组织,每个组织中分别包括2个peer节点、3个用户。那么对应这个配置修改的生成证书的yaml文件内容为:

	OrdererOrgs:
	 - Name: Orderer
	   Domain: michael.com
	   Specs:
	      - Hostname: orderer
	PeerOrgs:
	  - Name: Org1
	    Domain: org1.michael.com
	    EnableNodeOUs: true
	    Template:
	      Count: 2
	    Users:
	      Count: 3
	  - Name: Org2
	    Domain: org2.michael.com
	    EnableNodeOUs: false
	    Template:
	      Count: 2
	    Users:
	      Count: 3

根据这个crypto-config.yaml,生成对应证书:

	$ cryptogen generate --config=crypto-config.yaml
	# 参数config后面跟的是你编写的yaml文件的名字

在这里插入图片描述
在当前目录下会生成一个crypto-config文件夹,里面都是我上面设置的网络组件的身份证书。可以利用tree命令来查看层级间目录:

	$ tree crypto-config

crypto-config路径下有两个文件夹:ordererOrganizations和peerOrganizations。里面分别有各自组织内的网络组建信息。
需要注意的是,所有的网络组件(组织、节点(orderer节点、peer节点和用户))目录下都有一个msp目录。这个目录里面存放的就是该组件的证书相关信息
前面我在peer组织Org1中把EnableNodeOUs对应的值设成了true,在对应msp路径下生成了config.yaml文件。而Org2中却没有:
在这里插入图片描述
至于其他路径内容这里不做赘述。

ps:
本人热爱图灵,热爱中本聪,热爱V神,热爱一切被梨花照过的姑娘。
以下是我个人的公众号,如果有技术问题可以关注我的公众号来跟我交流。
同时我也会在这个公众号上每周更新我的原创文章,喜欢的小伙伴或者老伙计可以支持一下!
如果需要转发,麻烦注明作者。十分感谢!
后现代泼痞浪漫主义奠基人
公众号名称:后现代泼痞浪漫主义奠基人

版权声明:本文来源CSDN,感谢博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/michael_wgy_/article/details/88345065
站方申明:本站部分内容来自社区用户分享,若涉及侵权,请联系站方删除。

0 条评论

请先 登录 后评论

官方社群

GO教程

推荐文章

猜你喜欢