Docker Fundamentals · Module 06 of 12

Container networking and published ports

Understand bridge networks, service discovery, container-to-container communication and the difference between container ports and host publishing.

Learning objectives

By the end of this module, you should be able to:

Explain default and user-defined bridge networking at a fundamentals level.
Connect containers by name on a user-defined network.
Distinguish host-port publishing from internal container networking.

Containers need network namespaces and paths

Docker attaches containers to networks. A user-defined bridge network gives connected containers an isolated L2/L3 environment on one Engine and built-in DNS-based name resolution.

Containers on the same user-defined network should normally address each other by container/service name and container port—not by the host-published port.

Publishing is a host boundary decision

-p HOST:CONTAINER creates a path from the host interfaces to a container port. Internal services such as databases often do not need a host-published port when only other containers must reach them. Reducing published ports reduces exposure.

Debug the path in layers

Troubleshoot whether the target process is listening, whether both containers share the intended network, whether name resolution works, and whether host publishing is actually required. Avoid immediately disabling firewalls or using host networking as a shortcut.

Worked examples

See the idea in practice.

Create a private application network

docker network create appnet
docker run -d --name web --network appnet nginx:alpine
docker run --rm --network appnet busybox wget -qO- http://web/

web is resolvable by name on the user-defined network.
No host port is required for the temporary BusyBox client to reach nginx.

Publish only when the host must reach it

docker run -d --name published-web -p 127.0.0.1:8080:80 nginx:alpine

Binding to 127.0.0.1 limits the published listener to the local host.
Publishing on all interfaces can expose the service beyond the machine depending on firewall/routing.

Hands-on lab

Lab — Name-based container networking

Goal: Create two isolated containers and prove communication by Docker DNS without publishing nginx to the host.

STEP 1

Create network

docker network create dockerlab-net

STEP 2

Run web service

docker run -d --name dockerlab-web --network dockerlab-net nginx:alpine

STEP 3

Call it by name from another container

docker run --rm --network dockerlab-net busybox wget -qO- http://dockerlab-web/ | head

STEP 4

Inspect membership

docker network inspect dockerlab-net

STEP 5

Clean up

docker rm -f dockerlab-web
docker network rm dockerlab-net

Verify

The BusyBox client resolves dockerlab-web.
The web container has no host-published port.
Both containers participate in the same user-defined bridge for the request.

Expected outcome

HTML from nginx is returned through the private Docker network.

If it fails

If the name does not resolve, confirm both containers use the same user-defined network.
If connection is refused, verify the target process is running and listening on the expected container port.

Real-world connection

Compose applications commonly keep databases and caches private on application networks while publishing only the frontend/API service.

Avoid these traps

Common mistakes

Using localhost inside one container to refer to a different container.
Publishing every service port to the host by default.
Hard-coding transient container IP addresses instead of using names/service discovery.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does localhost mean inside a container?

That container’s own network namespace, not another container or the Docker host.

2Why use a user-defined bridge network?

It gives controlled container membership plus convenient name-based discovery between members.

3Does container-to-container traffic on one Docker network require -p?

No. -p is for publishing a container port through the host boundary.