In this part of the course,


I want to talk about how container storage


works within Docker.


Understanding storage is critical


to be able to use Docker containers in an effective way.


It avoids data loss


and will help you make sure containers run


as you expect them to.


Now let's dive in and get started.


The first type of storage available


within a container is something


I've mentioned earlier in the course,


and that's the writeable layer.


As a reminder, let's say that you have a docker image


which consists of three layers.


Conceptually, this would be represented


as a single file system.


When you run a container,


a writeable layer is added to this,


and this uses the union file system.


The result is that you see all of the existing data


from all file system layers in the image,


and then any new data is stored within this writeable layer.


And this includes both data


which is overwritten as well as any new data.


Now, the union file system allows files


and directories from different file systems to be overlaid


into one conceptual single file system,


and this is what allows this writeable layer


to be added over the read-only layers of the docker image.


This writeable layer is what makes every container


its own unique thing.


This architecture requires a file system driver,


and this has overhead and can impact performance.


So you have to keep that in mind


when architecting containerized applications.


Now the key things to remember are layers


from the docker image can be read from,


but any writes go into this writeable layer,


and the container sees both of these components


as one single file system.


Additionally, this writeable layer is linked


to the life cycle of the container.


It's not something which can be migrated around,


so any data written conceptually


is part of that one single container.


Now let's look at the other options that we have available.


Let's focus for now on a single Docker Host,


and running on this Docker Host,


let's say that we have two containers.


Now, the first storage option that we have available


is tmpfs, or tempfs.


This is a file system which is accessible


to a specific container,


which uses memory in the Docker Host.


And simply put, you should view this as fast


in memory storage, but it's not persistent


because it's not being stored on disk.


Also, it can't be shared between containers,


so really, you should only use this for temporary storage.


So maybe sensitive files


which you don't want to be stored on disk


for any length of time.


So data that you are only holding for the short-term


while processing or accessing.


The next type of storage is called a bind mount.


In addition to the containers running on the Docker Host,


we also have the host's file system.


Here, we have the root.


Then inside that, folders called /tmp, /srv,


and some others.


The names don't matter.


Bind mounts allow you to take a folder


on the host file system,


say, /srv, and mount this inside containers.


And one folder on the host file system can be accessed


by multiple containers on the same host.


Now, this is a good type of storage


if you need to share access to data,


which is stored on the host.


But that benefit does introduce a negative.


It means that this type of storage,


and so any containers that rely on this,


they also rely on a certain structure existing on the host,


and this can reduce portability.


In this example, a container configured


with a bind mount will only work if the /srv folder exists,


and it might not if I want to run this container


on my local machine or your machine, for example.


Bind mounts, because they exist as folders


outside of the container,


they will live on past the lifetime of that container.


And the folders they use on the host


could themselves be network-based folders,


for example, mounted remotely using NFS


or the network file system.


Now lastly, we have volumes, and these are like bind mounts


in that they are storage accessible to a container,


but they're managed by Docker.


So the volume is created by Docker as required,


and they also exist outside of the lifecycle of a container,


so they can remain when the container


which used them is removed.


They can be moved between containers


and even attached to multiple containers,


though there's no file locking,


so you have to be really careful about multiple processes


on multiple containers accessing files at the same time.


Now, that's all of the theory around storage,


which I wanted to cover at this fundamental level.


Don't worry, you'll get the chance to experience this


in a practical way elsewhere in the course.


For now, that's everything on this topic.


When you're ready, go ahead


and move on to the next part of the course.