Docker - DNS Based Inter Container Communication For ASP.NET Core WEB API REST Services - Part Two

If you missed the previous article, which introduced container internal communication using docker IP, see it here.

• Docker Part 1 - IP Based Inter Container Communication for ASP.NET Core WEB API REST Services 🤟

As mentioned in the previous article, you can't depend on IP for internal container communication. It would be better to have a DNS and connect to the containers using that DNS.

 

When we run a container it isn't directly connected to the network adapter of the host machine, but to a Bridge inside docker. Multiple containers can be connected to the same Bridge. DNS option is enabled by default, since automatically the Bridge DNS gets an entry for each container, using the name which has been assigned by Docker. The default Docker Bridge doesn't support this feature and you'll need to create your own Network Bridge to achieve this goal.

 

NB
Please make a note that Bridge networks can be created for single host and overlay networks can be created for multiple hosts. Here I am using Bridge as I have my own single host machine.

 

Creating Your Own Docker Network Bridge

 

I ran the command "docker network create jaish-container-network", which has created my own network bridge "jaish-container-network" inside my local docker service host.

 

I could confirm it by running  "docker network ls" as below.

 

 

 

Now you need to enable container orchestration inside your VS 2019 service projects

 

Enable Container Orchestration

 

You need to right click on project in Visual Studio 2019 and choose below options.

 

 

 

You need to do this with both service projects and then you will get a separate project like below. Please notice docker-compose.yml in it, where we will mention that the containers should use above created "jaish-container-network" as docker network.

 

 

 

You need to modify docker-compose.yml content for both service projects as below.

 

ServiceTwo docker-compose.yml

version: '3.4'

services:
  servicetwo:
    image: ${DOCKER_REGISTRY-}servicetwo
    container_name: servicetwo

    build:
      context: .
      dockerfile: ServiceTwo/Dockerfile
networks:
    default:
        external:
            name:  jaish-container-network

ServiceOne docker-compose.yml

version: '3.4'

services:
  serviceone:
    image: ${DOCKER_REGISTRY-}serviceone
    container_name: serviceone
    build:
      context: .
      dockerfile: Dockerfile
networks:
    default:
        external:
            name:  jaish-container-network

Please notice that we mentioned single custom network bridge for both services inside their.

 

Run Source (ServiceTwo)& Target (ServiceTwo) Services

 

Now you can run our source service;i.e. ServiceTwo and make sure that it's using our new custom Network Bridge. Once ServiceTwo has been started running locally using Visual Studio 2019, run docker command "docker network inspect f98a69e691b9" to inspect the docker network and make sure that ServiceTwo has been connected to our new custom Network Bridge. The last parameter is the network id of your new custom Network Bridge, which will get by running "docker network ls". You can see in below diagram that under Containers section, ServiceTwo is now displaying,

 

 

Remove IP Ref. in ServiceOne

 

Part 1 of this article used IP of the ServiceTwo container to access it from inside ServiceOne container. Now as both containers are bound to a common custom Network Bridge, replace that IP Ref. with just ServiceTwo DNS name, like below. 

using var client = new HttpClient
               {
                   BaseAddress = new Uri("http://servicetwo/")
               };

Now run this modified ServiceOne through Visual Studio 2019 and make sure that both services shares same custom Network bridge by again running "docker network inspect f98a69e691b9". This time you will notice additional ServiceOne as well under Containers section.

 

 

You got the expected response from ServiceTwo container, without using its container IP, but using it's DNS name.

 

 

 

During Microservices deployment, you need to consider internal communication across different services. You don't need to hit your API gateway for internal service communication. Using DNS as a way to communication across service containers is supported by multiple orchestration PaaS vendors including Azure Kubernetes Services.

 

Please use the same source code uploaded in Part 1 of this article and change it as mentioned here.