Infrastructure as Code with Terraform
- 1. Infrastructure as Code with Terraform Tim Berry
- 2. About Me Google Certified Professional Cloud Architect + Data Engineer Some RedHat certs Run the Google Cloud Platform SRE Team at Claranet Have a familiar and boring origin story based around a ZX Spectrum linkedin.com/in/timhberry
- 3. Definition Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. (Wikipedia)
- 4. • Why Infrastructure as Code? • The Terraform Lifecycle • Best Practices Overview
- 5. Why Infrastructure as Code?
- 9. A software engineering approach to an operations function: • Automated • Quality Managed • Modular/Re-usable • Collaborative • Auditable Infrastructure as Code
- 10. • Developed by HashiCorp • First released July 2014 • Open source (MPLv2.0) • Written in Go • Cloud Agnostic Neutral • Rapid development Terraform
- 11. • Major cloud vendors (AWS, GCP, Azure) • PaaS (Heroku) • SaaS (PagerDuty, DNSimple, CloudFlare) • Databases (PostgreSQL, MySQL) • Community providers Terraform Providers
- 13. • Define your infrastructure • Initialise your execution environment • Plan your execution • Apply your changes • Destroy your infrastructure Terraform Lifecycle
- 14. • A collection of configuration files in a single directory • Expressed in HCL Terraform syntax or JSON • Declarations of: - Providers - Resources - Data Sources Infrastructure Definition
- 15. • A collection of configuration files in a single directory • Expressed in HCL Terraform syntax or JSON • Declarations of: - Providers - Resources - Data Sources Infrastructure Definition s u f n o b
- 16. • A collection of configuration files in a single directory • Expressed in HCL Terraform syntax or JSON • Declarations of: - Providers - Resources - Data Sources Infrastructure Definition s u f n o b s u f n u y u n o f
- 17. • Parameters can be set via TF or environment variables • Local gcloud auth or service account (recommended) Provider
- 18. • Resource definitions declare what should exist • Unique to the provider (GCP resources != AWS resources) • Cloud resources supported by the vendor API generally supported by Terraform • Each resource will require a number of arguments • Each resource can provide attributes for further use Resources
- 19. • Resource type is google_compute_network • Resource name is bookface • Everything else is optional Resources: Define a Network
- 20. • Our subnetwork knows its parent network from this interpolation • Accessing resource attributes: “${<type>.<name>.<attribute>}” Resources: Define a Subnetwork
- 21. • Many resources require other resources to exist first - subnetwork required network • Start with the resource you need and work backwards • A google_compute_instance will require - subnetwork - zone - image • Terraform will build a Directed Acyclic Graph of resources to ensure dependencies are met Resource Dependencies
- 22. • Retrieve or compute values to be used in configuration • Avoids hard-coding • Gives dynamic values for things like: - Zones available in a region - Images available for Compute Engine Data Sources
- 23. Data Sources • Find available zones in europe-west2 • All arguments are optional for google_compute_zones • Retrieve a link to the latest version of the image in the ubuntu-1710 family • From the ubuntu-os-cloud project
- 24. Resources: Define a VM
- 25. • Prepares the environment • Runs syntax checks • Downloads providers • Populates a .terraform directory terraform init
- 26. terraform init
- 27. • Creates a plan for what actions to perform • In other words, a DAG of changes • Makes a three-way comparison between configuration, stored state and actual state • Outputs a plan confirming what will happen • Use the saved plan file to apply changes terraform plan
- 28. terraform plan
- 29. terraform plan
- 30. • Actually makes changes • Will run another plan if you don’t provide one • Takes anywhere from a few seconds to many minutes depending on resources being created • Changes are written to a JSON state file - Defaults to a local terraform.tfstate - Previous state preserved in terraform.tfstate.backup terraform apply
- 32. terraform apply
- 33. terraform apply
- 34. Magic
- 35. • Destroys all the resources in state • Provides a plan of what will be destroyed and prompts you to confirm • There is no Undo! terraform destroy
- 37. Wait, seriously, why Infrastructure as Code?
- 38. Living The Infrastructure Dream: AUDITABLE - REPEATABLE - DEPENDABLE • Interacting with a UI is none of those things • Imperatively using a CLI is maybe 1 of those things • Infrastructure gets BIG • You don’t want to start from scratch with every project Because
- 39. Best Practices
- 40. terraform fmt • Rewrites configuration files to a canonical style and format terraform validate • Validates syntax of configuration files Lint
- 41. • Store infrastructure state in the project itself • State locks itself during operations • Makes code portable and enables collaboration • Git all the things Remote State
- 42. • Maintain separate variables per environment • Use Makefile to interact with terraform params/dev.tfvars Environments Makefile
- 43. • Reusable collections of resource definitions and/or data sources • Can accept arguments and provide attributes • Basically just a bunch of .tf files in a directory • Community modules available for deploying common groups of resources or applications tf-gcp-standard-subnetwork • Standard subnetwork • HA NAT instances • Public routes and default NAT routes Modules
- 44. • Terrafile: https://github.com/claranet/python-terrafile Version management for modules • TfEnv: https://github.com/kamatama41/tfenv Version management for TF itself • Exekube: https://github.com/exekube/exekube Combines Terraform with Helm for complete IaC on Kubernetes • Pipelines! (didn’t have time for this talk, sorry) Worth a Look
- 45. • Terraform’s lifecycle is: init, plan, apply and eventually destroy • Use data sources and variables and be as generic as possible • Split variables into environment-specific parameter files • Use git and remote backends for portability • Use modules to save time Summary