Por defecto, todos los archivos creados dentro de un contenedor se almacenan en una capa writable del contenedor. Esto significa que:

• Los datos no persisten cuando ese contenedor ya no existe, y puede ser difícil extraer los datos del contenedor si otro proceso los necesita.
• La capa writable (en la que se puede escribir) de un contenedor está estrechamente ligada a la máquina anfitriona donde se está ejecutando el contenedor. No se puede mover fácilmente los datos a otro lugar.
• Escribir en la capa writable (en la que se puede escribir) de un contenedor requiere un controlador de almacenamiento para gestionar el sistema de archivos. El controlador de almacenamiento proporciona un sistema de archivos en unión, utilizando el núcleo de Linux. Esta abstracción adicional reduce el rendimiento en comparación con el uso de volúmenes de datos, que escriben directamente en el sistema de archivos del anfitrión.

Para demostrar el comportamiento predeterminado del contenedor Docker, ejecutemos el contenedor utilizando el siguiente comando:

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

Ejecutaremos el siguiente comando de Docker para listar los detalles de los contenedores en ejecución:

docker ps

Conectémonos al terminal de IRIS utilizando el siguiente comando de Docker:

docker exec -it iris-comm iris session iris

Guardaremos algunos datos en IRIS utilizando la variable global "DockerVolume".

Para ver el valor de la global, navegad al portal de gestión (demo | demo).
http://localhost:52773/csp/sys/exp/%25CSP.UI.Portal.GlobalList.zen?$NAMESPACE=USER
 
Para ver el valor, haced clic en la opción 'Ver'.

Ahora, recrearemos el contenedor para comprobar si los datos de IRIS persisten.

Para recrear el contenedor, debemos detener y retirar el contenedor.

Los siguientes comandos de Docker detendrán, retirarán y recrearán el contenedor.

# 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

Conectémonos al terminal de IRIS y verifiquemos el valor de la variable global que guardamos anteriormente.

Nuestros datos no están disponibles una vez que recreamos el contenedor.

Docker proporciona varias opciones para que los contenedores almacenen datos, permitiendo flexibilidad y personalización basada en diferentes casos de uso. Aquí están las principales opciones:

• 1- Volúmenes

  Los volúmenes se almacenan en una parte del sistema de archivos del host que es gestionada por Docker (/var/lib/docker/volumes/ en Linux). Los procesos que no pertenecen a Docker no deben modificar esta parte del sistema de archivos. Los volúmenes son la mejor manera de persistir datos en Docker. Cuando creamos un volumen, este se guarda dentro de un directorio en el host de Docker. Cuando montamos el volumen en un contenedor, este directorio es lo que se monta en el contenedor. Esto es similar a cómo funcionan los bind mounts, excepto que los volúmenes son gestionados por Docker y están aislados de la funcionalidad principal de la máquina host. Al montar un volumen, puede ser nombrado o anónimo. Los volúmenes anónimos reciben un nombre aleatorio que es único dentro de un host Docker dado. Al igual que los volúmenes nombrados, los volúmenes anónimos persisten aunque se elimine el contenedor que los utiliza, a menos que se utilice la bandera  --rm al crear el contenedor, en cuyo caso el volumen anónimo se destruye. Si creamos varios contenedores consecutivamente que usan volúmenes anónimos, cada contenedor crea su propio volumen. Los volúmenes anónimos no se reutilizan ni se comparten automáticamente entre contenedores. Para compartir un volumen anónimo entre dos o más contenedores, debemos montar el volumen anónimo utilizando el ID de volumen aleatorio. Los volúmenes también admiten el uso de controladores de volumen, que permiten almacenar los datos en hosts remotos o proveedores de la nube, entre otras posibilidades.

• 2- Montajes Bind

  Los montajes bind o bind mounts pueden almacenarse en cualquier lugar del sistema host. Los procesos que no pertenecen a Docker en el host de Docker o en un contenedor Docker pueden modificarlos en cualquier momento. Tienen funcionalidad limitada en comparación con los volúmenes. Cuando usamos un bind mount, un archivo o directorio en la máquina host se monta en un contenedor. El archivo o directorio se referencia por su ruta completa en la máquina host. El archivo o directorio no necesita existir previamente en el host de Docker. Se crea bajo demanda si aún no existe. Los bind mounts son rápidos, pero dependen de que el sistema de archivos de la máquina host tenga una estructura de directorios específica disponible. Si estamos desarrollando nuevas aplicaciones Docker, considera usar volúmenes nombrados en su lugar. No se pueden usar comandos de CLI de Docker para gestionar directamente bind mounts.

• 3- tmpfs

  Docker también admite contenedores que almacenan archivos en memoria en la máquina host. Estos archivos no persisten. Si estáis ejecutando Docker en Linux, utilizad el montaje tmpfs para almacenar archivos en la memoria del sistema del host. Si estáis ejecutando Docker en Windows, se utilizad un named pipe para almacenar archivos en la memoria del sistema del host. Este tipo de almacenamiento en memoria puede ser utilizado por un contenedor durante su ciclo de vida para almacenar estado no persistente o información sensible. Por ejemplo, internamente, los servicios de Swarm utilizan montajes tmpfs para montajes "secretos" en los contenedores de un servicio.

Cómo conservar datos de IRIS en un contenedor Docker durante un período prolongado utilizando Docker Volume

Usar volúmenes de Docker es sencillo. Todo lo que necesitamos es crear un volumen y especificar el nombre del volumen mientras ejecutamos el contenedor.

A continuación se muestra el comando Docker para crear un nuevo volumen llamado irisVol:

docker volume create irisVol

Se crea el volumen irisVol.

Nota: no es necesario que creemos un volumen antes de usarlo en un contenedor. Docker creará automáticamente un volumen si especifica un nombre de volumen que aún no existe.

A continuación se muestra el comando de la ventana acoplable para inspeccionar el volumen:

$ docker volume inspect irisVol

De forma predeterminada, los volúmenes con nombre se crean en esta ruta:
/var/lib/docker/volumes/<nombre>/_data.

Ingresad el mismo comando usado anteriormente para ejecutar el contenedor, pero agregad la opción de volumen irisVol

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/:

• Esta opción monta un volumen en el contenedor.
• source=mvol especifica el nombre del volumen Docker que se utilizará.
• target=/usr/irissys/mgr/user/ especifica el directorio dentro del contenedor donde se montará el volumen. Tened en cuenta que este es el directorio contenedor donde se almacena la base de datos de usuarios de iris.

Conectemos al terminal IRIS y establezcamos un valor global que comprobaremos si persiste

Detener y retirar el contenedor.

Recread el contenedor

Conectaos nuevamente al terminal iris y verificad el valor global ^DockerVolume

¡Éxito! Docker ha conservado los datos de IRIS

También podemos inspeccionar los detalles del volumen usando el siguiente comando:

$ docker container inspect iris-comm

Los resultados de este comando son largos, pero tened en cuenta que el área Montajes contiene información sobre vuestro volumen, que es este contenedor montado cuando se ejecuta inicialmente.
Al realizar este proceso con volúmenes montados, hay dos puntos clave que se deben comprender:

• Los volúmenes existen fuera del sistema de archivos en capas de un contenedor. Esto significa que no se incluyen en el procedimiento habitual de copia en escritura cuando se manipulan archivos en la capa contenedora de escritura.
• Podéis manipular archivos en la máquina host y hacer que esos cambios se propaguen sin problemas a un contenedor en ejecución a través de un volumen montado. Esta es una técnica popular para los desarrolladores que colocan en contenedores su entorno de ejecución, pero montan su código en desarrollo. De esta manera, podéis editar vuestro código usando vuestra máquina host y propagar esos cambios a contenedores en ejecución sin reconstruir ni reiniciar las máquinas.

Gracias!