How does Docker networking and port mapping work?

Question

IT Interview Practice · Accepted Answer

Docker provides **networking** so containers can communicate with each other and with the outside world. **Port mapping** exposes a container's ports to the host, and **networks** let containers talk to each other by name. Understanding the basics is essential for running connected applications.

## Port mapping — expose containers to the host

```bash
# -p HOST_PORT:CONTAINER_PORT maps a host port to a container port
docker run -p 8080:80 nginx
# → nginx listens on port 80 INSIDE the container;
#   accessing localhost:8080 on the HOST reaches it
# → without -p, the container's ports aren't accessible from outside
```

**Port mapping** (`-p host:container`) makes a container's internal port reachable from the host — necessary to access a containerized web app, API, etc. from outside the container.

## Container-to-container communication (user-defined networks)

```bash
# create a network; containers on it can reach each other BY NAME
docker network create mynet
docker run -d --name db --network mynet postgres
docker run -d --name api --network mynet myapi
# → the "api" container can connect to the database at hostname "db" (Docker DNS)
#   e.g. DATABASE_URL=postgres://db:5432/...
```

On a **user-defined network**, containers can reach each other by **container name** (Docker provides DNS resolution) — so an app container connects to a database container using its name as the hostname, no IP addresses needed.

## Network types

```text
bridge   → the default; containers on a bridge network communicate; isolated from host
           (user-defined bridge networks add name-based DNS — preferred)
host     → the container shares the host's network directly (no isolation, no mapping)
none     → no networking
overlay  → spans multiple hosts (for Docker Swarm / multi-host clusters)
```

## Why it matters

Understanding Docker networking and port mapping is essential for running real, connected applications in Docker, so it's important practical knowledge. **Port mapping** (`-p host:container`) is fundamental and used constantly — without it, a containerized web app or API isn't accessible from outside the container, so understanding how to expose container ports to the host is necessary to actually use containerized services.

Equally important is **container-to-container communication**: understanding that on a **user-defined network**, containers can reach each other **by name** (via Docker's built-in DNS) is essential for multi-container applications — an application container connecting to its database container using the container name as the hostname (e.g. `postgres://db:5432`) is a near-universal pattern, and understanding it is necessary for building applications composed of multiple containers (app + database + cache, etc.).

Knowing the **network types** (bridge as the default with user-defined bridges adding name-based DNS, host for sharing the host network, overlay for multi-host clusters) provides the context for configuring networking appropriately.

Since real applications involve services communicating (a web app reaching a database, services calling each other) and being accessed from outside (exposed ports), and since Docker networking (port mapping for external access, named container communication on networks) is how this connectivity works, understanding Docker networking basics is essential, frequently-applied knowledge for running connected containerized applications — necessary for anything beyond a single isolated container, and a foundational skill for the multi-container applications that are the norm in real Docker usage.

Port mapping — expose containers to the host

Container-to-container communication (user-defined networks)

Network types

Why it matters

Related questions