-: In the last section,
we took a look at some of the documentation
that was going to be used to write
our Docker run.aws.json file.
So without further ado, let's get to it.
I'm gonna flip over to my code editor
and then side of my root project directory,
I'll make a new file called dockerrun.aws.json.
Now I'm gonna blow up the size of my editor here
just so you can see the name very easily.
Notice how it is the word docker and then the word run.
So there's two r's in there.
Now the file type we're going to be working with here
is a Json file.
So we have to enter Json file throughout this entire thing.
So to get started, we're gonna put down one wrapping object
with the set of curly braces like so.
And then we're going to tell Elastic Beanstalk
what syntax we are using inside this file.
So we're gonna place AWS eb Docker run version is two.
So as you might imagine
there was a version one of this file
or the syntax used within this file.
We're using version two,
which is going to have this file be interpreted
in a very specific way.
We'll then put a comma on the very end
and then we'll start to list out
all the different container definitions.
Now, container definitions is very purposefully done
as a plural.
So definitions, we have many definitions.
So we're gonna put an array in here.
And then we're going to list out
a number of different container definitions.
For every entry that you and I
put into this array right here,
we're going to have one distinctly separate container
created inside of our application.
So at the end of the day,
you and I have four custom images
that we want to be hosted by Elastic Beanstalk.
So we're going to add four separate entries
inside of this container definitions Array.
For the first one we put together,
let's write out the configuration block
for our client to get started.
So I'm gonna put a new object inside of here
with a set of curly braces
and then I will provide a name for this container.
The name does not have to be identical
to the project name or the folder or anything like that.
This is the name of your container
that's going to eventually show up on the dashboard
so that you can identify it.
Now, just to stay consistent in all things
we are going to use the same name of our sub-project.
So we're gonna give it a name of client.
Next up we're going to list out the image to use
for this container.
So again, remember every record
inside of container definitions,
so like this record right here
corresponds to an actual container
that is going to be created along with our deployment.
So right here we're going to specify the exact image
that will be used to represent this container.
So the image we're going to use
is going to be the multi-client image
that we just pushed to Docker Hub.
So multi client, this one right here.
Now, to specify that image,
this is what I was talking about nonstop
in the last couple of sections when I was saying
oh yeah Docker Hub is great
because it's like the central repo
for all these different deployment services.
So in order to specify that image on Docker Hub,
all you have to do is write out your Docker id
and then the name of that image.
So for me, it's multi-client.
Chances are that for you it's the same.
So when AWS sees this string right here,
it's gonna say oh, they must be talking about Docker Hub.
And so they're going to go off to Docker Hub,
they're gonna look up your Docker id,
and then see if you have a repo in there
or a image with the name of multi-client.
And if you do, it'll then pull down that image
and use it as the basis for this container right here.
So like I said, really easy to use Docker Hub
with a lot of these different hosting services.
Now the next thing we're going to do is set up a host name.
Now the host name is a little bit more complicated.
Let's fill out the entry here
and I'll tell you a little bit more about what it's for.
So we're gonna say that it's going to be a client.
Okay, so quick reminder here.
Remember that back inside of our Docker Compose file,
I'm gonna open up it up GitHub here really quickly.
Inside this file, we had the list of services
and every service had a different name.
So for example, our client was called Client.
By setting up this name right here,
it essentially created a new host name
that could be accessed by any other container
that was created by Docker Compose.
And so the end result of that was, for example,
inside of our Nginx folder,
if you look at that default.com file,
remember that inside of here
we were able to reference another container
simply by writing out like oh yeah, http client.
So client right here you know,
you would normally write something like google.com,
but we were able to just write out client
and that was resolved as that other container
inside of our grouping of containers.
And so with the Docker Compose file,
we kind of set up that host name
by just defining the name of the service right here.
But in the world of the Dockerrunaws.json file
we have to specify a very distinct host name.
And so when we say host name right here,
we're essentially giving every other container
in this group of containers
the ability to access this container right here
by trying to make a request with a host name of client.
So if you really wanted to mess things up,
you could do something like google.com.
And then if you ever tried to make a request
to google.com from one of your containers,
rather than going to the real google.com
it would go to this container right here.
And obviously that's not what we want.
So we're going to give it a host name of client instead.
Okay, let's take a quick pause right here
and we'll continue working on the Docker run file
in just a moment.