基于Hyperledger Composer的跨物理机多组织业务网络搭建问询

Hey there! Since you’ve already nailed Hyperledger Composer multi-org setups on a single server and Playground, moving to two physical machines is mostly about adjusting network configurations and splitting your org deployments. Let’s walk through the process clearly:

1. Pre-Network Prep #

First, make sure your two machines can communicate reliably:

• Assign static IP addresses to both machines (or update their /etc/hosts files so each can resolve the other’s hostname)
• Open all required ports between them:
  • Fabric peer ports: 7051 (gRPC), 7053 (event hub)
  • Orderer port: 7050
  • CA ports (if using separate CAs): 7054
• Test connectivity with tools like nc (e.g., nc -zv <machine-ip> 7051) to confirm ports are accessible.

2. Split Org Deployments #

Let’s assume Machine A hosts Org1 (plus the orderer node, for simplicity) and Machine B hosts Org2.

On Machine A (Org1 & Orderer Host): #

• Deploy the orderer, Org1’s peer, CA, and CouchDB (if using) as you did in the single-server guide. The key change: modify your docker-compose.yaml to bind services to the machine’s public IP instead of localhost. Example for the peer service:

  environment:
    - CORE_PEER_ADDRESS=<machine-a-ip>:7051
    - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<machine-a-ip>:7051
  ports:
    - "7051:7051"
    - "7053:7053"
  

• Use cryptogen to generate crypto material for both orgs. Copy Org2’s crypto folder to Machine B (via SCP or a shared drive) once generated.
• Update configtx.yaml to include both orgs, then generate the genesis block and channel transaction files.

On Machine B (Org2 Host): #

• Paste the copied Org2 crypto material into the correct directory (match the path specified in your docker-compose.yaml).
• Deploy Org2’s peer, CA, and CouchDB. Modify its docker-compose.yaml to use Machine B’s public IP, and add a gossip bootstrap pointing to Org1’s peer:

  environment:
    - CORE_PEER_ADDRESS=<machine-b-ip>:9051
    - CORE_PEER_GOSSIP_EXTERNALENDPOINT=<machine-b-ip>:9051
    - CORE_PEER_GOSSIP_BOOTSTRAP=<machine-a-ip>:7051
  ports:
    - "9051:9051"
    - "9053:9053"
  

  The bootstrap setting lets Org2’s peer join the gossip network with Org1.

3. Channel Setup & Peer Joining #

• On Machine A, create the channel using the orderer:

  peer channel create -o <machine-a-ip>:7050 -c mychannel -f ./channel-artifacts/channel.tx
  

• Copy the generated mychannel.block file to Machine B.
• On Machine A, join Org1’s peer to the channel:

  peer channel join -b mychannel.block
  

• On Machine B, run the same peer channel join command using the copied block file to add Org2’s peer.

4. Chaincode & Business Network Deployment #

• Install your chaincode on both peers (run the install command inside each peer’s container on their respective machines).
• Instantiate the chaincode from one machine (e.g., Machine A) with an endorsement policy that includes both orgs:

  peer chaincode instantiate -o <machine-a-ip>:7050 -c mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"
  

• Generate your business network archive (.bna) as you did in Playground. Deploy it using a connection profile that references the public IPs of both peers and the orderer—don’t use localhost here.
• Test transactions from both orgs to confirm state syncs correctly across peers.

Critical Pitfalls to Avoid #

• Crypto Material Consistency: Ensure both machines have the correct, matching crypto material for their org and the orderer. Mismatched files will break authentication.
• Firewall Rules: Double-check that no firewalls (local or network-level) are blocking traffic between the machines.
• Connection Profile Accuracy: Every node entry in your Composer connection profile must use the public IP/hostname of the machine it’s hosted on.

内容的提问来源于stack exchange，提问作者csLijo