# How to deploy a Daml Driver for Corda ledger in distributed mode

**URL:** <https://forum.canton.network/t/how-to-deploy-a-daml-driver-for-corda-ledger-in-distributed-mode/2499>\
**Category:** Outreach\
**Tags:** from DA support, corda, driver\
**Created:** [April 21, 2021, 1:18pm UTC](https://forum.canton.network/t/how-to-deploy-a-daml-driver-for-corda-ledger-in-distributed-mode/2499 "2021-04-21T13:18:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zsolt\_Holman](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/zsolt_holman/32/2075_2.png) [@Zsolt\_Holman](https://forum.canton.network/u/Zsolt_Holman)\
**Post date:** [April 21, 2021, 1:18pm UTC](https://forum.canton.network/t/how-to-deploy-a-daml-driver-for-corda-ledger-in-distributed-mode/2499/1 "2021-04-21T13:18:23Z")

</div>

# How to deploy a Daml Driver for Corda ledger in distributed mode

Following the instructions of **README.pdf** packaged into the artifact bundle, one can easily deploy an environment for evaluation purposes. The shipped configuration enables local deployment mode by default. Distributed deployment assumes minor tailoring of config files on each node. Bootstrap script checks a bunch of components to be ready (including docker-compose, postgresql, java: currently only up to **Java version 1.8** accepted). The script generates a directory **/tmp/deployment** where network scripts will take place.

## Demo deployment architecture

We have 3 different _types_ of nodes: a **Site** node, a **Notary** node, and an **NMS** node.

### **Site**  **node**

- A ledger API.
- An associated IndexDB, that the ledger API needs to be able to talk to.
- A Corda node.
- An associated Vault DB, that the Corda subsystem needs to be able to talk to.

### **Notary**  **node**

- A corda node specially configured as a notary. Every Corda node needs to be able to talk to this.
- An associated Vault DB.

### **NMS**  **node**

- An instance of **Cordite**. Every Corda node needs to be able to talk to this when it turns on.

There are multiple connections between nodes that need to be properly configured and checked.

 ![DD4C - demo deploy](https://canada1.discourse-cdn.com/flex028/uploads/daml/original/2X/0/0ca09f5dc6c5a1c229f671c8d090e1fd75ce71a9.png)  
If any of those lines of communication are broken, the Ledger API isn’t going to come up healthy. The configs exist to configure those lines of communication.

## No ports are exposed from the containers

Distributed deployment assumes proper network connection among hosts involved in, otherwise the following erroneous Docker output might occur:

```
$ docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
NAMES STATUS PORTS
nodenode3-tribeca-corda Up 3 minutes (health: starting)
nodenode3-tribeca-ledgerapi Up 3 minutes (health: starting)
nodenode3-tribeca-index-db Up 3 minutes (healthy)
nodenode3-tribeca-vault-db Up 3 minutes (healthy)

```

And the containers are going down after sometime with error

```
[INFO] 2021-03-24 03:09:19.798 - Retrying Corda Subsystem (Attempt 50) ...
[ERROR] 2021-03-24 03:09:29.800 - Corda subsystem unreachable before timing out, exiting.

```

### Proper network setup of featuring hosts

Check logfiles that could be involved in:

```
/host3/deployment/Nodenode3-tribeca/ledgerapi/logs/20210325_125554.143550495_init.log
/host3/deployment/Nodenode3-tribeca/corda/logs/20210325_125553.806181382_init.log
/host2/deployment/Nodenode2-moorgate/ledgerapi/logs/20210325_125535.245255904_init.log
/host2/deployment/Nodenode2-moorgate/corda/logs/20210325_125534.960059960_init.log
/host1/deployment/NetMan/nms/logs/20210325_125515.927446489_init.log
/host1/deployment/Nodenode1-pembroke/corda/logs/20210325_125515.139796735_init.log

```

Look for ERROR messages in the logs as above:

### Corda log

`[ERROR] 2021-03-25 13:24:22.961 - NMS Service unreachable before timing out, exiting.`

### Ledger API log

`[ERROR] 2021-03-25 13:03:55.576 - Corda subsystem unreachable before timing out, exiting.`

To test network connectivity, you could **ssh** into the host running **node2** or **node3** and run

`​curl < *ip_NMS* >:< *port_NMS* >`

to reach **node0** NMS.

### Possible causes

- Firewall settings on either host are preventing communication.
- There’s an issue with the configuration.
- There’s a bug with the bootstrapper.
- Its databases didn’t come online.
- The Notary (Pembroke) was not reachable.
- The NMS service was not reachable.