Immutable infrastructure is a way to success, but what about the lifecycle of individual resources. This talk is about evolution of resources, code structure, Terraform coding tricks, composition and refactoring.
2. Anton Babenko
Terraform AWS fanatic
Organiser of {HashiСorp, AWS, DevOps}
User Groups in Norway
DevOpsDays Oslo (29-30th October 2018)
github.com/antonbabenko
twitter.com/antonbabenko
linkedin.com/in/antonbabenko
21. Create Your First Module
https://www.terraform.io/docs/enterprise/guides/recommended-practices/part3.2.html#3-create-your-first-module
22. Types of Terraform modules
• Resource modules — very flexible, no relations to other modules, born to be
open-sourced
• Infrastructure modules — group of versioned resource modules, data-
sources, company-wide standards, code-generators (eg, jsonnet)
23. Usage of resource modules
Q: Why use resource modules
instead of resources?
A: Resources can’t be versioned,
but modules can.
31. Modules tip #4 — size
Usually infrastructure modules repositories have 99.9% waste — «terraform init» is slow
32. How to call modules?
There are two extremes:
1. Call many modules in one place
2. Call one module in one place
33. Composite pattern — many-in-one
Good:
1. Declare variables and outputs in fewer places
Bad:
1. Large blast radius — easier to break things
2. Locks everything at once
3. Single run vs orchestration concern (eg, first
run: data{0}=>resources{1}=>outputs{1}; second
run: data{0,1}=>resources{2}=>outputs{2})
4. No way to specify dependencies between
modules (depends_on)
34. Composite pattern — one-in-one
Good:
1. Small blast radius — harder to break
things
2. Possible to orchestrate, or chain runs
3. Easy to navigate
Bad:
1. Declare variables and outputs in
more places
36. How to structure compositions?
1. Primary cloud provider services (VPC, ALB) or group of services (network, DB, shared)
2. Code changing frequency
3. Code change initiator (human or CI server)
4. Relation between components (eg, security group together with EC2 instance)
5. Used technology (AWS CodeDeploy, K8S, OpenShift)
6. Logical name of environment (staging, production)
7. Project
37. Code structure guidelines
• Try to keep Terraform state small and secure
• Use Terragrunt to orchestrate your configurations and to reduce copy-paste
• Let users to operate with «easy» values and keep interpolation magic hidden
most of the time
41. Refactoring
Any change (add feature, fix bug, improve design, optimise resource usage)
to the code which brings codebase closer to the desired state.
• incremental
• small
• accept the ugliness
• «edit & prey» vs «cover & modify»
44. Refactoring — lists
If user2 is removed then user3 and user4 will be recreated — this is a
problem for stateful resources like AWS IAM access keys.
46. Refactoring — import
• terraform import aws_iam_account_alias.this alias
• Use https://github.com/dtan4/terraforming to generate *.tf and tfstate from
existing AWS resources
49. Refactoring — edge cases
• Test in different AWS regions (S3 signature, EC2 ClassicLink, IPv6)
• Check or open new github issues
50. Summary
• Terraform 0.11 has certain limitations — plan in advance!
• Use composition pattern — write less and simpler
• Reuse existing code and modules, fallback to documentation
51. Related Terraform projects
• https://github.com/antonbabenko/pre-commit-terraform — pre-commit git hooks to take care of
Terraform configurations (fmt, validate, terraform-docs)
• https://github.com/terraform-aws-modules/ — Collection of verified Terraform AWS modules
supported by the community
• https://github.com/antonbabenko/terraform-best-practices — Terraform best practices with
examples and arguments (WIP)
• https://cloudcraft.co/app?beta — «Export your AWS diagram as Terraform code» (tweet, modules.tf)
• https://github.com/antonbabenko/terrapin — Terraform module generator (POC)
• https://github.com/antonbabenko/terrible — Orchestrate Terraform configuration using Ansible
(POC)