Is hostname property now required for inter-container communication?

I’ve been using Docker Desktop on Windows for 2-3 years now to orchestrate several services run in Windows containers based on ServerCore and NanoServer images. My compose file is fairly simple, no explicit network specification, using default nat network created by Docker Compose on Windows.

services:
  backend:
    container_name: backend
    ...
  database:
    container_name: database
    ...
  frontend:
    container_name: frontend
    ..

I haven’t used my services for several months, neither touching my compose file. Meanwhile, Docker Desktop received updates and I’m currently on Docker Desktop 4.37.1 (178610).

Today, I had to run my services and I found out my backend can not communicate with database.
I also found out that I cannot ping database from inside backend container, hostname no longer report backend or frontend, but container ID. Pinging on IP-s worked, of course.

I continued my investigation and found out that adding explicit hostname fixes the problem:

services:
  backend:
    container_name: backend
    hostname: backend
    ...
  database:
    container_name: database
    hostname: database
    ...
  frontend:
    container_name: frontend
    hostname: frontend
    ..

Has the hostname property now become mandatory?

I’m failing to find out any confirmation in issues on GitHub or in Docker documentation.

I have no experience with windows containers. On Linux, service discovery only requires the service name, but not the hostname. The container will have an arbitrary hostname, plus a dns alias for the service name. Hostnames or container names are usually not relevant, unless your application requires a specific hostname.

I’d like to add that while unnecessary, the container name can be used as well. I’m not sure about the hostname though, as I believe multiple containers can have the same one

Service names, container names, and network aliases will all end up being dns entries that resolve to the ip of the container.

The typical use case for network aliases:

  • you have an external network, and use it in more than one compose project, where service names are identical. The network alias would allow setting a distinguishable name per compose project.
  • you have multiple services that are members of a clustered service and can’t use replicas for it, because each service require slightly different configuration, but you want to loadbalance incoming request amongst the cluster members through a single domain-entry.

The following command can show the DNS names of the “testnetcontainer” container on the “test” network

docker inspect testnetcontainer --format '{{ json  .NetworkSettings.Networks.test.DNSNames }}'

If you see the service names there, it should be supported. If you see it, but it stopped working, that could be a bug, if the containers are on the same network.

1 Like

I would like to thank all of you for your responses, much appreciated.

I have performed a basic test on my Windows 11 machine with Docker Desktop 4.37.1:

# F:\Docker\test\docker-compose.yaml
name: test

services:

  db2:
    container_name: db2
    deploy:
      replicas: 1
    environment:
      ACCEPT_EULA: Y
      SA_PASSWORD: 'Password@123456'
    image: pachoo/mssql-server-2022-windows-developer:ltsc2022

  db3:
    container_name: db3
    deploy:
      replicas: 1
    environment:
      ACCEPT_EULA: Y
      SA_PASSWORD: 'Password@123456'
    image: pachoo/mssql-server-2022-windows-developer:ltsc2022

Containers inspection:

image

Test of connectivity between containers

image

Puzzling is this, where db2 is 74925895c0af as displayed above in the inspect output:

What am I doing wrong?

As I mentioned in my initial post, such setup used to work for me and services could inter-connect without problems. I don’t recall any changes to my Windows 11 workstation apart from Windows 11 upgrades like 22H2 to 24H2).

@vrapolinario can you pitch?

1 Like

Does my issue qualify to be submitted as a bug report to GitHub · Where software is built ?

Since I would expect feature parity between Windows and Linux containers for basic features like service discovery, I believe it does.

1 Like

Especially, that my setup had been working for a year or so. It no longer works.
I’ll copy GitHub link here when I craft a report soon.

Thank you. By the way I could reproduce it too, just forgot to mention.

1 Like

I’ve just opened bug report

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.