I’ve set up two containers on a custom bridge network, but they can't seem to ping each other using their container names. I verified both are attached to the same network using the inspect command. Is there a specific DNS setting within the Docker daemon or a network driver configuration that I might be missing for service discovery to work properly in a local dev environment?
3 answers
When using the default "bridge" network, Docker does not support service discovery via container names; you must use IP addresses, which is not ideal. However, when you create a user-defined bridge network, Docker's built-in DNS server enables name resolution automatically. Ensure you didn't accidentally use the default bridge. Also, check if your containers have multiple network interfaces. Sometimes, the routing table inside the container prioritizes the wrong interface, causing the ping to fail. Try using docker network inspect to confirm the exact aliases assigned to each container and ensure no firewall rules on the host are dropping internal traffic.
You should always use Docker Compose for this. It automatically creates a user-defined bridge network for your services, making name-based communication work out of the box.
Have you checked if the containers are actually running and if the internal firewall (iptables) on your host machine is allowing traffic between the virtual interfaces?
Steven, I checked the iptables and noticed that a recent Docker update had reset some of my forwarding rules. After flushing the chains and restarting the Docker service, the name resolution started working instantly. Brenda, your point about the user-defined network was the key—I was originally testing on the default bridge. Switching to a custom network solved the DNS resolution issue without needing to hardcode any IP addresses in my application's config files.
I agree with Larry. Docker Compose simplifies the networking layer so much that manually creating bridge networks is rarely necessary for standard microservices.