terraform reference

Keywords

• data - data source, requests terraform read from a given data source
• provider - configs for the specific provider e.g. aws with specified version
• resource - defines components of the infrastructure
• variable - defines variables
• output - use to connect the terraform projects with other parts of your infrastructure or with other terraform projects
• local - local variables to be reuse in this file

Difference of resource and data

• data is read only where resource cause terraform to create, update and delete infrastructure objects

Command Line

• init - initializes a working directory containing Terraform configuration files. It is safe to run this command multiple times.

Provisioning Infrastructure

• start with write author infrastructure as code
• validate - check whether the configuration is valid
• plan - present a plan for making changes, dry-run of apply
• apply - apply the planned changes to each resource using the relevant infrastructure provider’s API

Interally, Terraform uses API to create and manage cloud resources.

Inspecting Infrastructure

• console - inspect outputs interactively e.g. > data.terraform.remote_state.shared
• graph - creates a visual representation of a configuration or a set of planned changes.
• output - can get the values for the top-level output values of a configuration
• show - can generate human-readable versions of a state file or plan file, or generate machine-readable versions that can be integrated with other tools.
• state list - List resources in the state

Developing

• fmt - format
• validate - validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc.

See Also: terraform cli doc

Use Cases

• multi-cloud development: google cloud, aws, azure
• application infrastructure deployment, scaling and monitoring tools
  • terraform can handle dependencies to deploy database before provisioning the web servers
• platform team to build self-service clusters
  • use terraform to build a self-service infrastructure model that lets product teams manage their own infrastructure independently. You can create and use Terraform modules that codify the standards for deploying and managing services
• setup Platform as a service
  • use Terraform to codify the setup required for a Heroku application, configure a DNSimple to set a CNAME, and set up Cloudflare as a Content Delivery Network (CDN) for the app. Terraform can quickly and consistently do all of this without a web interface.
• manage Kubernetes
• setup parallel environments: development, test, QA and production
• setup software demo

Concepts

Terraform module

1. Group resources that you usually deploy together, letting you define reusable units of infrastructure code. For example, the official “VPC module” let you customise using input variables to quickly create VPC, subnets, route table, internet gateway, security groups…
2. Help teams establish infrastructure configuration standards. For example, you can write a module to create a database used by your application that includes all of the defaults that your architecture requires. The module can define the database size, type and handle all of the required networking. This ensures that module consumers provision infrastructure in line with your organisation standard and requirements.

Terraform state

Terraform stores state about your workspace’s managed infrastructure and configuration due to following reasons.

Why does Terraform use state?

1. Terraform uses your workspace’s state of map real world resources to your configuration.Prior to any operation, Terraform does a “refresh” to update the state with the real infrastructure. The primary purpose of state is to store bindings between objects in a remote system and resource instances declared in your configuration. When Terraform creates a remote object in response to a change of configuration, it records the identify of that remote object against a particular resource instance, and potentially updates and deleted that objects in response to future configuration changes.
2. keep track of metadata, such as resource dependencies, terraform uses configuration to determine dependency order.
3. remote backend is for securely store state and collaborates with team members.
4. performance, cache attribute values for remote resources, avoid network requests, more useful for large infrastructure.

The primary purpose of state is to store bindings between objects in a remote system and resource instances declared in your configuration. When Terraform creates a remote object in response to a change of configuration, it records the identity of that remote object against a particular resource instance, and potentially updates and deletes that objects in response to future configuration changes.

Internal to terraform, workspace state is stored as JSON file. Do not directly edit this file. Terraform expects a one-to-one mapping between configured resource instance and remote objects. Normally that is guranteed by Terraform being the one to create each object and record its identity in the state, or to destroy an object and then remove the binding for it. If you add or remote bindings in the state by other means, such as by importing externally - created objects with ‘terraform import’, or by asking Terraform to ‘forget’ an existing object with ‘terraform state rm’, you’ll then need to ensure for yourself that this one-to-one rule is followed, such as by manually deleting an object that you asked terraform to forget, or by re-importing it to bind it to some other resource instance.

remote state backends

Helps collaboration and coordinate execution for multiple developers working on the same codebase.

• state locking: Terraform will lock your state for all operations that could write state. State locking prevents concurrent Terraform operations on a single state file.
• state file may contain sensitive data, use state encryption.

scale Terraform

how to define boundaries or infrastructure ownership. need to decide on a cloud deployment strategy, possible approaches include using a single account in a single cloud provider, a hybrid or multi-cloud approach, or to divide up resources across accounts by environments.

Divide infrastructure responsibility

It’s common for different teams to focus on different parts of your organisation’s infrastructure. Networking team manage the VPCs, application team only needs to know where to deploy their application and focus on configuring servers and databases. But application still needs to access data about the networking resources for their own configuration - use reference data about other resources in your configuration without having to manage them in the same state file, allowing you to maintain distinct areas of ownership and infrastructure decoupling.