Successfully reported this slideshow.
Your SlideShare is downloading. ×

OSDC 2018 | Lifecycle of a resource. Codifying infrastructure with Terraform for the future by Anton babenko

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 52 Ad

OSDC 2018 | Lifecycle of a resource. Codifying infrastructure with Terraform for the future by Anton babenko

Download to read offline

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.

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.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to OSDC 2018 | Lifecycle of a resource. Codifying infrastructure with Terraform for the future by Anton babenko (20)

Advertisement

Recently uploaded (20)

OSDC 2018 | Lifecycle of a resource. Codifying infrastructure with Terraform for the future by Anton babenko

  1. 1. Lifecycle of a resource in Terraform by Anton Babenko
  2. 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
  3. 3. Write, plan, and create infrastructure as code www.terraform.io
  4. 4. Once created, infrastructure is going to be updated…
  5. 5. And new versions of Terraform will come out! Yay!!!
  6. 6. This talk is about evolution of resources Code structure, Terraform coding tricks, refactoring
  7. 7. Terraform primitives • Resources • Data sources • Variables • Terraform state
  8. 8. Resources • Create, Read, Update, Delete • Lifecycles: • ignore_changes • prevent_destroy • create_before_destroy
  9. 9. Data sources — read-only
  10. 10. Variables • string, integer, boolean • list • map
  11. 11. Types of variables Type of variable => string, integer, boolean list [] map {} Command line Yes Yes Yes *.tfvars Yes Yes Yes Inside computing values (count, lifecycle) Yes No No Inside other variables (string) Yes Yes Yes Inside other variables (list) Yes Yes Yes, partially Inside other variables (map) Yes Yes Yes
  12. 12. Terraform state JSON file (*.tfstate) with information about created resources Humans should not touch it (often)
  13. 13. AWS S3 bucket
  14. 14. AWS EC2 Security Group
  15. 15. AWS EC2 Security Group module
  16. 16. Small infrastructure As infrastructure grows and you manage more resources — how to group them?
  17. 17. Resources + Data Sources = Module
  18. 18. Create Your First Module https://www.terraform.io/docs/enterprise/guides/recommended-practices/part3.2.html#3-create-your-first-module
  19. 19. 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)
  20. 20. Usage of resource modules Q: Why use resource modules instead of resources? A: Resources can’t be versioned, but modules can.
  21. 21. Usage of infrastructure module
  22. 22. Modules tip #0 Check Terraform Registry before starting new resource module
  23. 23. Modules tip #1 — count types Value of 'count' cannot be computed (issue #10857)
  24. 24. Modules tip #2 — scope Remember the scope — no computed values in counts, no loops, no strict assumptions on region/service availability.
  25. 25. Modules tip #3 — implementation «Terraform module which creates RDS instance» https://github.com/terraform-aws-modules/terraform-aws-rds
  26. 26. Modules tip #3 — implementation (example)
  27. 27. Modules tip #3 — usage (example)
  28. 28. Modules tip #4 — size Usually infrastructure modules repositories have 99.9% waste — «terraform init» is slow
  29. 29. How to call modules? There are two extremes: 1. Call many modules in one place 2. Call one module in one place
  30. 30. 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)
  31. 31. 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
  32. 32. Composite pattern — everything-in-between The most popular choice
  33. 33. 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
  34. 34. 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
  35. 35. Poor man orchestration inception
  36. 36. WIP — https://github.com/antonbabenko/terraform-best-practices Read more
  37. 37. Refactoring using Terraform 0.11
  38. 38. 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»
  39. 39. Add new features/resources Often easy, but…
  40. 40. Refactoring — conditional Use existing resource or create a new one
  41. 41. 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.
  42. 42. jsonnet — alternative to lists for stateful resources (eg, AWS IAM Access Keys)
  43. 43. 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
  44. 44. Refactoring — rename/move
  45. 45. Refactoring — testing •Basics — pre-commit (fmt, validate) •Medium — review terraform plan •On PR — Atlantis (runatlantis.io) •Integration testing — terratest, awsspec
  46. 46. Refactoring — edge cases • Test in different AWS regions (S3 signature, EC2 ClassicLink, IPv6) • Check or open new github issues
  47. 47. 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
  48. 48. 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)
  49. 49. Thank you! Questions? Code: github.com/antonbabenko DM are open for all: twitter.com/antonbabenko

×