DevOps – Terraform Lifecycle

Terraform lifecycle consists of – init, plan, apply, and destroy.

1. Terraform init initializes the (local) Terraform environment. Usually executed only once per session.

Hands-on: Try the Terraform: Get Started tutorials. For more in-depth details on the init command, check out the Initialize Terraform Configuration tutorial.

The terraform init command initializes a working directory containing Terraform configuration files. This is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. It is safe to run this command multiple times.

Usage: terraform init [options]

This command performs several different initialization steps in order to prepare the current working directory for use with Terraform. More details on these are in the sections below, but in most cases it is not necessary to worry about these individual steps. This command is always safe to run multiple times, to bring the working directory up to date with changes in the configuration. Though subsequent runs may give errors, this command will never delete your existing configuration or state.

General Options –

The following options apply to all of (or several of) the initialization steps:

• -input=true Ask for input if necessary. If false, will error if input was required.
• -lock=false Disable locking of state files during state-related operations.
• -lock-timeout=<duration> Override the time Terraform will wait to acquire a state lock. The default is 0s (zero seconds), which causes immediate failure if the lock is already held by another process.
• -no-color Disable color codes in the command output.
• -upgrade Opt to upgrade modules and plugins as part of their respective installation steps. See the sections below for more details.

2. Terraform plan compares the Terraform state with the as-is state in the cloud, builds and displays an execution plan. This does not change the deployment (read-only). The terraform plan command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructure. By default, when Terraform creates a plan it:

• Reads the current state of any already existing remote objects to make sure that the Terraform state is up-to-date.
• Compare the current configuration to the prior state and note any differences.
• Proposes a set of change actions that should, if applied, make the remote objects match the configuration.

Usage: terraform plan [options]

The plan subcommand looks in the current working directory for the root module configuration. Because the plan command is one of the main commands of Terraform, it has a variety of different options, described in the following sections. However, most of the time you should not need to set any of these options, because a Terraform configuration should typically be designed to work with no special additional options for routine work.

The remaining sections on this page describe the various options:

• Planning Modes: There are some special alternative planning modes that you can use for some special situations where your goal is not just to change the remote system to match your configuration.
• Planning Options: Alongside the special planning modes, there are also some options you can set in order to customize the planning process for unusual needs.
• Resource Targeting is one particular special planning option that has some important caveats associated with it.
• Other Options: These change the behavior of the planning command itself, rather than customizing the content of the generated plan.

3. Terraform apply executes the plan. This potentially changes the deployment.

The terraform apply command executes the actions proposed in a Terraform plan.

Hands On: Try the Apply Terraform Configuration tutorial to learn how Terraform applies a configuration, how Terraform recovers from errors during apply, and common ways to use this command.

Usage: terraform apply [options] [plan file]

When you run terraform apply without passing a saved plan file, Terraform automatically creates a new execution plan as if you had run terraform plan, prompts you to approve that plan, and takes the indicated actions. You can use all of the planning modes and planning options to customize how Terraform will create the plan.

You can pass the -auto-approve option to instruct Terraform to apply the plan without asking for confirmation.

4. Terraform destroy deletes all resources that are governed by this specific terraform environment.

The terraform destroy command is a convenient way to destroy all remote objects managed by a particular Terraform configuration.

While you will typically not want to destroy long-lived objects in a production environment, Terraform is sometimes used to manage ephemeral infrastructure for development purposes, in which case you can use terraform destroy to conveniently clean up all of those temporary objects once you are finished with your work.

Usage: terraform destroy [options]

This command is just a convenience alias for the following command: terraform apply -destroy

For that reason, this command accepts most of the options that terraform apply accepts, although it does not accept a plan file argument and forces the selection of the “destroy” planning mode.

You can also create a speculative destroy plan, to see what the effect of destroying would be, by running the following command: terraform plan -destroy

This will run terraform plan in destroy mode, showing you the proposed destroy changes without executing them.

Terraform Core Concepts –

1. Variables: Terraform has input and output variables, it is a key-value pair. Input variables are used as parameters to input values at run time to customize our deployments. Output variables are return values of a terraform module that can be used by other configurations.
Read our blog on Terraform Variables

2. Provider: Terraform users provision their infrastructure on the major cloud providers such as AWS, Azure, OCI, and others. A provider is a plugin that interacts with the various APIs required to create, update, and delete various resources.
Read our blog to know more about Terraform Providers

3. Module: Any set of Terraform configuration files in a folder is a module. Every Terraform configuration has at least one module, known as its root module.

4. State: Terraform records information about what infrastructure is created in a Terraform state file. With the state file, Terraform is able to find the resources it created previously, supposed to manage and update them accordingly.

5. Resources: Cloud Providers provides various services in their offerings, they are referenced as Resources in Terraform. Terraform resources can be anything from compute instances, virtual networks to higher-level components such as DNS records. Each resource has its own attributes to define that resource.

6. Data Source: Data source performs a read-only operation. It allows data to be fetched or computed from resources/entities that are not defined or managed by Terraform or the current Terraform configuration.

7. Plan: It is one of the stages in the Terraform lifecycle where it determines what needs to be created, updated, or destroyed to move from the real/current state of the infrastructure to the desired state.

8. Apply: It is one of the stages in the Terraform lifecycle where it applies the changes real/current state of the infrastructure in order to achieve the desired state.

Check Out: Our previous blog post on Terraform Cheat Sheet.