Run a simple Fabric Network on the IBM Container Service

The scripts here will deploy a sample Fabric Network on the IBM Container Service. The are using the docker images hyperledger/fabric-peer, hyperledger/fabric-orderer, hyperledger/fabric-ccenv and hyperledger/fabric-tools. The config used to configure the network can be found here. The scripts install the EVM chaincode that can be found here. The instructions below will also cover creating a Go SDK configuration file that can be used with Fab3 enabling the use of the web3 library to deploy Solidity Smart contracts to Fabric.

Run your own network:

Prequisites

• Have a one node Kubernetes cluster up and running on the IBM Container Service
• kubectl is configured to talk to your cluster. You can do this by using the Bluemix CLI and running bx cs cluster-info <cluster-name>. Export the config file that is the output of that command for kubectl to be configured to talk to your cluster.
• Have at least Go 1.10.x installed.

Directions

Set up the Cluster

1. Make sure you have all the prerequisites. The scripts will deploy a 2 Peers (1 for each Org) and 1 orderer. The scripts will also setup a channel with the id mychannel, create credentials needed to talk to the network, and finally installs & instantiates the EVM CC. Run the following from the root of this repo:

  $ cd cs-offerings/scripts
  $ ./create_all

1. Next the credentials created on the cluster need to be copied locally to communicate with the deployed fabric network.

  $ kubectl get pods
  NAME                                    READY     STATUS    RESTARTS   AGE
  blockchain-org1peer0-<uuid>   1/1       Running   0          20d
  blockchain-org2peer0-<uuid>   1/1       Running   0          20d
  blockchain-orderer-<uuid>     2/2       Running   0          20d

  $ kubectl cp <pod name>:/shared/crypto-config crypto-config

Any of the pods in the fabric deployed can be used to copy the certs.

Setting up the Proxy to Communicate with the Fabric Network

1. Using those credentials update the sample sdk config file (fabric-cluster.yml) to the location of the crypto-config directory that was copied in the previous step. Find and replace <path-to-crypto-config-folder> in the file.
2. Update the cluster ip in the sample sdk config file to the cluster ip of your Kubernetes cluster. You can run the following to get the cluster ip:

 $ bx cs workers <cluster-name>
 ID                                                 Public IP        Private IP     Machine Type   State    Status   Zone    Version
 kube-hou02-<uuid>                          <cluster-public-ip>   <cluster-private-ip>   free      normal   Ready    hou02   1.8.8_1507*

With the <cluster-public-ip> grabbed from the Bluemix CLI, use that to replace all instances of <cluster-public-ip> found in fabric-cluster.yml

1. Clone the repo https://github.com/hyperledger/fabric-chaincode-evm
2. Go to the root of that repo and run the following to start the proxy locally at port 5000:

FABPROXY_CONFIG=<path-to-this-repo>/fabric-cluster.yml go run main.go

To customize the proxy more you can use the follow environment variables:

PORT              -- Proxy will run on the port specified on the environment variable. Default is 5000.
FABPROXY_ORG      -- Proxy will use the org specified. It will expect the user
is of this org.
FABPROXY_USER     -- Proxy will use the user id specfied on the environment variable. The user id corresponds to the name of the directories under the crypto-config/peerOrganizations/org1.example.com/users/.
FABPROXY_CHANNEL  -- Proxy will use the channel specified on the environment variable. For this deployment it should be mychannel.
FABPROXY_CCID     -- The chaincode id of the EVM Chaincode that has been
installed. For this deployment it should be evmcc.

Deleting the Cluster

1. Run scripts/delete_all To delete run scripts/delete_all.

Privacy Notice

For serviceability needs regarding the number of network activity, IBM has added a mechanism in the ordering service to collect a "pulse" from the networks. The UUID of a network is collected periodically and sent to a monitoring service, there is no blockchain or transaction information or data gathered or accessed. The only purpose is to provide information on activity passing through the ordering service.

The UUID is generated by the network randomly when the orderer comes up and is not attached to any further network information. The UUID is re-generated and old UUID lost whenever the ordering service is restarted.