Add diagram(s) to help demonstrate bind mounting of host system directories into containers

[jcohen02]

This issue is the result of some discussions about clarity of parts of the lesson material at a recent maintainers meeting. It extends the points discussed in #130 and is intended to provide a clear overview of what we're hoping can be illustrated visually in the material. We felt a diagram (or a couple of diagrams) would help to make this much clearer than simply describing it.

A running Docker container is effectively a lightweight "sandboxed" environment running within a host computer system. An individual interacting with a terminal inside a running container will not, by default, be able to see any files on the host system. The root (/) directory within the container is the base of the container's filesystem which is based on the image used to start the container.

The user of this container can write files to the container filesystem, install new software, download data, etc. Anything stored within the running container is stored temporarily - that is, if the container is stopped and removed, anything stored within it that was not part of the original image used to start the container is lost.

Much more practical is to be able to access and work with files from the host system directly. One option is to copy files from the host system into a running container using docker cp, then to work with them and then copy any modified/new files back to the host system from the container, again using docker cp. This is sub-optimal. If the host system fails/crashes during the process of working with the data and the docker container ends up being removed or becomes inaccessible, we lose the modified state of the data.

A better solution is that we can work directly with files located on the host system. Changes made within the running docker container are immediately visible on the host system and when the container exits and is removed, any changed files on the host system remain. This is undertaken by using docker's mount options to "bind mount" a host filesystem into a container when it is started. The user working at a terminal within the container can then see the files at the shared location within a folder inside the container - these files are the actual files stored on the host system and changing them is immediately reflected on the host system. The bind options allow mounting of a specific folder on the host system to a (potentially different) location inside the container.

Based on the comments in #130, can we provide a diagram that illustrates the host system, a container existing within the host system and then the concept of files that exist on the host system and files within the container, which are the content of the image used to start the container. Then we'd like to show how the container has a "view" of files located on the host system if they are mounted when starting the container, and that these files remain on the host system but commands/software inside the container can work with/edit these files.

@sstevens2 @ChristinaLK @aturner-epcc Hopefully this makes sense and fits with your understanding of what we'd like to illustrate, happy to provide further detail/clarification if it's not sufficiently clear.

[NeginValizadegan]

@jcohen02 Is the schematic here something similar to what you're describing here?

[jcohen02]

Hi @NeginValizadegan, thanks for following up on this. Yes, I think to some extent that the schematic you linked to is the sort of thing we're looking for (I don't recall having seen that diagram in the Docker docs previously).

I think what I had in mind was a similar style schematic-type diagram, but ideally showing an example of how an individual file or folder on a host system appears within a running container, potentially at a different mount point inside the container to where it is located on on the host system. There's an ASCII diagram in the singularity material showing how files and folders map from a host system into a container. I think I was hoping there would be a more visual way to illustrate this within the context of a diagram like the one you highlighted.

I don't know that I'm doing a great job of describing what I had in mind, but hope that helps to some extent?! 🙂