So, as I mentioned,
there are different kinds of data,
and we need to understand which kinds of data we have,
in order to understand which problems we might be facing,
and which problems we'll be solving throughout this modules.
Of course, we have our application.
So our source code and the environment in which
this application runs.
This is what we talked about a lot
in the last modules.
Now, of course, this code is written by us.
Maybe we also use some third party packages,
like the dependencies our Node applications used,
that were specified in the package.json file.
But overall, we got a package of code,
which is set up and written by us.
Now, this code
and the entire environment,
is added to the image during the build phase.
So when we build an image,
our code is copied into the image.
That was what we used the Dockerfile for,
to set up these instructions.
And when we then run a container based
on an image, of course,
that container also uses our code
end the provided environment.
Now, since it's copied into an image,
that code is fixed.
It can't be changed once the image is built.
So this data,
if you wanna call it like this, our source code
and everything related to that,
is unchangeable if we copied it into an image.
Because images are read-only,
once all the instructions finished executing,
the image is locked in
and it's closed,
and you have to rebuild it,
and therefore build a new image,
if you want to change something about it.
You can't go into an existing image
and start changing things in there,
that won't work.
But that's no problem here because our application code
and the environment, should be read-only.
And that is why we store it in an image.
The running application should not start
editing the source code, right?
That's not something you do typically
and not something you wanna do.
So that's the kind of data we thoroughly covered
in the last modules.
Now, there are two other kinds of data.
For example, we got temporary application data.
And with that, I don't mean our source code,
but I mean, data generated,
whilst the application is running.
For example, if we're talking about a website,
a user might be entering something in a forum,
and when we then fetch that data and handle it
on the server,
which might be running into container,
then this entered user data, is temporary data.
We might store it in variables, in our code,
and therefore it's in the end, only stored in memory,
or maybe we even store it in a database
or in a file.
But we are absolutely fine with losing that data
when the containers shuts down, right?
Because it's just temporary.
It's not data that needs
to be stored long term.
So that would be data,
which is not read-only,
we actually also want to write it,
whilst our application is running,
but it is temporary.
It's okay if we lose it.
And eventually we do want to clear it.
But therefore, since it's read-write,
it's stored in containers
and not in images
because images are read-only.
And when I say stored in containers,
not in images, I'm talking about this extra layer,
which is added by Docker on top of our image,
which then actually makes up that container.
And this extra layer basically is a bit
of a logic you could say,
that is aware of the image,
is aware of the file system of the image,
and kind of mirrors that file system
without copying it.
But then that's the extra thing,
here, Docker then actually also has read-write access,
and is able to manipulate that file's system.
Without changing it in the image,
just by changing it in that extra layer.
And behind the scenes,
this is managed in a very efficient way,
where Docker basically keeps track
of the changes made by the container,
and derives the final file system,
by taking the file system in the image,
and combining it with the changes stored
in that read-write layer.
That's how you can think about that,
but that's also what happens behind the scenes.
What isn't too important to us.
But that is what I mean.
When I say stored in the container,
the container stores this information,
stores files, whatever it is,
in this read-write layer,
or with help of that read-write layer.
But it's all inside of the container.
It's not on our local file system,
on our local machine,
and it's not in the image.
It's in the container.
And that's something we haven't done up to this point.
We haven't really tried to write data
inside of a container.
We haven't tried to create a file there,
and store it in the container file system.
That's not something we did up to this point,
but that is something we are going to do in this module.
And, then we got a third kind of data,
and you might be able to guess which kind of data that is.
It's permanent application data.
For example, if we got an application,
where users can sign up
and lock themselves in,
then, we got these user accounts,
which we wanna store in files
or typically in a database.
And of course that data needs to persist.
We're fetching and producing that data
in a running container.
So in the application running in the container,
but then the data, as I mentioned should be stored,
because if the container stops and restarts,
the data should still be there, right?
We don't wanna lose all the user accounts,
or any other kind of permanent data,
our application might be generating,
just because the container has stopped.
After all, we might just be deploying
a new version of our application,
and therefore we stop the container,
and deploy a new one.
That's all fine.
But our application data should not be lost because of that,
because if it would be, that would mean
that we're never allowed to change
and update the code in our container.
And that's definitely not what we want.
So there will be data which must not be lost
when a container shuts down.
And for the temporary app data,
that would be the problem.
So permanent app data is read-write data.
We wanna write it whilst the application is running,
but it must be stored permanently.
And therefore we store it in containers,
but with help of volumes.
And volumes are one of the key concepts
we are going to cover in this course module.
It's a key concept baked into Docker.
And we're going to take a closer look at it,
throughout this module.