Hyperledger Composer:.bna文件与byfn.sh节点/通道连接及生产部署咨询
Let’s tackle your questions one by one—this is a common workflow when bridging Hyperledger Composer with a Fabric network set up via the "Build Your First Network" (BYFN) tutorial, and clarifying deployment best practices is crucial for production planning.
The BYFN script (byfn.sh) spins up a standard local Hyperledger Fabric network—Composer can easily connect to it without relying on Playground. Here’s the step-by-step process:
First, create a Composer connection profile for the BYFN network
Composer needs a connection profile (a JSON file) to know how to communicate with your Fabric nodes. The BYFN network uses default settings (channel namemychannel, Org1/Org2 peers, orderer atlocalhost:7050), so you can create a profile that references the crypto material generated by BYFN (located infabric-samples/first-network/crypto-config).Example snippet of the connection profile:
{ "name": "byfn-network", "x-type": "hlfv1", "x-commitTimeout": 300, "version": "1.0.0", "client": { "organization": "Org1", "connection": { "timeout": { "peer": { "endorser": "300" } } } }, "organizations": { "Org1": { "mspid": "Org1MSP", "peers": ["peer0.org1.example.com"], "certificateAuthorities": ["ca.org1.example.com"] } }, "peers": { "peer0.org1.example.com": { "url": "grpc://localhost:7051", "grpcOptions": { "ssl-target-name-override": "peer0.org1.example.com" }, "tlsCACerts": { "path": "./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" } } }, "orderers": { "orderer.example.com": { "url": "grpc://localhost:7050", "grpcOptions": { "ssl-target-name-override": "orderer.example.com" }, "tlsCACerts": { "path": "./crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt" } } }, "certificateAuthorities": { "ca.org1.example.com": { "url": "http://localhost:7054", "caName": "ca-org1" } } }Import the BYFN admin identity into Composer
BYFN generates admin credentials for each organization. For Org1, you’ll find the cert and private key incrypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp. Import this identity into your Composer wallet with:composer identity import \ -p ./byfn-connection-profile.json \ -u Admin \ -c ./crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem \ -k ./crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/<your-private-key-file>Replace
<your-private-key-file>with the actual filename of the private key (it’s a long, random string ending in_sk).Install and deploy your .bna file
First, install the business network to the peer node:composer network install -c Admin@org1 -a your-business-network.bnaThen start the network on the BYFN channel (
mychannel):composer network start \ -c Admin@org1 \ -n your-business-network \ -V 0.0.1 \ -A network-admin \ -S admin-password \ -f network-admin.cardThe
-fflag generates a card file you’ll use to connect to the deployed network.Test the connection
Import the generated card and ping the network to confirm it’s working:composer card import -f network-admin.card composer network ping -c network-admin@your-business-networkIf you get a successful response, your .bna is now connected to the BYFN peer and channel.
Absolutely not. Playground is a visual development tool for rapid prototyping and testing—it’s not required for any part of this workflow:
- Nodes, peers, and channels are core Fabric components, created using Fabric tools like
byfn.sh,cryptogen, andconfigtxgen. Composer never creates these resources; it only deploys business logic on top of an existing Fabric network. - Deploying .bna files can be done in three ways:
- Composer CLI: The method above—this is the standard for automation and production-like workflows.
- Playground: A convenient visual option for debugging, but entirely optional.
- REST API: If you’ve generated a Composer REST server, you can deploy via API calls, though CLI is more straightforward.
In short: Playground is a nice-to-have tool for development, but it’s not a requirement for deploying .bna files or working with Fabric networks.
No, it’s not designed for production use. Here’s why:
- Security risks: Playground stores identities in browser local storage, which is insecure for production-grade credentials. It also lacks support for enterprise identity systems (like LDAP or OAuth) that production environments demand.
- No automation: Playground is manual—you can’t integrate it into CI/CD pipelines, which are essential for reliable, repeatable production deployments.
- Scalability limits: It’s not built to handle high transaction volumes or large, distributed Fabric networks.
- Deprecation context: Hyperledger Composer itself is deprecated, but even when active, Playground was explicitly intended for development and demonstration only, not enterprise production.
For production, use the Composer CLI (or automation scripts wrapping it) to deploy .bna files to a properly secured, production-ready Fabric network (note: byfn.sh is also a test tool—you’ll want to use a custom, hardened Fabric deployment for production).
内容的提问来源于stack exchange,提问作者Sowmya Kannan

