By definition, distributed application components need to communicate with one another. Container technologies encourage developers to make these interconnection points explicit and provide a number of mechanisms to coordinate or otherwise enable communication between containers.
Consider the database example in the previous section. Once we have established persistent storage for the database server, we also need to consider how database clients will connect to it. In nearly all cases these connections will occur through a socket, ever over the network or locally via UNIX domain socket special file.
(Diagram placeholder - Block for running container, inset for listening port on top of container block, distinct block outside of container showing shared/mapped directories for UNIX sockets.)
Simple non-distributed applications may assume that a database is co-located on the same server and use an established port number, or UNIX domain socket path, as their default access mechanism.
True multi-node distributed applications may host the database as a distinct node in which case communication must occur via the network. Clients that wish to use the database must be made aware of its location, either via explicit configuration or a service discovery mechanism.
The previous example shows a traditional database where a single node allows both socket and port (TCP/IP) connections. If we were to "containerize" the database server and the database client into seperate containers, this would present a slight challenge in the architecture due to the container namespacing. Consider the following image:
In this setup, there are actually two clients. One is containerized and the other is executing from the container host directly. The database is also containerized but isolated by namespacing as well. The database client executing on the host can still communicate with the containerized database server via TCP/IP because Docker has an internal network for containers to communication with each other and the host. Once an interconnection mechanism has been established a container developer must ensure that service containers are properly configured to allow access to these connections.
Some container coordination frameworks, such as Kubernetes, attempt to simplify this use case for containers co-located on a single node by sharing the network port space between node-local containers.
Further details and examples of networking interconnect options for various contaner frameworks and scenarios can be found in the network considerations section of this document.
For non-network connections between containers on a single node, shared filesystem locations, either for domain sockets or actual filesystem content, must be set up at the time the containers are launched. Docker, for example, allow mapping a host directory to a container directory by adding the following argument to the run command:
-v <host_directory>:<container_directory>
In our DB server example, assuming the database maintains a listening UNIX domain socket in "/var/run/postgres" we could launch both our server and client with the following argument included:
-v /var/run/postgres:/var/run/postgres
This will ensure that both the server and client see the same directory content, exported from the host, allowing the client to connect using the expected/default location.
Further details and example can be found in the storage considerations section of this document.
Another iteration on this scenario would be where the database server and clients are on different nodes and require network access to communicate. In this case, you must ensure that Docker not only exposes a port for the database container but that a port is also exposed to the network so other clients can communicate with it.
Notice how in this scenario, the database server is still containerized but the client resides on a different node. For network connections, Docker provides a simple directive in the Dockerfile to expose a port from the running container. For example, to create a Postgres DB server container that listens on the default Postgres port, you would add the following line:
EXPOSE 5432
You then also need to ensure that you perform the port mapping when the container runs using either the -P or -p flags.
Establishing network connection between containers in OpenShift is different from the standard Docker container linking approach. OpenShift uses a built-in DNS so that services can be reached by the service DNS and service IP address. In other words, applications running in a container can connect to another container using the service name. For example, if a container running the MySQL database is a database service endpoint, database will be used as a hostname to connect to it from another container. In addition to DNS record, you can also use the environment variables with IP address of the service which are provided for every container running in the same project as the service. However, if the IP address (environment variable) changes, you will need to redeploy the container. Using service names is therefore recommended.
For details, see OpenShift Documentation.