It’s not common knowledge, but NetApp actually introduced the concept of a snapshot to the industry, the ability to quickly and efficiently record the state of a volume at a point in time, as part of ONTAP way back in 1993. In fact, many of ONTAP’s most valuable features are built on snapshots, including clones.
Fast forward to today, both our ONTAP and SolidFire platforms provide snapshot and clone capabilities. You can use snapshots to backup your application by regularly sending them to another location. You can instantly revert a volume to a previously known good state if something or someone mucks with your data. You can dramatically enhance the software development lifecycle by making many efficient independent copies of an existing dataset for development and test. The possibilities are endless!
If you want to get at these features through Docker today, it’s a bit of a challenge. The current Docker volume paradigm does not support these types of primitives, limiting itself to create and destroy operations. This prevents you from realizing the full potential of the data stored in those Docker volumes.
Despite the current limitations, NetApp has worked around this, to a limited degree, by adding the ability to view snapshots on a volume using the
docker volume inspect command and to create clones using options during a
docker volume create operation, for example:
# create a volume
docker volume create -d ontap-gold --name thepub -o size=10g
# list snapshots
docker volume inspect thepub
# clone the volume
docker volume create -d ontap-gold –name netappio -o from=thepub
This bit of magic exposes the raw functionality, but it is crude for a number of reasons. It does not allow you to discover this capability through standard Docker interfaces, you have to know that it exists. You cannot truly manage snapshots, and it is not an interface you can depend on regardless of the vendor providing your storage.
Solving the Problem
NetApp, a company known for our engineering culture, holds periodic innovation challenges where we encourage our developers to spend a few days away from their day job focusing on a technical challenge or concept that is interesting to them. The team working on our containers integrations happens to be extremely passionate about that technology, so they chose to extend Docker’s volume functionality to include some new concepts.
The end result is fascinating, and a powerful testament to what a small team of skilled developers can accomplish in a short amount of time. The team added core primitives to the Docker technology stack end-to-end which enables full support for all of the snapshot-based use cases.
The following primitives were added into the Docker engine and CLI, designed to be a natural extension to the current volume functionality.
docker volume snapshot– a category of management commands for snapshots
create– create a snapshot on the volume
inspect– view details of the snapshot, such as the creation time
ls– view snapshots on the volume
rename– change the name of a snapshot, for example if doing snapshot rotation
restore– revert the volume to a particular snapshot
rm– destroy a snapshot
docker volume clone– create a clone, optionally using a snapshot as the base
With this, snapshots and clones can be treated as first class objects, and you can do a lot more with your data!
Solving the Problem, For Everyone
This functionality adds significant value for many applications, however it’s not publicly available yet. NetApp is proposing to contribute this directly to the Docker project. Keeping in line with NetApp’s core tenet of contributing to the community and participating upstream as much as possible, we want to enable this functionality for everyone, ensuring that the community benefits as much as possible.