Instructor: We now have a rock solid
Travis CI deployment process or maybe pre-deployment,
I guess would be the best way of saying it.
It's our build pipeline of sorts.
Anytime that we make a change to our GitHub repository,
Travis is going to automatically pull down a repo
and build out a new set of production images
and then push them off to Docker Hub.
So now we need to start thinking about
how we're going to use these images
and actually deploy them in production.
So for that,
we're going to again be using Amazon Elastic Beanstalk.
Now as a quick reminder,
back when we had a single Docker container
in our last project, something was kind of going on
automatically behind the scenes
anytime that we pushed our code over to Elastic Beanstalk.
You might have noticed that you and I
did not have to set up any custom configuration
or anything to tell Elastic Elastic Beanstalk that,
hey, you need to take this Docker file
and build it and run the image that comes out of that.
That was an automated process.
We didn't have to add any configuration.
We essentially just took our project directory
with a Docker file in the root directory
drew it over to Elastic Beanstalk.
And Elastic Beanstalk said, well, you know what?
They got a Docker file,
I guess I might as well build it
and try running the image that comes out of that.
So now, this time around,
we're in a very different situation.
We don't have a single Docker file anymore.
We have a couple of different folders
and each of them has a separate Docker file.
And so if we just toss this entire project directory
off to Elastic Beanstalk, it would probably say,
hey, look, I know you got these Docker files.
I don't know which one you want me to run.
So anytime that we want to run multiple separate containers
on Elastic Beanstalk at the same time,
we have to go through an extra little step of configuration
to tell Elastic Beanstalk exactly how to treat our project.
So here's what we're gonna do.
Inside of our project directory,
we're going to create a file with a very special name.
This file is called Dockerrun.aws.json.
This is going to be a JSON file.
So it's gonna contain some JSON data
that's going to tell Elastic Beanstalk exactly where to pull
all of our images from,
what resources to allocate to each one,
how to set up some port mappings,
and some associated information.
In fact, when you think about the purpose
of this Docker run AWS JSON file,
it's going to very quickly remind you
of exactly how our Dockercompose.yml file is set up.
Remember, Docker Compose is primarily meant for use
in development environments, and you can kind of think of it
as a single file that encodes a lot of directions
that would normally be passed directly to Docker run.
Inside of our current Docker Composed file,
we list out a bunch of different services,
and then with each service,
we tell Docker how to build the image,
what ports to open, environment variables,
and a bunch of stuff like that.
So we're gonna do a very similar thing
with this Docker run AWS JSON file.
The only difference is that rather than referring
to these as services,
like they're called over on Docker Compose,
the Docker run file refers to them as container definitions.
The biggest difference that you're going to see
between these two files is that in the Docker Compose file,
it's going to contain some information
about how to build an image using a Docker file, right?
That's what we were doing inside of Docker Compose.
If you go open up the Docker Compose file right now,
you'll see that in each service
we have the different build directions.
But in the case of the AWS JSON file,
we already have a set of images.
So rather than saying, "Oh, here's how to build a client
or here's how to build NGINX," we're just gonna say,
"Go and pull the image from Docker Hub
with the name of your Docker ID/multi-client."
We just say, "Go pull this image.
Elastic Beanstalk is going to automatically pull down
that image and use it for each of these different
container definitions that we're going to add."
So again, I really want you to think
of these two files as being rather similar.
The Docker run file is really just customized
to work directly with AWS
and the big difference between the two
is that the Docker Compose file has directions
on how to build an image.
But with the Docker run file,
we have already built the image, no build required.
We're just going to specify the image to use.
So let's take a quick pause right here.
In the next section, we're gonna start putting together
our container definition file, the Dockerrun.AWS.json file.
So I'll see you in just a minute.