Neos - What I Learned

Appearance

Lesson 4.1: Docker Network Basics ​

Welcome to Phase 4! You've learned to build, run, and persist data in containers. Now it's time to make them communicate. Docker networking allows containers to talk to each other and to the outside world. In this lesson, we'll explore the fundamental concepts of Docker networking, the default networks, and how to inspect and manage them. By the end, you'll understand how containers are isolated by default and how to enable communication.

Learning Objectives ​

TIP

By the end of this lesson, you will be able to:

  • Explain the role of Docker networking in container communication.
  • Identify the default Docker networks (bridge, host, none) and describe their purposes.
  • Use docker network ls, inspect, create, and rm commands.
  • Run containers on different networks and understand their connectivity.
  • Inspect a container's network configuration.

1. Why Networking Matters ​

Containers are isolated by default. This means a container running a web server cannot be accessed from your host unless you explicitly publish ports, and two containers cannot talk to each other unless they are on the same network. Docker's networking subsystem provides the necessary connectivity while maintaining isolation.

INFO

Understanding Docker networking is crucial for:

  • Running multi‑container applications (e.g., web server + database).
  • Exposing services to the outside world.
  • Securing container communication.
  • Debugging connectivity issues.

2. Docker Network Drivers ​

Docker uses network drivers to create and manage networks. The most common drivers are:

DriverDescription
bridgeDefault network driver for standalone containers. Creates a private network on the host; containers on the same bridge network can communicate.
hostRemoves network isolation; the container shares the host's network stack. Useful for performance or when the container needs full host network access.
noneDisables networking; the container has only a loopback interface.
overlayUsed in Docker Swarm or Kubernetes to connect containers across multiple hosts.
macvlanAssigns a MAC address to the container, making it appear as a physical device on the network.
ipvlanSimilar to macvlan but uses layer 3.

TIP

In this lesson, we'll focus on bridge, host, and none. Overlay and macvlan will be covered later.

3. Default Networks ​

When you install Docker, three networks are created automatically:

bash
docker network ls

Sample output:

NETWORK ID     NAME      DRIVER    SCOPE
e4b5c6d7e8f9   bridge    bridge    local
a1b2c3d4e5f6   host      host      local
123456789abc   none      null      local

3.1. bridge Network ​

The default bridge network is created automatically. When you run a container without specifying a network, it attaches to this bridge network.

  • Containers on the default bridge can communicate with each other by IP, but not by container name unless you use --link (deprecated).
  • It provides NAT (Network Address Translation) so containers can access the internet through the host's network.
  • Ports must be published (-p) to be accessible from the host.

3.2. host Network ​

The host network removes isolation: the container uses the host's network stack directly.

  • No port mapping is needed; the container's ports are exposed on the host.
  • Performance is slightly better, but security is reduced (container can bind to any port).
  • Only works on Linux; not available on Docker Desktop for Mac/Windows (there it's simulated but behaves differently).

3.3. none Network ​

The none network disables all networking. The container has only a loopback interface.

  • Used for containers that don't need network access.
  • Useful for batch jobs or isolated processes.

4. Working with Networks ​

4.1. Listing Networks ​

bash
docker network ls

4.2. Inspecting a Network ​

bash
docker network inspect bridge

This shows details like subnet, gateway, and which containers are attached.

4.3. Creating a User‑Defined Bridge Network ​

The default bridge has limitations (no automatic DNS). User‑defined bridge networks provide better isolation and automatic name resolution.

bash
docker network create mynet

You can specify driver, subnet, etc.:

bash
docker network create --driver bridge --subnet 172.20.0.0/16 mynet

4.4. Removing a Network ​

bash
docker network rm mynet

Networks cannot be removed if they have active containers attached.

5. Running Containers on Networks ​

5.1. Attach a Container to a Network ​

Use --network flag with docker run:

bash
docker run -d --name web --network mynet nginx

5.2. Connect an Existing Container to a Network ​

bash
docker network connect mynet web

5.3. Disconnect a Container from a Network ​

bash
docker network disconnect mynet web

6. Container Communication on User‑Defined Bridge ​

On a user‑defined bridge, containers can resolve each other's names automatically.

Example:

  1. Create a network appnet.
  2. Run two containers on that network:
    bash
    docker run -d --name app1 --network appnet alpine sleep 3600
docker run -d --name app2 --network appnet alpine sleep 3600
  3. Exec into app2 and ping app1:
    bash
    docker exec -it app2 ping app1

The ping succeeds using the container name. This does not work on the default bridge.

7. Exposing Ports to the Host ​

To make a container accessible from outside the host, use -p or --publish.

bash
docker run -d --name web -p 8080:80 nginx
  • Maps host port 8080 to container port 80.
  • If you omit -p, the container is only reachable from other containers on the same network.

You can also bind to a specific host IP:

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

8. Host Network Example ​

Run a container with host networking (Linux only):

bash
docker run -d --name net-host --network host nginx

Now you can access nginx at http://localhost:80 (no port mapping). The container shares the host's IP address and all ports.

9. None Network Example ​

Run a container with no networking:

bash
docker run -it --network none alpine sh

Inside, ip addr shows only lo (loopback). No external connectivity.

10. Inspecting Container Network Settings ​

You can inspect a container's network details with docker inspect:

bash
docker inspect web

Look for the NetworkSettings section. For a container on a bridge network, you'll see IP address, gateway, and port mappings.

To quickly get a container's IP:

bash
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web

Hands-On Tasks ​

Task 1: Explore Default Networks ​

  1. Run docker network ls and note the three default networks.
  2. Inspect the bridge network: docker network inspect bridge. Look at the Containers section – it will show any containers currently attached.
  3. Inspect host and none networks.

Task 2: Run a Container on the Default Bridge ​

  1. Run a simple container in detached mode: docker run -d --name web1 nginx.
  2. Check its IP address: docker inspect web1 | grep IPAddress.
  3. Try to access nginx from your host: curl http://<container-ip>. It should work because the host can reach the bridge network.
  4. Now publish the port: stop and remove web1, then run docker run -d --name web1 -p 8080:80 nginx. Access http://localhost:8080 from your host.

Task 3: Create a User‑Defined Bridge Network ​

  1. Create a network: docker network create mynet.
  2. List networks again; you'll see mynet.
  3. Run two containers on mynet:
    bash
    docker run -d --name app1 --network mynet alpine sleep 3600
docker run -d --name app2 --network mynet alpine sleep 3600
  4. Exec into app2 and ping app1 by name: docker exec -it app2 ping app1. It should succeed.
  5. Try pinging app1 from the default bridge network: run a third container on the default bridge (docker run -it --rm alpine sh), then try ping app1 – it will fail because they are on different networks.
  6. Connect the default bridge container to mynet: docker network connect mynet <default-container>. Then ping again – it should work.

Task 4: Host and None Networks ​

  1. Run a container on host network (if on Linux) and check its interfaces: docker run --rm --network host alpine ip addr. Compare with ip addr on your host.
  2. Run a container on none network: docker run --rm --network none alpine ip addr. You'll see only lo.

Task 5: Inspect Network Connectivity ​

  1. Run an nginx container on a user‑defined network without publishing ports.
  2. Run another container on the same network and use curl to access nginx by container name.
  3. Remove the containers and networks when done.

Summary ​

Key Takeaways

  • Docker provides several network drivers: bridge, host, none, overlay, etc.
  • Three default networks are created automatically: bridge, host, none.
  • The default bridge network provides basic connectivity but lacks automatic DNS resolution.
  • User‑defined bridge networks allow containers to communicate by name and provide better isolation.
  • Use -p to expose container ports to the host.
  • docker network commands manage networks: ls, inspect, create, connect, disconnect, rm.

Check Your Understanding ​

  1. What are the three default Docker networks and their purposes?
  2. How do you list all Docker networks?
  3. Why does the default bridge network not allow containers to ping each other by name?
  4. What command would you use to run a container on a user‑defined network named backend?
  5. How do you expose a container's port 3000 to host port 9000?
  6. What is the difference between the host network driver and the bridge driver?
Click to see answers
  1. bridge: Default network for standalone containers with NAT to host. host: Removes network isolation, shares host's network stack. none: Disables all networking, only loopback.
  2. docker network ls
  3. The default bridge does not have an embedded DNS server. Name resolution only works on user-defined bridges.
  4. docker run -d --name mycontainer --network backend imagename
  5. docker run -d --name mycontainer -p 9000:3000 imagename
  6. Bridge creates a private internal network with NAT; containers get their own IP. Host removes isolation entirely—the container uses the host's IP and network stack directly.

Additional Resources ​

Next Up

In the next lesson, we'll dive deeper into bridge networks and explore user‑defined bridges in detail, including custom subnets, gateways, and how they enable container‑to‑container communication. See you there!