So that were volumes and bind mounts.
Here's a quick overview, since I know it's a lot to digest
and easy to mix up these concepts.
You basically have these three ways
of using the dot v option when you use docker run.
And, this first example would create
an anonymous volume since you don't assign any name.
The second example would create a named volume
since you do assign a name.
And in the third example, the name is actually
an absolute path to a folder on your host machine
and therefore this is then a bind mount.
It's actually as easy as that.
Now when it comes to the different features
these different concepts have,
I've got another comparison for you.
With anonymous volumes, you create a volume
which is kind of attached to a container.
It's removed if the container is removed.
It survives container shut down and restart,
but if it's removed, it's gone and therefore
if you use the dash dash rm
when you ran the container,
of course the volume is all gone when you stop the container
because stopping then basically also means
removing the container.
Therefore, since it is removed when the container
is removed, you can't use anonymous volumes
to share data across containers.
And you also can't use it to save data across container
destruction and recreation as you saw.
Anonymous volumes are not useful for that.
But anonymous volumes either created
with the volume instruction in the dockerfile
or created with dash v, like this,
can be useful for locking in certain data
which already exists in the container.
They can be useful for avoiding
that this data then gets overwritten by another module.
And that's something where anonymous volumes
can save the day.
In addition, anonymous volumes also still create
a counterpart, a folder, on your host machine.
Of course that's removed when the container's removed,
but that exists as long as the container is running.
And that of course means that docker
doesn't have to store all the data inside
of the container and doesn't have
to manage all the data inside
of this container read write layer.
But that instead it can outsource certain data
to your host machine file system.
And this can also help with performance and efficiency.
So that's why anonymous modules can be worth a closer look.
And in this example,
we could consider creating another anonymous volume,
maybe inside of the docker file
to mix things up for the temp folder.
It's okay if we lose that folder
when the container is removed,
but for the reasons I just mentioned,
for example for tiny performance improvements,
it can be worth mapping this temp folder
to an anonymous volume so the data managed in there
is not managed in the docker container anymore,
but actually well outsourced
to the host file system, you could say.
That could be useful and therefore
it is something we can do here for sure.
Obviously very useful, are named volumes.
Named volumes can not be created in the dockerfile,
but instead you create them with the dash v instruction
when you run a container.
They are named because you assign a name
in front of the colon.
Now the great thing about named volumes
is that they're created in general.
They're not tied to any specific container.
They do survive container shut down
and also the removal of containers.
If you want to remove a named volume,
you can still do that, but you have to do it
with a separate command built into the Docker CLI.
We'll have a look at that later.
Now since they survived container removal,
you can use named volumes
to share data across multiple containers,
Something we didn't do in this module,
but of course you could do that.
You could mount one of the same named module
to multiple different containers,
and hence the data in there
could be shared between containers.
And you can also use them
to store data across container shutdowns and removals.
That is what we did in this module.
And then we had bind mounts.
Bind mounts serve a different purpose.
Here we know where data is stored on the host machine.
Bind mounts are also not tied to one specific container.
You can attach them to multiple containers
and they do survive container shutdown and removal.
If you want to clear the data of a bind mount,
you actually have to delete it on your host machine.
So here I would have to delete all the content here
in my project to also remove it in the container.
You can't delete it with a docker command.
And that makes a lot of sense,
because it is a folder on your system after all
and you don't want to accidentally delete this somehow.
Now of course you can share them across containers
and you can also reuse them on one
of the same container across restarts.
This also works.
And these are the three main ways we have
for managing data inside of a container.
I hope I could make it clear what the differences are
and when you use which.
And of course it should be needless to say
that throughout this course,
we'll also have plenty of other examples
where it shows this.