mloskot
(Mateusz Łoskot)
January 17, 2025, 4:47pm
1
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.
meyay
(Metin Y.)
January 17, 2025, 7:15pm
2
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.
deanayalon
(Dean Ayalon)
January 18, 2025, 10:54am
3
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
meyay
(Metin Y.)
January 18, 2025, 12:22pm
4
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.
rimelek
(Ákos Takács)
January 18, 2025, 7:37pm
5
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
mloskot
(Mateusz Łoskot)
January 20, 2025, 7:42pm
6
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:
Test of connectivity between containers
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).
meyay
(Metin Y.)
January 20, 2025, 9:00pm
7
@vrapolinario can you pitch?
1 Like
mloskot
(Mateusz Łoskot)
January 22, 2025, 11:08am
8
Does my issue qualify to be submitted as a bug report to GitHub · Where software is built ?
meyay
(Metin Y.)
January 22, 2025, 11:45am
9
Since I would expect feature parity between Windows and Linux containers for basic features like service discovery, I believe it does.
1 Like
mloskot
(Mateusz Łoskot)
January 22, 2025, 2:42pm
10
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.
rimelek
(Ákos Takács)
January 22, 2025, 6:34pm
11
Thank you. By the way I could reproduce it too, just forgot to mention.
1 Like
mloskot
(Mateusz Łoskot)
January 23, 2025, 12:34am
12
I’ve just opened bug report
opened 12:32AM - 23 Jan 25 UTC
needs-triage
version/4.37.1
### Description
This report is spawned from the recent discussion thread [Is ho… stname property now required for inter-container communication?](https://forums.docker.com/t/is-hostname-property-now-required-for-inter-container-communication/146183) that I opened.
I have a fairly simple Docker Compose configuration with services like frontend app, backend app, SQL Server and everything used to work for a year or so, but I recently discovered containers cannot inter-communicate any more. My configuration is based on the default `nat` network created by Docker Compose on Windows.
### Reproduce
1. Minimal reproducible configuration example:
```yaml
# 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
```
1. Containers inspection

2. Try connectivity between containers


3. Observe pinging with container (hostname) name does not work, but pinging at container ID does work, where `db2` is `74925895c0af` as displayed above in the `inspect` output earlier

### Expected behavior
I'd expect to be able to reach `db2` from `db3` and vice versa. As mentioned earlier, 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).
By the way, it looks like I'm not alone, as my thread on the forums received [confirmation that another Docker user was able to reproduce my problem](https://forums.docker.com/t/is-hostname-property-now-required-for-inter-container-communication/146183/11).
### docker version
```bash
Client:
Version: 27.4.0
API version: 1.47
Go version: go1.22.10
Git commit: bde2b89
Built: Sat Dec 7 10:40:21 2024
OS/Arch: windows/amd64
Context: desktop-windows
Server: Docker Desktop 4.37.1 (178610)
Engine:
Version: 27.4.0
API version: 1.47 (minimum version 1.24)
Go version: go1.22.10
Git commit: 92a8393
Built: Sat Dec 7 10:39:14 2024
OS/Arch: windows/amd64
Experimental: false
```
### docker info
```bash
Client:
Version: 27.4.0
Context: desktop-windows
Debug Mode: false
Plugins:
ai: Ask Gordon - Docker Agent (Docker Inc.)
Version: v0.5.1
Path: C:\Program Files\Docker\cli-plugins\docker-ai.exe
buildx: Docker Buildx (Docker Inc.)
Version: v0.19.2-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.31.0-desktop.2
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.37
Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe
desktop: Docker Desktop commands (Beta) (Docker Inc.)
Version: v0.1.0
Path: C:\Program Files\Docker\cli-plugins\docker-desktop.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.27
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scout: Docker Scout (Docker Inc.)
Version: v1.15.1
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 14
Server Version: 27.4.0
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 26100 (26100.1.amd64fre.ge_release.240331-1435)
Operating System: Microsoft Windows Version 24H2 (OS Build 26100.2894)
OSType: windows
Architecture: x86_64
CPUs: 24
Total Memory: 63.77GiB
Name: DEV690
ID: 6a513b95-c805-446c-a766-0f90e9423fe5
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: false
Labels:
com.docker.desktop.address=npipe://\\.\pipe\docker_cli
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
```
### Diagnostics ID
BF7F7741-2D95-454A-895E-217224018559/20250123003021
### Additional Info
I run `docker compose` inside PowerShell 7.4.6
2 Likes
system
(system)
Closed
February 2, 2025, 12:34am
13
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.