Docker containers aren’t just about isolation—they’re often used to manage processes that still need to talk to each other directly. But, to communicate, you’ll often need to know each container’s IP address, which you can find with a few commands.

Consider Using a User-Defined Bridge

Docker networking is a little complicated. Containers launched by default will be placed in the default “bridge network,” and are allowed to communicate with other containers directly, provided you have their private IP address. This can be turned off for true isolation, but it isn’t by default.

You can also use this address to communicate from the host OS if you don’t want to bind a port. This is the primary use case of accessing a container directly through its IP address, but you should probably still just bind a port (you can keep it closed from the internet in your firewall).

However, IP addresses are ephemeral, and can break easily when containers are stopped and started. For communication between containers, Docker provides a solution through user-defined bridge networks, which you probably should be using if you have multiple containers talking to each other.

Containers added to non-default networks will be able to access each other through their alias, which will resolve to the private IP automatically. You can create new networks, run containers in those networks, and connect existing containers to the network. You can then access the other containers using the alias as a hostname; for example, the NGINX container here can access the MongoDB instance with the connection string mongodb://mongohost:27017.

docker network create example
docker run --net example --name nginx -d nginx
docker network connect example --alias mongohost mongodb

There’s a lot of upside to using bridges, and it’s recommended over the legacy --link option, which works on the default network. The primary issue is that containers in user-defined networks will be exposed to each other’s ports, regardless of if they’re published, but you can set up multiple networks, so this isn’t usually an issue.

The other downside is that because user-defined networks provide better isolation, they also disallow you to access containers across networks with their private IP address. All containers in the default network can talk to each other, but once it’s removed and placed in a user-defined network, that ability is disabled. However, you can also just launch the container in both the default and user-defined networks, so it’s not a problem if you choose to make the container visible to others.

Getting The IP Address From Docker

If you just want the IP address though, it’s pretty simple to get from the host OS. First, you’ll need to find the ID or name of the container you want to get the information for, which you can do with:

docker ps

Then, run docker inspect, which returns a huge JSON file with all the information about the container. We’re only interested in the IP address though, so you can pass it a formatting option with -f to narrow it down to just the address.

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' name_or_id

This command works well, but it’s also only returning info for one container which you will need the ID of. If you want a more concrete solution, you can use docker network inspect which prints info about all containers in the given network, optionally formatting as a JSON lookup table:

docker network inspect bridge -f '{{json .Containers}}'

Getting Network Config From The Container

Docker containers are really just an isolation mechanism, and nothing is preventing you from just entering the container and running regular Linux commands like ifconfig and getting the IP address that way.

To do that, you’ll need to grab the container name or ID with docker ps, then run exec -it, in this case, printing out all IP information:

docker exec -it b94ef3169cd4 ip a

Profile Photo for Anthony Heddings Anthony Heddings
Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon's AWS platform. He's written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times.
Read Full Bio »