How do containers connect?

Containers connect by joining pre-configured networks at the moment they are run, allowing them to communicate with other containers, the host system, and the outside world based on the network's configuration.

The Foundation of Container Connectivity

At its core, a container connects to its configured networks when it runs. This means that when you initiate a container, it immediately integrates into one or more predefined network segments. This crucial step is what allows containers to send and receive data, forming the backbone of distributed applications.

For continuity, especially in stateful applications, container platforms manage IP addresses carefully. If a specific IP address was assigned to a container, "if specified, the container's IP address(es) is reapplied when a stopped container is restarted. If the IP address is no longer available, the container fails to start." This ensures that services dependent on stable network identities can resume operation smoothly after a restart, preventing disruptions.

Diverse Network Models for Varied Needs

Containerization platforms like Docker offer various network drivers, each designed for specific use cases, ranging from isolated environments to complex multi-host deployments. Understanding these types is key to efficient container networking.

Here's a breakdown of common container network types:

Network Type	Description	Use Case
Bridge	The default network type for standalone containers. It creates a private, isolated network on the host and uses Network Address Translation (NAT) for external access.	Most common for single-host applications, allowing containers to communicate with each other by name or IP.
Host	The container shares the host's entire network stack, removing network isolation between the container and the host.	High-performance scenarios where network overhead must be minimized, or specific port access is needed without NAT.
Overlay	Enables communication between containers running on different hosts, typically in a cluster (e.g., Docker Swarm, Kubernetes).	Essential for building distributed applications spanning multiple physical or virtual machines, ensuring seamless inter-service communication across a cluster.
Macvlan	Assigns a container its own unique MAC address and IP address, making it appear as a physical device directly on the network.	Useful for integrating containers directly into an existing physical network, often for legacy applications or specific network appliances requiring direct network access.
None	The container is completely isolated from the network, with only a loopback interface.	Running tasks that require no network access (e.g., batch processing that doesn't need external data), or for debugging network-related issues.

How Containers Talk: Internal and External Communication

Once connected to a network, containers can engage in various forms of communication:

Inter-Container Communication:
- Same Custom Bridge Network: Containers connected to the same user-defined bridge network can communicate with each other using their container names as DNS hostnames. For instance, a web_app container can reach a database container simply by using database as the hostname. This simplifies service discovery.
- Service Discovery: In orchestration platforms like Kubernetes or Docker Swarm, built-in service discovery mechanisms allow containers to find and communicate with other services without hardcoding IP addresses, promoting highly decoupled architectures.
Host-to-Container Communication:
- Port Publishing: To allow external access to a containerized application, specific container ports are published or mapped to ports on the host machine. For example, mapping container port 80 to host port 8080 (-p 8080:80) makes the application accessible via http://localhost:8080 from the host or external clients.
Container-to-External Communication:
- Containers on bridge networks typically use Network Address Translation (NAT) to communicate with external resources (like the internet or other servers outside the host). The host acts as a gateway, routing outgoing traffic and forwarding incoming responses.

Setting Up Container Networks: Practical Steps

Managing container networks often involves simple command-line interface (CLI) commands:

Creating a Custom Network:
```
docker network create my_application_network
```
This command creates an isolated bridge network, which is generally preferred over the default bridge for better isolation and built-in DNS resolution.

Connecting Containers to the Network:

# Run a database container on the custom network
docker run --name my_database --network my_application_network -e MYSQL_ROOT_PASSWORD=secret -d mysql:latest

# Run a web application container on the same network, exposing port 80
docker run --name my_webapp --network my_application_network -p 80:80 -d my_webapp_image

In this setup, the my_webapp container can reach my_database using the hostname my_database, thanks to the custom network's DNS capabilities.

Inspecting Networks:
```
docker network ls
docker network inspect my_application_network
```
These commands help in understanding the existing networks, viewing their configurations, and checking which containers are connected.

In summary, container connectivity hinges on their ability to integrate with pre-configured network types upon execution, facilitated by robust IP management and versatile networking models. This foundational mechanism ensures seamless communication within and beyond the container ecosystem.