单组织场景下本地部署配置Hyperledger网络并迁移至Azure Hyperledger Fabric

Got it, let's walk through how to set up a Hyperledger Fabric network locally first, then migrate it to Azure's single-organization Hyperledger Fabric environment. I’ve done this a handful of times, so I’ll break it down into clear, actionable steps.

Start with a solid local foundation—this ensures you have a working baseline before moving to Azure.

• Prepare your local environment
  Install all required tools first: Docker, Docker Compose, Go (1.18+ recommended), and the Hyperledger Fabric binaries/images. Use the official script to grab consistent versions:

  curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.5.2 1.5.2
  

  Verify Docker is running with docker --version and docker-compose --version to avoid setup headaches later.

• Spin up a single-org test network
  Use the official Fabric samples to avoid building from scratch. Clone the repo and launch the test network with a Certificate Authority (CA):

  git clone https://github.com/hyperledger/fabric-samples.git
  cd fabric-samples/test-network
  ./network.sh up createChannel -c mychannel -ca
  

  This starts an orderer, a peer node for Org1, creates a channel named mychannel, and sets up a CA for identity management.

• Test the local network
  Deploy a sample asset-transfer chaincode to validate functionality:

  ./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go
  

  Then switch to the application directory and run the test client:

  cd ../asset-transfer-basic/application-go
  go run .
  

  You should see output showing assets being created, queried, and updated—confirm this works before moving on.

• Export critical network artifacts
  Save these files to a safe place—you’ll need them for migration:

  • Channel genesis block: fabric-samples/test-network/channel-artifacts/mychannel.block
  • Org1 MSP files: fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/ (contains CA certs, admin identities, etc.)
  • Connection profile: fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/connection-org1.yaml
  • Packaged chaincode: If you want to reuse the same chaincode, package it locally with peer lifecycle chaincode package basic.tar.gz --path ../asset-transfer-basic/chaincode-go --lang golang --label basic_1.0

Now let’s move that working network to Azure. Azure’s managed Fabric service handles infrastructure, so you just need to align your local artifacts with Azure’s setup.

• Create an Azure Hyperledger Fabric cluster
  Head to the Azure Portal, search for "Hyperledger Fabric", and create a new cluster. Choose the Single Organization deployment mode. Configure:

  • Organization name (match your local Org1 name if possible, e.g., org1.example.com)
  • CA setup: You can use Azure’s managed CA, or select "Import existing CA" if you want to reuse your local CA certs.
  • Node counts: For testing, 1 orderer and 1 peer node are sufficient.
    Wait for the cluster to provision (this can take 10-15 minutes).

• Import local MSP and certificates
  Azure uses Azure Key Vault to manage certificates. Upload your local Org1 MSP files (CA cert, TLS CA cert, admin cert) to a Key Vault in the same resource group as your Fabric cluster. Then, in the Azure Fabric cluster’s organization settings, associate these Key Vault secrets with your organization’s MSP configuration. This ensures Azure’s nodes recognize your local identities.

• Migrate channel and chaincode

  1. Create the channel in Azure: Upload your local mychannel.block to Azure Storage, then use the Azure Fabric CLI or Portal to create a new channel using this genesis block. This ensures the channel matches your local setup exactly.
  2. Deploy the chaincode: Upload your packaged basic.tar.gz to Azure Storage. Then use the Azure CLI to install the chaincode on your peer node, approve the chaincode definition for your organization, and commit it to the channel—these steps mirror the local peer lifecycle commands, but target Azure’s nodes.
     Example Azure CLI command to install chaincode:

  az hlf chaincode install --name basic --path ./basic.tar.gz --peer <peer-node-name> --resource-group <your-rg> --cluster-name <your-cluster>
  

• Update the connection profile
  Modify your local connection-org1.yaml to point to Azure’s node endpoints:

  • Replace the peer and orderer addresses with the FQDNs of your Azure Fabric nodes (found in the Azure Portal under your cluster’s nodes tab)
  • Update the CA address to point to Azure’s managed CA (or your imported CA)
  • Update certificate paths to reference the Key Vault secrets (or use Azure’s built-in identity management)

• Validate the migrated network
  Use Azure Cloud Shell to run test commands against the Azure network, just like you did locally:

  peer chaincode query -C mychannel -n basic -c '{"Args":["GetAllAssets"]}'
  

  You should see the same asset data as your local network. Try updating an asset too, to confirm write operations work.

• Version alignment: Ensure your local Fabric version matches Azure’s supported version (check Azure docs for the latest supported versions—2.5.x is a safe bet right now). Mismatched versions cause cryptic errors.
• Key Vault permissions: Make sure your Fabric cluster has access to the Key Vault where you stored your certificates. Use Azure RBAC to assign the Key Vault Secrets User role to the cluster’s managed identity.
• Chaincode dependencies: If your chaincode uses third-party Go modules, make sure they’re included in the packaged chaincode, or that Azure’s chaincode runtime can access them (use go mod vendor to package dependencies locally).
• Network security: Configure your Azure NSG to allow inbound traffic on Fabric ports (7050 for orderer, 7051 for peer) from your client IP address.

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