如何在Hyperledger Fabric网络中添加跨物理机部署的新组织？

Alright, let's tackle adding two new cross-machine organizations (Org1 on Machine1, Org2 on Machine2) to your existing Hyperledger Fabric 1.1-rc1 network. I’ve broken this into clear, step-by-step actions since deploying orgs on separate machines adds a few extra network and configuration considerations compared to the same-machine setup you started with.

First, we need to generate cryptographic identities for the new orgs and distribute them to their respective machines:

• On your original network machine, open your existing crypto-config.yaml and add the two new peer organizations (make sure to avoid name collisions with your existing Or1/Or2):

  PeerOrgs:
    # Existing organizations (keep these as-is)
    - Name: Or1
      Domain: or1.example.com
      EnableNodeOUs: true
      Template:
        Count: 1
      Users:
        Count: 1
    - Name: Or2
      Domain: or2.example.com
      EnableNodeOUs: true
      Template:
        Count: 1
      Users:
        Count: 1
    # New organizations to add
    - Name: Org1
      Domain: org1.example.com
      EnableNodeOUs: true
      Template:
        Count: 1 # Adjust if you want multiple peers per org
      Users:
        Count: 1
    - Name: Org2
      Domain: org2.example.com
      EnableNodeOUs: true
      Template:
        Count: 1
      Users:
        Count: 1
  

• Regenerate the crypto material to include the new orgs:

  cryptogen generate --config=./crypto-config.yaml
  

• Securely copy the relevant crypto directories to each new machine:
  • Copy crypto-config/peerOrganizations/org1.example.com/ to Machine1
  • Copy crypto-config/peerOrganizations/org2.example.com/ to Machine2

Next, modify the existing channel's configuration to recognize the new organizations:

• On your original machine, fetch the current channel config block:

  peer channel fetch config config_block.pb -o orderer.example.com:7050 -c mychannel --tls --cafile /path/to/orderer/tls/ca.crt
  

• Convert the protobuf block to JSON for editing:

  configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
  jq .data.data[0].payload.data.config config_block.json > config.json
  

• Create a modified_config.json file that adds the new orgs' MSP definitions (mirror the format used for Or1/Or2 in the original config, using the MSP structure from the new orgs' crypto material)
• Compute the config update and package it into an envelope:

  # Encode original and modified configs to protobuf
  configtxlator proto_encode --input config.json --type common.Config --output config.pb
  configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
  
  # Calculate the config update
  configtxlator compute_update --channel_id mychannel --original config.pb --updated modified_config.pb --output config_update.pb
  
  # Convert back to JSON and wrap in an envelope
  configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
  echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
  configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb
  

• Sign the config update with your existing org admins and submit it to the orderer:

  # Sign with at least one existing org admin (repeat for Or2 if needed)
  peer channel signconfigtx -f config_update_in_envelope.pb
  # Submit the update
  peer channel update -f config_update_in_envelope.pb -c mychannel -o orderer.example.com:7050 --tls --cafile /path/to/orderer/tls/ca.crt
  

Each new machine needs a Docker Compose file to run its peer node(s):

• On Machine1, create docker-compose-org1.yaml (adjust paths and IPs to match your setup):

  version: '2'
  services:
    peer0.org1.example.com:
      container_name: peer0.org1.example.com
      image: hyperledger/fabric-peer:1.1.0-rc1
      environment:
        - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
        - CORE_PEER_ID=peer0.org1.example.com
        - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
        - CORE_PEER_LOCALMSPID=Org1MSP
        - CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer/msp
        - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.or1.example.com:7051 # Use an existing peer from your network
        - CORE_PEER_GOSSIP_EXTERNALENDPOINT=Machine1-IP:7051 # Public IP/hostname of Machine1
        - CORE_PEER_TLS_ENABLED=true
        - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/msp/peer/tls/server.crt
        - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/msp/peer/tls/server.key
        - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/msp/peer/tls/ca.crt
      volumes:
          - /var/run/:/host/var/run/
          - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer/msp
          - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/msp/peer/tls
      ports:
        - 7051:7051
        - 7052:7052
      command: peer node start
  

• Repeat this on Machine2 for docker-compose-org2.yaml, replacing Org1 references with Org2, and setting CORE_PEER_GOSSIP_EXTERNALENDPOINT to Machine2's IP/hostname.
• Start the peer nodes on each machine:

  # Machine1
  docker-compose -f docker-compose-org1.yaml up -d
  # Machine2
  docker-compose -f docker-compose-org2.yaml up -d
  

Connect the new peers to your existing channel:

• On your original machine, fetch the channel genesis block and copy it to both new machines:

  peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c mychannel --tls --cafile /path/to/orderer/tls/ca.crt
  

• On Machine1, set admin environment variables and join the channel:

  export CORE_PEER_MSPCONFIGPATH=./crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
  export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
  export CORE_PEER_LOCALMSPID=Org1MSP
  export CORE_PEER_TLS_ROOTCERT_FILE=./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
  
  peer channel join -b mychannel.block
  

• Repeat this on Machine2, replacing Org1 references with Org2.

Anchor peers enable gossip communication between organizations across the network:

• On your original machine, update your configtx.yaml to include anchor peer definitions for the new orgs:

  Organizations:
    # Existing orgs (keep as-is)
    - &Or1
      Name: Or1MSP
      ID: Or1MSP
      MSPDir: ./crypto-config/peerOrganizations/or1.example.com/msp
      AnchorPeers:
        - Host: peer0.or1.example.com
          Port: 7051
    - &Or2
      Name: Or2MSP
      ID: Or2MSP
      MSPDir: ./crypto-config/peerOrganizations/or2.example.com/msp
      AnchorPeers:
        - Host: peer0.or2.example.com
          Port: 7051
    # New orgs
    - &Org1
      Name: Org1MSP
      ID: Org1MSP
      MSPDir: ./crypto-config/peerOrganizations/org1.example.com/msp
      AnchorPeers:
        - Host: peer0.org1.example.com
          Port: 7051
    - &Org2
      Name: Org2MSP
      ID: Org2MSP
      MSPDir: ./crypto-config/peerOrganizations/org2.example.com/msp
      AnchorPeers:
        - Host: peer0.org2.example.com
          Port: 7051
  

• Generate the anchor peer update transactions:

  configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP
  configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP
  

• Copy these tx files to the respective machines and submit the updates:

  # Machine1
  peer channel update -f Org1MSPanchors.tx -c mychannel -o orderer.example.com:7050 --tls --cafile /path/to/orderer/tls/ca.crt
  # Machine2
  peer channel update -f Org2MSPanchors.tx -c mychannel -o orderer.example.com:7050 --tls --cafile /path/to/orderer/tls/ca.crt
  

Key Notes to Avoid Issues #

• Network Connectivity: Ensure all machines can reach each other over the network. Open ports 7050 (orderer), 7051 (peer gossip), and 7052 (peer chaincode) on firewalls.
• TLS Trust: All nodes must have the root CA certificates of the orderer and other organizations to establish secure connections.
• Consistent Versions: Use the exact same Fabric binary and Docker image versions (1.1.0-rc1) across all machines to avoid compatibility bugs.

内容的提问来源于stack exchange，提问作者chinmaya.mahunta