Now there is one other thing related
to volumes which I wanna show you.
And that would be read only volumes.
Let's say we start our container again with Docker run
the same container we've been starting over
and over for all this module,
we started this feedback app with our named volume
with our bind mount and with our anonymous volume
for node modules to save those dependencies
from the bind mount.
But now let's have a closer look at our bind mount
before we start this container.
If we think about this bind mount,
the idea is that we can edit our source code here,
and changes are automatically available
inside of the container right?
The idea is definitely not that the container should be able
to write into the app folder,
the container should not be able to change the files
in there, only we should be able to change them
on our host machine file system,
not from inside the container, the running application
in the container should not change these files.
And that's why we might want to enforce this.
Also to make it really clear what our intention is,
by turning this volume this bind mount
into a read only volume.
By default volumes, are read write,
which means the container is able to read data from there
and write data to them.
But you can restrict that by adding an extra colon
after the container internal path,
and then RO for read only.
This ensures that docker will now not be able to write
into this folder or any of its sub-folders.
Of course, we on our hosting machine still will be able
to change these files, this does not affect us,
it only affects the container and the application running
in the container.
Still, this is not all we need to do in this scenario,
because you have to keep in mind that we bind
this entire project folder as a bind mount.
So all the folders and files here.
And at the moment, this would mean that we also restrict
the write ability to feedback and temp.
These, however, are folders to which we wanna write
from inside our source code.
In server.js, I will definitely try to write a file
into my temp folder and into my final folder,
so the feedback folder.
Hence, we should make sure that writing is possible
to those folders.
And here the logic is the same as before
with this anonymous node modules folder.
If we specify another volume, inside of this entire project
folder volume here inside of the entire app folder
in the container, if we specify a more specific sub-volume,
so to say, then that sub-volume overrides the main volume,
you could say, just like this anonymous volume ensures
that node modules is not taken from the bind mount,
but instead we stick to the one created
during the image building.
So that means that for example, for app/feedback,
we're already good.
We already have this extra volume of course,
because we wanna persist the data that's in there,
we want the data to survive.
And since this has a longer container internal path
than just a /app, and this is not read only this named
volume here, this feedback folder will be writable.
Now we just need to do something similar for the temp
folder, which means we need to add an additional volume.
And that can be an anonymous volume to app/temp.
That might be a good idea anyways,
because even though that will not survive container removal
and restarts, it actually will ensure that the container
can write this temporary data to the host file system.
And that actually will make it a bit more efficient
internally I did talk about this before.
And we did add this in the Dockerfile already.
However, we should remove it there
because we actually only overwrite our bind mount here.
If we specify this anonymous volume here in the command line
on Docker run, not when we do it inside of the Dockerfile.
This is actually required to be specified
in the command line on Docker run in order to ensure
that it really overrides this bind mount here.
So I removed it from the Dockerfile
and instead added it here.
And now with that, we should be good.
We ensure that all the volumes where we need to write
from inside the container are writable
and the outer volumes where this is not required or not.
So if we now hit Enter, we start this container.
We can reload this page.
And if we leave a number feedback here,
that all works just as before, but now actually,
we have this extra clarity regarding our bind mount.
Now, of course, in this application,
we never tried writing to it.
But this is simply a good practice, you could say
a good idea to ensure that you don't accidentally
change files inside of your container
which you shouldn't change, then this might be worth a look
it might actually be a useful pattern to use here.