Managing Storage for Container Images

By default all files created inside a container are stored on a writable container layer. This means that:

  • The data doesn't persist when that container no longer exists, and it can be difficult to get the data out of the container if another process needs it.
  • A container's writable layer is tightly coupled to the host machine where the container is running. You can't easily move the data somewhere else.
  • Writing into a container's writable layer requires a storage driver to manage the filesystem. The storage driver provides a union filesystem, using the Linux kernel. This extra abstraction reduces performance as compared to using data volumes, which write directly to the host filesystem.

There are two options for containers to store files in the host machine so that the files are persisted even after the container stops: volumes and bind mounts.

For more information about storage options for containers, see Manage Data in Docker in the Docker documentation.

Support is provided for any storage-driver— overlay2 is a good choice.

Use Volumes for Storage-Elements

The container image has predefined mount points for an event broker's storage-elements. If you leave the storage-elements unspecified when you start the container, they will be stored in the container's writable layer. This can cause the container to run out of space in the union filesystem and prevent data from being properly migrated during upgrade. We strongly recommended allocating storage outside the union filesystem for all storage-elements.

The software event broker requires storage with medium to high bandwidth/IOPs and low latency. For information about getting the best storage performance, consult the best practices documentation for your platform.

As mentioned above, a volume is storage on the host filesystem that has been mounted on the container's filesystem outside the writable layer. We recommend using volumes as the means to persist data for a software event broker container.

For storage-elements mounted as volumes, we recommend xfs as the filesystem, because it has better performance than ext4.

Use External Storage Devices in Production

For production deployments, we recommend that you assign the event broker's storage-elements to external storage devices.

For information about storage options for Kubernetes, see Storage in the Kubernetes documentation.

For information about storage options for OpenShift, see Understanding Persistent Storage in the OpenShift documentation.

Some examples for how to assign external storage with Docker are shown below.

Example: Docker for Linux

To assign storage-elements to dedicated external volumes, do the following:

  1. Attach a disk, or disks, to the host. Since the specific steps for performing this task vary from one environment to the next, we recommend that you consult your environment’s documentation for instructions.
  2. Create the volumes. For detailed instructions, refer to Volumes in the Docker documentation.
  3. Update the docker create command using the --volume option to assign the storage-elements to the volumes you've created. In this example, all the storage-elements have been re-assigned, but you can delete lines in accordance with your own plan.
    docker create \
    list of options \
    --volume <jail-volume-name>:/usr/sw/jail \
    --volume <diagnostics-volume-name>:/var/lib/solace/diags \
    --volume <spool-volume-name>:/usr/sw/internalSpool \
    --volume <adbBackup-volume-name>:/usr/sw/adb \
    --volume <adb-volume-name>:/usr/sw/internalSpool/softAdb \
    --volume <var-volume-name>:/usr/sw/var \
    list of options \

Example: Docker for Windows

To expand the default storage capability of software event broker containers in Docker for Windows, you can make use of drives from the host, but these drives must be shared with the Docker for Windows Linux VM. Shared drives are configured in the Docker Settings menu.

To assign additional directories on the host as external storage, add the following to the docker run command line when starting a software event broker:

-v <host-path>:<mount-path>

Where:

<mount-path>: is the path to the storage-element listed in Understanding Storage-Elements.

For example, to assign the message spool:

> docker run -v C:\Users\username\storage\data:/usr/sw/internalSpool -d -p 8080:8080 -p 55555:55555 --shm-size=1g --env 'username_admin_globalaccesslevel=admin' --env 'username_admin_password=admin' --name=solace solace-pubsub-standard:8.10.x.x

This example mounts the internalspool volume on the host in the C:\Users\username\storage\data directory.

Example: Docker for Mac

To expand the default storage capability of software event broker containers in Docker for Mac, you can make use of drives from the host, but these drives must be shared with the Docker for Mac Linux VM. Shared drives are configured in the Docker Settings menu.

To assign additional directories on the host as external storage, add the following to the docker run command line when starting a software event broker:

-v <host-path>:<mount-path>

Where:

<mount-path>: is the path to the storage-element listed in Understanding Storage-Elements.

For example:

> docker run -v /Users/username/storage/data:/usr/sw/internalSpool -d -p 8080:8080 -p 55555:55555 --shm-size=1g --env 'username_admin_globalaccesslevel=admin' --env 'username_admin_password=admin' --name=solace solace-pubsub-standard:8.10.x.x

This example mounts the internalspool volume on the host in the /Users/username/storage/data directory.