Test deploy your CorDapp with Corda network bootstrapper

Corda Jul 29 2022 By: Peter Li
Comments

0 Comments

Views

219 Views

Test deploy your CorDapp-with-corda network bootstrapper
Peter Li
Peter Li Senior Developer Evangelist
Share this post:
Copied

The Corda network bootstrapper is a tool that allows you to quickly bootstrap a Corda test network. The reason it is only recommended to be used as a test network is that it uses all the development java keystores to sign the nodes, CorDapp, transactions, etc as default. And managing to upgrade the development keystore to production keystore is not supported out of the box. The Corda network bootstrapper primarily comes in handy when you plan to deploy your CorDapp into virtual machines to present a demo or PoC. In this article, we will be walking through the steps of setting up Corda network with the network bootstrapper tool.

Using network bootstrapper locally

Pre-deployment

1. Download the Corda Network Bootstrapper from here.

2. Prepare the node.conf file for each. Here is a sample config. (This template is for local deployment. We will show another example of remote deployment in the later section of this blog)


devMode=true
myLegalName="O=PA,L=London,C=GB"
p2pAddress="localhost:10007"
rpcSettings {
    address="0.0.0.0:10008"
    adminAddress="0.0.0.0:10108"
    standAloneBroker=false
    useSsl=false
}
security {
    authService {
        dataSource {
            type=INMEMORY
            users=[
                {
                    password=password
                    permissions=[
                        ALL
                    ]
                    user=user1
                }
            ]
        }
    }
}

3. Build and place the CorDapps next to the node.config files.

The project folder should look like this:


. 
├── network_Bootstrapper.jar    // The Corda Network Bootstrapper
├── notary_node.conf            // The notary's node.conf file 
├── partya_node.conf            // Party A's node.conf file 
├── partyb_node.conf            // Party B's node.conf file 
├── cordapp-a.jar               // A cordapp to be installed 
└── cordapp-b.jar               // Another cordapp to be installed

Run the bootstrapper



java -jar corda-tools-network-bootstrapper-4.9.jar

Result folder structure

Based on the input of the network bootstrapping process, you should be expecting the following items in the result folder.


. 
├── network_Bootstrapper.jar    
├── notary_node.conf            
├── partya_node.conf            
├── partyb_node.conf            
├── cordapp-a.jar    
├── cordapp-b.jar
├── checkpoints_xxxxxx.log       //Logs of bootstrapping
├── diagnostic-xxxxxxx.log       //Logs of bootstrapping
├── node-xxxxx.log               //Logs of bootstrapping
├── Notary                       //Notary's folder
├── PartyA                       //PartyA's folder
└── PartyB                       //PartyB's folder

Post bootstrapping

Before we can start the node and run our app in the terminal, we have to do another step. (It is optional) We need to installed the standalone-node-shell to the node. There are two options to do so:

  1. Copy/paste the driver’s folder from any samples. (It will appear in the node directory after deployNodes)
  2. Download the standalone node shell and run it separately in another terminal. Instruction here.

Run the app

Rather than having the option of running all the nodes together (as shown in all the samples), you will have to start each node manually. Go into each node folder and run:


Java -jar corda.jar

Your nodes will be up. And now you have a local bootstrapped network!

Using the network bootstrapper with VMs

Step 1: Create a VM, and get the public IP address. (For the simple demo purpose, I disabled all the security rules, allowing all inbound and outbound traffic to these VMs. Never do this in production!)

Using the network bootstrapper with VMs

Step 2: Install java 1.8 at the VM


sudo apt-get update
sudo apt-get install openjdk-8-jdk

Step 3: Bootstrap the Corda network (generating all the node files)

Except for this time, we will need to modify the node.config files with the VM’s public IPs. For example, we designate the above VM (13.71.147.131)to host node A. We will put the public IP in the p2pAddress field.


devMode=true
myLegalName="O=PA,L=London,C=GB"
//remote VM address
p2pAddress="13.71.147.131:10007"
rpcSettings {
    address="0.0.0.0:10008"
    adminAddress="0.0.0.0:10108"
    standAloneBroker=false
    useSsl=false
}
security {
    authService {
        dataSource {
            type=INMEMORY
            users=[
                {
                    password=password
                    permissions=[
                        ALL
                    ]
                    user=user1
                }
            ]
        }
    }
}

Step 4: Paste the standalone node shell drivers into the node folders (described above)

Step 5: Drop the node folder to the designated hosting VMs.


scp -r ./PartyA user@13.71.147.131:./ 

We are dropping PartyA’s entire folder to the VM home directory.

Step 6: Go into the node folder and run the node (Same as local deployment)


Java -jar corda.jar

You will need to perform the exact same procedure for PartyB and Notary. Once you start both nodes and notary service, you should have successfully deployed a test Corda network on remote VMs.

DevModes

devMode must be disabled on all production nodes. In development mode (i.e. when devMode = true), the certificates the directory is filled with pre-configured keystores if they do not already exist to ensure that developers can get the nodes working as quickly as possible. More details.

You can in fact turn the devMode to false by changing the node.config flag to false:


devMode=false 
myLegalName="O=PA,L=London,C=GB"
//remote VM address
p2pAddress="13.71.147.131:10007"
rpcSettings {
    address="0.0.0.0:10008"
    adminAddress="0.0.0.0:10108"
    standAloneBroker=false
    useSsl=false
}
security {
    authService {
        dataSource {
            type=INMEMORY
            users=[
                {
                    password=password
                    permissions=[
                        ALL
                    ]
                    user=user1
                }
            ]
        }
    }
}

However, this will need a few additional steps to ensure your CorDapp continues to function normally.

Step 1: You will have to sign the CorDapp with a non-dev key, more specifically we only care about the contracts.jar. And, FYI, the workflow jars typically do not need to be signed with any keys. So how do you sign the contract jars? You can simply use the Gradle to do it. Just edit the build.gradle file for the contracts package:


cordapp {
    targetPlatformVersion corda_platform_version
    minimumPlatformVersion corda_platform_version
    contract {
        name "4.8LTS Tutorial Contracts"
        vendor "Corda Open Source"
        licence "Apache License, Version 2.0"
        versionId 1
    }
    signing {
        enabled true
        options {
            Properties constants = new Properties()
            file("$projectDir/../gradle.properties").withInputStream { constants.load(it) }
            keystore getProperty('jar.sign.keystore')
            alias "cordapp-signer"
            storepass getProperty('jar.sign.password')
            keypass getProperty('jar.sign.password')
            storetype "PKCS12"
        }
    }
}

and the gradle.preperties the file will have the information of the place of Keystore and the password:


jar.sign.keystore=/Users/admin/corda/corda4/networkBootstrap
per/certificates/jarSignKeystore.pkcs12 
jar.sign.password = bootstrapper

See the full tutorial of signing a CorDapp jar here. Once you have the CorDapp jars correctly signed, simply replace the old CorDapp jars with the lately signed jars.

Step 2: You will have to either use the standalone-node-shell outside of the starting terminal or use ssh to connect to the node because a devMode=false node does not allow shell interface upon start. More standalone-node-shell details refer to here. But in this blog, we will simply use the ssh connection. We need to modify the node.config once again, set a port at 2222.


devMode=true
myLegalName="O=PA,L=London,C=GB"
//remote VM address
p2pAddress="13.71.147.131:10007"
rpcSettings {
    address="0.0.0.0:10008"
    adminAddress="0.0.0.0:10108"
    standAloneBroker=false
    useSsl=false
}
security {
    authService {
        dataSource {
            type=INMEMORY
            users=[
                {
                    password=password
                    permissions=[
                        ALL
                    ]
                    user=user1
                }
            ]
        }
    }
}
sshd {
    port = 2222
}

Now we are ready to run the node with devMode=false. Since we are not expecting any shell interaction, we will just run it in the background.


Java -jar corda.jar &
ssh -p 2222 localhost -l user1

Then it will prompt you for the node user’s password. Then you are in!


In summary, this blog teaches:

  1. How to use the Corda Network Bootstrapper to test and deploy a local Corda network.
  2. How to use the Corda Network Bootstrapper to test and deploy a Corda network onto remote VMs.
  3. How to set the devMode of a Corda node to false.

Last Note: A Corda Node with devMode set to false does not mean it is production use ready. A production-level Corda network is more about setting up all the certificates, signing components, network identities, and network management. If you are interested to deploy your CorDapp to a production level, please contact us at: devrel@r3.com.

We would love to help!

Peter Li
Peter Li Peter Li is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Leave a Reply

Subscribe to our newsletter to stay up to date on the latest developer news, tools, and articles.