-: In the last section,
we started putting together our container definitions
inside of the Dockerrun.aws.json file.
We're now going to continue
with two other important parameters
that are going to be added to our client container,
right here.
So the next one that we're going to put on
is a flag called essential,
and we're going to set it to false by default.
The essential flag is something that we've not seen before
in any other docker concept.
The essential flag essentially means
that this container right here is not considered to be,
as you might guess, essential.
So what would it mean
if we marked this thing as essential true?
If we marked a container as essential true,
and this container ever crashes for any reason whatsoever,
then all the other containers in this group
of containers will be closed down at the same time.
So in other words,
if we end up with some other containers inside of here,
like let's say container one,
and notice this is not valid syntax,
I just mean to say
that there are some other containers in here.
Now, if client was marked as essential,
and this thing crashed for any reason,
container one and container two
would be automatically shut down as well,
even if they are still running a-okay.
Now, in the case of our client,
if this thing crashes for any reason,
that's kind of okay,
and I would still want all the other containers,
or the other services,
in my group of containers to continue running.
The only service that I have, or we have,
inside this list of container definitions
that you and I really care about
is the NGINX routing server.
Remember, that's the server that routes
to either the client or the API,
the express API that we have.
So if that thing goes down,
it means that no one can access
any of the different services in our group of containers.
And so we're probably gonna want to mark that one
as our essential container to say,
hey, if the engine X server crashes,
well, we can't reach any of the other services
in our grouping of containers,
so we better just shut everything down.
Now, the one little bit of trivia that I wanna share
with you about essential right here
is that at least one service in your listing
of container definitions must be marked as essential.
So at least one thing inside of here has to be essential.
And like I just said,
we're going to treat the NGINX container
as our essential service.
So I'm going to flip the client back over to false
to say that, hey, if this thing crashes,
that's kind of okay, we don't really care.
Now, the last property that we're going to add on here.
Oh actually, you know what I, excuse me,
that was the last one.
Okay, so that's it for our client definition.
We're now going to skip over NGINX
and take care of the server
and the worker container definitions, as well.
Those are both going to end up being very similar
to the client definition that we just put together.
The NGINX one is going to be a little bit different,
that's why we're gonna save it for last.
So after the client definition, I'll put in a comma,
and then open up another record.
Remember, every one of these objects right here
represents a different container that we want to create.
So the next one is going to have a name,
and we'll do the server.
So I'll call this server.
The image that we're going to use is multi-server.
So we'll say your Docker ID/multi-server,
and then the host name this time around,
remember that when we put together our host name
inside of the NGINX default.com file right here,
if you open that file up
you'll recall that we actually renamed that endpoint
or that host name to be API,
because we have been calling that Express Project Server.
But we very quickly realized that,
you know, if we called everything server,
stuff was gonna get really confusing, really quickly,
and it just didn't make a lot of sense.
And so we ended up renaming this host as API instead.
So for the host name over here,
rather than making use of server,
we're going to use API,
because that is what the NGINX is going to look for
when it tries to redirect traffic upstream.
And then finally, we'll add on an essential to this one
and this will also be false because,
yeah, it's not the best thing if our server crashes
for any given reason, but if it does crash,
well, there's not a good reason to shut down
everything else as well.
Okay, so now onto the next one,
we'll move on to our worker container.
So I'll do a name of worker,
we'll do an image of your Docker ID/multi-worker.
Our host name is going to be Worker,
and essential, as you might guess, yep,
this one's also false.
So out of all the services that we have, without a doubt,
the worker crashing is the least of our concerns.
If the worker crashes,
our application can still be visited by users.
Users can still enter in indices to be calculated,
and they can still see values that have already
been calculated by the worker in the past.
So if the worker crashes,
that just means that we're not going to calculate any values
in the future, and I'm totally okay with that.
If that happens, no big deal.
We could definitely do a little bit of debugging,
figure out why the worker crash,
and then figure out some way to start it back up
in the future.
Okay, so that's it for container definitions
for the client server and worker.
Now we have to do the NGINX one last here,
so let's take another quick pause.
We'll come back in the next section
and we'll take care of that container definition.
So I'll see you in just a minute.