-: In the last section
we started putting together production versions
of our Docker files for nginx server and worker.
We're now going to start to move forward
to our client project.
Now, we're going to be writing a production Docker file
for a React project right here.
As you might recall, we already did this
during our single container deployment section
many, many videos ago.
I took the liberty of opening up the Docker file
from that project
and I'm going to pull it on the screen here really quickly.
So again, this is the production Docker file
for the single container deployment that we worked on before
specifically tailored to a React type application.
Although to be honest, we could have used it just as well
with any other front end framework.
This was a multi-stage deployment
where we first started with a node image.
We installed all of our dependencies
and then ran NPM run build to build production versions
of all of our assets.
We then started up a second layer right here
or a second phase of the build process
where we started from nginx.
We opened up port 80,
and then we copied over the production version
of all of our assets into that image.
So that's what we did before
on this single container deployment.
Now things this time around are going to be just
very slightly different than what we had back then.
So here's a diagram of the single container deployment.
We had the nginx with production versions
of our React files inside of it,
and that was all running on an Elastic Beanstalk instance.
Anytime a browser made a request to Elastic Beanstalk,
nginx automatically responded on port 80
with the production version of those React files.
Now I want to give you a quick reminder of how
our architecture is a little bit different this time around
with our multi container set up
specifically in the development environment.
So this time on this project,
browser will make a request into the initial nginx server.
And this nginx server right here,
this is specifically responsible for routing
and making sure that requests get to the correct backend.
When a request goes off to get our production,
or excuse me, our React assets,
a request is made or forwarded onto port 3000
on the React server.
Now when we move into production,
we have to take that port 3000 right there into account.
So this time around we're still going to have a nginx server
that is solely dedicated to serving up
our production React files.
But this time around, rather than listening on port 80
and being like the first jump inside of the
Elastic Beanstalk instance,
it's going to be listening on port 3000.
And users are only going to be able to access
this nginx server right here
with all of our production files
by first going through the other copy of nginx
that is specifically responsible for, again, routing.
So between the previous version of this
React front end Docker file
and all this kind of production-izing of the React project
before we will, we're 100% concerned with port 80,
this time around we need to do a little bit of configuration
of the nginx server to make sure that it instead
listens on port 3000 and still exposes
all the React production assets on Port 3000, instead.
Now, quick question, you might have.
You might be curious, "Steven we've got two copies
of nginx right here.
Could we, instead, just like make use of one copy?
Like maybe just have a single copy of nginx
that listens on port 80,
and both service up production React files,
and does routing to our back end services?
You know, in this case we'd only have the express server
but we could very easily have other services
back here, as well."
The answer to that is "Yes."
We could absolutely collapse this down
to just use one single nginx server.
However, there are definite reasons
that you might want to run multiple copies of nginx.
The easiest reason for that might be
maybe two serve up our production React files over here,
maybe we were not running nginx.
Maybe it was a much more simplistic file system data store.
And so there was no nginx there and it was just like,
flat files were being served for whatever crazy reason.
So if that was the case
we would still need to have the nginx server out here
and still have it route traffic
looking for our production assets
to some specific port where users could get
our production files.
So it just happens that in our example right now
we are using nginx for both of these servers.
It could be very well possible,
that we are using different services for the two.
And because of that, I want to give you the more like,
complete, complicated example here
to get you a little bit more ready
for real world production deployments.
Where you might have one container responsible for routing
and a different container entirely responsible
for serving up your front end assets.
So yes, we could condense the two down
to just one nginx server,
but we're going to leave it as two separate servers
just to give you a little bit more complex example
that transitions to the real world a little bit more nicely.
Okay? So a lot of talking.
At the end of the day all I'm really trying to say here is
when we build our production Docker file for the React app,
we need to customize nginx
to make sure that it listens on port 3000.
And that's pretty much it.
So with that in mind, let's take a quick pause.
We're going to come back the next section,
we're going to start working on the Docker file
for our client project.
So I'll see you in just a moment.