fabric網絡環境啓動過程詳解

最新內容會更新在主站深刻淺出區塊鏈社區
原文連接:Fabric1.0 交易流程

這篇文章對fabric的網絡環境啓動過程進行講解,也就是咱們上節講到的啓動測試fabric網絡環境時運行network_setup.sh這個文件的執行流程

fabric網絡環境啓動過程詳解

上一節咱們講到 fabric網絡環境的啓動測試，主要是使用 ./network_setup.sh up 這個命令，因此fabric網絡環境啓動的重點就在network_setup.sh這個文件中。接下來咱們就分析一下network_setup.sh這個文件
network_setup.sh其中包括兩個部分，一個是利用generateArtifacts.sh腳本文件配置組織關係和頒發證書、公/私鑰、通道證書等，另外一個是docker-compose-cli.yaml用於根據配置啓動集羣並測試chaincode的示例代碼。下面是具體的流程圖介紹：

首先看下generateArtifacts.sh腳本文件，它包含三個函數，分別是：
```
1.generateCerts：
該函數使用cryptogen工具根據crypto-config.yaml來生成公私鑰和證書信息等。

2.replacePrivateKey：
將docker-compose-e2e-template.yaml文檔中的ca私鑰替換成具體的私鑰。

3.generateChannelArtifacts：
使用configtxgen工具根據configtx.yaml文件來生成創世區塊和通道相關信息，更新錨節點。
**接着是docker-compose-cli.yaml文件** docker-compose-cli.yaml文件根據組織關係啓動docker集羣，並在cli容器中執行command命令運行./scripts/script.sh腳本文件。 那./scripts/script.sh腳本具體作了什麼呢？
1.createChannel：建立channel。

1. joinChannel：將每一個peer節點加入channel。
2. updateAnchorPeers：更新錨節點
3. installChaincode：部署chaincode。
4. instantiateChaincode：初始化chaincode。
5. chaincodeQuery：chaincode查詢

另外docker-compose-cli.yaml這個文件還有一個配置項是須要注意的地方，那就是：

file: base/docker-compose-base.yaml

這裏的docker-compose-base.yaml其實就是Orderer和peer的基礎配置文件，包括指定端口等。
### 幾個重要的配置文件
#### 1.crypto-config.yaml
基於crypto-config.yaml（此文件在../fabric/examples/e2e_cli中）**生成公、私鑰和證書信息，並保存在crypto-config文件夾中**。另外crypto-config.yaml還定義了組織成員以及組織下的peer節點個數。
**crypto-config.yaml文件講解：**
字段Name和Domain就是關於這個組織的名字和域名，這主要是用於生成證書的時候，證書內會包含該信息。而Template.Count=2是說咱們要生成2套公私鑰和證書，一套是peer0.org1的，還有一套是peer1.org1的（也就指定了org中存在peer0和peer1兩個節點）。最後Users.Count=1是說每一個Template下面會有幾個普通User（注意，Admin是Admin，不包含在這個計數中），這裏配置了1，也就是說咱們只須要一個普通用戶User1@org1.example.com 咱們能夠根據實際須要調整這個配置文件，增刪Org Users等。文件內容以下：

# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------

• Name: Orderer
  Domain: example.com

  ---------------------------------------------------------------------------

  "Specs" - See PeerOrgs below for complete description

  ---------------------------------------------------------------------------

  Specs:

  • Hostname: orderer

    ---------------------------------------------------------------------------

    "PeerOrgs" - Definition of organizations managing peer nodes

    ---------------------------------------------------------------------------

    PeerOrgs:
    # ---------------------------------------------------------------------------
    # Org1
    # ---------------------------------------------------------------------------

• Name: Org1
  Domain: org1.example.com

  ---------------------------------------------------------------------------

  "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.

  ---------------------------------------------------------------------------

  Specs:

  - 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: 2
  # Start: 5
  # Hostname: {{.Prefix}}{{.Index}} # default

  ---------------------------------------------------------------------------

  "Users"

  ---------------------------------------------------------------------------

  Count: The number of user accounts in addition to Admin

  ---------------------------------------------------------------------------

  Users:
  Count: 1
  # ---------------------------------------------------------------------------
  # Org2: See "Org1" for full specification
  # ---------------------------------------------------------------------------

• Name: Org2
  Domain: org2.example.com
  Template:
  Count: 2
  Users:
  Count: 1

**注：**
peer：
Fabric 網絡中的節點，表現爲一個運行着的docker容器。能夠與網絡中的其餘peer進行通訊，每一個peer都在本地保留一份ledger的副本。它是org下的組織成員。
org:
一個組織，它能夠由一個或多個peer組成。
Orderer :
聯盟成員共享的中心化節點。用來對交易進行排序，是 Fabric 共識機制的重要組成部分。
#### 2.configtx.yaml
基於configtx.yaml（此文件在../fabric/examples/e2e_cli中）**生成創世區塊和通道相關信息，並保存在channel-artifacts文件夾。還能夠指定背書策略。**
**configtx.yaml文件講解：**
1.官方提供的examples/e2e_cli/configtx.yaml這個文件裏面配置了由2個Org參與的Orderer共識配置TwoOrgsOrdererGenesis，以及由2個Org參與的Channel配置：TwoOrgsChannel。
2.另外咱們能夠在此文件的Orderer部分設置共識的算法是Solo仍是Kafka，以及共識時區塊大小，超時時間等，咱們使用默認值便可，不用更改。而Peer節點的配置包含了MSP的配置，錨節點的配置。若是咱們有更多的Org，或者有更多的Channel，那麼就能夠根據模板進行對應的修改。
3.Policies配置也要特別注意，該配置項定義了不一樣角色的權限,Reader,Writer以及Admin分別對應讀，寫，以及admin權限,讀權限角色只能從別的peer節點同步帳本而不能發起交易，只有writer定義項下的角色才擁有發起交易的也就是調用chaincode的invoke方法的權限(不必定都是invoke方案，只要涉及到chaincode中狀態修改的方法，都只有擁有writer權限或admin權限的角色才能調用)。以該配置的Organizations配置下的Org1配置爲例,"OR('Org1MSP.admin', 'Org1MSP.client')",表示org1的msp服務中的admin或者client角色擁有發起交易的權限。文件內容以下：

Copyright IBM Corp. All Rights Reserved.

SPDX-License-Identifier: Apache-2.0

---

Profile

- Different configuration profiles may be encoded here to be specified

as parameters to the configtxgen tool

Profiles:

TwoOrgsOrdererGenesis:
    Orderer:
        <<: *OrdererDefaults
        Organizations:
            - *OrdererOrg
    Consortiums:
        SampleConsortium:
            Organizations:
                - *Org1
                - *Org2
TwoOrgsChannel:
    Consortium: SampleConsortium
    Application:
        <<: *ApplicationDefaults
        Organizations:
            - *Org1
            - *Org2

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
    # 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

    # MSPDir is the filesystem path which contains the MSP configuration
    MSPDir: crypto-config/ordererOrganizations/example.com/msp

- &Org1
    # 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: crypto-config/peerOrganizations/org1.example.com/msp

    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: crypto-config/peerOrganizations/org2.example.com/msp

    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: 7051

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
# Available types are "solo" and "kafka"
OrdererType: solo

Addresses:
    - orderer.example.com:7050

# 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: 98 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

Kafka:
    # Brokers: A list of Kafka brokers to which the orderer connects
    # NOTE: Use IP:port notation
    Brokers:
        - 127.0.0.1:9092

# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:

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: