Containers generally run from an image and have no access to the host file system. This is fine for stand-alone ephemeral containers, but others require persistent data. While we can pass in environment variables to configure the app inside the container, sometimes a place to read and write more complex files is needed. When you update or replace such a container (perhaps with a new release) you want the new container to have access to the same data as the previous one.
The tricky thing with rootless containers is that you’re not
root on the host and, as per my previous post, containers can run as any user id. If the container runs as
0) then that is fine as it actually maps to your non-root user on the host (e.g.
1000) and management of the data is therefore easy. However, containers running as other users (e.g.
123) will map to a uid on the host based on the subuid offset range (e.g.
100122) which will not match your non-root user and therefore data management is harder.
Providing persistent storage to a container is done by setting up a bind mounts using the
-v) option with
podman. Note that volumes are not restricted to just one per container, simply repeat the
-v option for as many volumes as required!
The volume option uses a colon separated format specifying the source on the host and then the destination directory where the volume is mounted to inside the container (e.g.
The source is generally one of two types; either a container volume (like a container image) or a regular host directory.Continue reading