Originally presented at the Phoenix Golang Meetup
Terraform is typically used by DevOps teams to provision infrastructure from code. Its modular design allows it to interact with any system by writing a little bit of Go.
Terraform has three main operations.
Plan shows what would happen
Apply performs the plan
Destroy tears down all managed resources (from state)
Let’s say you want to build something like this
There are a ton of steps, each of which would be done by ops manually (error-prone, not peer-reviewed, not scalable)
It’s hard to keep track and properly build. Begins to feel like one of these things.
Cloud misconfiguration happens in the wild. It's costly.
Show instance https://us-west-1.console.aws.amazon.com/ec2/v2/home?region=us-west-1
Update SSH config with the plan output
SSH via public (bastion) instance
Modules and variables as inputs
Modules are just directories with .tf files in them
APIs called on your behalf
State is produced and tracked
Outputs are displayed
A provider is responsible for understanding API interactions and exposing resources.
A data source is something to look up, usually from an API
Example: the latest Ubuntu 14.04 Amazon Machine Image
A resource is something managed by Terraform.
Example: an AWS EC2 instance
Plugins listed by HashiCorp are pulled automatically on terraform init
Community and custom providers have to be placed in a special directory
(System-level installation is possible)
Originally set out to (and built) a provider to list and upload to another workspace
Slack broke the (undocumented) method I used to upload.
New goal: list all emoji in a workspace and expose them as routes on an ALB.
Terraform could be used to expose your company’s APIs
Employees requesting access to resources as PRs (reviewable, auditable)
Legacy shell scripts and things that one person has on their machine can be centralized
Or literally anything else…
Go out there and Terraform all the things.
The more providers there are, the more powerful the tool is (like IFTTT)