Container Storage Plugins and Persistent Storage Architecture

The article introduces the growing importance of containers as the standard deployment unit in cloud environments and raises three key questions for architects: how containers address persistent storage needs, challenges posed by container orchestration to storage systems, and whether container‑storage integration should follow a fused or separated architecture.

It then explains Docker's storage plugin model, where Docker defines a simple set of interfaces (Plugin.Activate, VolumeDriver.Create, VolumeDriver.Mount, VolumeDriver.Path, VolumeDriver.Unmount, VolumeDriver.Remove, VolumeDriver.List, VolumeDriver.Get, VolumeDriver.Capabilities) that external storage systems implement, allowing containers to mount external volumes transparently.

Convoy, a Docker volume plugin, is examined in detail. The daemon process starts with a command such as convoy daemon --drivers glusterfs --driver-opts glusterfs.servers=192.168.0.3 --driver-opts glusterfs.defaultvolumepool=vol2 , parses arguments, initializes drivers from configuration files or command‑line options, registers routers for client and Docker requests, and launches an HTTP server on a Unix socket.

The daemon’s request handling logic routes HTTP calls to modules for volume, snapshot, and backup operations, each implemented via the ConvoyDriver interface. Up to version 0.4.3, Convoy supports four backend storage types (e.g., glusterfs, ceph, etc.), abstracted through Driver, Volume, Snapshot, and Device structures.

Objectstore provides a backup framework with implementations for S3 and VFS, offering DeltaBlockBackup and BackupFile strategies. Configuration files (e.g., volume.cfg, backup_*.cfg) store metadata, while block directories hold actual snapshot data.

In the discussion of containers, applications, and persistent storage, the author argues that containers themselves are stateless packaging mechanisms, while stateful needs arise from the applications inside them. For databases, containerization requires external persistent storage, illustrated with a MySQL example using shared virtual disks.

The article concludes with a comparison of open‑source distributed storage options (block: Ceph RBD, Sheepdog; file: GlusterFS, CephFS, HDFS; object: OpenStack Swift, Ceph RGW), recommending object storage for container workloads due to its URL‑based access model, and outlines why traditional storage struggles with the flexibility, automation, and granularity demanded by cloud‑native environments.