-: In the last section, we were able to finally test
out our application inside of a web browser.
So this is awesome.
We're now ready to start thinking
about how we're going to deploy this application
off to AWS Elastic Beanstalk.
Let's first begin with a quick review
of how we deployed our single container set up.
So we were pushing our code to GitHub.
We then set up Travis CI to automatically
pull in our repository.
Travis built an image out of all of our code,
so it ran the actual Docker build command.
It then used the built image to test out our code base,
specifically by running that NPM run test command.
Travis then pushed all of our code to Elastic Beanstalk
through the use of that deployment script.
And then finally, once the code showed
up over on Elastic Beanstalk, Elastic Beanstalk
took all of our code, built the image again
and deployed it to a running web server.
So as we said, at the start
of all this multi-container stuff,
having Elastic Beanstalk build our images was probably
not a very good approach,
because we were building everything
out far more often than it had to be.
And we were also relying
upon a running web server to have to download a bunch
of dependencies and build an image for us,
which kind of kept it from doing its primary job
of serving web requests.
So this time around, we're gonna use a slightly
different deployment flow, although in general
most of these pieces are gonna look very similar.
All right, so here's what we're gonna do
for our multi container setup.
We're still going to be using a primarily
Travis CI driven deployment flow.
So all you are gonna have to do is deploy your code
to GitHub, then Travis CI will pull your code down
and immediately start to run some build process on it.
So we pushed a GitHub, Travis pulls down your repo.
We're going to have Travis then build a test image,
or in other words, it's going to build out that kind
of React test image that we made just
to test the React code inside of our project.
As soon as that React test image is made,
we're going to essentially throw away
everything inside that image.
So again, the image is only being made for testing purposes.
After the tests successfully run, and we decide to go ahead
and deploy our application, we're then going to make Travis
in charge of building our production images.
So Travis is going to run a production build script,
or essentially build a production image using Docker files
that we've placed inside of our project for each
of our different services for the client,
Nginx, server and worker.
Once Travis has built those images,
and remember, these are image files,
so they are single files.
We're then gonna have Travis push them off
to the Docker Hub service.
Let's take a quick pause right there.
At this point, we've been making use of Docker Hub
throughout this entire course.
And remember, you can get there by going to hub.docker.com.
Every time that we've come here, we've always
looked at the dashboard or explore tab up here
and looked at some official repositories.
Again, these are public repositories
that everyone has access to,
but in addition to those public repositories,
you can also have repos that belong specifically to you
and only contain your code, your own personal projects.
So Docker Hub is not only for hosting kind
of common community packages or community images,
it can also be used to host your personal projects as well.
So we're gonna have Travis build these images
and then push them up to your personal Docker Hub account.
Docker Hub is kind of like a universal
hub for Docker images.
A tremendous number of deployment services out there,
such as Amazon Elastic Beanstalk
really all Amazon services and all Google Cloud services,
are all wired up natively to automatically
pull images that are stored on Docker Hub.
So if you and I push our production images to Docker Hub,
we can then easily get Elastic Beanstalk
to download those images
and use them as a basis for deploying our application.
So in short, after pushing
up the built production images to Docker Hub,
Travis is then going to essentially push a little message
over to Amazon Elastic Beanstalk
rather than pushing over the entire project and saying,
oh, hey, it's time to like build some images.
Travis is just going to kind of tap Elastic Beanstalk
on the shoulder and say,
hey, I just deployed a new set of images up to Docker Hub.
You should probably make use of them.
And so at that point, Elastic Beanstalk
is going to download those images.
It doesn't have to build them, they've already been built.
It'll download the images and only use them
as the basis for a brand new deployment.
So the benefit to this entire setup is
that we are no longer going to be dependent
upon Elastic Beanstalk to build our images.
Everything is going to be done by Travis,
and it's only going to be done one time.
We then are gonna push these images up to Docker Hub
and once they're on Docker Hub,
we essentially can deploy anywhere you can possibly imagine.
Like I said, Amazon Web Services and Google Cloud
and many other providers are set up
outta the box to automatically download images
from Docker Hub specifically,
without a whole bunch of additional configuration.
And so we really consider Docker Hub
to be like a central repository
for everything in the Docker world.
All right, so now that we've got the idea
of what we're going to do here, let's take a quick pause,
and we'll continue in the next section
by starting to build out our Travis.yaml file.
And we'll also start to make some production versions
of our Docker files for each of our different services.
So quick break and I'll see you in just a minute.