Application Communication

Network-based application communication offers several advantages over other inter-process communication (IPC) methods such as domain sockets, file systems, or shared memory, especially when dealing with distributed systems.

• It is highly scalable, allowing for communication between processes across different machines and networks. This is essential for building distributed applications that can scale across multiple servers or even geographical locations.
• Network based procotols offers the flexibility to interact across various frameworks, platform and operating systems, e.g. using rest api are typically universally supported, enabling interoperability between diverse systems.

NOTICE

If your application is planning to provide APIs, Industrial Edge recommends using network-based communication.

Default Edge Device Network

Each edge device has a default network proxy-redirect which can be used for communicating with other applications and exposing services.

Warning

The proxy-redirect Docker network exposes your container with all its open ports to other containers connected to this network, regardless of any PORT or EXPOSE declarations.

Unless you need to communicate with the databus or other 3^rd party applications, Industrial Edge recommends creating a new dedicated network and then adding both applications to that network if you want your applications to be better separated.

Container-Internal DNS Resolution

Container IP addresses are usually automatically assigned by Docker at runtime, from a pool of purely host-internal IP address ranges. While a container's IP address stays static during the lifetime of the particular container instance, the exact IP address cannot and should never be predicted. In consquence, if you container needs to communicate with other containers inside the same edge device, connect your and the other application to the same Docker network(s) and then always use DNS names of containers, or better, DNS names of container services.

Service and Container DNS Names

Given the following compose project YAML file,

# nota bene: "version" top-level element is obsolete, see also:
# https://github.com/compose-spec/compose-spec/blob/master/04-version-and-name.md#version-top-level-element-obsolete

name: 'myapp' # optional project name definition, just here for sake of completion of explanation

services:
    myservice: # service container(s) will be named "myapp-myservice-<number>"
        image: 'myimage:v1.2.3'
        restart: always
        mem_limit: 10mb
        networks: # see also: https://github.com/compose-spec/compose-spec/blob/master/05-services.md#networks
            - my-personal-network

networks: # see also: https://github.com/compose-spec/compose-spec/blob/master/06-networks.md#networks-top-level-element
    my-personal-network: # empty object declaration defaults to bridge driver

Docker's embedded DNS resolver will resolve the following DNS names:

1. [Strongly Recommended] myservice.my-personal-network from all containers connected to the my-personal-network.
2. [Strongly Discouraged] myservice from all containers connected to the same network(s) as myservice, because services from different applications might be attached to the proxy-redirect network with the same, potentially common name, such as database. This results in undefined DNS query resolution behavior.
3. [Discouraged] myapp-myservice-1.my-personal-network and myapp-myservice-1, because this hardwires communication to a particular container instance. First, this bypasses Docker's horizontal service scaling using the (network-qualified) service name. Second, this can result in spurious fails when a service container gets assigned an attempt number different from -1.

Docker's Embedded DNS Resolver

The Docker container engine automatically configures containers connected to Docker networks to use Docker's internal DNS resolver ("server"): this internal DNS server resolves DNS names of containers connected to the same network(s), as the container sending the DNS name query.

If a DNS name queried by a container doesn't match any service or container DNS names that are reachable from the container issuing the DNS query, Docker's embedded DNS resolver automatically forwards the query to the Edge's DNS resolver (systemd-networkd, unless configured otherwise by a device builder). The Edge's DNS resolver then might need to forward the query further to its upstream resolvers.

Info

Docker's embedded resolver cannot know if a currently unknown DNS name would belong to a service or container that just isn't started yet. In consequence, Docker's embedded resolver will always forward any name queries it cannot answer itself. In particular, single "hostname" queries, such as "my-database", might become visible outside an edge device, potentially spuriously triggering network security systems.

Naming Structure

[Must Have] The name by which your service can be reached by other containers is the servicename (don't use container names). To avoid ambiguous addressing and possibly duplicated servicenames, we recommend that you follow the following naming scheme for your servicename:

servicename should be applicationname-containername.

For instance, a nginx service in an application named tetris should have the servicename tetris-nginx.

services:
    tetris-nginx:
        image: 'nginx:latest'
        restart: always
        volumes:
            - './publish/:/publish/'
            - './cfg-data/:/cfg-data/'
        mem_limit: 100mb

NOTICE

The servicename MUST be all lowercase and NO spaces are allowed. So if your application name contains spaces, simply remove them.

Network Use Cases

Incoming Service Communication (External to Service)

[Recommended] For incomming HTTP/HTTPS communication it is recommended to use the Reverse Proxy from Industrial Edge. This can be configured in the Industrial Edge App Publisher which provides additional security measures such as user access.

Intra-App Service-to-Service Communication

• [Strongly Recommended] Two services within the same application can directly communicate without publishing or exposing their service ports.
• [Strongly Recommended] Two services within the same application that are not to be consumed by other applications or services should use their own (custom) Docker bridge network, preferably configured to be "internal" only in order to never expose their ports on the Edge device (see below).
• [Strongly Recommended] You should always refer to services by their servicename, not individual container names.
• [Recommended] Make sure that, if you have set a fixed proxy, you have set a no Proxy ruleset for your internal communication.
• [Recommended] By setting the "internal" option for a network, you will make the network inaccessible from the outside, giving your container some privacy.

NOTICE

Docker Compose defaults to creating a project/application-specific network for your application if you do not explicitly specify one or more networks for your application. The name will be applicationname-default. These project-specific default networks are NEVER "internal".

NOTICE

Docker custom networks that are declared as "internal" are also blocking container IP traffic from leaving the internal network. Additionally, Docker's embedded DNS resolver blocks all DNS name queries that cannot be resolved locally on this internal network, such as global DNS names.

App-to-App Communication

• [Recommended] For app-to-app communication, it is recommended that you use the Industrial Edge Proxy-Redirect network.
• [Strongly Recommended] For time-sensitive data, use the IE-Databus.
• [Recommended] You can use the Alias configuration in Docker Compose to support backwards compatibility of your application.

Outside-to-App Communication

• Same recommendation as App-to-App Communication
• [Cannot] Host ports cannot be used on Industrial Edge. The ports will be accessible from inside the device. However, the firewall will block access to the Host Port from outside the device.

Communication via Shared Files

[Not Recommended] For the following reasons, file sharing is NOT recommended by us:

• No access control: There is currently NO access control in place to verify a container's authentication for file/socket access.
• Potential interference: There is NO guarantee of file persistence and integrity.

References

References
Network Configuration