-: We have that unequal setup
at least partially decoded right will be the same one
but the way we run it, differs.
And for example, for this React app
we have this difference between what we have
during development, this development server
which also has life reloading to reload
the page whenever we change the code
which is nice, but not something we need in production.
And then we have what we want in production.
We have our finished code, which is good to have
but which doesn't bring its own server.
And that is generated
with help of a build step, a bill script
which is this build script here, which we can execute
with NPM run build.
So that's what we have.
And that's of course not what you want
because it's dot like this can't be deployed.
So let's now find out how we can still utilize features
Docker gives us to make sure
that we don't just have a container
for development, which allows us to test this application
but also a container
for production, which allows us to deploy this application.
So our React app basically needs to be executed differently
in development and in production.
And therefore we'll have to set
up two different environments
because our reactor forces us to do so.
It's also worth keeping in mind that
we, for example, only need node
in development because that's development server
which has started with NPM start is actually a node server
under the hood.
In production if we won't need node
unless we wanna build our own
node server that serves the finished JavaScript files
and the finished front end web application because
of JavaScript code itself
which we build with react is not dependent
on node is not executed with node JS.
So that's one important difference to keep in mind.
And therefore what I'll do is I will
add a second Dockerfile and I'll name it, Dockerfile.prod.
Now the name is up to you.
I just wanna indicate that this is my production Dockerfile
and this is my development Dockerfile.
Now the Dockerfile.prod file will
have all the instructions we need
to create a web server that serves these built
and optimized Java script files.
And of course the big problem here will be
that we therefore don't just need to run
NPM run build to generate these files
but that we also need to bring our own server
which serves them
because again with just build,
we don't get a server, start brings one
but it's just this unoptimized development server.
Now, nonetheless, let's first of all, build all of that.
And for this, we can generally copy our Dockerfile set up
from the main Dockerfile into the prod file.
Maybe switch to a special node image
the 14-alpine image maybe, to use a smaller one
which has everything we need, but is less to download.
But besides that we set the working directory.
We copy package.json, we install all our dependencies.
We copy over our code into the image
but then here the last two steps that will differ.
We won't expose any port
because here we won't start any service.
Instead here, I wanna run this build script here
and we can do this by calling NPM, run, build here.
So I wanna execute this command and we need to run here.
We can't just do NPM build
because that's how the package.json file and NPM works.
The start script is effectively a special script
which we can execute with just NPN start for other scripts
we need to execute them with the NPM run command.
And therefore we now run the build command here
when this container is created
when this image is instantiated as a container,
but as I mentioned, this
can't be all because this now gives us the optimized files.
But if we wanna use this container
in production, we don't just need the finished files.
We also need a server that serves them.
And for this, let me introduce you to Multi-Stage Builds.