Understanding docker volumes and networking

If you are a complete beginner and don’t know what Docker is, let me explain it in a simple way.

Docker is an open-source platform used for developing, shipping, and running applications using containers.

A container is a lightweight and isolated environment that includes everything needed to run your application. Because of this, the application works the same way on every machine, no matter where it is running.

Why Docker Matters

Docker separates your application from the infrastructure, which allows you to manage your software the same way across all environments.

This means you don’t have to worry about differences between your local machine, testing environment, or production server. The application runs inside a container with everything it needs, so it behaves consistently everywhere. This makes development, deployment, and scaling much easier and more reliable.

Networks and Volumes

Since this article is about networks and volumes, these are the concepts that become important when you have multiple containers running.

You usually need:

• containers to talk to each other
• data to persist even after Docker restarts

Volumes

A volume is a persistent data store for containers, created and managed by Docker.

Volumes are stored on the Docker host, not inside the container itself. When a volume is mounted to a folder inside a container, any data written to that folder is actually written into the volume.

Because of this:

• data does not get deleted when the container stops or restarts
• the same volume can be mounted to multiple containers at the same time

Volumes must be removed manually, which makes them safe for storing important data.

Create a Volume

You can create a Docker volume using the following command:

docker volume create vol_name

This creates a named volume managed by Docker, which can be reused by multiple containers.

Using the Volume with a Container (Example: MongoDB)

Below is an example of running a MongoDB container and attaching the volume to it:

docker run -d --name mongo_container -v vol_name:/data/db -p 27017:27017 mongo

Explanation (Simple)

• -v vol_name:/data/db
  Mounts the Docker volume vol_name to the /data/db directory inside the container

• /data/db
  This is the directory where MongoDB stores its database files

• -p 27017:27017
  Exposes MongoDB’s default port so it can be accessed from the host machine

• -d
  Runs the container in detached mode (in the background)

With this setup, MongoDB writes all its data to the Docker volume, not the container itself.
Even if the container is stopped, removed, or recreated, the data remains safe inside the volume.

Listing Volumes

To see all Docker volumes on your system, use:

docker volume ls

Inspecting a Volume

To view detailed information about a specific volume (such as its mount location on the host), use:

docker volume inspect vol_name

Networking in Docker

Docker includes a built-in networking system that manages communication between containers, the Docker host, and the outside world. It supports different types of networks to handle common real-world use cases.

At a high level, Docker networking solves three main problems:

• How does a container talk to the outside world?
• How do containers talk to each other?
• How isolated or exposed should a container be?

Key Networking Concepts

Bridges

A bridge works like a virtual switch. It connects containers to each other and to the host machine.
Docker automatically creates a default bridge network if you don’t choose a network yourself.

Network namespaces

Each container runs inside its own network namespace.
This means every container has its own IP address, network interfaces, and routing table, completely separated from other containers and the host.

Virtual Ethernet interfaces (veth pairs)

Docker uses veth pairs to connect containers to a bridge network.
One end of the veth pair lives inside the container, and the other end connects to the Docker bridge on the host.

IP addresses and subnets

Docker assigns an IP address to each container from a subnet.
Containers on the same network can talk to each other directly using these IP addresses.

DNS resolution

Docker includes an internal DNS service.
This allows containers on the same network to communicate using container names instead of hard coding IP addresses.

Port mapping

Port mapping allows a container to expose a port to the host machine.
This makes the application inside the container accessible from outside using the host’s IP address and a mapped port.

Routing

Docker automatically manages routing rules so network traffic can move between containers, the host, and the internet.
Each container follows the routing rules defined inside its own network namespace.

Important Docker Network Types

1. Bridge

This is the default network type for standalone containers.

• It creates a private internal network on the Docker host
• Containers on the same bridge can communicate with each other
• On a user-defined bridge network, containers can talk using container names instead of IP addresses

2. Host

The host network removes network isolation completely.

• The container uses the host machine’s network stack directly
• The container shares the host’s IP address and ports
• There is no port mapping (-p) because ports are exposed directly

3. None

The none network disables networking entirely for the container.

• No internet access
• No communication with other containers
• Fully isolated environment

4. Other Network Types

Docker also supports additional network drivers for advanced use cases:

• Overlay – used in multi-host and Docker Swarm setups
• Macvlan – allows containers to appear as physical devices on the network
• Ipvlan – similar to macvlan, but with simpler network management

Default Bridge Network

The default bridge network is a virtual network that Docker creates automatically when you install Docker.
If you don’t specify a network while running a container, Docker attaches the container to this default bridge network.

How Networking Works in the Default Bridge

Each container gets:

• its own IP address
• its own network namespace

Containers can access the internet but cannot resolve each other by name.
Containers can communicate only using IP addresses.

Problems with the Default Bridge Network

• No built-in DNS between containers
• Containers cannot communicate using container names
• Hard to scale applications
• IP addresses can change when containers restart
• Not recommended for production
• Limited features and poor flexibility
• Security risks

User Defined Bridge Network

A user-defined bridge network is a custom virtual network that you create manually.

You can create one using:

docker network create my-net

Key Benefits of User Defined Bridge Networks

• Automatic DNS resolution
• Containers can communicate using container names
• Better isolation and security
• Dynamic connectivity without restarting containers

How to Create and Use a Custom Bridge Network

1. Create the Network

docker network create my-net

2. Connect Containers to the Network

docker run -d --name container1 --network my-net nginx:latest
docker run -d --name container2 --network my-net alpine:latest

3. Verify Communication Between Containers

docker exec -it container2 sh
ping container1

Host Network

With host networking, a container shares the host machine’s network stack directly.

• The container does not get its own IP address
• It uses the host’s IP address
• It shares the same network interfaces and ports as the host

If a process inside the container listens on port 80, it will be available at:

<host_ip>:80

How to Use the Host Network

docker run --network host nginx

Problems with Host Networking

• No network isolation
• Port conflicts
• Security risks

None Network

The none network type in Docker disables all networking for a container.

• No internet access
• No communication with other containers
• Fully isolated environment

docker run --network none alpine

The container will run without any network interfaces, making it completely isolated.