This document discusses Terraform, an open source tool for building, changing, and versioning infrastructure safely and efficiently. It provides declarative configuration files to manage networks, virtual machines, containers, and other infrastructure resources. The document introduces Terraform and how it works, provides examples of Terraform code and its output, and offers best practices for using Terraform including separating infrastructure code from application code, using modules, and managing state. Terraform allows infrastructure to be treated as code, provides a faster development cycle than other tools like CloudFormation, and helps promote a devOps culture.

1. Terraform
Make infrastructure great again

2. A gopher
@advincze
https://github.com/advincze

3. WeltN24 & AWS
Using AWS for 1++ year
Started with an ops guy, ruby sdk, AWS cli, cloudformation,
Terraform helped adoption among non ops

4. What is terraform?
Declarative infrastructure Management
Better cloudformation? (code writability, open source, speed of dev, planning)
Network Setup to application deployment
Cloud / vendor agnostic
AWS first class citizen (uses directly AWS Go sdk, not CF)

5. Application Code vs. Infrastructure code
Imperative
Hopefully stateless
>50y
Declarative
Global state (dns, ips, s3 buckets, ssl
certs)
<10y

6. Quick look at code

7. How Terraform works
State-Before
Get state
Configuration:
*.tf files
Get config Validate config
Config errors
Calculate Diff
(graph)
Execute plan Write new State
State After
Exec errorsOutput plan

8. Three states
configuration Terraform state Real world

9. UI
Commands: plan, apply, destroy
Dev workflow : click, click-delete, read docs (similar to CF), write code, plan,
apply, destroy, fmt !
- Input/Output: Variables
- Interpolation
- Strings, functions

10. demo

11. Default VPC
EC2 instance
Security group CNAME: demo1.mob.welt.de

12. code
- File names don’t matter: *.tf
- Interpolation + var maps to switch regions easily (genesis example)
- Tag the resources

13. state
- What terraform knows about the real world
- Validated before application
- Used for planning (to create and ! to destroy)
Remote
- Store remote in artifactory, Atlas, Consul, S3, HTTP, etcd, swift (openstack)
- Easy to forget to configure (gist: terraformw)

14. - From relative filepath or e.g. github
- enable shared, reusable components
- Abstraction (!) for service developers
- Examples: ECS cluster, private_nets, public_nets
Modules - teams share code

15. Real Life demo

16. VPC
Public subnet
Internet gateway
Public subnet
Internet gateway
routingrouting

17. VPC
Public subnet
Internet gateway
Public subnet
Internet gateway
routingrouting
ECS instance
ECS cluster
SG
ECS instance
IAM
SG

18. VPC
Public subnet
Internet gateway
Public subnet
Internet gateway
routingrouting
ECS instance
ECS cluster
SG
ECS instance
IAM
SG ECR repository
APP image

19. VPC
Public subnet
Internet gateway
Public subnet
Internet gateway
routingrouting
ECS instance
ECS cluster
SG
ECS instance
IAM
SG ECR repository
APP image
ECS task ECS task
ECS service
ELB
CNAME: demo2.mob.welt.de
SSL

20. State dependencies
State
VPC
State
ECS
State
ECR
State
App
vpc.tf ecs.tf ecr.tf app.tf

21. - Input/Output in separate files
- Resource names: the resource type is part of the name
Best practices - code

22. - For production, use remote state only
- Separate repos/states for big logical parts (how often do you change this?
Who contributes?)
- Central components
- Shared components, services
- Service individual infrastructure
- Service deployment
- This is not Free !
Best practices - state

23. - Start with (repo) local modules and
- move them into separate repo if used elsewhere + mature
- Use ID prefix for module resources to avoid problems
- Practice: create + destroy all every day
- Don’t apply locally (only plan) - Centralize plan+apply
- Pin module versions
Best practices - modules

24. - Terraform is Production ready
- It can be used with your existing setup
- Extendable with custom plugins - standard lifecycle CRUD
- Main benefits: easy installation,ease of use, readable code, fast dev cycle,
open source - often quicker than CF
- Drawback: no rollbacks
- helps devOps culture
- Written in go, you should learn go.
summary

25. Thanks, questions?
@advincze