Networking
The Nerve Data Gateway can be used to connect to data sources and sinks over the network, as well as to connect to applications that run locally on the same edge device.
External connections can simply be addressed using standard mechanisms like IP addresses or urls.
Connecting to applications that run locally on the same edge device can be done using a custom docker network. However, using a complete custom docker network might lead to issues when undeploying workloads. A custom network needs to be created in one workload (either the Nerve Data Gateway or the connected application) and is then used in the other workload as external network. This will lead to an issue when trying to undeploy the workload that created the network while the other workload is still using it. In the default workload, the Nerve DataGateway application creates the datagateway_network network.Other applications can use this network as external network in the compose file. In this case make sure, that the applications that use the network are always undeployed before the Nerve Data Gateway is undeployed.
A more convenient way to connect local applications to the Nerve Data Gateway is to use one of the isolated networks provided by the Nerve platform. By default, the Data Gateway is connected to the isolated1 network. So another application that is connected to the isolated1 network ( use external: true for the isolated1 network in the Docker Compose file ) can be addressed by the Data Gateway via container name resolution.
Isolated networks are automatically created by the Nerve platform and are not removed when a workload is undeployed. This will avoid any issues with undeployment.
For security reasons, the Nerve Data Gateway does not connect to any isolated network by default, because only the Nerve operator knows which networks are already in use, and it should be avoided to connect containers that do not need to communiciate.
When using a custom network to connect the Data Gateway to another application, or when using a network other than isolated1, isolated4 and isolated5, first add the network to the networks section of the Data Gateways Docker Compose file (example with customnetwork):
...
networks:
isolated4:
external: true
isolated5:
external: true
isolated1:
external: true
customnetwork:
driver: bridge
datagateway_network:
driver: bridge
services:
...
Then connect all protocol handler (all services with service names that end in handler) to the desired network:
...
services:
...
opcuaclienthandler:
...
networks:
...
customnetwork:
...
mqttclienthandler:
...
networks:
...
customnetwork:
...
IP addresses and potential conflicts
The application is implemented in a microservices architecture that uses the isolated networks provided by Nerve for internal communication between the services. To maximize the tolerance of the application in case of intentional and unintentional restarts, the services use fixed IP addresses instead of name resolution. Those IP addresses are hardcoded via the docker compose file of the Data Gateway. By default, the following networks are used:
isolated5for Gateway-internal data communication between the servicesisolated4for Gateway-internal configuration of the servicesisolated1to access other workloads from the gateway via an isolated network
The standard Docker Compose file, as it is part of the Data Gateway release package, is configured for a standard Nerve installation where isolated5 uses the network 172.20.80.0/24, isolated4 uses the network 172.20.76.0/24 and isolated1 uses the network 172.20.64.0/24. Since Nerve release 3.0.1, docker network range can be changed either during Nerve installation or via Nerve Node DNA to avoid conflicts with connected physical networks. If this is the case, all occurrences of IP addresses in the Docker Compose file must be changed to match the network addresses as they are used on the particular nodes.
The services always use the last 3 IP addresses that are available within the particular network: <251-253>. So e.g. on a standard Nerve installation, on isolated5 network, the Data Gateway uses the addresses 172.20.18.80.<251-253>. If any other workload uses any of those addresses, this will result in an IP address conflict. In this case either the Data Gateway and the other application cannot be deployed together. To resolve this, adapt the other workload to use a different IP address (ideally avoid using any IP address 245 or higher within the isolated networks 1, 4 and 5). This is to avoid conflicts in the future as the Data Gateway might use additional services in future releases. If for any reason the conflict cannot be resolved by adapting the other application, the only way is to adapt the Docker Compose file of the Data Gateway. In this case search the Docker Compose file for all occurrences of the particular IP address and replace them by an available address within the particular network.
Whenever changing an IP address in the Data Gateway's Docker Compose file it is very important to change all occurrences of that IP address.