Fabric2.X的配置文件(以test-network为例)

Hyperledger Fabric项目可以认为是一个BaaS - Blockchain as a Service,其主要的服务是为提供企业级的联盟链基础设施,多用于商业环境。和公有链不同的是,联盟链削弱中心化这一特性,通过灵活的身份准入、私有数据隔离、智能合约和链码等特性,使得使用者可以根据实际业务需求去设计自己的网络。而一个Fabric网络的结构,则依赖于许多网络配置文件。这些配置文件定义了参与网络的组织有哪些,每个组织的有哪些节点,以及这些节点的信息;除此之外,背书策略、排序策略、身份管理等内容也是通过这些配置文件来定义。

网络启动流程

第一步 使用cryptogen工具生成参与网络组织实体的证书

cryptogen工具用于生成证书文件,PKICAX.509公钥体系等密码学基础为整个Fabric提供了底层的安全支持,实现可信成员对网络资源的合法访问。启动一个网络的第一步,就是生成证书

在Fabric2.2中,同先前所有生成证书的配置都在一个文件中不同的是,每一个组织在都有单独的配置文件来管理。test-network使用三个文件生成对应三个组织的证书,在脚本中,它们是这样的:

 cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"
 ...
 cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output="organizations"
 ...
 cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output="organizations"
 ...

这几个文件的组织形式是这样的:

root@lizonglin-virtual-machine:/home/lizonglin/GoWork/src/github.com/fabric/scripts/fabric-samples/test-network/organizations# tree
.
...
├── cryptogen   
│   ├── crypto-config-orderer.yaml
│   ├── crypto-config-org1.yaml
│   └── crypto-config-org2.yaml
└── fabric-ca
    ├── ordererOrg
    │   └── fabric-ca-server-config.yaml
    ├── org1
    │   └── fabric-ca-server-config.yaml
    ├── org2
    │   └── fabric-ca-server-config.yaml
    └── registerEnroll.sh

orderer组织,两个org分别由三个文件定义。

使用cryptogen工具生成证书材料,三个文件内容如下:

  • crypto-config-orderer.yaml
# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs: # orderer组织来管理orderer节点,定义orderer节点所属组织的信息
  # ---------------------------------------------------------------------------
  # Orderer
  # ---------------------------------------------------------------------------
  - Name: Orderer	# 组织名称
    Domain: example.com	# 组织域名
    EnableNodeOUs: true	# 是否在msp下生成config.yaml文件(许可为节点组织单元的一员)
    # ---------------------------------------------------------------------------
    # "Specs" - See PeerOrgs for complete description
    # ---------------------------------------------------------------------------
    Specs:	# Hostname + Domain 组成了完整的Orderer组织的域名: orderer.example.name
      - Hostname: orderer
        SANS:
          - localhost
  • crypto-config-org1.yaml
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:	# 这里定义的由peer节点组成的组织1的信息
  # ---------------------------------------------------------------------------
  # Org1
  # ---------------------------------------------------------------------------
  - Name: Org1	# 组织名称
    Domain: org1.example.com	# 组织域名
    EnableNodeOUs: true	# 生成msp文件
    # ---------------------------------------------------------------------------
    # "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
    # ---------------------------------------------------------------------------
    # "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:
      Count: 1	# 节点个数
      SANS:
        - localhost
      # Start: 5
      # Hostname: {{.Prefix}}{{.Index}} # default
    # ---------------------------------------------------------------------------
    # "Users"
    # ---------------------------------------------------------------------------
    # Count: The number of user accounts _in addition_ to Admin
    # ---------------------------------------------------------------------------
    Users:
      Count: 1	# 管理员个数
  • crypto-config-org2.yaml
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
  # ---------------------------------------------------------------------------
  # Org2
  # ---------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    # ---------------------------------------------------------------------------
    Template:
      Count: 1
      SANS:
        - localhost
    # ---------------------------------------------------------------------------
    Users:
      Count: 1

如果我们要配置三个组织:含有三个orderer节点的Orderer组织,两个包含两个peer节点的Org组织,那么配置文件应该这样写:

# Orderer组织配置如下
OrdererOrgs:
	- Name: Orderer
	  Domain: example.com
	  EnableNodeOUs: true
	  Specs:
	  	- Hostname: orderer0
	  	- Hostname: orderer1
	  	- Hostname: orderer2
# Org1组织配置如下
PeerOrgs:
	- Name: Org1
	  Domain: org1.example.com
	  EnableNodeOUs: true
	  Template:
	  	Count: 2
	  Users:
	  	Count: 1
# Org2配置如下
PeerOrgs:
	- Name: Org2
	  Domain: org2.example.com
	  EnableNodeOUs: true
	  Template:
	  	Count: 2
	  Users:
	  	Count: 1

关于使用cryptogen还是CAs去生成加密证书材料,Fabric是这样说的:

启动网络之前,每个组织需要生成加密材料,来定义网络中的组织。由于Fabric是许可链,网络中的每一个节点和用户需要使用证书以及密钥进行签名、验证等行为。此外,每个用户需要从属于某个组织,这个组织被视为网络的成员。你可以使用Cryptogen toolFabric CAs去生成组织的加密材料。

默认情况,测试网络使用cryptogen工具。这个工具在开发和测试环境中可以快速的生成证书材料和密钥,这些几乎在网络中处处都会用到。

同样的,也可以使用Fabric CAs生成证书、密钥等加密材料。CAs对证书进行签名并发放密钥,为每个组织生成一个合法的根信任。通过配置文件,使用registerEnroll.sh脚本生成实体、证书、MSP相关的文件。

第二步 使用configtxgen生成创世区块

configtxgen工具使用configtx.yaml文件生成创世区块,这个文件也用来定义网络。通过这个文件,我们可以定义联盟,也就是把组织是为联盟的成员。其中,需要用到每个成员的MSP证书(上一步已经生成),来创建通道MSP,作为每个组织的根信任。通道MSP使得组织可以被视为网络成员。configtx.yaml文件同样定义了每个peer组织的锚节点,之后还用于创建通道及更新锚节点。

root@lizonglin-virtual-machine:/home/lizonglin/GoWork/src/github.com/fabric/scripts/fabric-samples/test-network/configtx# cat configtx.yaml 
# 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	# 可以在yaml文件的其他地方引用这个名字
        # 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: OrdererMSP	# MSPid

        # MSPDir is the filesystem path which contains the MSP configuration
        MSPDir: ../organizations/ordererOrganizations/example.com/msp	# 寻找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('OrdererMSP.member')"	# 由该OrdererMSP的任何一个成员签名就可以读
            Writers:	# 写策略
                Type: Signature
                Rule: "OR('OrdererMSP.member')" # 同样的 OR 指 有一个就行
            Admins:		# 管理员
                Type: Signature
                Rule: "OR('OrdererMSP.admin')"

        OrdererEndpoints:	# 该组织端口号
            - orderer.example.com:7050

    - &Org1 # 组织1,在yaml文件中 &xxx 的写法使其可以在别处被引用
        # 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.example.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
                # 这里的策略是,有'Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client'三者中的一个允许就可以读
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers: # 同理有两个中的一个就可写
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:	# 只有admin
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:	# 有一个Org1MSP的peer节点签名就可以背书
                Type: Signature
                Rule: "OR('Org1MSP.peer')"

        # leave this flag set to true.
        AnchorPeers:	# 锚节点用于跨组织通信
            # AnchorPeers defines the location of peers which can be used
            # for cross org gossip communication.  Note, this value is only
            # encoded in the genesis block in the Application section context
            - Host: peer0.org1.example.com
              Port: 7051

    - &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.example.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')"

        AnchorPeers:
            # AnchorPeers defines the location of peers which can be used
            # for cross org gossip communication.  Note, this value is only
            # encoded in the genesis block in the Application section context
            - Host: peer0.org2.example.com
              Port: 9051

################################################################################
#
#   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
    OrdererType: etcdraft

    EtcdRaft:
        Consenters:
        - Host: orderer.example.com
          Port: 7050
          ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
          ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.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:

    TwoOrgsOrdererGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    TwoOrgsChannel:
        Consortium: SampleConsortium
        <<: *ChannelDefaults
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities
自认为是幻象波普星的来客
Built with Hugo
主题 StackJimmy 设计