-: In the last section,
we pushed up all of our code to GitHub,
Travis pulled it down and started to build a project.
Now I've got my build right here,
and it looks like it was successfully built
and deployed off to Elastic Beanstalk.
So if you have any error at the Travis CI step it,
it very likely means that you might have made a typo
somewhere along the way.
As a reminder, you can always check out
the GitHub repository of all of my code,
which is linked in one of the very first sections
in this entire course.
And so that's a great place to get started
if you wanna do a little bit of troubleshooting.
Now, assuming that the deploy for you went successfully,
So all the way down here I can see deploying application,
no problems with that.
We can then flip over
to our Elastic Beanstalk dashboard over on AWS.
So once you go over here, you might see an error
or a warning, which again is totally fine,
We very much expected this to happen.
I just wanted you to see an example error
with a deployment like this.
So if I scroll down a little bit,
I can see recent events,
and underneath recent events,
you might notice an error message right here
and it says invalid setting for container client.
So that is a invalid setting that was detected
inside of our dockerrun.aws.json file right here.
In particular, it's complaining to say
that we did not specify in option called memory
and we must specify this option
if we're going to use the Docker run file.
So what's going on here?
Essentially we correctly put together our Docker run file,
but we missed one required option
for everyone of our container definitions,
and that is a memory option.
Essentially, when Elastic Beanstalk decides to create
each of these containers,
it's going to allocate some amount of RAM to each of them.
So it wants us to tell it exactly how much RAM
or how much memory should be allocated to each container.
And we do so by adding in a memory option
to each of these different objects inside of here.
So underneath the essential flag on client,
I'm gonna put a comma, and I'll specify memory,
and then we're going to specify the amount of memory
in megabytes.
Now for this step, unfortunately,
it's kind of challenging for me to give you
very strong guidance on exactly how much memory
should be allocated to each of these services
or more precisely, how much memory you should use
as a rule of thumb.
The best guidance I can possibly give you
is to do a little bit of research to look up these services
that you're trying to host.
And traditionally, there tends to be many
Stack Overflow posts that give a little bit of guidance
on the appropriate amount of memory to allocate.
So for our application,
we're just going to do a straight across the board,
128 megabytes for every one of our services.
Again, I'm not gonna necessarily say this is
good practice or bad practice,
or maybe we're putting too much memory into one service
or too little into another,
I really recommend that when you start
working on your own projects,
you do a little bit of research on this front.
So I'm gonna take this memory, 128,
I'm gonna copy it and then I'll go down to the server.
At the end of essential, I'll put a comma,
and I'll paste in memory 128.
I'll go to worker, I'll find essential false,
I'll put a comma in and do memory 128.
And then finally I'll do the same thing down on Nginx.
Here's links, I'll put a comma at the very end,
and I'll do memory 128 again.
Okay, so that's it, I'm gonna save this file,
and then we will again flip back over to our terminal.
We'll do a git status.
So we made a change and we now want to deploy this change.
So we'll do a git add, a commit,
I'll say something like added memory allocation,
and we'll do a git push origin master again.
And now just like before,
this is going to send all of our code to GitHub,
Travis CI is gonna pull it down, build our images,
push them off to Docker Hub,
and then attempt to send that Docker run JSON file
back over to Elastic Beanstalk.
So another quick break and I'll see you in just a minute.
Once again, if anything goes wrong, totally fine,
this is all a part of the debugging process.
So if anything goes wrong, continue in the next section,
and we'll take a look at any possible error message.
So quick break, and I'll see you in just a minute.