|
2 | 2 |
|
3 | 3 | This document covers setting up an Openchain network on your local machine for development using Docker containers.
|
4 | 4 |
|
5 |
| -All commands should be run from within the Vagrant environment described [here](https://github.com/openblockchain/obc-docs/blob/master/dev-setup/devenv.md). |
| 5 | +All commands should be run from within the Vagrant environment described in [Setting Up Development Environment](https://github.com/openblockchain/obc-docs/blob/master/dev-setup/devenv.md). |
6 | 6 |
|
7 |
| -**Note:** When running with security enabled, first modify the [openchain.yaml](https://github.com/openblockchain/obc-peer/blob/master/openchain.yaml) to set the security.enabled setting to 'true' before building the peer executable. Furthermore, follow the security setup instructions described [here](https://github.com/openblockchain/obc-docs/blob/master/api/SandboxSetup.md#security-setup-optional) to set up the CA server and log in registered users before sending chaincode transactions. |
| 7 | +**Note:** When running with security enabled, follow the security setup instructions described in [Chaincode Development](https://github.com/openblockchain/obc-docs/blob/master/api/SandboxSetup.md#security-setup-optional) to set up the CA server and log in registered users before sending chaincode transactions. |
8 | 8 |
|
9 |
| -### Setting up an Openchain Docker image |
10 |
| -First clean out any active Openchain containers (peer and chaincode) using "docker ps -a" and "docker rm" commands. Second, remove any old Openchain images with "docker images" and "docker rmi" commands. |
| 9 | +### Setting up Docker image |
| 10 | +To create a Docker image for Open Blockchain, named `openchain`, |
| 11 | +first clean out any active `openchain` containers (peer and chaincode) using `docker ps -a` and `docker rm` commands. Second, remove any old `openchain` images with `docker images` and `docker rmi` commands. |
11 | 12 |
|
12 |
| -Now we are ready to build a new Openchain docker image: |
| 13 | +Now we are ready to build a new `openchain` docker image: |
13 | 14 |
|
| 15 | +``` |
14 | 16 | cd $GOPATH/src/github.com/openblockchain/obc-peer/openchain/container
|
15 | 17 | go test -run BuildImage_Peer
|
| 18 | +``` |
16 | 19 |
|
17 |
| -Check the available images, and you should see "openchain-peer" image. |
| 20 | +Check the available images again with `docker images`, and you should see `openchain-peer` image. |
18 | 21 |
|
19 | 22 | ### Starting up validating peers
|
20 |
| -Find out which IP address your docker0 interface is on with *ip add* command. For example, your output might contain something like *inet 172.17.0.1/16 scope global docker0*. That means docker0 interface is on IP address 172.17.0.1. Use that IP address for the OPENCHAIN_VM_ENDPOINT option. |
| 23 | +From the Vagrant environment, find out which IP address your docker0 interface is on with `ip add` command. For example, |
| 24 | + |
| 25 | +``` |
| 26 | +vagrant@vagrant-ubuntu-trusty-64:/opt/gopath/src/github.com/openblockchain/obc-peer$ ip add |
| 27 | +
|
| 28 | +<<< detail removed >>> |
| 29 | +
|
| 30 | +3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default |
| 31 | + link/ether 02:42:ad:be:70:cb brd ff:ff:ff:ff:ff:ff |
| 32 | + inet 172.17.0.1/16 scope global docker0 |
| 33 | + valid_lft forever preferred_lft forever |
| 34 | + inet6 fe80::42:adff:febe:70cb/64 scope link |
| 35 | + valid_lft forever preferred_lft forever |
| 36 | +``` |
| 37 | + |
| 38 | +Your output might contain something like `inet 172.17.0.1/16 scope global docker0`. That means docker0 interface is on IP address 172.17.0.1. Use that IP address for the `OPENCHAIN_VM_ENDPOINT` option. For more information on the environment variables, see `openchain.yaml` configuration file in the `obc-peer` repository. |
21 | 39 |
|
22 |
| -The ID value of OPENCHAIN_PEER_ID must be lowercase since we use the ID as part of chaincode containers we build, and docker does not accept uppercase. The ID must also be unique for each validating peer. |
| 40 | +The ID value of `OPENCHAIN_PEER_ID` must be lowercase since we use the ID as part of chaincode containers we build, and docker does not accept uppercase. The ID must also be unique for each validating peer. |
23 | 41 |
|
24 |
| -We are also using the default consensus, called NOOPS, which doesn't really do consensus. If you want to use some other consensus plugin, see note 1 below. |
| 42 | +By default, we are using a consensus plugin called `NOOPS`, which doesn't really do consensus. If you want to use some other consensus plugin, see Using Consensus Plugin section at the end of the document. |
25 | 43 |
|
26 |
| -Start up the first validating peer: |
| 44 | +#### Start up the first validating peer: |
27 | 45 |
|
28 | 46 | ```
|
29 | 47 | docker run --rm -it -e OPENCHAIN_VM_ENDPOINT=http://172.17.0.1:4243 -e OPENCHAIN_PEER_ID=vp1 -e OPENCHAIN_PEER_ADDRESSAUTODETECT=true openchain-peer obc-peer peer
|
30 | 48 | ```
|
31 | 49 |
|
32 |
| -Start up the second validating peer: We need to get the IP address of the first validating peer, which will act as the root node that the new peer will connect to. The address is printed out on the terminal window of the first peer (eg 172.17.0.2). We'll use "vp2" as the ID for the second validating peer. |
| 50 | +####Start up the second validating peer: |
| 51 | +We need to get the IP address of the first validating peer, which will act as the root node that the new peer will connect to. The address is printed out on the terminal window of the first peer (eg 172.17.0.2). We'll use "vp2" as the ID for the second validating peer. |
33 | 52 |
|
34 | 53 | ```
|
35 | 54 | docker run --rm -it -e OPENCHAIN_VM_ENDPOINT=http://172.17.0.1:4243 -e OPENCHAIN_PEER_ID=vp2 -e OPENCHAIN_PEER_ADDRESSAUTODETECT=true -e OPENCHAIN_PEER_DISCOVERY_ROOTNODE=172.17.0.2:30303 openchain-peer obc-peer peer
|
@@ -84,3 +103,15 @@ With security enabled, modify the command as follows:
|
84 | 103 | ```
|
85 | 104 | ./obc-peer chaincode query -u jim -l golang -n <name_value_returned_from_deploy_command> -c '{"Function": "query", "Args": ["a"]}'
|
86 | 105 | ```
|
| 106 | + |
| 107 | +### Using Consensus Plugin |
| 108 | +A consensus plugin might require some specific configuration that you need to set up. For example, to use Byzantine consensus plugin provided as part of Open Blockchain, perform the following configuration: |
| 109 | + |
| 110 | +1. In `openchain.yaml`, set the `peer.validator.consensus` value to `obcpbft` |
| 111 | +2. In `openchain.yaml`, make sure the `peer.id` is set sequentially as `vpX` where `X` is an integer that starts from `0` and goes to `N-1`. For example, with 4 validating peers, set the `peer.id` to`vp0`, `vp1`, `vp2`, `vp3`. |
| 112 | +3. In `consensus/obcpbft/config.yaml`, set the `general.mode` value to either `classic`, `batch`, or `sieve`, and the `general.N` value to the number of validating peers on the network (if you do `batch`, also set `general.batchsize` to the number of transactions per batch) |
| 113 | +4. In `consensus/obcpbft/config.yaml`, optionally set timer values for the batch period (`general.timeout.batch`), the acceptable delay between request and execution (`general.timeout.request`), and for view-change (`general.timeout.viewchange`) |
| 114 | + |
| 115 | +See `openchain.yaml` and `consensus/obcpbft/config.yaml` for more detail. |
| 116 | + |
| 117 | +All of these setting may be overriden via the command line environment variables, eg. `OPENCHAIN_PEER_VALIDATOR_CONSENSUS=obcpbft` or `OPENCHAIN_OBCPBFT_GENERAL_MODE=sieve` |
0 commit comments