Stop 07 · Containers & DockerTopics · 5/9

Container Networking

Part of the DevOps Roadmap

In short

Your API container can't reach the database container, but both are running. Nine times out of ten, it's a networking mix-up: wrong network, wrong hostname or a port that was never published.

How containers communicate with each other and the outside world — bridge networks (the default), host networking, and port mapping/exposure are the core concepts.

The mascot sits at a reception desk plugging cables into an old telephone switchboard.

Think of it like this

The office switchboard

Inside an office, staff call each other by extension name. An outside caller can't dial an extension directly; they ring the main number and the operator connects them. Containers on a network call each other by name, and -p is the operator forwarding outside calls in.

Watch it happen

A request reaching the API, then the DB

Browser
Host :8080
api
db

GET localhost:8080

1/6Your browser only knows the host machine. It talks to port 8080 on it.

The big ideas

What you need to know

Bridge is the default

Containers get private IPs on a virtual bridge network. Create your own network so containers can find each other by name.

-p publishes a port

-p 8080:3000 means host port 8080 goes to container port 3000. EXPOSE in a Dockerfile is only documentation.

Only publish what users need

Publish the web or API port. Keep databases and caches unpublished, reachable only on the private network.

localhost means 'me'

Inside a container, localhost is that container. Use the other container's name instead, like db or redis.

See it in code

Walk through the code

bash
1# Create a user-defined bridge network2docker network create appnet3 4# Database: reachable only inside appnet, by name "db"5docker run -d --name db --network appnet \6  -e POSTGRES_PASSWORD=devpass postgres:177 8# API: publish container port 3000 on host port 80809docker run -d --name api --network appnet \10  -p 8080:3000 -e DATABASE_HOST=db myapi:1

1/3A user-defined network gives you automatic DNS between containers, which the default bridge doesn't.

myapi:1 stands for your own API image. Run docker network inspect appnet to see both containers and their private IPs.

Save yourself the pain

Common mistakes

Oops

Setting DATABASE_HOST=localhost in the API container.

Do this instead

Use the database container's name. localhost inside the API container points back at the API itself.

Oops

Publishing the database with -p 5432:5432 on a cloud server just to make things work.

Do this instead

Put both containers on the same network instead. A published database on a public IP gets scanned within minutes.

Your mission

Wire two containers together

~25 min

Quick check

Your API container needs Postgres in another container on the same user-defined network. What host should it use?

Go deeper

  1. 1Practice exposing a container's port to the host machine and connecting to it.
  2. 2Learn how two containers on the same Docker network can reach each other by service name.
  3. 3Understand the difference between EXPOSE in a Dockerfile and actually publishing a port at runtime.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge