Container Networking Models for Inter-Service Communication

In this lesson, you will learn how to architect communication between .NET containers by leveraging bridge networking to allow isolated services to discover and talk to each other.

The Mechanics of Bridge Networking

When you deploy multiple .NET services (e.g., an OrderService and a ProductService) via Docker, they operate within isolated network namespaces. By default, they cannot reach each other via localhost. To solve this, we define a user-defined bridge network. In this model, the Docker daemon acts as a virtual switch, assigning each container an internal IP while managing an internal DNS resolver.

When containers share a bridge network, they can resolve each other by their container name instead of ephemeral IP addresses.

Implementation Strategy

Imagine your OrderService needs to call your ProductService. Instead of hardcoding an IP, you configure your HttpClient to use the container name as the hostname.

1. Define the Network: docker network create my-app-net

2. Run Containers on the Bridge:

   docker run -d --name product-service --network my-app-net my-product-image
   docker run -d --name order-service --network my-app-net my-order-image
   

3. Inter-Service Communication in .NET: In your OrderService code, you configure the HttpClient base address using the container name:

   // Inside OrderService, calling ProductService
   var httpClient = new HttpClient();
   // The DNS name 'product-service' is resolved via the Docker bridge
   var response = await httpClient.GetAsync("http://product-service:80/api/products");
   

Architectural Considerations

This approach relies on the embedded DNS server within the Docker bridge. Because the services are on the same virtual subnet, they can communicate securely without exposing ports to the host machine unless explicitly mapped with -p. This keeps your internal traffic "off the wire" of the host network, reducing overhead and improving security. When scaling beyond a single host, however, this model serves as the architectural foundation for more complex overlay networks used in orchestration tools like Kubernetes.

Key Takeaway: By placing containers on the same user-defined bridge network, you enable internal DNS resolution, allowing .NET services to communicate reliably using their container names as stable network hostnames.