-: In the last section
we spoke about reasons that you might decide to use
an outside elastic cache or RDS instance
for data needs in your application.
In this section, we're going to talk about
how we set up these outside services
and connect them to Elastic Beanstalk.
So unfortunately, you have to do a little bit
of behind the scenes work here.
Fortunately, the amount of work we have to do is
very, very small, like it's just going to be
a handful of clicks, but the very few clicks
or the very few actions that we're going to take
require some kind of specialized knowledge.
And so before we go and create the RDS instance
or the EC instance I want to very quickly give you
an overview of exactly what we're going to do.
All right, so.
You and I are going to have an Elastic Beanstalk instance,
and inside of it are going to be
our four different containers.
And we're going to eventually want to
connect those containers, or at least some number of them
to RDS.
The PostgreSQL instance we create and elastic cache
or the Reddest instance that we create.
Now, unfortunately, in the world of AWS, by default,
these services do not get to talk to each other.
In other words, once we create these other services
we cannot just automatically say, "Oh hey, containers.
Go out and find this RDS instance for me and connect to it
and make use of PostgreSQL
or whatever you might want to do."
Instead, we have to form up
a very distinct link between the two,
and that's the kind of series of clicks
we have to go through.
Now when I use the word "link",
I am not talking about the same kind of link
that we put together inside of the Docker run file
just a little bit ago.
So the kind of connection between Elastic Beanstalk
and RDS and EC that we're going to form up here
has absolutely nothing to do with Docker.
Docker is not involved one bit whatsoever.
This is a completely unrelated aspect of
wiring up these different services together,
completely unconnected from Docker.
All right, so here's the background.
Here's what you need to know.
Right now, when we created our Elastic Beanstalk instance
over here called Multidocker,
it was created in a very specific region of the world.
So Amazon has a variety of different regions
or essentially data centers
where you can create these different services.
Right now I'm using the Northern California region.
You can find what region you're using
on the top right hand side.
And you can actually also
just take a quick glance at the URL to get the actual
kind of like, region code of where you are.
So for me, I'm at US dash West dash one.
That's the kind technical designation of
US West or Northern California.
Now, in each of these different regions, by default,
you get something created that is called
a virtual private cloud or VPC for short.
A VPC essentially is kind of its own private little network
so that any instance or any different service
that you create is isolated to just your account
and it doesn't get automatically shared with, like,
someone else's AWS account.
In other words, when you create
an Elastic Beanstalk instance,
only your account is going to have access to that instance
and not like Bill, Joe, or Ted down the street.
They're not going to magically see this
Elastic Beanstalk instance appear in their account.
Now, this VPC right here is also used to implement
a lot of different security rules
and a lot of different ways of
connecting together these different instances,
or these different services that you create on AWS.
Now, before we move on,
just one thing to make really clear here,
in each of the different regions or
data centers around the world
you automatically get one default VPC created.
And so when we created our Elastic Beanstalk instance,
it was automatically assigned to that default VPC.
Unless you are a total Elastic, oh excuse me,
a total AWS wiz and you already decided to assign it to
some other VPC for whatever reason.
You get one of these default VPCs
for every region around the world.
Let's very quickly flip over to the AWS console
and we'll take a look at the virtual
VPC that was created for us.
All right, so on services, I'll do a search for VPC
and that will bring up the VPC dashboard.
And then once over here, you can click on your VPCs
on the left hand side, and it will show the default VPC.
If you see multiple VPCs right here,
it's probably because at some other point in time
you went through the process of creating another VPC.
I only have one right here, and this is my default VPC.
I can tell by scrolling over to the right hand side
and you'll see this default VPC column says "Yes" for me.
Now, if I look at my ID right here
you'll notice it's like 0 3 3 0, whatever.
If I now flip over to some other region around the world,
like, let's say Paris for example,
I can flip over here
and after a very long load time
because this is on the other side of the world for me.
So here are all the VPCs I have in the Paris region.
You'll notice that the idea of this VPC
is distinctly different.
So I copy the idea of the other one.
In Northern California, I had 0 3 3 0.
Over here I have 0 4 3 F.
So in other words, in every region
you get a different default VPC.
All right, so with that knowledge in mind
we now are going to kind of take that idea of a VPC
and figure out how we can get our
different services to connect to each other.
So to get these different services to connect to each other
we have to create something called a security group.
A security group is a really fancy term for firewall rule.
It's a rule describing what different services
or what different sources of internet traffic can connect
to different services running inside of your VPC.
When you created the Elastic Beanstalk instance
just a couple of seconds ago,
or a couple sections ago, excuse me,
a security group was automatically created
that allows any incoming traffic from anywhere in the world
to connect to Port 80 on your Elastic Beanstalk instance.
Each of the different security groups that you create
are going to apply to some set number
of different services that exist inside of your VPC.
So the security group that was created
for Elastic Beanstalk is already kind of attached,
or kind of scoped to your Elastic Beanstalk instance
and that's what allows someone else in the world
to come into your virtual private cloud
and connect specifically to your Elastic Beanstalk instance.
Now, to look up this security group
we'll go back over to the VPC dashboard,
make sure that you're in the same region
as where you just created the Elastic Beanstalk instance at.
And then on the left hand column
you can scroll down to security groups right here
and you'll see that there is a security group
at the name of Multidocker dash N.
So again, this was a security group that was created for
our Elastic Beanstalk environment.
If you click on this thing,
you can then see a little summary down at the bottom.
And most interestingly, you can click on "Inbound Rules."
So these are the kind of security rules, or firewall rules,
that are going to be applied
to your Elastic Beanstalk instance.
And so this inbound rule says
that we're going to allow all http traffic
to come in on port 80, and that traffic can come from
absolutely any source in the world.
Security groups can also optionally have
outbound rules as well.
The current default outbound rule essentially says,
"Yeah we're just going to allow all traffic, whatsoever,
any traffic you can possibly imagine
from that Elastic Beanstalk instance,
to reach any possible destination across the globe."
All right, now on this diagram right here
I also reflected like an additional security group.
This is just a random one.
I just mean to say, you can create your own security groups
that customize the way in which
your different instances are allowed to receive
or respond to traffic.
So now that we understand what a VPC is
and now that we understand what a security group is
how are we going to form a connection
between Elastic Beanstalk and RDS and EC?
Well, here's what we're going to do.
We're going to create a new security group,
and the security group is going to say,
essentially as a rule,
"Let any traffic access this instance,
if it belongs to the security group."
So we're going to create the security group,
and then we're going to attach it
to all three of these different services.
So they're all going to belong
to this one common security group.
And the security group essentially says,
"If another AWS instance belongs to this thing right here,
then let the traffic flow through and let them,
these different services, talk to each other."
So that's how we're going to get Elastic Beanstalk
to talk to RDS and to EC, as well.
Again, the big takeaway here
is that by default when you create these services,
they don't get to talk to each other,
so we have to create the security group that specifically
says, "Yeah, these different things can communicate
with each other."
All right, so that's pretty much it.
I just wanted to give you a quick overview
on the entire process before we go off
and create the RDS and EC instances.
Because once you create them
it then gets a little bit confusing about, "Hey what do we,
you know, what are we doing here?
Why are we clicking around all over the place?"
So let's take a quick pause right here.
We're going to come back the next section.
We're going to start to create
the RDS instance and the EC instance,
and then create a new security group
and apply that security group to
all three of these different services inside of our VPC.
So quick break, and I'll see you in just a minute.