Docker's built-in `local` volume driver can be given mount options at creation time, and third-party volume plugins can be installed alongside it. Explain what a volume driver is responsible for, what the `local` driver's options let you do, and how you would decide whether a workload needs a plugin driver instead.

## What a driver is Docker's volume subsystem is an interface, not an implementation. When you run `docker volume create`, the daemon delegates to a **volume driver** that implements a small contract: `Create`, `Remove`, `Mount`, `Unmount`, `Path`, `Get`, `List`, `Capabilities`. The daemon knows only "give me a host path I can bind into this container's mount namespace, and tell me when I may release it". Everything about where the bytes really live is the driver's business. `docker volume inspect app-data` shows which driver owns a volume, the options it was created with, and its **scope**: `local` (meaningful only on this host) or `global` (the same volume name means the same storage across a cluster). Scope is the property that decides whether rescheduling a workload onto another machine can work. ## The built-in `local` driver Default, always present, no installation. Data lives under `/var/lib/docker/volumes/<name>/_data` on the daemon host — meaning the workload is pinned to that machine. What many engineers miss is that `local` accepts options that map directly onto the Linux `mount` command, so it can front other filesystems: **NFS** ``` docker volume create --driver local \ --opt type=nfs \ --opt o=addr=10.0.0.5,rw,nfsvers=4,hard,timeo=600 \ --opt device=:/exports/app app-nfs ``` The daemon host performs the NFS mount when a container first uses the volume. Containers on several hosts pointed at the same export share data — a poor-man's shared storage with no plugin installed. The `hard`/`timeo` options matter: with a soft mount, an NFS blip surfaces as I/O errors inside the container. **tmpfs** ``` docker volume create --driver local --opt type=tmpfs --opt device=tmpfs \ --opt o=size=256m,uid=1000 scratch ``` A named, reusable RAM-backed volume (distinct from a per-container `--tmpfs` flag). **Bind to a specific host path** ``` docker volume create --driver local \ --opt type=none --opt o=bind --opt device=/srv/app-data app-bind ``` This gives a named, inspectable, labelled object whose data sits at a path you chose — useful when you want volume-shaped lifecycle management over a directory on a dedicated disk. Two constraints to remember: options are **fixed at creation** (no editing later — recreate and copy), and the mount is attempted lazily, so a bad NFS address surfaces as a container that will not start rather than as a failed `volume create`. ## Plugin drivers Installed as managed plugins: ``` docker plugin install vieux/sshfs docker volume create -d vieux/sshfs -o sshcmd=user@host:/data -o password=... remote ``` The ecosystem covers cloud block storage, distributed filesystems and vendor arrays. Swarm additionally supports cluster volumes backed by CSI plugins, where the orchestrator asks the driver to attach storage wherever the task is placed. What you buy: storage that outlives one host, so a container rescheduled elsewhere finds its data; features the local filesystem lacks (snapshots, replication, quotas, encryption at rest managed by the array); and, for `global`-scope drivers, one namespace across the cluster. What you pay: - **A dependency in the container start path.** Plugin down or wedged → containers cannot mount → they will not start. You have added a distributed system beneath your distributed system. - **Maintenance risk.** Many once-popular volume plugins are unmaintained; several vendors moved their investment to CSI for Kubernetes and left the Docker plugin behind. Check commit activity before adopting. - **Operational surface.** Credentials for the storage backend on every host, plugin upgrades coordinated with engine upgrades, driver-specific failure modes to learn, and metrics that your existing monitoring does not collect. - **Backups are still yours.** A replicated array protects against disk failure, not against `DELETE FROM`. Helper-container or application-native backups remain necessary. - **Performance shape changes.** Network storage turns local page-cache-friendly I/O into round trips; latency-sensitive databases feel it. ## The decision Ask, in order: 1. **Must this workload's data survive the loss of one host, or move with the container?** No → `local`, and stop. This covers most single-host deployments, CI, dev, and services whose durability comes from application-level replication (a three-node database replicating over the network wants fast local disks, not shared storage). 2. **If yes, can the application replicate instead?** Application-level replication is usually more predictable than shared block storage and avoids the split-brain risks of shared filesystems. 3. **If shared storage is genuinely required, is NFS via the `local` driver enough?** Often yes, and it costs no plugin — good for shared assets, uploads, artefact caches. 4. **Only then take a plugin**, and require: active maintenance, a documented failure behaviour when the backend is unreachable, a tested restore, and metrics. And note the strategic angle: if you are heading toward orchestration, storage integration there is done through CSI rather than Docker volume plugins, so investing heavily in engine-level plugins can be a dead end. That belongs in the decision, not just the implementation.