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.

To demonstrate the default behavior of the docker container, let us run the container by using the following command:

docker run -d --name iris-comm -p 1972:1972 -p 52773:52773 -e IRIS_PASSWORD=demo -e IRIS_USERNAME=demo intersystemsdc/iris-community:latest

#docker run command to create and start the container
docker run 
#-d -an option used to start container in deattach mode
-d 
#name of the container
--name iris 
#-p -an option is used to map the ports
-p 1972:1972 
-p 52773:52773 
#-e -an option to set environment variable
-e IRIS_USERNAME=demo
-e IRIS_PASSWORD=demo
#base image
intersystemsdc/iris-community:latest

Run the following Docker command to list the details of running containers:

docker ps

Let us connect to the iris terminal by using the following docker command:

docker exec -it iris-comm iris session iris

We will save some data to IRIS by using "DockerVolume" global

To view the value of global, navigate to the management portal (demo | demo)
http://localhost:52773/csp/sys/exp/%25CSP.UI.Portal.GlobalList.zen?$NAMESPACE=USER
 
To see the value, click on the 'View' option

Now, we will recreate the container to check if IRIS data persists.

In order to recreate the container, we have to stop and remove the container.

Below docker commands will stop, remove, and recreate the container. 

# Stop the container
docker stop iris-comm

# Remove the container
docker rm iris-comm

# Create the container
docker run -d --name iris-comm -p 1972:1972 -p 52773:52773 -e IRIS_PASSWORD=demo -e IRIS_USERNAME=demo intersystemsdc/iris-community:latest

"Let us connect to the IRIS terminal and check the value of the global which we saved earlier

Our data is not available once we recreated the container.

Docker provides several options for containers to store data, allowing for flexibility and customization based on different use cases. Here are the main options:

• 1- volumes

  Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux). Non-Docker processes should not modify this part of the filesystem. Volumes are the best way to persist data in Docker. When we create a volume, it's stored within a directory on the Docker host. When we mount the volume into a container, this directory is what's mounted into the container. This is similar to the way that bind mounts work, except that volumes are managed by Docker and are isolated from the core functionality of the host machine. When we mount a volume, it may be named or anonymous. Anonymous volumes are given a random name that's guaranteed to be unique within a given Docker host. Just like named volumes, anonymous volumes persist even if we remove the container that uses them, except if you use the --rm flag when creating the container, in which case the anonymous volume is destroyed.  If we create multiple containers after each other that use anonymous volumes, each container creates its own volume. Anonymous volumes aren't reused or shared between containers automatically. To share an anonymous volume between two or more containers, we must mount the anonymous volume using the random volume ID. Volumes also support the use of volume drivers, which allow you to store your data on remote hosts or cloud providers, among other possibilities.  

• 2- Bind mounts

  Bind mounts may be stored anywhere on the host system. Non-Docker processes on the Docker host or a Docker container can modify them at any time. It has limited functionality compared to volumes. When we use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full path on the host machine. The file or directory does not need to exist on the Docker host already. It is created on demand if it doesn't yet exist. Bind mounts are fast, but they rely on the host machine's filesystem having a specific directory structure available. If we are developing new Docker applications, consider using named volumes instead. You can't use Docker CLI commands to directly manage bind mounts.  

• 3- tmpfs

  Docker also supports containers storing files in-memory on the host machine. Such files are not persisted. If you're running Docker on Linux, tmpfs mount is used to store files in the host's system memory. If you're running Docker on Windows, named pipe is used to store files in the host's system memory. It can be used by a container during the lifetime of the container, to store non-persistent state or sensitive information. For instance, internally, Swarm services use tmpfs mounts to mount secrets into a service's containers.

Retain IRIS data in a Docker Container for a long duration by using Docker Volume

Using Docker volumes is straightforward. All we need is to create a volume and specify volume name while running container

Below is the Docker command to create a new volume named irisVol:

docker volume create irisVol

irisVol volume is created.

Note: we do not necessarily need to create a volume before using it in a container. Docker will automatically create a volume for you if you specify a volume name that doesn't already exist.

Below is the docker command to inspect the volume:

$ docker volume inspect irisVol

By default, named volumes are created under this path:
/var/lib/docker/volumes/<name>/_data.
 

Enter the same command used earlier to run the container, but add the irisVol volume option

docker run -d --name iris-comm -p 1972:1972 -p 52773:52773 -e IRIS_PASSWORD=demo -e IRIS_USERNAME=demo --mount source=mvol,target=/usr/irissys/mgr/user/ intersystemsdc/iris-community:latest

--mount source=mvol,target=/usr/irissys/mgr/user/:

• This option mounts a volume to the container.
• source=mvol specifies the name of the Docker volume to use.
• target=/usr/irissys/mgr/user/ specifies the directory inside the container where the volume will be mounted. Please note this is container directory where iris user database is stored.

Let's connect to the IRIS terminal and set a global value that we will check to see if it persists

Stop and Remove the container

Recreate the container

Connect to iris terminal again and check the global ^DockerVolume value

Kudos! Docker has retained IRIS data

We can inspect the volume details by using the following command as well:

$ docker container inspect iris-comm

The results of this command are lengthy but notice that the Mounts area contains information about your volume, which is this container mounted when initially run.

By going through this process with mounted volumes, there are two key points to understand:

• Volumes exist outside of the layered file system of a container. This means that they are not included in the usual copy-on-write procedure when manipulating files in the writable container layer.
• You can manipulate files on the host machine and have those changes seamlessly propagate into a running container via a mounted volume. This is a popular technique for developers who containerize their runtime environment, but mount their in-development code. This way, you can edit your code using your host machine, and propagate those changes into running containers without rebuilding or restarting machines.

Thanks!