8e5b17cf13
Signed-off-by: Mrunal Patel <mrunalp@gmail.com> |
||
---|---|---|
.. | ||
container.go | ||
containers.go | ||
create.go | ||
delete.go | ||
diff.go | ||
exists.go | ||
image.go | ||
images.go | ||
layers.go | ||
main.go | ||
metadata.go | ||
mount.go | ||
name.go | ||
README.md | ||
shutdown.go | ||
status.go | ||
tree.go | ||
tree_test.go | ||
version.go | ||
wipe.go |
This is oci-storage
, a command line tool for manipulating a layer store.
It depends on storage
, which is a pretty barebones wrapping of the
graph drivers that exposes the create/mount/unmount/delete operations
and adds enough bookkeeping to know about the relationships between
layers.
On top of that, storage
provides a notion of a reference to a layer
which is paired with arbitrary user data (i.e., an image
, that data
being history and configuration metadata). It also provides a notion of
a type of layer, which is typically the child of an image's topmost
layer, to which arbitrary data is directly attached (i.e., a
container
, where the data is typically configuration).
Layers, images, and containers are each identified using IDs which can be set when they are created (if not set, random values are generated), and can optionally be assigned names which are resolved to IDs automatically by the various APIs.
The oci-storage tool is a CLI that wraps that as thinly as possible, so that other tooling can use it to import layers from images. Those other tools can then either manage the concept of images on their own, or let the API/CLI handle storing the image metadata and/or configuration. Likewise, other tools can create container layers and manage them on their own or use the API/CLI for storing what I assume will be container metadata and/or configurations.
Logic for importing images and creating and managing containers will most likely be implemented elsewhere, and if that implementation ends up not needing the API/CLI to provide a place to store data about images and containers, that functionality can be dropped.