In the last section we saw that making a change to our index such as file and then rebuilding the image
caused the copy step to be completely invalidated.
We had to rerun copy in every step after it which means we had to sit through and wait for all of our
dependencies to be installed through run npm install.
So in this section we're going to try to figure out a way to avoid having to completely reinstall all
dependencies just because we made a little change to one the source code files inside of our project.
So here's what we'll do.
We're gonna take our current build process inside of the docker file and we're going to split the corporate
Copy operation out into two different steps.
The only thing that npm install right here requires in order to run successfully is the package not
JS on file.
That's all we care about.
We don't care about the index such as file or any other file inside of here.
So during this initial copy step I'm going to say the only thing that I want to copy is the package
not just on file so I just change the instruction right here.
It now says look in the current working directory or look in the directory specified by the build context
argument of Docker run or something Docker built and find the package stop Jace on file and then copy
that into the current working directory of the container will then rerun or Samuel will then run npm
install and then after we install all those dependencies we'll copy over everything else and so we'll
do a copy dot slash dot slash like so so.
Think about what is going to happen now as you start to work on your project.
You can make as many changes as you want to the index not just file and it will not invalidate the cache
for either of these steps right here.
The only time that NPM is npm install is going to be executed.
Again if we make a change to that step or any step above it.
And so in other words the really only effect this is going to have is if we make a change to the package
not just on file.
That's really the only situation in which npm install will normally be executed again during the build
process.
All right.
So let's try building this again and then starting the container up and just making sure that everything
still works.
All right.
I'm going to flip back over I'll do a docker build dash T.
Steven Greider again your Docker I.D. not mine.
Simple web and I will specify that Bill context with that simple dot.
So I'm gonna rerun this.
Now we have made a change to the docker files so we are gonna see some steps rerun and then we eventually
get our successfully tagged and built image.
Now before trying to run it I want you to run the same command a second time so same thing.
No changes whatsoever so that time it went extremely quickly because we were able to use the cached
version of every single step.
So now let's imagine that we are doing some normal changes to our application and a normal change would
probably be a change the index not just file.
So maybe we decide that we don't want to say bye there anymore.
Maybe instead we want to send back.
How are you doing.
So we've now made a change the index not J.S. file and we definitely need to rebuild our image because
we do not have any support for kind of hot reloading of the index Dot.
J ust file a project file into the container so we have to rebuild the image.
So I'll go back over.
I'm going to rerun the same command for a third time and we saw that it executed very quickly because
the only change that we made to any step along the way was step number five.
We copied over the entire contents of that directory Docker detected that we made a change to one of
those files and so it reran that step and every step after it.
But we did not have to rerun the NPM install step and reinstall those modules which would have taken
you know in our application not very long but in a real application it could take several minutes to
run.
All right.
So the real lesson to learn here is that yes it does make a difference.
The order in which you put the L.D. instructions into your Docker file and wherever possible it is kind
of nice to segment out the copy operations to make sure that you are only copying the bare minimum for
each successive step.
All right.
So that's pretty much it for this application now.
I hope that it was not terribly annoying for me to show you kind of like some the wrong way of doing
things and incorrect them along the way.
I hope that it was kind of nice to see the error messages appear and see the changes that we made.
Of course we could have put the right Docker file together from the get go but I don't know.
You probably may have not learned quite as much as seeing the errors occur and then fixing them in as
they occurred.
No I think this application has turned out pretty well but it's definitely a very very basic operation
so let's take a quick break right now.
We're going to come back the next section we'll start working on a much more advanced Docker project
so I'll see you in just a minute.