Docker is a platform that allows users to build, ship, and run distributed applications. Applications are stored inside docker containers.
A docker container uses a Union File System which consists of read-only layers and a read / write layer on top.
Whilst the container is running, it is possible to write information to disk, however, when the container is removed that information does not persist.
In order to persist information it is necessary to mount a volume. A volume operates outside of the Union File System - any information written to the read/write layer will be copied to the volume.
The great thing about volumes is that they decouple the life of the data being stored in them from the life of the container that created them. The volume continues to be accessible on the host machine even if the container is removed or no longer running.
Mounting a Volume
Volumes can be mounted to container at run time ...
docker run -d -P --name javaContainer -v /myVol bin/echo "Doing java stuff" > /myVol/java_activity.txt
... or from within the docker file.
FROM java
RUN mkdir /myvol
RUN echo "Doing java stuff" > /myvol/java_activity.txt
VOLUME /myvol
But what if you have multiple instances of the application that need to access the same volume? You need to make the most of the sharability that Docker provides.
The Data Container Pattern
Rather than mounting a volume to your application's container, the Data Container Pattern closely follows the single responsibility principle.
It involves setting up a volume in a separate data container. Your application container then points to the data container to read and write information (using the volume-from command). This is a common practice when working with databases.
The Lifecycle of a Data Container
The data container only runs whilst it is needed and is does next to nothing in terms of work. The application container mounts the volume contained inside the data container, once this is done the data container shuts down.
Preventing Problems
When creating a data container (e.g for storing information from a database application) it's wise to use the same base image in both your application container and data container. This will prevent any file permission issues as the data container will seed the application container with the correct file permissions and brings about greater efficiency as you are reusing the image.
Further reading
Thanks
Many thanks to Rob Taylor and Mash Badar for proof-reading this article
This post was cross-posted to my personal blog.
