Container Storage

How to give a container persistent storage or access to host files.

  3 minute read  

By default, anything a container writes is lost when it stops — the filesystem is reset every time the container restarts. To keep data around, or to share a file from the appliance with the container, configure a mount on the container’s Mounts screen.

There are two mount types: bind and volume. Pick a volume for application data you want to keep; pick a bind mount when you want to share a specific file or folder that already exists on the appliance.

Bind mounts

A bind mount makes a file or folder from the appliance visible inside the container.

FieldNotes
TypeBIND
SourceThe path on the appliance, e.g. /etc/myapp or /var/log/myapp. The path must already exist on the appliance before the container starts.
DestinationWhere the container should see it.

Limitations:

  • The path has to already exist on the appliance — there’s no portal mechanism to populate an arbitrary appliance path. For shipping configuration in, use environment variables or bake the config into the image.
  • On a cluster, the path has to exist on every member or the container will fail on the member that’s missing it.
  • The container needs permission to read or write the path. If it can’t, you’ll see a Permission denied error in the container’s logs.

Volumes

A volume is a piece of managed storage that lives alongside the container, set up under Compute → Container Management → Volumes. Volumes have a name and can be reused across containers.

FieldNotes
TypeVOLUME
SourceThe name of a volume you already created.
DestinationWhere the container should see it.

When to use a volume:

  • You want Trustgrid to handle the storage location instead of picking a host path yourself.
  • You want the data to survive container restarts, image updates, or container reconfiguration.
  • You want to share storage between two containers running on the same appliance.
  • You want to encrypt the data at rest (see below).

Encrypted volumes

Mark a volume Encrypted to have Trustgrid encrypt its contents at rest. The key is fetched from the Trustgrid control plane when the container starts, so the volume can only be unlocked while the appliance is connected to the control plane.

When mounting an encrypted volume, the mount configuration includes Require Connectivity, which controls what happens when the appliance is disconnected from the control plane:

  • On - the container won’t start until the appliance reconnects to the control plane and the volume can be unlocked. Use this when running offline is worse than not running.
  • Off - a container that’s already running keeps running; one trying to start while disconnected will fail because the volume can’t unlock.

Require Connectivity has no effect on unencrypted volumes.

Bind or volume — quick comparison

BindVolume
Storage locationA path you pick on the applianceTrustgrid manages it
Survives container restart / image changeYesYes
Encryption availableNoYes
Works automatically on all cluster membersNoYes — volumes are defined at the cluster level
Good fit for application data (databases, app state)Not ideal — no encryption, manual cluster setup✔

For most workloads, use volumes. Bind mounts are a fit only when there’s already an appliance-side path the container needs to see (e.g. a path created by another Trustgrid feature).

Importing volumes between nodes

Under Container Management → Volumes there’s an Import action that copies a volume’s name and settings from another node or cluster — handy when rolling out the same container to a new edge. It copies the definition only; the new volume starts empty.