Now you will notice one thing.
If you have a look at the command I used
for running this container,
also locally here and later also once I deployed it,
I'm not using a bind mount.
Actually for this application
I'm not using any volumes at all
and there is a reason for that
because there will be a difference
between running a container in development mode
and in production mode.
In development so whilst we're working on the application,
our container of course should encapsulate
the runtime environment,
but not and that's important, not necessarily the code.
So we wanna ensure that the container
has all the tools needed to run the application,
but the code for the application during development
we are actually fine if that's coming
from outside the container
and if the container is able to pick up the latest code
without us rebuilding the image
and restarting the container.
And that's exactly what we enabled or what we added
during development with help of bind mounts
because with that we could bind a localhost project folder
so on our local machine to some folder
inside of the running container
and therefore our latest project code
was always exposed to that container
and we could make changes to that code
and see them being reflected instantly
without restarting the container.
And that's of course very convenient during development
and therefore something you commonly do during development
because it allows for instant updates
and we don't have to restart and rebuild
the image and container.
But for production, so once we take our image and container
and we move that to some remote machine
where we then run it so that users from all over the world
can see the application, there it's different.
There the idea really is that the container
works standalone and that it does not depend on
any surrounding setup on the remote machine.
The image and therefore the container based on the image
should be the single source of truth you could say.
That means we can rely on the fact
that if we take that image and run a container based on it,
we got everything this application needs.
We don't also need to move some source code
into a special folder on that remote machine.
That would totally destroy the idea behind containers
if we now all of a sudden again need to configure
the hosting machine.
We want to have everything,
what our application needs inside of that container.
There should be nothing, absolutely nothing,
around that container on the hosting machine.
And therefore when we build for production,
we use copy instead of bind mounts.
That means that we copy our source code into the image
when we build the image and therefore the built image
has the source code and the application environment.
It has everything it needs to run this application.
So copy instead of bind mounts,
that is what we wanna use for production.
And I mentioned this earlier in the course already
when I first introduce bind mounts.
I just want to highlight and emphasize it again here.
Now it's also worth noting of course
that we do have copy here and still on our local machine
during development we could run this container
and also provide a bind mount
because the bind mount is not something
set up in a Docker file.
It's something we set up on the Docker run command
with the -v flag as you learn throughout the course.
And that is why we set it up on the Docker run command
and not in the Docker file.
By doing that, we can simply differentiate
between development and production
by running a different Docker run command.
We don't have to encode anything into the Docker file
and therefore we can use one and the same Docker file
for production and for development.
That's how we can ensure that we always
work with exactly the same image
and still we have more flexibility during development.
Now of course if we used a Docker compose file,
we might have that bind mount
written into that compose file,
but I will come back to compose files
and how we deploy such multi container projects later.
For the moment it's about one container, one image
and then copy is your friend
to ensure that we have one reproducible code
and environment snapshot inside of the image
because this ensures that every image
runs without any extra surrounding configuration or code
no matter where you run it as a container
and that's really, really important.