Name: hyperledger-ibmcs
Owner: HM Land Registry
Description: Deploy Hyperledger Fabric & Composer to IBM Container Services using Kubernetes
Forked from: idpattison/hyperledger-ibmcs
Created: 2017-12-06 14:42:32.0
Updated: 2018-01-18 09:31:30.0
Pushed: 2017-12-18 10:51:16.0
Homepage: null
Size: 32
Language: Shell
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
The transaction_backend app built for the Digital Street hack day needs to communicate with Hyperledger Fabric via Hyperledger Composer. It was built to be compatible with Composer 0.13.1 with respect to the way it authenticates (connection profiles with certificates). However as of version 0.15 the authentication method has completely changed, to be via all-encompassing “cards” that need to be loaded into the environment using the Composer CLI. While we can export cards from Composer Playground and change the app to use them, when deployed to a cloud machine outside of our control there is currently no easy way to use the composer CLI to load cards and make them available to the app, and no way to use environment variables instead like we do for connection profiles (see this issue). There were other breaking changes in 0.14 too with respect to access control in the business network itself that means the easiest option is to carry on using 0.13.1.
These instructions and scripts were designed to work with that version (the maintained ones that work with the latest versions are here) and so we have modified them to simplify deployment (only one peer) and pin them to 0.13.1 images.
The following instructions have been copied and modified (to deal with the fact we are working with an older version) from here
As you'll be interacting with Kubernetes, IBM Bluemix and Hyperledger Composer, you need to install three command line tools:
Install node
from here - or using brew is easier on a Mac.
Install kubectl
from here choosing the option of your choice
Install bx
from
here.
Validate the installations with node --version
, kubectl version
and bx -v
.
Now add the container service plugin - this will let you interact with the IBM Container Service. Add the repo first (this tells the following command where to find the plugin to be installed) - you may get a message saying it already exists, if so that's fine.
lugin repo-add bluemix https://plugins.ng.bluemix.net
lugin install container-service -r bluemix
Install the Hyperledger Composer CLI tool with
install -g composer-cli@0.13.1
Clone this git repository and transaction_backend to your local machine if you haven't already and cd into this one.
Point the Bluemix CLI at the (UK) API endpoint, then login
pi api.eu-gb.bluemix.net
ogin
This will ask for your IBM ID and the account password.
You will be asked to select the number of an account (if using the our main one it's 1 - HM Land Registry). You also need to set an org and a space. Assuming these have already been set up in the web UI, you can just run the following (our main ones are HMLR Digital Street / dev)
arget --cf
Now create the cluster on the IBM Container Service
s cluster-create --name cluster_name_here
This could take up to 30 minutes. You can check progress with
s clusters
Once the State shows normal, it's done. You should see something like this:
ing clusters...
ID State Created Workers
ter_name_here 0783c15e421749a59e2f5b7efdd351d1 normal 2017-05-09T16:13:11+0000 1
Once that's done, you can check the status of the worker node:
s workers cluster_name_here
This will show the public and private IP addresses. Note down the public IP address, as you will use this later to access the Blockchain network.
Issue the following command
s cluster-config cluster_name_here
The output will contain an EXPORT
command which will point your local kubectl
to the cluster. Copy and paste that command into the command line and run it. It will be something like this:
rt KUBECONFIG=/home/*****/.bluemix/plugins/container-service/clusters/cluster_name_here/kube-config-prod-dal10-blockchain.yml
If you open any more command windows at a later date you may need to rerun that.
The kube-configs directory defines a Blockchain implementation which consists of:
To deploy the Blockchain:
cripts
eate_all.sh --with-couchdb
Once that's complete you can use the Kubernetes Dashboard to explore the services and pods which have been created. Run
ctl proxy
Now browse to here and you will see the dashboard.
You can get all of this information from the command line (try kubectl get pods -a
), but it's convenient to have it all just a few clicks away.
We're going to deploy the business network, but to do that we need a connection profile to tell our local Hyperledger Composer CLI where to deploy it. Local connection profiles are stored in ~/.composer-connection-profiles/ by default.
Create a new connection profile directory for IBM Container Services and copy the example profile.
r ~/.composer-connection-profiles/ibmcs
rofile/connection.json ~/.composer-connection-profiles/ibmcs
Edit it to use the public IP address of your container cluster - the one from bx cs workers cluster_name_here
.
To use this cluster with the transaction_backend deployed to Bluemix, the public IP must be placed in the connection profile environment variable defined in it's manifest.yml.
When the Hyperledger instance was deployed to IBM Container Service, a set of cryptographic credentials was created. We need to copy some of those off the peer so we can connect to it locally.
Start by getting the container name of the Org1 peer - it will be something like blockchain-org1peer1-1820571918-bdqrv.
ctl get pods
Now extract two files from that peer - these are the certificate and key for the admin user. You need to use the container name you found in the previous step.
ctl cp blockchain-org1peer1-xxxxxxxxxx-xxxxx:/shared/crypto-config/peerOrganizations/org1.example.com/users/Admin\@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem cert.pem
ctl cp blockchain-org1peer1-xxxxxxxxxx-xxxxx:/shared/crypto-config/peerOrganizations/org1.example.com/users/Admin\@org1.example.com/msp/keystore/key.pem key.pem
Import that identity into the local credential store, creating a new identity to use them with at the same time (called PeerAdmin). Clear out the store first to remove any old keys.
rf ~/.composer-credentials/*
oser identity import -p ibmcs -u PeerAdmin -c cert.pem -k key.pem
The three files that this command creates are the files you will need to upload to Bluemix's Object Storage to allow the deployed transaction_backend to connect to this cluster.
Make sure that composer-cli is version 0.13.1, or you will get compatibility errors. Run the following commands from the transaction_backend directory:
oser archive create -a hmlr-network.bna -t dir -n hmlr-network/
oser network deploy -a hmlr-network.bna -p ibmcs -i PeerAdmin -s anything
NB: if you want to update an existing business network you need to use
composer network update
:
When the Composer REST server starts, it reads the model information from the business network which is deployed in the Blockchain. Therefore you can't start it until after you have deployed the business network.
That's the reason we didn't deploy the REST server along with all the other services; we're going to do that now.
Run the following command, adding in your business network name (that's the one defined in the package.json file, not necessarily the file name).
eate/create_composer-rest-server.sh org-acme-biznet
Examine the running pods (either with the Kubernetes Dashboard or kubectl get pods
) to see that the REST server has started. View the logs from the Dashboard (or use kubectl logs <container-name>
) to ensure that it is serving on port 3000 - this will be exposed externally as port 31090.
Now access the Composer REST server explorer; browse to http://your-ip-address:31090/explorer
Congratulations! You've successfully deployed a Hyperledger Fabric Blockchain and a business network to IBM Container Services, and exposed it as an API.
If you want to start from scratch you can remove the containers you deployed via Kubernetes with a single script.
cripts
lete_all.sh
However there are some things left over so you should use your web browser to visit the kubernetes proxy described earlier and delete two Persistent Volume Claims (from the Overview page) and two Persistent Volumes (from the Persistent Volumes page).