Terraform

Overview

Terraform 내용 정리.

CLI

Usage: terraform [-version] [-help] <command> [args]

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure
    env                Workspace management
    fmt                Rewrites config files to canonical format
    get                Download and install modules for the configuration
    graph              Create a visual graph of Terraform resources
    import             Import existing infrastructure into Terraform
    init               Initialize a Terraform working directory
    output             Read an output from a state file
    plan               Generate and show an execution plan
    providers          Prints a tree of the providers used in the configuration
    refresh            Update local state file against real resources
    show               Inspect Terraform state or plan
    taint              Manually mark a resource for recreation
    untaint            Manually unmark a resource as tainted
    validate           Validates the Terraform files
    version            Prints the Terraform version
    workspace          Workspace management

All other commands:
    0.12upgrade        Rewrites pre-0.12 module source code for v0.12
    debug              Debug output management (experimental)
    force-unlock       Manually unlock the terraform state
    push               Obsolete command for Terraform Enterprise legacy (v1)
    state              Advanced state management

Configurations

Syntax

• https://www.terraform.io/docs/configuration-0-11/syntax.html

Provider

provider "google" {
  credentials = "${file("account.json")}"
  project     = "my-project-id"
  region      = "us-central1"
}

Module

A module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.

The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.

Structure

• Input variables to accept values from the calling module.
• Output variables to return results to the calling module, which it can then use to populate arguments elsewhere.
• Resources to define one or more infrastructure objects that the module will manage.

To define a module, create a new directory for it and place one or more .tf files inside just as the user would do for a root module. Terraform can load modules either from local relative paths or from remote repositories; if a module will be re-used by lots of configurations you may wish to place it in its own version control repository.

Modules can also call other modules using a module block, but the recommendation is keeping the module tree relatively flat and using module composition as an alternative to a deelpy-nested tree of modules, because this makes the individual modules easier to re-use in different combinations.

When to write a module

In principle any combination of resources and other constructs can be factored out into a module, but over-using modules can make your overall terraform configuration harder to understand and maintain.

A good module should raise the level of abstraction by describing a new concept in your architecture that is constructed from resource types offered by providers.

Standard module structure

The standard module structure is a file and directory layout we recommend for reusable distributed in separate repositories. Terraform tooling is built to understand the standard module structure and use that structure to generate documentation, index modules for the module registry, and more.

• Root module

This is the only required element for the standard module structure. Terraform files must exist in the root directory of the repository. This should be the primary entrypoint for the module and is expected to be opinionated.

• README

The root module and any nested modules should have README files. This file should be named README or README.md. The latter will be treated as markdown. There should be a description of the module and what it should be used for. If you want to include an example for how this module can be used in combination with other resources, put it in an example directory. Consider including a visual diagram depicting the infrastructure resources the module may create and their relationship.

See also

• https://www.terraform.io/docs/modules/index.html