- [Instructor] Here we'll review infrastructure as code
with AWS CloudFormation.
One of the most powerful things,
and I think one of the things that
really sets Amazon Web Services apart from other providers,
is the ability to think of our infrastructure as code
to configure our infrastructure
by writing not only scripts,
but writing things like CloudFormation templates.
So, CloudFormation is a solution to a particular problem,
and that is that our architectures
can often be very complex.
There are often a lot of moving parts
when you really zoom out and look,
and you'll see that we have virtual private clouds,
we have subnets and route tables
and network access control lists,
security groups, EC2 instances of various types
and various sizes doing various different jobs,
we have databases and DynamoDB tables.
The list goes on.
There are so many resources that need to be created
and managed, and doing these manually are challenging
because if we architect something,
if we draw it out in a diagram,
we have to know that it's reliable.
We have to know that it was created
exactly the way that we designed it.
And then, of course, comes the issue of reproducibility.
If we want to take that environment,
that particular architecture
and create it in a development, a testing,
a staging, a production environment,
we're looking at doing that manually not once
but two, three, four times or more.
What if we wanted to take that architecture
and roll it out to multiple regions
so that we can serve a broader audience.
Again, it's one thing to do it once,
it's quite another to do it two, three, four or more times.
And then, of course, comes the issue of documentation.
By having all of this handled by a template, by a script,
then the template or script becomes
somewhat self-documenting.
Now, yes, we can do these things with just scripts.
We could do them with Bash shell scripts,
leveraging the Amazon command line tools.
We could to them with a programming language
such as Python, leveraging the boto libraries.
But the challenges with scripts
could be dependencies and parallelization.
We need to know that certain resources have to come first.
Before you launch an EC2 instance into a VPC,
you first have to create a subnet;
and before you create a subnet,
you have to create the VPC.
So your scripts need to know the appropriate order
in which things need to be created.
So the solution to all of that,
the solution to the challenges of a manual process,
the challenges of human error factors,
the solution to the challenges with scripts
is to automate with AWS CloudFormation.
CloudFormation gives us
the ability to write what we call templates,
which are just JSON-formatted text files
that we can and should put into source control.
We then upload those to the CloudFormation Engine,
which is responsible for processing that template
and creating and/or updating or deleting resources.
The CloudFormation Engine inherently knows
the order in which things should be built.
It already knows that it should build the VPC first
before it builds the subnet,
before it launches the EC2 instance.
It just knows a lot of those things.
We don't have to worry about that order.
But in cases where it get ambiguous,
such as launching a database in an EC2 instance,
we do have control over the order.
Once we upload a template to the CloudFormation Engine,
and the CloudFormation Engine has created these resources,
we can manage the collection of those resources
under what we call the stack;
that is, the larger umbrella of all of those resources.
So let's say that we have
a very complex architecture with VPCs, subnets,
EC2 instances, load balancers, and so on and so forth.
If we reach a point where we don't
need that infrastructure anymore,
then we can just go in and delete the stack,
and by deleting the stack,
we then delete all of those resources.
That's a whole lot easier
than going in and manually picking through your environment
and worrying whether or not
you're deleting the right thing versus the wrong thing.
So, with CloudFormation,
we have what we would consider declarative programming.
Imperative programming is concerned
with the exact order of things.
You're saying do this step, then do that and do that,
you're actually telling it what to do
and how to do it.
With declarative programming,
we're just declaring the resources that we want,
the ways in which we want those resources connected,
and we allow the CloudFormation Engine
to worry about how those get built
and in what order those get built.
And again, these templates,
because they are just JSON text files,
they should be stored in source control,
and I can speak from personal experience
that having your CloudFormation templates
under source control not only makes working with a team
a whole lot easier,
it makes rolling back to a previous version
a whole lot easier,
it makes it a predictable place
to know where you can find that particular template.
With CloudFormation, we can nest our templates.
We can put one template inside of another one,
and we can write that template once
and then deploy it to numerous applications.
Perhaps we have an architecture that we want to mirror
across development, testing, staging
and production environments.
And so we can write that template once
and deploy it many times.
Now, another nice thing about CloudFormation
is that it does not impose any particular model
for development and operations.
It just gives us the absolute flexibility
to create our architectures the way we see fit.
Within a template, we will declare certain things
such as parameters
or what we could also describe as variables.
We'll describe the resources that we want to create,
such as VPCs and EC2 and RDS instances.
We can also create what we call mappings.
These are another form of variable
that help us map one value to another value.
And then, of course, we can control
the output of that template as well.
So, perhaps we want to create a load balancer
and then, from that, once that's created,
we want to get some of the attributes
of that load balancer back as output.
So let's take a look at an example template.
Again, this JSON, as you can see
by the curly braces and the key value pairs
that we see here.
One parameter might be the CIDR range,
so, at the time we launched this particular template,
any parameters that we have listed here,
this right here, Cidr would be name of that parameter.
When we upload this into the AWS console,
we will be presented with a text field
with this particular text, Cidr,
off to the left as the label,
and it will give us a place to type in a value,
and that particular text box will be prepopulated
with this value here, with the default.
And so, we would use this parameter,
you'll notice here, we're going to use this parameter later
as a reference in our resources.
Our resources, again, are the very things
that we want CloudFormation to create for us.
In this example, we're asking CloudFormation
to create a VPC, and within its properties,
we're going to say that the Cidr block of that VPC
should be pulled or referenced
to the Cidr parameter that specified up here.
So that gives us the ability to,
instead of hard-coding our IP range here,
it allows that particular template to be flexible
so that we can launch the same exact infrastructure,
perhaps into multiple CIDR ranges.
Perhaps we have a load-balanced application
that needs to serve different applications,
so each one gets their own CIDR range.
So this is just a little bit of an example
of the possibilities with CloudFormation.
These templates can get incredibly complex,
but it makes creating complex infrastructures
so much easier by allowing
one service to handle all of the details
of the creation of these resources for you.
So that is AWS CloudFormation.