Network and Data Management

Follow Us

Our Communities

Chapter 4: Network and Data Management

In today’s data-driven world, efficient data and network management are the cornerstones of any successful software system. Docker, being a leading platform in the realm of containerization, offers comprehensive features for handling both these aspects effectively.

In this chapter, we will delve into the foundational components of Docker that allow it to handle data and network management in a seamless and scalable manner. We will begin by exploring Docker’s networking features, which enable containers to communicate with each other and with external networks. You will learn about Docker’s network commands, and how to configure the network to meet the needs of your specific use case.

Next, we will delve into Docker’s data management capabilities, focusing on Docker Volumes and Bind Mounts. We will explain how Docker volumes provide a way to persist data and share it among containers, and how bind mounts allow you to share specific directories or files from the host to the container.

Then we will touch upon tmpfs mounts, which are temporary file systems stored in the host system’s memory. These are especially useful for cases where you don’t want data to persist either on the host machine or within the container.

Lastly, we will dive into Docker Storage Drivers, which are responsible for enabling and managing the persistent storage operations of Docker containers. The choice of storage driver can significantly impact the performance and functionality of your Docker containers.

By the end of this chapter, you will have a solid understanding of Docker’s networking and data management capabilities and be equipped to handle these aspects effectively in your Docker projects. With plenty of practical examples and exercises, we ensure that you not only gain theoretical knowledge but also get hands-on experience with Docker’s network and data management features. Let’s dive in!

Understanding Docker Networking

In Docker, networking plays a crucial role in interconnecting containers not only within the same host but also across different hosts. Docker provides several built-in networking drivers to facilitate this, each offering unique features to suit different networking use cases.

Let’s dive into the various types of Docker networking:

Bridge Networks

The bridge network is the default network in Docker. When you start a container without specifying a network, Docker attaches it to the bridge network. This network type enables the container to access external networks, and other containers on the same bridge network can communicate with each other. However, containers on different bridge networks cannot communicate directly unless they are explicitly linked.

Host Networks

When you attach a container to the host network, it shares the network stack of the host machine, without any isolation. This means the container can access all the services running on the host machine, just like a process running on the host. This network type offers the highest performance and is useful when you need to avoid network isolation for your container.

None Networks

The none network type attaches a container to a network stack but does not configure it. The container has a network interface, but it doesn’t have an IP address, so it can’t communicate with other containers or the external network. This type is useful when you want to create and manage your own custom network stack.

Overlay Networks

Overlay networks allow containers across multiple Docker hosts to communicate as if they were on the same host. This network type is particularly useful in Swarm mode, where many Docker nodes need to work together.

Macvlan Networks

Macvlan networks assign a MAC address to a container, making it appear as a physical device on the network. The Docker host’s network routes traffic to these containers by their MAC addresses. Macvlan networks are useful when you need containers to look like physical hosts on your network for security or compliance reasons.

In addition to these built-in network types, Docker also supports network plugins, allowing you to integrate Docker with more advanced network technologies like Weave or Calico.

It’s also important to note that Docker automatically manages DNS resolution for containers. When a container wants to reach another container via its name, Docker acts as a DNS server and returns the appropriate IP address.

In summary, Docker provides robust networking capabilities that give you great flexibility in how you enable communication between containers, and between containers and external networks. Understanding these networking concepts will help you design and manage your Docker environments more effectively.

Docker Network Commands

To effectively manage the networking aspects of your Docker containers, Docker provides a set of commands that you can use. Here, we’ll go through some of the most commonly used Docker network commands:

Listing Networks (docker network ls):

This command lists all the networks currently defined on your Docker host. Each network will be displayed with its ID, name, driver, and scope.

docker network ls

Inspecting a Network (docker network inspect):

If you need more detailed information about a specific network, you can use the docker network inspect command followed by the network name or ID.

docker network inspect <network-name>

This will give you a detailed JSON output, including information about the network’s IPAM settings, options, and containers attached to the network.

Creating a Network (docker network create):

To create a new network, you use the docker network create command followed by the network name.

docker network create <network-name>

By default, this creates a bridge network. If you want to create a network of a different type, you can specify the driver using the -d or --driver option.

Removing a Network (docker network rm):

If you need to remove a network, you can use the docker network rm command followed by the network name or ID.

docker network rm <network-name>

Connecting a Container to a Network (docker network connect):

To connect an existing container to a network, you can use the docker network connect command followed by the network name and the container name or ID.

docker network connect <network-name> <container-name>

Disconnecting a Container from a Network (docker network disconnect):

Similarly, to disconnect a container from a network, you can use the docker network disconnect command followed by the network name and the container name or ID.

docker network disconnect <network-name> <container-name>

Understanding and using these commands will allow you to effectively manage the networking aspects of your Docker containers, enabling them to communicate as needed within and across Docker hosts.

Docker Network Configuration

Docker network configuration is a vast topic as it involves understanding how Docker creates, manages, and assigns networking interfaces and IP addresses to the containers. Here, we’ll discuss a few key aspects of Docker network configuration:

Creating a Network:

When you create a Docker network, Docker automatically assigns it a subnet from the private IP range. You can also manually specify a subnet using the --subnet option:

docker network create --subnet <network-name>

Inter-Container Communication:

By default, Docker allows containers attached to the same network to communicate with each other. If you want to disable this behavior, you can use the --icc=false option when starting the Docker daemon.

dockerd --icc=false

Publishing a Service:

When you want to make a service running in a Docker container available to the outside world, you can use the -p option when running the container to publish a port. For example, to run a web server on port 80 inside a container and make it accessible at port 8080 on the host, you would run:

docker run -p 8080:80 <image-name>

Assigning a Static IP:

While Docker automatically assigns an IP address to each container, you may sometimes need to assign a specific IP address to a container. You can do this using the --ip option when connecting a container to a network:

docker network connect --ip <network-name> <container-name>

DNS Configuration:

Docker provides a built-in DNS server for containers, which allows containers to resolve each other by name. You can modify the DNS settings for a container using the --dns option when running a container:

docker run --dns <image-name>

Network Aliases:

Docker allows you to assign one or more network aliases to a container, providing additional names to use when connecting to the container from other containers. You can set a network alias using the --network-alias option:

docker run --network-alias alias1 --network-alias alias2 <image-name>

Remember, Docker networking is a complex and versatile feature. While the configurations mentioned above are quite common, Docker provides many more options for advanced network settings to cater to complex networking scenarios. Understanding the basics and knowing where to look for advanced options is crucial for effectively managing Docker networks.

Introduction to Docker Volumes

When working with Docker, one of the challenges you might face is data persistence. By default, the data in a Docker container is ephemeral, meaning it disappears when a container is removed. To solve this, Docker provides a feature known as volumes.

Docker Volumes:

A Docker volume is a mechanism that allows you to store and manage data generated by and used by Docker containers. Volumes work on both Linux and Windows containers. They are a better choice than persisting data in a container’s writable layer, because they are decoupled from the life cycle of the container and have optimized I/O performance.

Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux). Non-Docker processes should not modify this part of the filesystem. Volumes are the best way to persist data in Docker.

Why Use Docker Volumes?

There are several reasons why you’d want to use Docker volumes:

Data Persistence: Docker volumes provide persistent storage, meaning the data doesn’t disappear when the container is removed.

Data Sharing: Volumes can be shared and reused among containers. You can use a volume in multiple containers simultaneously.

Data Backup and Migration: Volumes can be backed up and migrated, which is not possible with a container’s writable layer.

Performance: Volumes are stored on the host filesystem and managed by Docker, providing better performance than storing data in the container’s writable layer.

Compatibility: Docker volumes work on both Linux and Windows Docker containers.

Volume Drivers: Docker supports volume drivers, which allow you to store volumes on remote hosts or cloud providers.

Working with Docker Volumes

Working with Docker volumes involves a few fundamental commands and concepts. Here, we’ll discuss how to create, inspect, use, and remove Docker volumes:

Creating Volumes (docker volume create):

To create a new volume, use the docker volume create command followed by the volume name:

docker volume create <volume-name>

Listing Volumes (docker volume ls):

You can see a list of all created volumes with the docker volume ls command:

docker volume ls

Inspecting Volumes (docker volume inspect):

For detailed information about a specific volume, use the docker volume inspect command:

docker volume inspect <volume-name>

This command provides a JSON output containing detailed information about the volume, including its name, driver, mountpoint, and any options.

Using Volumes (docker run -v):

To use a volume in a container, include the -v option followed by the volume name and mount point when starting a container with the docker run command:

docker run -v <volume-name>:<mount-point> <image-name>

This command attaches the specified volume to the container at the specified mount point. If the volume does not already exist, Docker creates it.

Removing Volumes (docker volume rm):

To remove a volume, use the docker volume rm command:

docker volume rm <volume-name>

Note that you cannot remove a volume that is in use by a container. To remove a volume from a container, you must first remove or stop the container.

These commands form the foundation of working with Docker volumes. Volumes provide an effective way to persist data generated by and used by Docker containers. They also allow you to share data between containers and ensure data survives even after a container is removed. Understanding and using Docker volumes are essential skills when working with Docker.

Docker Bind Mounts

While Docker volumes are a great way to persist data, Docker also provides another feature known as bind mounts. Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes but can still be quite useful in certain scenarios.

What are Bind Mounts?

A bind mount is essentially mapping a host file or directory to a container file or directory. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine. Bind mounts can be used both in Linux and Windows containers.

Working with Bind Mounts

The way you use a bind mount is similar to using a volume. Here is a basic example of creating a bind mount:

docker run -v /host/path:/container/path <image-name>

In this command, /host/path is the file or directory on the host machine, and /container/path is the path where the file or directory will be available in the container.

Differences Between Bind Mounts and Volumes

While bind mounts and volumes may seem similar, they have some important differences:

  • Persistence: Both bind mounts and volumes provide data persistence, but they do so in different ways. Volumes are stored in a part of the host filesystem managed by Docker, while bind mounts can be stored anywhere on the host filesystem.

  • Portability: Volumes are more portable than bind mounts. With volumes, you don’t need to worry about the directory structure of the host machine. Bind mounts, however, are dependent on the directory structure of the host machine.

  • Performance: Volumes may have better performance for I/O operations than bind mounts.

  • Use Cases: Bind mounts are typically used during development to mount source code or configuration files into a container, while volumes are used more often in production for persisting data.

Understanding the differences between bind mounts and volumes is crucial for making the right choice for data persistence in your Docker containers.

Docker tmpfs Mounts

In addition to volumes and bind mounts, Docker offers another type of mount known as a tmpfs mount. tmpfs mounts are stored in the host system’s memory and are mainly used for cases where you don’t want data to persist either on the host machine or within the container. They are commonly used for sensitive data that you don’t want to write to disk.

What are tmpfs Mounts?

tmpfs stands for temporary file storage. tmpfs mounts are temporary file systems that reside in memory and, optionally, swap. Files in tmpfs are stored in volatile memory; when the system restarts, files in tmpfs are lost. On Docker, tmpfs mounts are used for creating a temporary space that can be written to and read from, but that doesn’t leave traces on the host machine or the container once the container is removed.

Working with tmpfs Mounts

You can create a tmpfs mount when running a container. Here is how you can do it:

docker run --tmpfs /tmpfs_mount_location <image-name>

In this command, /tmpfs_mount_location is the directory inside the container where the tmpfs mount will be created.

Differences between tmpfs Mounts, Bind Mounts, and Volumes

The differences between tmpfs mounts, bind mounts, and volumes can be summed up as follows:

  • Persistence: Volumes and bind mounts persist data, while tmpfs mounts do not.

  • Storage: Volumes and bind mounts store data on the host machine’s filesystem. In contrast, tmpfs mounts store data in the host machine’s RAM, making them faster but also more volatile and consuming more of the system’s memory resources.

  • Use Cases: Bind mounts are often used during development to mount source code or configuration files into the container. Volumes are more often used in production for persisting data. tmpfs mounts, however, are mainly used for sensitive information or for cases where you need a temporary storage area that doesn’t leave traces on the host or container when the container is removed.

Understanding how and when to use each type of mount is crucial when working with Docker containers. tmpfs mounts can be particularly useful when dealing with sensitive data or when you need a temporary storage area that doesn’t persist data.

Docker Storage Drivers

Docker storage drivers are an essential component of the Docker ecosystem, as they are responsible for enabling and managing the persistent storage operations of Docker containers.

What are Docker Storage Drivers?

A storage driver is responsible for the layering mechanism in Docker, which is a key part of how Docker efficiently handles data. The storage driver provides a way to manage the data that Docker containers create. It handles the details of the read/write operations, image handling, and the layering of images.

Types of Docker Storage Drivers

Docker supports several storage drivers, each with its unique advantages, limitations, and use cases. Choosing the right driver depends on the nature of your workloads and specific use case. Here are a few of the most common storage drivers:

aufs: It’s a fast and mature storage driver, but it’s not included in the mainline Linux kernel.

overlay2: This is the recommended storage driver for most use cases and is the default for Docker CE. It’s faster than Device Mapper, Btrfs, and ZFS in most scenarios.

devicemapper: This driver is robust and offers granular control for advanced Docker users. However, it’s not recommended for high-performance requirements.

btrfs and zfs: These drivers can be an excellent choice if your system already uses Btrfs or ZFS, as they offer features like snapshotting and scalability.

Selecting a Docker Storage Driver

To select a storage driver, you need to consider several factors:

  • Stability: Some drivers are more stable than others. For instance, overlay2 and aufs are typically more stable than btrfs.

  • Performance: The performance can significantly vary between drivers and can depend on your workload.

  • Compatibility: Not all drivers are available on all platforms. For instance, aufs is not included in the mainline Linux kernel.

  • Features: Some drivers offer unique features. For instance, btrfs and zfs support snapshotting.

To check what storage driver your Docker installation is currently using, you can use the docker info command. To change the storage driver, you would typically do so when starting the Docker daemon, using the --storage-driver flag.

Understanding Docker storage drivers is crucial for managing Docker containers, especially for workloads that require high I/O performance or specific features not provided by the default storage driver.

Exercise & Labs

Exercise 1: Create and Inspect a Docker Network

In this exercise, students will create a new Docker network and then inspect it to understand its configuration.


  1. Create a new Docker network using the command docker network create <network-name>.
  2. List all Docker networks to confirm the creation of your network using docker network ls.
  3. Inspect your newly created Docker network using docker network inspect <network-name>.

Exercise 2: Working with Docker Volumes

In this exercise, students will create a Docker volume, use it within a container, and inspect it.


  1. Create a new Docker volume using docker volume create <volume-name>.
  2. Run a container and attach the volume to it. Use the -v option with docker run.
  3. Inspect the volume to see if it is properly attached to the container using docker volume inspect <volume-name>.

Exercise 3: Docker Bind Mounts

In this exercise, students will use Docker bind mounts to map a host directory to a directory in the container.


  1. Create a new directory on the host machine.
  2. Create a new file within this directory and write some text into it.
  3. Run a container and mount the directory from the host to the container using the -v option with docker run.
  4. Inside the container, navigate to the mounted directory and check if the file and its content are available.

Exercise 4: Docker tmpfs Mounts

In this exercise, students will create a tmpfs mount in a Docker container, write data to it, and observe the behaviour after the container is removed.


  1. Run a new Docker container with a tmpfs mount using the --tmpfs option with docker run.
  2. Within the container, navigate to the mount point, create a new file, and write some data into it.
  3. Exit and remove the container.
  4. Run a new instance of the same Docker container without the tmpfs mount and check if the data persists.

Exercise 5: Exploring Docker Storage Drivers

In this exercise, students will explore different storage drivers used by Docker.


  1. Use the docker info command to find out which storage driver your Docker installation is currently using.
  2. Research on the storage driver being used. What are its key features, and why is it suitable for your current Docker installation?
  3. Research on at least two other Docker storage drivers. Compare them with your current driver.

Remember, the purpose of these exercises is to familiarize students with different Docker components related to network and data management. If students encounter any difficulties during the exercises, they should be encouraged to refer back to the respective sections of the chapter.

Working with Docker Images


Docker Use Cases