So that's it for this module.
Again, another large module with a lot of content
and a lot of explanations in it,
but we had a look at a couple of key concepts
which you have to know when you're working with Docker.
We learned that containers can read and write data
but that volumes can help us with storing data
especially with data that should survive container removal.
We also had a look at bind mounts
which can help us with direct container interaction.
For example, with our source code,
that should be updatable by us and where the latest source
code should then always be available
inside of the container.
But let's go through what we learned step-by-step.
Containers are the heart of Docker
and they can already read and write data.
They do add this read-write layer
on top of your image after all
but data, which you write inside of a container is lost
if that container is removed.
Because of that isolation concept
often that's useful but sometimes it's not.
Pretty much every application has some kind of data
which should survive, which should persist.
And that's why you can add volumes.
Volumes in the end are folders on your host machine
on which your containers are running,
which are managed by Docker
and which are mounted into a Docker container.
There is this connection
between the paths which are mapped inside of a container
and the automatically created folder on your host machine.
And whatever is written into that mapped path
inside of the container,
is also stored on the host machine therefore,
and hence this data survives if the container is removed,
because it's basically mirrored or copied
to the host machine
and not just stored inside off the container.
Now specifically, we learned about two kinds of volumes.
Named volumes are useful because of these survive
if a container is removed
and they offer, these are the volumes we need
if we wanna store data permanently.
Anonymous volumes are actually attached to a container
and are removed if the container are removed
and therefore they're not useful for storing permanent data,
which should persist.
They can still be useful to save temporary data
make D container a bit more efficient
because less data has to be stored in the container.
More data can be outsourced to the host system.
And we also saw that they can help us with bind mounts
because bind mounts allow us to map local folders
on the host machine, which we, as a developer know
two internal folders into container
for example, to expose our source code to the container.
And then we can combine that with anonymous volumes
to not accidentally override folders that already existed
in the container, which we don't wanna override.
Bind mounts are a bit like named volumes
but the key differences that we know
the path on the host machine, where the data is mirrored,
and that we actually use that path to pass data
into the container and to actually pass data
into the container which we can change on the host machine.
And where then the latest data is always available
in the container.
Like we did it with our source code.
Now you can set up these volumes on the Docker run command
with the -v option.
Here we have a named volume
and Docker automatically creates these volumes for you.
If they don't exist yet, if they do exist
it uses the existing ones instead.
Here, we set up a bind mount by mapping an absolute path
on our local machine to an internal path into container.
And here we set up an anonymous volume.
Here we do the same to simply make sure
that certain folders inside of the container
are not overridden by the bind mount in this case.
And last but not least,
we also had a look at build arguments
and runtime environment variables
which simply can make our images
and containers a bit more dynamic and configurable
since we can pass in certain pieces of data
from outside when we built the image
or when we ran the container.
And we don't have to hard code everything
into the Docker file or into our source code.
Instead, we can configure this when we run the container
and that can be useful as well.
And that's what we learned in this module
as always definitely feel free to go back
to certain lectures and go through them again.
If certain concepts should not be entirely clear by now
in the next module,
we're going to dive even deeper into Docker.
And we're also going to explore
how we can actually use multiple containers
running different applications, and how we can ensure
that these containers can then work together.
Also quite interesting this year
is an important of foundation, which we need for debt.
So make sure we're all on the same page.