Skip to content

7.02 Volume Driver Plugins in Docker

Abstract

Volume Driver Plugins manage Docker volumes and allow containers to use storage from local or external storage systems.

Storage drivers manage image and container layers, while volume drivers manage persistent volumes.

Docker Storage Overview

Docker storage has two important driver types:

Driver Type Purpose
Storage Driver Manages image layers and container writable layers
Volume Driver Manages persistent volumes for containers

Note

Storage drivers and volume drivers are not the same.

  • Storage drivers handle layered image storage.
  • Volume drivers handle persistent container data.

Storage Drivers vs Volume Drivers

Storage Drivers

Storage drivers manage:

  • image layers
  • container layers
  • copy-on-write behavior
  • layered file systems

Examples:

  • AUFS
  • ZFS
  • BTRFS
  • Device Mapper
  • Overlay
  • Overlay2

Volume Drivers

Volume drivers manage:

  • persistent volumes
  • external storage integration
  • cloud block/file storage
  • shared storage systems

Examples:

  • Local
  • Azure File Storage
  • Convoy
  • DigitalOcean Block Storage
  • Flocker
  • gce-docker
  • GlusterFS
  • NetApp
  • RexRay
  • Portworx
  • VMware vSphere Storage

Tip

Use storage drivers for Docker image/container layers and volume drivers for application data persistence.

Default Volume Driver

Docker uses the local volume driver by default.

Create a local volume:

docker volume create data_volume

Docker stores it under:

/var/lib/docker/volumes

Note

The local driver stores data on the same Docker host.

Why Volume Driver Plugins Are Needed

The default local driver works well for single-host workloads.

However, production systems often need:

  • cloud storage
  • shared storage
  • durable storage
  • storage available across hosts
  • backup and disaster recovery support

Volume driver plugins allow Docker containers to use external storage platforms.

Warning

Local volumes are tied to a single host. If the host fails, the application may lose access to data unless backups or replication exist.

External Volume Driver Example

A volume driver can provision storage from external systems such as AWS EBS.

Example using RexRay:

docker run -it \
  --name mysql \
  --volume-driver rexray/ebs \
  --mount src=ebs-vol,target=/var/lib/mysql \
  mysql

This creates a MySQL container using an external EBS-backed volume.

Success

When the container exits, the data remains stored on external storage.

Common Volume Driver Plugins

Volume Driver Example Use Case
Local Store data on Docker host
Azure File Storage Shared file storage in Azure
DigitalOcean Block Storage Cloud block storage
gce-docker Google persistent disk
GlusterFS Distributed file storage
NetApp Enterprise storage
RexRay AWS EBS, S3, EMC, Google PD, OpenStack Cinder
Portworx Cloud-native container storage
VMware vSphere Storage VMware-backed persistent storage

Example

RexRay can integrate with multiple backends such as AWS EBS, S3, Google Persistent Disk, EMC storage, and OpenStack Cinder.

Production Use Cases

Volume driver plugins are useful for:

  • databases
  • stateful applications
  • shared storage
  • cloud storage integration
  • persistent application data
  • backup and restore workflows

Examples:

Workload Storage Requirement
MySQL Durable block storage
PostgreSQL Persistent disk
Jenkins Persistent workspace
Monitoring tools Retained metrics
File upload services Shared file storage

Volume Driver Workflow

Typical workflow:

  1. Container starts
  2. Docker calls the configured volume driver
  3. Volume driver provisions or attaches storage
  4. Volume is mounted into the container
  5. Application writes data to the mounted path
  6. Data persists outside container lifecycle
Container
   ↓
Docker Engine
   ↓
Volume Driver Plugin
   ↓
External Storage

Production Best Practices

Recommended

  • Use external volume drivers for stateful production workloads
  • Use cloud-backed storage for durability
  • Back up critical volumes regularly
  • Use encryption for sensitive data
  • Monitor volume usage and performance
  • Choose drivers based on workload needs
  • Test failover and recovery procedures

Do's

  • Use volume drivers for persistent data
  • Use local volumes only when host dependency is acceptable
  • Match storage type to workload requirements
  • Monitor IOPS, latency, and capacity
  • Document volume ownership and backup policy

Don'ts

  • Don't store databases only in container writable layers
  • Don't depend on local volumes for highly available workloads
  • Don't use untested drivers in production
  • Don't ignore storage performance limits
  • Don't store secrets directly in mounted volumes without encryption

Danger

Choosing the wrong volume driver can cause data loss, poor performance, or application downtime.

Local Driver vs External Driver

Feature Local Driver External Volume Driver
Storage location Docker host External storage system
High availability Limited Depends on backend
Cloud integration No Yes
Best for Local/dev workloads Production/stateful workloads
Portability Host-dependent Better across infrastructure

Quick Commands

List Docker volumes:

docker volume ls

Inspect a volume:

docker volume inspect <volume_name>

Create a volume:

docker volume create <volume_name>

Use a volume with a container:

docker run --mount source=<volume_name>,target=/data nginx

Summary

Quote

  • Storage drivers manage Docker image and container layers
  • Volume drivers manage persistent container data
  • The default volume driver is local
  • External volume drivers integrate Docker with cloud and enterprise storage
  • Production stateful workloads should use reliable, backed-up, external storage