Hyperledger Fabric智能合约修改：避免删Docker镜像及数据丢失的方法

Awesome question! You’re right that deleting application Docker images would be a bad move (and totally unnecessary) in Hyperledger Fabric. The framework is designed specifically to let you update smart contracts (chaincode) without touching your application containers or losing ledger data. Let’s walk through the proper workflow:

Key Background First #

First, let’s clarify a critical distinction: your application’s Docker containers (the business logic that interacts with the Fabric network) are completely separate from the chaincode containers running on peer nodes. Your app communicates with peers via the Fabric SDK, while chaincode runs in isolated containers to execute ledger transactions. Updating chaincode only affects these peer-side containers—your app images stay untouched, and ledger data is preserved because it’s stored in the peer’s state database (LevelDB or CouchDB), not the chaincode container.

Step-by-Step Chaincode Upgrade Process #

1. Package Your Updated Chaincode #

First, package your modified chaincode with a new version identifier (this is how Fabric distinguishes the updated code from the old one). For example, if your original chaincode was version 1.0, use 2.0 for the update.

Use this command (adjust paths, language, and labels to match your setup):

peer chaincode package updated_chaincode.tar.gz \
  --path ./path/to/your/chaincode \
  --lang golang \ # Replace with your chaincode language (node, java, etc.)
  --label my_contract_v2

2. Install the Updated Chaincode on All Relevant Peers #

Every peer that needs to execute the chaincode (based on your channel’s endorsement policy) must have the new package installed. Run this on each peer:

peer chaincode install updated_chaincode.tar.gz

Verify the installation was successful with:

peer chaincode list installed

3. Approve the Chaincode Definition for Your Organization #

Each organization’s admin needs to approve the new chaincode definition, specifying the new version and an incremented sequence number (the sequence tracks how many times the chaincode has been updated—start at 1 for the first deployment, add 1 for each upgrade).

Example command:

peer chaincode approveformyorg \
  -o orderer.example.com:7050 \
  --channelID mychannel \
  --name my_contract \
  --version 2.0 \
  --sequence 2 \ # Must be +1 from the previous sequence
  --tls \
  --cafile /path/to/orderer-ca-cert.pem

4. Commit the Chaincode Definition to the Channel #

Once enough organizations (as defined by your channel’s lifecycle endorsement policy) have approved the update, commit the new definition to the channel. This triggers peers to spin up the updated chaincode containers and replace the old ones.

Example command:

peer chaincode commit \
  -o orderer.example.com:7050 \
  --channelID mychannel \
  --name my_contract \
  --version 2.0 \
  --sequence 2 \
  --tls \
  --cafile /path/to/orderer-ca-cert.pem \
  --peerAddresses peer0.org1.example.com:7051 \
  --tlsRootCertFiles /path/to/peer0-org1-ca-cert.pem

5. Verify the Upgrade Worked #

Test that the updated chaincode logic is working by running a query or invoke command:

peer chaincode query \
  -C mychannel \
  -n my_contract \
  -c '{"Args":["yourUpdatedFunction"]}'

You can also check the committed chaincode versions on the channel:

peer chaincode list committed -C mychannel

Critical Things to Remember #

• Versioning Rules: The version string can be any semantic version (e.g., 2.0.1), but the sequence number must strictly increment with each upgrade—Fabric uses this to enforce the order of chaincode changes.
• Backward Compatibility: If your update changes the structure of ledger data (e.g., adding new fields to assets), ensure the new chaincode can read old data. Test this thoroughly before upgrading.
• Application Updates: You only need to modify your application if the chaincode’s function signatures or expected input/output formats changed. Otherwise, your existing app will work seamlessly with the updated chaincode.
• No Data Loss: Ledger data is stored in the peer’s state database, not the chaincode container. Upgrading chaincode doesn’t touch this data, so all your historical transactions and current state stay intact.

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