-: In the last section,
we spoke about the new deployment practice
that we're going to use for this multi-container deployment.
Again, the big change this time around
is that we're going to use Travis CI to build our images
and then push them to Docker Hub.
So now Elastic Beanstalk will not
have to do any build process for us.
And the first thing we need to do as part of this process
is to make sure that we have production versions
of all of our different Dockerfiles.
As a reminder,
all of our different services
currently have Dockerfile.dev files.
These are Dockerfiles specifically made
to get our projects set up in a development environment,
and in some cases,
we need to customize them to get them
a little bit more ready for a production-style deployment.
So we're gonna first begin with our worker process.
Inside of my worker directory,
I'll make a new Dockerfile file.
Boy, that's a tongue twister.
Inside of here, we're gonna put in a series of instructions
to get a production version
of this worker application put together.
Now, here's kind of the interesting thing.
I want you to open up the Dockerfile.dev version right now.
Inside of here,
you'll see this very familiar configuration
that we've used many times around.
So I'll be honest with you
we don't actually have to make a darn change
in here for the production version of this Dockerfile.
All the production version has to do
is get our NPM modules installed
and then run some setup or startup command.
And that's essentially exactly what
our existing Dockerfile does.
So rather than trying to write
an entire new Dockerfile from scratch,
I'm gonna take everything inside of the dev file,
I'm gonna copy it,
and then I'll paste it over
into the new production Dockerfile right here.
So we're going to still do all the same steps.
We're gonna use Node Alpine as a base image,
set up a working directory,
copy over the package.json file,
install some dependencies,
copy over all of our other files
inside of our project directory,
and then run some startup command.
So the only thing that's going to be different
inside of our production Dockerfile
is in fact the startup command.
Rather than starting up with npm run dev,
we're going to make a npm run start command instead.
So traditionally, npm run dev is used,
as you might guess, for the development environment.
Usually when we move to a production environment,
we change this to start because you might have
a slightly different command.
Now, as a reminder,
these npm run scripts
that we're putting together right here,
they are not just created for us by magic.
These are actual scripts that you and I define
inside of our package.json file.
So I'm gonna open up the package.json file
and just verify that we do in fact have a start script,
and in fact we do,
and this definitely is appropriate,
or good enough, really,
for starting up our application
in a production environment.
So I think that's pretty much it for our Dockerfile
for the worker.
We just used everything the same as the development version.
We just did a little bit of a customization
for the npm run start command.
Let's now go through the same process
for the server service, as well.
Inside my server directory,
I'll make a new file called Dockerfile.
And again, I'm gonna open up my Dockerfile.dev,
I'll copy everything inside of here,
and then I'll paste it inside of the new Dockerfile.
Again, we don't really have to do any customization here.
Sometimes in some projects,
like, for example,
as we saw with the Create React App example,
sometimes we do want a difference
between our production Dockerfile
and the development one,
but sometimes it's just not necessary.
There's really nothing different that we need to do.
Nonetheless, I do still recommend
that you have different Dockerfiles
because you might want to make a small change or two.
And I guess in this case,
we are changing the default startup command,
so it is a little bit different.
All right, so again,
I'm going to find my initial command right here.
Rather than running npm run dev,
which is usually used for development purposes,
I'll do npm run start instead.
Now, if I open up my package.json file,
I can just verify that I do in fact have a start script.
Yep, I do.
And so I'll save the production Dockerfile.
And again, I think we're all good to go.
Now we'll do just one more inside this section.
We'll do the Nginx, as well.
Again, it's the same story.
We're not making any changes
with the production Dockerfile.
So I'll make the Dockerfile,
I'll open up the development version,
and we're going to use the exact same thing
this time around.
So we're gonna copy over the default.conf file
'cause it has all of our routing rules,
and that's going to be overriding
the default default.conf file that exists
inside the Nginx image.
Again, no changes.
Now, in this case,
I will say this is probably the one location
where we might want to make a little change
to the Dockerfile.
I'm not going to because it's not strictly necessary.
I'm just gonna throw this out as a possible example.
You recall that just one or two sections ago
inside of the default.conf file,
we added on one of those routing rules right here.
This was to allow web sockets to connect
to that specific endpoint
on our React JS development server.
And so this right here was really a development-specific
piece of configuration.
And so if we were really doing
a super, super production version,
you know, again, for this course,
I'm trying to make things
as production realistic as possible,
but this is one of the locations where it's just
really not a big deal at all.
If we really wanted to have a separate production version,
I might make a separate default.conf file
that would not have this web socket block inside of it.
So if you wanted to, you could absolutely do that.
But for right now,
having a production Dockerfile
that just uses the same default.conf is good enough.
It is definitely good enough.
There's not a huge reason to make any changes.
All right, so those are our production Dockerfiles
for the worker server and Nginx services.
Let's take a quick pause
and then we'll tackle the client in the next section.