In this lesson, you will learn how to expand your container storage beyond a single host by configuring third-party volume drivers for distributed storage.
Beyond Local Storage
Up until now, we have used named volumes and bind mounts that exist on the physical host machine. While this works perfectly for a single node, it becomes a bottleneck when you move to distributed environments. If your container stops on Node A and restarts on Node B, your data won’t follow it.
Volume drivers solve this by acting as a bridge between Docker and external storage providers like AWS EBS, Azure Disk, or networked NFS shares. Instead of telling Docker to look at a local folder, you instruct it to mount a network-attached resource as if it were a local drive.
Implementing a Volume Driver
To use a distributed storage solution, you typically install a plugin and then reference it in your docker volume create command or within your docker-compose.yml file.
Imagine you have an NFS server providing a central location for your application logs. You can create a volume managed by the local-persist or a dedicated NFS driver:
services:
app:
image: my-web-app
volumes:
- nfs_data:/app/data
volumes:
nfs_data:
driver: nfs
driver_opts:
share: "192.168.1.50:/exports/data"
device: ":/exports/data"
type: "nfs"
In this example, the nfs driver handles the heavy lifting of connecting to the remote server and ensuring the mount is ready before your container starts. Docker treats nfs_data just like any other volume, but the data is physically stored on a remote server accessible to all nodes in your cluster. This ensures that no matter where your service is scheduled, it always sees the same persistent files.
By offloading storage to dedicated distributed systems, you decouple your data from the lifecycle of the host server, enabling true mobility for your services.
Key Takeaway: Volume drivers allow you to decouple your data from specific host machines by mounting network-attached or cloud-native storage directly into your containers.