Hyperledger Fabric v1跨物理机部署配置调整及Host字段疑问

Great question! Since you’ve already nailed a single-machine setup, you’re well-positioned to expand to two physical machines. Let’s break this down into two parts: the key config files to modify, and the answer to your Host field question.

1. Config Files to Modify for Two-Machine Deployment #

Here’s a rundown of the critical files you’ll need to adjust, along with what changes to make:

docker-compose.yaml (or docker-compose-*.yaml) #

This is the biggest one—your single-machine setup probably uses localhost for all services, which won’t work across two machines.

• Update service endpoints: For each peer/orderer/CA, change environment variables like CORE_PEER_ADDRESS from localhost:7051 to the real IP address of the machine hosting that service (e.g., 192.168.1.100:7051).
• Adjust port mappings: Ensure the published ports on each machine don’t conflict, and that firewalls allow incoming traffic on these ports (7051 for peers, 7050 for orderers, 9443 for CAs, etc.).
• Add extra_hosts (optional but helpful): If you’re using virtual hostnames instead of raw IPs, add entries here to map hostnames to the other machine’s IP (e.g., extra_hosts: - "peer0.org2.example.com:192.168.1.101").

crypto-config.yaml #

While this file is used to generate certificates upfront, you’ll need to:

• Make sure the certificate directory structure aligns with which services are on which machine. For example, copy the peer0.org1.example.com certs to Machine A, and peer0.org2.example.com certs to Machine B.
• Ensure both machines have access to the root CA certs of all organizations (so peers can verify each other’s identities).

configtx.yaml #

This file defines your channel and network configuration—critical for cross-machine connectivity:

• Update OrdererAddresses to point to the orderer’s real IP/port (e.g., 192.168.1.100:7050 instead of orderer.example.com:7050, unless you’ve set up hostname resolution).
• For each organization’s peer definitions, set Endpoints to the peer’s real IP/port (e.g., - "192.168.1.101:7051"). This ensures other nodes can connect to the peer over the network.

core.yaml (Peer Node Configuration) #

If you’re not using docker-compose environment variables to override settings, modify this file on each peer machine:

• Set CORE_PEER_ADDRESS to the peer’s real IP/port.
• Update CORE_PEER_GOSSIP_EXTERNALENDPOINT to the peer’s publicly accessible IP/port—this lets other peers discover it via gossip.
• Set CORE_PEER_GOSSIP_BOOTSTRAP to the address of a peer on the other machine (e.g., 192.168.1.100:7051), so the peer can join the gossip network.

orderer.yaml (Orderer Node Configuration) #

If your orderer is on a separate machine:

• Set Orderer.ListenAddress to 0.0.0.0:7050 (or the orderer’s specific IP) to allow connections from other machines.
• Ensure Orderer.General.BootstrapFile points to the correct path of your genesis block on the orderer machine.

2. Clarification on the Host Field in configtx.yaml #

The Host field (e.g., Host: peer0.org1.example.com) is a virtual hostname, but it needs to be resolvable to the peer/orderer’s real IP by all nodes in the network. You have two options to make this work:

1. Edit /etc/hosts on both machines: Add entries mapping each virtual hostname to its corresponding machine’s IP. For example:

   192.168.1.100 peer0.org1.example.com
   192.168.1.101 peer0.org2.example.com
   192.168.1.100 orderer.example.com
   

2. Use a DNS server: If you have access to a local DNS server, configure it to resolve these hostnames to the correct IPs.

Can you use a real IP instead of a hostname? Yes—you can replace peer0.org1.example.com with the peer’s actual IP address, and it will work. However, using hostnames is more flexible: if you ever need to change a machine’s IP, you only update the /etc/hosts or DNS entries instead of regenerating network/channel configurations.

Quick Additional Tips #

• Double-check firewall rules: Ensure all required ports are open between the two machines (7050, 7051, 7053, 9443 are common ones).
• Sync certificates properly: Make sure each machine has the necessary certs (its own node certs, plus root CA certs for all other organizations).
• Test connectivity first: Use ping or telnet to verify each machine can reach the other’s service ports before starting the network.

内容的提问来源于stack exchange，提问作者V. Kar