fabric網路環境啟動過程詳解

深入淺出區塊鏈發表於2019-02-16

最新內容會更新在主站深入淺出區塊鏈社群
原文連結: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:

相關文章