A Developer’s Guide to Terraform

Why infrastructure as code is important

Creating cloud resources or setting up monitoring with a simple configuration file provides enormous benefits for engineering or infrastructure teams. Provisioning infrastructure with code offers many ways to reduce risk, i.e. increase stability, including:

  • Traceability
  • Repeatability
  • Automation
  • Documentation

How Terraform code becomes infrastructure

Terraform does not create infrastructure directly from code. HashiCorp calls the group of files that describe the infrastructure a “configuration”. Terraform configurations rely on a provider which interfaces with the desired client to create and manage infrastructure directly. A Terraform Provider creates an execution plan that explicitly describes what changes will be made. After reviewing the plan, developers and engineers can apply the plan to perform the operations specified in it.

  • Amazon Web Services
  • Azure
  • Splunk
  • Datadog
  • Google Cloud
  • Sentry
  • Github
  • (Many more!)

Creating an AWS S3 Bucket with Terraform

Creating cloud resources is one of many tasks Terraform can abstract away for teams. It’s relatively straightforward to define details for cloud resources, and we’ll use AWS S3 as an example (S3 = Simple Storage Solution).. This is cloud storage into which you can upload and download files of nearly any kind, both manually and via the API. Both Azure and Google Cloud have similar products, but for this example S3 will suffice.

Setting up AWS Credentials

If you don’t already have an account with AWS, you can quickly create an account for free. Once you’ve done that, or if you have an account already, you’ll need to create an IAM (Identity and Access Management) role for Terraform to connect with. In the AWS web console, search for and select IAM. From the left-side menu, select “Users” and then click “Create a new user”.

Setting up Terraform on Your Machine

If you haven’t already, you’ll need to install Terraform on your machine. This is easiest to do with homebrew by running:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Writing a Configuration

Like we mentioned earlier, configurations are what Terraform calls the code that defines a piece of infrastructure. Terraform configurations must be in their own directories, so create a new one for this project somewhere on your machine.

terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
required_version = ">= 1.2.0"
}
variable "access_key" {
description = "AWS IAM access key"
type = string
sensitive = true
}
variable "secret_key" {
description = "AWS IAM secret key"
type = string
sensitive = true
}
provider "aws" {
region = "us-east-1"
access_key = var.access_key
secret_key = var.secret_key
}
resource "aws_s3_bucket" "create-my-bucket" {
bucket = "some-bucket-name-that-must-be-globally-unique"
}
access_key = "<aws_iam_access_key>"
secret_key = "<aws_iam_secret_key>"

Applying the Plan

Next, initialize the directory by running:

terraform init
terraform fmt
terraform validate
terraform apply -var-file=testing.tfvars

Terraform in CI with Semaphore

Terraform can be run as part of a CI/CD pipeline on Semaphore! To do this, you’ll first need to create a repository in the directory with your terraform configuration:

git init
# Local .terraform directories
**/.terraform/*
# .tfstate files
*.tfstate
*.tfstate.*
# Crash log files
crash.log
crash.*.log
# Exclude all .tfvars files, which are likely to contain sensitive data, such as
# password, private keys, and other secrets. These should not be part of version
# control as they are data points which are potentially sensitive and subject
# to change depending on the environment.
*.tfvars
*.tfvars.json
# Ignore override files as they are usually used to override resources locally and so
# are not checked in
override.tf
override.tf.json
*_override.tf
*_override.tf.json
# Include override files you do wish to add to version control using negated pattern
# !example_override.tf
# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
# example: *tfplan*
# Ignore CLI configuration files
.terraform*
terraform.rc

Everyone wins when developers aren’t afraid of Terraform

Developers are often not completely responsible for creating and managing infrastructure, but everyone benefits when they’re comfortable doing so. Many developers are apprehensive about Terraform due to the mild complexity it introduces over UI or command line tools. Developers commonly find the learning curve a bit steep, especially when learning the correct use of new Terraform providers. Site reliability engineers often advocate or even mandate that infrastructure or even monitoring tools are configured with Terraform, so having familiarity enables developers to better participate and collaborate. The benefits of provisioning infrastructure with Terraform are clear and the learning curve is not nearly as steep as it seems, so don’t be afraid to try it out!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Semaphore

Semaphore

Supporting developers with insights and tutorials on delivering good software. · https://semaphoreci.com