via GIPHY
If you search a bit on google, you’ll find lots of sample templates for both of these systems. However I found they had a lot of complexity.
When you’re just starting, you want a very simple example. So I thought I’d put one together.
Join 38,000 others and follow Sean Hull on twitter @hullsean.
I’m going to compare both terraform & cloudformation. They get you to the same endpoint, but do it slightly differently.
Very basic terraform template
Ok, you’ve got terraform installed right? If not there are howtos here.
Now let’s create a server.
Create a directory “terraform” then cd into it. Edit this file as main.tf
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-40d28157"
subnet_id = "subnet-111ddaaa"
instance_type = "t2.micro"
key_name = "seanKey"
}
Please change the subnet to a valid one for you. In the real world you would definitely *not* hardcode a subnet like this. But I wanted to keep this example very simple. Don’t know what subnet to use? Navigate your aws dashboard over to “VPC” and dig around.
Also of course edit for your key.
Ok, you’re ready to test. Let’s first ask terraform what it will do with the “plan” command:
levanter:terraform sean$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.
Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.
+ aws_instance.example
ami: "ami-40d28157"
availability_zone: ""
ebs_block_device.#: ""
ephemeral_block_device.#: ""
instance_state: ""
instance_type: "t2.micro"
key_name: "seanKey"
network_interface_id: ""
placement_group: ""
private_dns: ""
private_ip: ""
public_dns: ""
public_ip: ""
root_block_device.#: ""
security_groups.#: ""
source_dest_check: "true"
subnet_id: "subnet-111ddaaa"
tenancy: ""
vpc_security_group_ids.#: ""
Plan: 1 to add, 0 to change, 0 to destroy.
levanter:terraform sean$
Related: What is devops and why is it important?
Build & change with Terraform
Next you want to ask terraform to go ahead and do the work. Because above we only did a dry-run.
levanter:terraform sean$ terraform apply
aws_instance.example: Creating...
ami: "" => "ami-40d28157"
availability_zone: "" => ""
ebs_block_device.#: "" => ""
ephemeral_block_device.#: "" => ""
instance_state: "" => ""
instance_type: "" => "t2.micro"
key_name: "" => "seanKey"
network_interface_id: "" => ""
placement_group: "" => ""
private_dns: "" => ""
private_ip: "" => ""
public_dns: "" => ""
public_ip: "" => ""
root_block_device.#: "" => ""
security_groups.#: "" => ""
source_dest_check: "" => "true"
subnet_id: "" => "subnet-111ddaaa"
tenancy: "" => ""
vpc_security_group_ids.#: "" => ""
aws_instance.example: Still creating... (10s elapsed)
aws_instance.example: Still creating... (20s elapsed)
aws_instance.example: Creation complete
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.
State path: terraform.tfstate
levanter:terraform sean$
One thing I like is terraform shows us the progress at command line. Cloudformation isn’t so nicely finished. 🙂
Ok, let’s add a tag name to our server. We’re going to add just three lines to our main.tf file:
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-40d28157"
subnet_id = "subnet-111ddaaa"
instance_type = "t2.micro"
tags {
Name = "terraform-box"
}
}
Now we do terraform apply again. Look how easy that change is to make!
levanter:terraform sean$ terraform apply
aws_instance.example: Refreshing state... (ID: i-0ddd063bbbbce56e2)
aws_instance.example: Modifying...
tags.%: "0" => "1"
tags.Name: "" => "terraform-box"
aws_instance.example: Modifications complete
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.
State path: terraform.tfstate
levanter:terraform sean$
Navigate to the EC2 dashboard and you should see the first column showing your new name.
That was cool!
Chances are you don’t wanna leave these components sitting around. Let’s cleanup. That’s easy too!
levanter:terraform sean$ terraform destroy
Do you really want to destroy?
Terraform will delete all your managed infrastructure.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
aws_instance.example: Refreshing state... (ID: i-0ddd063bbbbce56e2)
aws_instance.example: Destroying...
aws_instance.example: Still destroying... (10s elapsed)
aws_instance.example: Still destroying... (20s elapsed)
aws_instance.example: Still destroying... (30s elapsed)
aws_instance.example: Still destroying... (40s elapsed)
aws_instance.example: Still destroying... (50s elapsed)
aws_instance.example: Still destroying... (1m0s elapsed)
aws_instance.example: Destruction complete
Destroy complete! Resources: 1 destroyed.
levanter:terraform sean$
Related: Top questions to ask on a devops interview
Very basic CloudFormation template example
Hopefully you wrote down your subnet name & keyname. So this will be easy.
Let’s create a “cfn” directory and cd into it.
Next edit main.yml
AWSTemplateFormatVersion: '2010-09-09'
Resources:
EC2Instance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
SubnetId: subnet-333dfe6a
KeyName: "iheavy"
ImageId: "ami-40d28157"
Now let’s build that with cloudformation. You need to have the awscli installed. Here’s amazon’s howto.
Now let’s create. Cloudformation organizes things as “stacks.
aws cloudformation create-stack --template-body file://sean-instance.yml --stack-name cfn-test
Since I didn’t define “outputs” to keep the yaml simple, the command above should just return without error.
You can go into the aws dashboard, and navigate to “CloudFormation” and see the stack being created. You can also see under “EC2” a new instance has been created.
Related: How do I migrate my skills to the cloud?
Add an instance name with tags in Cloud Formation
As we did with terraform, let’s add a name to the server. This is just a tag, not a hostname, so it’s only useful throughout the AWS API.
AWSTemplateFormatVersion: '2010-09-09'
Resources:
EC2Instance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
SubnetId: subnet-333dfe6a
KeyName: "iheavy"
ImageId: "ami-40d28157"
Tags:
- Key: "Name"
Value: "cfn-box"
Note the three new lines at the bottom. Ok, let’s apply those changes:
levanter:cfn sean$ aws cloudformation update-stack --template-body file://sean-instance.yml --stack-name cfn-test
Navigate to the EC2 dashboard and you should see the first column showing your new name.
Time to cleanup. Let’s delete that stack:
levanter:cfn sean$ aws cloudformation delete-stack --stack-name cfn-test12
levanter:cfn sean$
Related: Is upgrading Amazon RDS like a sh*t storm that will not end?
Conclusions
Terraform just supports JSON or it’s HCL (hashicorp configuration language). Actually the latter way of formatting is better supported.
On the CloudFormation side you can use yaml or json.
However CloudFormation can be clunky and frustrating to work with. For example to dry-run in terraform is easy. Just use “plan”. And isn’t something we’re going to do over and over?
In CloudFormation there is a “validate-template” option, but this just checks your JSON or YAML. It doesn’t hit amazon’s API or test things in any real way. They have added something called Change Sets, but I haven’t tried them too much yet.
Also CloudFormations error messages are really lacking. They often give you a syntax error or tell you a resource is incomplete without real details on where or how. It makes debugging slow and tedious. Sometimes I see errors at create-stack calls. Other times that succeeds only to find errors within the CloudFormation dashboard.
Terraform is wayyyyy better.
Related: Is Amazon Web Services too complex for small dev teams?