Part 4: Working with Networks

🇧🇷 Artigo em português aqui

Using Docker — Part 4: Working with Networks

In Part 3 of this series, we covered persisting data with volumes. Now let's tackle another fundamental pillar of multi-container applications: networking. When an application depends on several services (for example, an API that needs to talk to a database), those containers need to be able to communicate with each other — and that's what Docker networks make possible.

Listing networks

Docker already creates a few default networks on installation (bridge, host, none). To list all existing networks:

$ docker network ls

Creating a network

To create a custom network, isolated from the others:

$ docker network create <network_name>

Containers connected to the same custom network can communicate with each other using the container name as the hostname — no need to discover or hardcode IP addresses manually.

Inspecting a network

To see details about a network — such as the IP range, driver used, and which containers are connected to it:

$ docker network inspect <network_name>

Running a container already connected to a network

To create a container and connect it to a specific network right at creation time:

$ docker run -it -d --rm --net <network_name> httpd

Connecting a running container to a network

If the container is already running and you want to add it to an additional network (a container can belong to multiple networks at once):

$ docker network connect --ip 192.168.100.10 <network_name> httpd

The --ip flag lets you pin a specific IP for the container within that network — useful when other applications need a predictable address to connect to.

Disconnecting a container from a network

$ docker network disconnect <network_name> httpd

Removing a network

$ docker network rm <network_name>

A network can only be removed if no container is currently connected to it.

Cleaning up unused networks

Just like with volumes, it's common to accumulate orphaned networks over time. To remove all networks not currently used by any container:

$ docker network prune

Why this matters

Running isolated containers without a custom network works fine for quick tests — but as soon as an application needs multiple services talking to each other (app + database + cache, for example), custom networks stop being optional. They provide isolation (containers from different projects can't see each other by default) and simple name-based communication, without relying on manually managed fixed IPs.

Next steps

With volumes for persistence and networks for communication between containers, we now have the two fundamental pieces needed to run multi-service applications. In Part 5 of this series, we'll cover image management: how to build, version (tag), and publish your own images to a registry.

Continued in Part 5.