When two containers are connected to the same user-defined Docker network, how does one container resolve the hostname of the other container?
Think about how Docker manages networking internally for containers on the same network.
Docker creates an internal DNS server for each user-defined network. This DNS server automatically resolves container names to their IP addresses, allowing containers to communicate by name.
Given two containers web and db connected to the same user-defined network mynetwork, what key in the output of docker network inspect mynetwork shows the container names and their IP addresses?
docker network inspect mynetworkLook for the section that maps containers to their network details.
The Containers section in the network inspect output shows each container's ID, name, and IP address on that network.
You have two containers on different user-defined Docker networks. You want them to resolve each other's hostnames. Which configuration allows this?
Think about how Docker networks isolate containers and how to bridge that isolation.
Containers must share at least one common user-defined network for Docker's internal DNS to resolve their names. Connecting both containers to a shared network enables this.
You have two containers on the default bridge network. One container tries to ping the other by container name but fails. Why?
Consider the difference between the default bridge network and user-defined networks.
The default bridge network does not support automatic DNS resolution by container name. Only user-defined networks provide this feature.
In a Docker Swarm cluster with multiple hosts, how should you configure services to ensure DNS resolution between containers works reliably?
Think about how Docker Swarm manages networking across multiple hosts.
Docker Swarm uses overlay networks to connect containers across hosts. The internal DNS resolves service names within these overlay networks, enabling reliable cross-host communication.