Now working with containers gets a bit more complex
if data is involved,
especially if it stayed up,
which must not be lost when a container shuts down.
Because by default containers are isolated and stateless,
which means they can read or write data.
But every data they generate will be lost
when the container shuts down.
It's by default not shared with the outside world,
and stateless means that it's not safe anywhere.
So whilst they do have their own filesystem,
that filesystem is detached from the host machine,
and they can store data,
but that data will be lost
whenever the container is removed.
Now we can work around that with bind mounts,
and with volumes,
you also see the commands for adding bind mounts
and volumes below.
Now the idea for bind balances,
that we have a certain path on our host machine,
which we know which we want to mirror into a path
and the container.
This is typically used if we have some source code
or configuration which should be picked up
by the running container.
Hence it mostly matters during development.
For volumes, our container folder is also mirrored,
to some folder on our local system,
but we don't know where this folder is necessarily.
We don't plan on putting content into that folder,
from inside our host machine,
instead it's just being used,
so that data generated by the container survives,
and is a way that again if we'd run a new container,
after the old one was removed.
That's the difference here,
and you of course learned both in detail
throughout this course.
For volumes we also have named and anonymous volumes.
We typically work with named volumes,
like here on this slide, if we want to persist data,
anonymous volumes can be useful for saving data,
which might be overwritten by some setup step
in our container otherwise.
Again, this is something where I showed you
a concrete example, in the data module of this course.
And now very interesting aspect,
when we think about containers, are networks,
and container communication,
because containers as mentioned before
by default are isolated.
Still they can be connected and send requests
to each other, and also to the outside world.
Now sending requests to the outside world is easy.
The more tricky part is
when you wanna have container to container communication.
And their option one was
to look up the IP address of the container,
and nava containers should communicate with,
and then to use that IP address.
The downside is that this might change.
It's always a lot of unnecessary work,
and the offer it's not too convenient.
Hence the more convenient and recommended alternative is,
to create a Docker network,
and to add all containers that should be able
to talk to each other, into that same network.
Then you can simply use the container name as an address,
and Docker will be able to automatically resolve
the IP addresses of the underlying containers.
That's what we learned in the networking section.
And that's an awesome feature which makes working
with containers and multi container projects way easier.