-: In the last section,
we started to run into a problem
that we've seen once before inside this course.
We made a change to the source code
of one of our files,
but that change was not immediately reflected
inside the running container.
In this section, we're gonna figure out
how we can somehow get this change
to somewhat cleverly show up
inside that running Docker container
without us having to stop it, rebuild the image,
and then restart the container.
So let's get to it.
I wanna first begin by giving you a quick reminder
of how our Docker file is currently working.
We first begin by copying over the package.json file.
We then run npm install, and then most importantly
we run that copy command,
which takes the public directory,
the SRC directory,
and everything else inside of here,
and copies them over into our working directory of /app.
So just remember that for a second.
All right.
So I wanna show you that same flow
kind of in a diagram format.
So like we just said,
we get our package.json copied over,
now reflected in this diagram, we install the dependencies,
and then at some point in time,
we make a copy of SRC and Public,
and we move those copies into that container.
Remember that that is a temporary container
that is created during the image building process.
When we make these copies over here,
we are essentially taking a snapshot
of the contents of SRC and public.
It's a snapshot that is locked in time
and by default is not going to be updated
anytime we make a change to this code.
So in order to get these changes that we're making
to files inside of SRC and public,
we need to kind of abandon this approach
of doing this straight copy.
So rather than doing the straight copy,
we're going to adjust the Docker run command
that we use to start up our running container.
By adjusting this command, we're going to be making use
of a feature included with Docker called volumes.
So we're going to make use of a Docker volume.
With a Docker volume we essentially set up a placeholder
of sorts inside of our Docker container,
and so we're no longer going to copy over
the entire SRC directory or the entire public directory.
Instead, you can kind of imagine
that we're going to put a sort of,
that's not how to spell it.
We're gonna put in a kind of reference here instead.
The volume is essentially gonna set up a reference
that's going to point back to our local machine
and give us access to the files and folders
inside of these folders on the local machine.
So a Docker volume can kind of be thought of
in a very similar fashion to the port mappings
that we were setting up before.
The port mapping that we were using
mapped a container, or excuse me a port inside the container
to a port outside the container.
With a Docker volume,
we're essentially setting up a mapping
from a folder inside the container
to a folder outside the container.
Now you might be wondering,
why did we not just make use of volumes before
if this kind of solves the issue
of hooking up files and folders inside the container
to files and folders outside of it?
Well, the issue is that setting up a Docker volume
is sometimes a little bit of a pain in the rear,
just because of the syntax we have to use
when we run Docker run.
So let's take a look at these syntax we're gonna use
to set up these volumes
when we execute the Docker run command
at our terminal.
All right, so this is it.
And as you can see, we're gonna add on a fair bit here.
Now we first start off with docker run -p 3000,
but we're gonna add on these two additional switches.
Now, I'm going to ignore this first switch right here
for just a moment and just focus on the second one.
So on the second little switch we say -v,
which is used to set up a volume,
and then we say $ present working directory.
This dollar sign with pwd, or present working directory
inside of that set of parentheses
is a little bit of a shortcut.
If you flip back over to your terminal right now
and stop the running process,
if you are on Windows,
I want you to know right now,
if you're on Windows and you're running Command Prompt
or PowerShell this command is not going to work,
but it will work if you're running Git Bash.
So back at your terminal, you can run pwd
and you'll see that it's gonna print out the path
to your present working directory on your machine.
So by putting in pwd right here,
we're essentially saying get the present working directory
or the path to it,
and take this folder, like this front end folder
and everything inside of it,
and map it up to the app folder
running inside of our container.
This pwd thing right here
is something that you're gonna use every time
if you want to use docker Run to start up the container.
And so writing out this
kind of long-winded switch right here,
yeah, like I said it's just a little bit annoying.
So in general, well that's exactly why
we have not used volumes up to this point.
Now again, there's this other switch on here.
You'll notice that the first switch right here
does not have a colon like the second one does.
I wanna first run the docker run command
without the first switch.
So we're gonna run it only with the second one
and our image id on the end,
and we're just gonna see what happens,
'cause you're gonna notice some pretty interesting behavior.
All right, so let's try running this.
Now, I'm gonna first rebuild my image
with docker build -f dockerfile.dev.
I'm gonna copy my id
and then I'll execute docker run -p:3000, colon 3000.
We'll do -v with a dollar sign, a parenthesis, pwd.
We'll then put the colon in a /app,
and then finally I'll paste the image id.
Now again, if you are on PowerShell
or if you're on Windows Command prompt,
this command is not going to work
because are making use of pwd right there.
Now, if you did not install Git Bash earlier
inside this course
and if you're not using Git Bash right now,
you can either use Git Bash or in just a moment
I'm gonna show you a workaround
where we do not have to use this kind
of long form syntax right here.
So you can just hold on for a second
if you're using Command Prompt or PowerShell.
All right, so I'm gonna start that up
and you're gonna very quickly see an error message.
If you read this error message somewhat closely,
you'll notice that it appears
that the project did attempt to start up,
specifically the React project,
but we got this message here that said
React Scripts not found.
So this is clearly, well, maybe not clearly.
I take that back, not clearly,
but let me just kind of cut to the chase here
and tell you we're seeing this error message
because we obviously kind of skipped off
this additional little argument right here.
But I wanted to show you why this argument was necessary.
Let's take a quick pause.
When we come back to the next section,
I'll tell you about exactly what's happening right now
and why we are seeing that error message pop up
in our terminal.