-: In this section we're gonna take care
of our very last container definition,
the definition for NGINX container.
And remember, this is the container
that's going to do some routing of incoming requests
to either the client or the backend API server.
So, inside my Dockerrun.aws.json file,
I'll add a comma, put in our last configuration object.
So, we're gonna give this a name of NGINX
or image will make use
of your Docker ID/multi-NGINX, like so.
Now this time around, we're not going to add in a host name
because no other service in everything that we have here
needs to directly access NGINX.
The host name is actually an optional field.
And because nothing needs to kind of reach out
to NGINX and get a handle on it,
we are not required to add in a hostname.
Now, you definitely can if you want to.
So, if you want to be 100% complete,
we could add in a hostname of NGINX
or whatever you might wanna do
but it's not strictly required in this case.
You know, now that I think about it,
the worker hostname here is actually not required as well
because nothing is actually reaching out
to the worker as well.
So, you could probably get away with deleting that
if you wanna be a little bit adventurous,
but I'm gonna leave it in.
Okay, so now we're gonna add in our essential flag
to the NGINX definition,
and we're gonna add in two additional flags
on top of that as well.
So, we'll say essential is true.
So, like, I said previously,
at least one container must be marked as essential.
If this container crashes for any reason,
everything else, all these other containers
will be automatically shutdown at the same time.
And that definitely makes a lot of sense
with our current architecture,
'cause like we said just a moment ago
if the NGINX server crashes, well that's pretty much it.
Users cannot access the API, they can't access the client,
and the worker can technically still run
but essentially this group of containers is now kinda dead,
and we should shut everything down
and try to fix it up at some point in the future.
So, that's why we are going to mark NGINX as essential true.
Okay, now we're gonna put in two other flags,
so we did not add into any of the previous ones.
Very quickly I wanna open up the docker-compose.eml file.
You'll recall that to expose traffic
to our group of containers,
we had opened up a port for the NGINX service right here.
And so, we had said that if you ever try to visit
our group of containers at localhost 3050,
that would map up to port 80 inside the container,
because NGINX by default is going to listen on port 80.
And so we need to do that exact same port mapping process
inside of our NGINX server configuration right here as well.
So, we're going to do a port mapping
by saying, port mappings.
This is going to be an array
because we could technically have
several different port mappings.
I'm gonna put in a single record inside of here
that will have a host port of 80
and a container port of 80 as well.
So, this means open up a port on the host or on the machine
that is hosting all of our containers,
and map that to port 80 inside of the container
which again is the default port
that NGINX listens to inside the container.
So, as you can see, setting up a port mapping
is a little bit more typing than it was
back inside of the Docker Compose file.
Back inside a Docker Compose, we got away with just saying,
"Ports is, oh, yeah, 30, 50, colon 80."
And the docker run file, a lot more syntax goes into it
but at the end of the day, it does the exact same thing.
It maps the port inside the container
to a port on the host
where the machine that is running all these containers.
Now, one last flag that we're going to add on
to the NGINX configuration.
So, after the closing square bracket for the port mappings,
I'll make sure I get a comma in there,
and then I'm going to add on links.
We'll talk about what links is in just a second
but first let's fill out the definition for it.
This is going to be an array
and it's going to have a string
that refers to our server and our client.
So, here's the links array.
We'll say client and server like so
in two separate strings separated by a comma.
So, let's talk about what this is doing.
As a quick reminder back inside of our Docker Compose file,
we were very easily able to kind of communicate
between different containers
by making use of the different hostnames.
So, for example, when the API had to connect to Redis,
we simply said,
"Oh, yeah, connect to the hostname of simply Redis."
Anytime that the API made a request
out to a hostname of Redis, it automatically got routed
over to this other running service
or this other running container.
When you start deploying containers
over to Amazon Elastic Beanstalk, however,
or as we've said behind the scenes, technically ECS,
we have to do a little bit more explicit mapping
or kind of more explicitly form up links or connections
between these different containers.
So, in the world of Docker Compose,
everything was easy as pie.
We just said, "Oh, yeah, try to access
"this other running service over here,"
or "Try to access this other running service over here,"
and Docker Compose kind of took care of everything for us
or all that networking for us.
So, in the world of ECS,
you and I have to form a little bit more distinct links
between each of these running containers.
So, in our case, we know that
NGINX needs to eventually send some traffic
or redirect a request from the NGINX server
to either the client or the API.
So, in our case, we want to make sure that NGINX knows
that these other two containers exist,
and we're going to do so by forming up a link between them.
Now, notice that links are kind of unidirectional.
In other words, NGINX right here
only has to kind of point over to client,
but we don't have to form
a opposite direction connection, like so,
it's just unidirectional.
We just say, "Oh, yeah, form a connection
"from NGINX over to the client."
And so, in our case right here, we're saying,
"Yep, form a link from NGINX over to the client container
"and the server container."
And one thing I wanna mention here is that
the name to links that we're providing
maps up to the name property
of the other container definition.
So, for example, this gets really important
with the server definition right here
because we used a name of server,
but we used a hostname of API.
So, for hostname we did not...
Oh, excuse me.
For the link definition, we did not say API right here
instead we just provided the name to that other container,
that's how we form out the link.
All right, so that's pretty much it
for our container definition file.
Now the last thing that I kind of recommend you do
just because this is a JSON file,
and it's really easy to make typos in here
without realizing it.
One thing that you might do is open up a new tab
and do a search for like JSON Validator
or something like that,
and then find any random service in here.
And then take all the JSON that we just put together,
copy it and throw it into the validator.
And then somewhere on here...
Oh, there we go, Validate JSON.
And that's gonna say, "Okay, you have valid JSON."
So, if you made any typo, this will very quickly tell you
and give you a little bit of feedback
before you try deploying the application
because Elastic Beanstalk is gonna be a little bit brutal
when it comes to validating the JSON here.
It's gonna be a lot more challenging to figure out exactly
where the typo was.
So, again, I do recommend that you do
just a quick validation to make sure
that you don't have any missed commas,
or missed curly braces,
or didn't use single quotes instead of double quotes
or whatever it might be.
All right, so that's pretty much it
for our Dockerrun.aws.json file.
So let's take a quick pause right here.
We're gonna come back to the next section
and start setting up our environment
on Elastic Beanstalk in the next section.