Docker Network Drivers Overview | Networking in Docker #3
Tags: docker, containers, networking, devops
Published: 2022-01-10 10:36:11

> Learn how Docker Network Drivers allow easy Container network configuration by implementing the Container Network Model

---

Link to video: https://www.youtube.com/watch?v=vmgSIBzYoiE

---

What are Network Drivers in Docker? How do they enable easy network configuration for Containers?

This blog will try to answer that as simply as possible.

# Introduction

This blog is the third one in a series for Docker Networking.

- [blog #1 - **Why is Networking important in Docker?**](https://www.techmormo.com/posts/docker-networking-1-why-is-networking-important/)
- [blog #2 - **Basics of Networking**](https://www.techmormo.com/posts/docker-networking-2-basics-of-networking/)

If you are looking to learn more about the basics of Docker, I’ll recommended checking out the [Docker Made Easy](https://www.techmormo.com/posts/docker-made-easy-1-what-is-docker/) series.

Here’s what we will discuss today:

- The Container Network Model
- Network Drivers: `none`, `host`, `bridge` & `overlay`

Okay.

Firstly, it’s good to know that networking in Docker is made possible by the...

# Container Network Model

> **The Container Network Model** (CNM) formalizes the steps required to provide networking for containers while providing an abstraction that can be used to support various types of networks.

![CNM](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h2x6aalcg1owf1ihqy5k.png)

CNM has 3 main components: Sandbox, Endpoint, and Network.

1. **Sandbox**: It contains the configuration of a container's network stack, which means management of the container's network interfaces, DNS settings, route tables, etc. A Sandbox may contain *many* endpoints from *multiple* Networks.
2. **Endpoint**: It joins a Sandbox to a Network. An Endpoint can belong to only one Network and it can belong to only one Sandbox if connected.
3. **Network**: It is formed by a group of Endpoints that are able to communicate with each other directly.

You can think of the Container Network Model as an abstract class that defines the required interface, whereas _network drivers_ correspond to concrete classes implementing the interface.

This is, of course, an oversimplification so feel free to learn more about the design of CNM [here](https://github.com/moby/libnetwork/blob/master/docs/design.md).

As users of Docker, instead of the detailed implementations of CNM, we should learn more about how to properly use...

# Network drivers

> Network drivers are pluggable interfaces that provide the actual network implementations for Docker Containers.

Docker comes with several drivers out-of-the-box that provide core networking functionality for many use cases - like service discovery, encryption, multi-host networking, etc.

Then there are 3rd party drivers (by plugin providers) available for special use cases.

Lastly, one can even build their own custom drivers if available ones don't suffice (although that will rarely ever be required).

The 4 out-of-the-box network drivers are:

1. `none`
2. `host`
3. `bridge`
4. `overlay`

The driver can be specified by the `--network` option for the `docker run` command like this:

```bash
docker run -d --network host nginx
```

This command runs a `nignx` container using the `host` driver in the background (specified by the `-d` flag).

It’s interesting to note that a Container is generally unaware of the network driver it uses, except when using the `none` driver.

So, how do each of the drivers differ?

Reminder: a **Docker host** is a host/computer running the Docker daemon. You can learn more about Docker’s architecture [here](https://techmormo.com/posts/docker-made-easy-1-what-is-docker/).

## None Driver

The `none` driver simply disables networking for a container, making it isolated from other containers.

![driver none](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/21rzn2e4pmi995mobx4b.png)

---

## Host Driver

When using the `host` driver, the container shares the network stack of the Docker host - appearing as if the container is the host itself, from a networking perspective.

![driver host](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qk9z9nvlisw8cc7a05mc.png)

NOTE: the `host` driver is only supported on Linux as of now.

---

## Bridge driver

The `bridge` driver creates an internal network within a single Docker host. containers placed within this network can communicate with each other but are isolated from containers, not on the internal network. `bridge` is the default driver when running single containers or when using docker-compose.


![driver bridge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xq8i8ctvd77zh5l79c6g.png)

---

## Overlay driver

The `overlay` driver creates a distributed network that can span multiple Docker hosts, and therefore is the preferred driver for managing container communication within a multi-host cluster. `overlay` is the default driver for Docker swarm services.

![driver overlay](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4vn4ivzabywvekl0tqm1.png)

---

# Conclusion

Alright.

Today we briefly learnt about the Container Network Model and the main Network Drivers that Docker provides.

In the upcoming blogs of this series, we will explore each of the Drivers in more detail.

Being pluggable makes drivers highly extensible & portable. As a result, they allow the use of various types of networks, and connect containers amongst themselves and with non-Docker workloads as needed.

I honestly find great joy when my fellow Engineers/Developers use Container technology effectively to build awesome things!

Thanks for making it so far! 🎉

See you at the next one.

Till then…

Be bold and keep learning.

But most importantly,

Tech care!