Getting Started with IaC and AWS CDK
Infrastructure as code (IaC) is the standard practice of defining various infrastructure components using code. You must have heard about a few of these software tools, such as Chef, Puppet, Terraform, or the old-school Bash programming, to set up servers in a predictable way.
The need for IaC was born out of the toolset for spinning up servers circa 2006 lacking the predictability, speed, and agility of the code used in programs that were deployed onto servers. Pre IaC, the normal workflow of deploying something on AWS would be this:
- Spinning up Elastic Compute Cloud (EC2) servers manually via the dashboard
- SSHing into the machines
- Copying some Bash configuration files using Secure Copy Protocol (SCP)
- Running them in a certain sequence to deploy an application
- Configuring database connections
This is one of the better scenarios of how things were done back then.
Needless to say, this method was not scalable, repeatable, or reliable enough to deal with the ever-increasing complexity of web applications on the cloud. Around the same time, tools such as Chef, Puppet, and a few others showed up, which helped immensely with server configuration.
A couple of years later, tools such as Terraform popped up, which at the time were quite revolutionary in the way that they defined the desired state of the deployment on a given cloud service provider (CSP) such as Amazon Web Services (AWS) in a declarative fashion. This configuration would then be fed into the Terraform toolset, which would then decide which AWS services needed to be created, deleted, or modified. Let’s look at one such Terraform configuration file:
resource "aws_instance" "single-instance"{
ami = "ami-ebd02392"
instance_type = "t2.micro"
subnet_id = "subnet-eddcdzz4"
vpc_security_group_ids = ["sg-12345678"]
}
The preceding Terraform configuration file defines an AWS EC2 server using the aws_instance resource type provided by Terraform’s AWS provider and then is given an Amazon Machine Image (AMI) configuration (which is essentially the operating system image) instance type to define its CPU and RAM configuration and other network settings. If you have Terraform set up correctly locally, this will investigate your AWS setup, see that this server doesn’t exist, and then proceed to create this server for you.
Obviously, this is a very simple example. There are Terraform configuration projects with many thousand lines of configuration files. These projects can get quite elaborate and out of hand once the complexity of the deployment increases. There are various remedies for this, none of which—in our opinion—really addresses the issue here. Have you spotted the problem?
The problem is that these configurations are not really defined as code. They are defined as declarations in a declarative language that are not Turing Complete code blocks.
In this chapter, we will cover the following main topics:
- Introduction to AWS CDK
- Setting up your local environment and writing your first CDK app
- Creating a containerized web application in AWS CDK using Docker
- Understanding the inner workings of AWS CDK