When somebody says “Infrastructure Automation”, what’s the first thing that crosses your mind?

If you’re anything like me a year ago it was…

Sci-fi movies.

Robots.

Big machines wheeling servers around a crowded dev pit.

Over the last year, as I’ve setup more automated infrastructure it has morphed from that big screen vision to a simple JSON file.

I know, it’s not quite as illustrious, but it’s so easy and efficient.

So what is Infrastructure Automation?

Infrastructure automation is the process of scripting environments — from installing an operating system, to installing and configuring servers on instances, to configuring how the instances and software communicate with one another, and much more. By scripting environments, you can apply the same configuration to a single node or to thousands.

Why would we want to automate infrastructure?

I personally find dabbling with and automating servers fun, what I don’t find fun is chasing down production bugs because of inconsistent environments and servers. No one wants to be logging into dozens of servers to type a command to get the latest security patch installed.

Tamagotchi – Pocket Pets

Much like anyone else who has been deploying production apps to the internet over the past 15 years, I have setup many “snowflake” and “pet” servers. You spin them up, physical or virtual, configure them, feed them, nurture them and hope they don’t die while you’re sleeping.

Then I stumbled across this article, which really made my head spin. All I could think was “what have I done with my life?”

On that day, I started to find and walk the enlightened path of infrastructure automation. Sometimes the path gets dark and you have to write your own tools, but it’s always worth it in the end.

This will be the first in a series of posts in which you’ll learn:

  1. Introduction to Automation and AWS CloudFormation
  2. Create Simple Express App
  3. Setup Ansible to configure server and deploy
  4. Putting it all together aka Winning
  5. Advanced setup with Packer.io and creating AMI as build

The main goal here is to get properly setup so we have a fully automated stack we can develop against, push updates to, and scale without ever having to SSH into the machine and feed or nurture it.

Introduction to CloudFormation

If you don’t have an AWS account already go sign up for a free trial! I am a huge fan of using CloudFormation to automate AWS infrastructure. I’ll spare you the marketing pitch as I don’t work or get paid by AWS. But, as you’ll see, breaking down an entire stack into a single or set of JSON files is a dead simple way to organize and build infrastructure.

Not a pro at building JSON? Already have your “pets” setup on AWS?

Set up a CloudFormer machine and let the AWS tool scan your account and create the template for you!

Much easier (and faster).

To demonstrate, we’re going to use a simple CloudFormation template I built.

It does the following:

It may not seem like this template does a whole lot, but I have set it up intentionally that way.

I prefer to split my templates into layers so I’ll have one template that defines all of my base level networking, then if I need to come back to this layer and make changes, I can do so without having to rebuild all of my other templates.

Let’s break this down further:

Parameters

If you look at the template, you can see we are asking for 2 parameters, an EC2 KeyPair and SSHLocation. You can easily set up a keypair in the EC2 Console and the SSHLocation should be your IP Address.

Mappings

This is just one of many cool features offered inside the CloudFormation templates. You can set up the mappings to have a centralized location to setup, and later lookup commonly used values in your templates. You’ll find plenty of documentation on CloudFormation Templates here.

Resources

Resources are the meat and potatoes of the template. They contain all the AWS resources you’ll need.

If you’ve ever setup a Virtual Private Cloud (VPC) on AWS before you’ll know there is a decent amount of configuration needed.

Don’t worry about it. This template is very simple.

Let’s break down each resource:

  • VPC – Sets up the actual VPC resource and uses the values from mapping to specify the CIDR block.
  • PublicSubnet – Creates a subnet inside the VPC we created using the Public CIDR block from our mapping.
  • InternetGateway – Sets up an IG in the AWS Account and tags it with a StackName. That’s for rour Public network.
  • GateWayToInternet – Attaches the InternetGateway to the VPC you created.
  • PublicRouteTable – Creates and tags a route table in your VPC.
  • PublicSubnetRouteTableAssociation – Associates the Public subnet with the route table you just created.
  • PublicNetworkAcl – Creates a network access control list inside the VPC so rules can be added to it.
  • InboundHttpPublicNetworkAclEntry – Adds an inbound port 80 (HTTP) rule from any address to your public subnet.
  • InboundHTTPSPublicNetworkAclEntry – Adds an inbound port 443 (HTTPS) rule from any address to your public subnet.
  • InboundSSHPublicNetworkAclEntry – Adds an inbound port 22 (SSH) rule from the IP Address you specified in the parameters.
  • InboudEphemeralPublicNetworkAclEntry – Add inbound Ephemeral ports see: Recommended Network ACL Rules for Your VPC.
  • OutboundPublicNetworkAclEntry – Adds an outbound rule to allow traffic out.
  • PublicSubnetNetworkAclAssociation – Associates the Public subnet with your freshly created Network ACL.
  • EC2SecurityGroup – Creates a Security group you’ll use later when you setup EC2 instances, and give it an inbound rule for SSH, port 22, from the IP specified in parameters.

 

Outputs

When you create resources in a CloudFormation template sometimes there are properties of those resources that may be needed elsewhere. Outputs are a great way for us to grab those values.

If you’re using the console they will show up on screen, but they will also show up through API calls to CloudFormation.

In this template you are outputting the VPC ID and Public Subnet ID.

In the next post, we’ll add an EC2 instance to the VPC and get a simple web app ready to be deployed.

Sign up for our newsletter and get part 2 delivered straight to your inbox.