Terraform: Taming the Machines Through Continuous Integration
1. TERRAFORM: TAMING THE
MACHINES WITH
CONTINUOUS
INTEGRATION Justin Rice
Source Code: jsrice7391/tf-talk
Medium: Jsrice7391
Twitter: jsrice617
GitHub: Jsrice7391
2. JUSTIN RICE
• DevOps Engineer @
Indigo Ag
• Full-Stack Web
Development Teacher
@ 2U
• New England Native
• Four years in IT
• Broadcast before IT
• Sports, Cyber Sec,
Dogs, Education and
Snow enthusiast
3. INDIGO
• Indigo works to improve
grower profitability,
environmental sustainability, and
consumer health through the use
of natural microbiology and
digital technologies
• Working with digital
technologies in the many
different sectors of the
agricultural distribution pipeline
to bring farmers and consumers
closer to one another and make
a more natural and modern
approach from seed to shelf
4. INDIGO +
TERRAFOR
M
In early 2019, Indigo purchased a company called Tellus
labs, a company that specialized in geospatial mapping
and engineering.
With Tellus being acquired, and a growing software
company that released its first public facing app in July
2018, our DevOps team saw a need for control, but for a
modern age of continuous integration.
This is what we learned, and we’re happy to share it with
you.
6. THE CLASSIC SCENARIO
• Architecture of applications is fixed
and is rarely iterated on
• Big Releases for the sake of
compliance or feature releases.
• Big and scary
8. PROBLEMS
Lots of tools to choose
from
Infrastructure over time
needs documentation.
If you want something
scalable, it has to be
repeatable
Not everyone knows
which shiny button to
click.
11. WHY IT’S AWESOME
• Terraform is a platform that uses
Infrastructure as code (IaC) to allow its
users to manage cloud and local
architecture
• The community version is open sourced
with an available enterprise version
through HashiCorp.
• Reproducible environments
• Idempotence and convergence through
state
• Easing collaboration
• No need for the learning curve that
comes with different services and their
APIs
12. WHAT ITS NOT
• Cloud Formation – modularization and can handle writing true logic.
• Vagrant - Terraform can help create Vagrant resources.
• Puppet, Chef, Ansible – not cloud native
17. RESOURCES
• The main reason we use terraform.
• All other tooling within Terraform is
built around the ability to manage
these resources.
18. PROVIDERS
• Responsible for writing
and understanding the
API interactions.
• Commonly written in GO
• Could be compared to as
a wrapper.
• AWS provider attempts to
be an exhaustive wrapper
around the API.
19. Modules
• Reusable configurations that can be
used throughout terraform.
• A module can consist of multiple,
related resources.
Variables
• Inputs given to a module to be able
to make the resource parameters
more dynamic
• Declared in HCL specific way
• Strongly typed
21. You want to start experimenting with terraform, but with something smaller and
with less expensive resources. You go and look for one of Terraforms many:
A. Providers
B. Resources
C. Services
D. Employees
23. You pitch this new idea to your boss of using Terraform. She asks you to
name two of the major benefits of using Terraform. Which of the following are
two benefits of Terraform?
A. Configurations are written in YAML/YML and everyone loves yml.
B. It allows versioning of resources through the use of state.
C. It provides documentation for all services and their APIs
D. One singular language can be used to configure resources from multiple
different providers
24. B AND D
TERRAFORM USES A STRONGLY TYPED LANGUAGE PAIRED
WITH A CATALOG OF DIFFERENT PROVIDERS TO HANDLE
THEIR CONFIGURATION AND VERSIONS THEIR STATE
OVER TIME THROUGH STATE.
25. She then replies, “That sounds great, but how much does it cost.” What is your
best answer to this question?
A. “Terraform community version is well-supported, documented and free. You
only pay for the underlying resources you create with it.”
B. “It’s the holiday season, is cost really a concern?”
C. “Wicked expensive”
26. A
TERRAFORMS COMMUNITY VERSION IS FREE, IS WELL
DOCUMENTED AND CARRIES NO COST. YOU ONLY
PAY FOR THE RESOURCES YOU CREATE AS YOU USE
IT.
28. 1. Code A VPC
2. Make that VPC
3. Make the subnets within that VPC.
4. Talk about state and then making it remote.
5. Hashi Corp Language.
6. More TF Concepts
7. Using loops for maximum Power
8. Using Terraform in Continuous Integration
9. The Beyond
29. STARTERS
• Every Terraform project
should begin with a
provider.
• Each provider has its own
set of resources that it is
capable of creating and
managing.
30. TERRAFORM INIT
WILL PULL DOWN THE PROVIDERS CONFIGURATION
SO WE CAN USE IT TO CREATE THE RESOURCES.
31. TERRAFORM PLAN
WILL SHOW THE USER WHAT TERRAFORM PLANS TO DO WITH
THE NEW CONFIGURATIONS COMPARED TO WHAT IT ALREADY
KNOWS.
35. STATE
• State is where terraform really shines.
• It can be viewed in the new terraform.tfstate file that was just created.
• As you continue to add more resources and modify resources, Terraform will create new
versions of the state file and modify the objects
37. TERRAFORM
BACKENDS
• Allows Terraform to send
the state file to another
location such that other
developers (or a CI
pipeline) can iterate on it.
• Hashi Corp provides a
service called Consul, but
also supports s3 for a
backend service.
40. Data
• As seen in other languages, but
defined in a slightly unique manner.
• Can be used to create dynamic
values throughout.
Locals
• Creates a reference block for resources
to be able to access.
• A resource not quite in terraform or in
another location? Create a data block
to be able to access those needed
values.
• Common for providers to create
provider specific references to this.
41. OUTPUT• Allows for users to find values from
within the command line without
needing to access the state file
• Outputs should be used on variables
you might want to access after the
apply and be used
42. TERRAFORM
FUNCTIONS
• Terraform comes with a multitude
of different kinds of functions to
modify the data that we use to
create resources.
• These can also be used to create
”loops” without having to write as
much code.
47. THAT’S COOL AND ALL,
BUT…
THE INEVITABLE QUESTION THAT COMES WHEN WE MAKE
BIG DECISIONS IN ARCHITECTURE HAVE NOT CHANGED.
48.
49. TERRAFOR
M IMPORT
Currently a feature that TF allows
that still requires a bit more
overhead, but works like a charm.
Import allows each provider to be
able to import a resource to state
file.
As of this writing, Terraform does
not automatically write a tf file, it
does however update the state.
51. TOPICS FOR
CONVERSATIO
N
Implement Terraform within multiple accounts, created from
Terraform. Block master branch to this repo. All Pull requests
generate a TFPlan file. Upon PR approval, merge to master and
make the changes.
Developers need exact stacks, add an object to the collection, TF
apply. Done.
Pushback from the organization to make sure all resources are
tagged, a certain ami, different version over multiple VMS in
multiple accounts. Change it in terraform.