terraform/website/docs/commands/apply.html.markdown

81 lines
3.5 KiB
Markdown
Raw Normal View History

2014-07-25 00:53:46 +02:00
---
layout: "docs"
page_title: "Command: apply"
sidebar_current: "docs-commands-apply"
2014-10-22 05:21:56 +02:00
description: |-
The `terraform apply` command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a `terraform plan` execution plan.
2014-07-25 00:53:46 +02:00
---
# Command: apply
The `terraform apply` command is used to apply the changes required
to reach the desired state of the configuration, or the pre-determined
set of actions generated by a `terraform plan` execution plan.
## Usage
Usage: `terraform apply [options] [dir-or-plan]`
2014-07-25 00:53:46 +02:00
By default, `apply` scans the current directory for the configuration
and applies the changes appropriately. However, a path to another configuration
or an execution plan can be provided. Explicit execution plan files can be
used to split plan and apply into separate steps within
[automation systems](https://learn.hashicorp.com/terraform/development/running-terraform-in-automation).
2014-09-30 00:58:45 +02:00
backend/local: treat output changes as side-effects to be applied This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.
2020-05-27 01:59:06 +02:00
If no explicit plan file is given on the command line, `terraform apply` will
create a new plan automatically and prompt for approval to apply it. If the
created plan does not include any changes to resources or to root module
output values then `terraform apply` will exit immediately, without prompting.
2014-07-25 00:53:46 +02:00
The command-line flags are all optional. The list of available flags are:
2014-07-28 05:40:18 +02:00
* `-backup=path` - Path to the backup file. Defaults to `-state-out` with
the ".backup" extension. Disabled by setting to "-".
2014-07-28 05:40:18 +02:00
* `-compact-warnings` - If Terraform produces any warnings that are not
accompanied by errors, show them in a more compact form that includes only
the summary messages.
2017-04-04 19:48:59 +02:00
* `-lock=true` - Lock the state file when locking is supported.
* `-lock-timeout=0s` - Duration to retry a state lock.
2014-12-06 00:39:49 +01:00
* `-input=true` - Ask for input for variables if not directly set.
* `-auto-approve` - Skip interactive approval of plan before applying.
2014-07-25 00:53:46 +02:00
* `-no-color` - Disables output with coloring.
* `-parallelism=n` - Limit the number of concurrent operation as Terraform
[walks the graph](/docs/internals/graph.html#walking-the-graph). Defaults to
10.
2014-07-27 02:50:53 +02:00
* `-refresh=true` - Update the state for each resource prior to planning
and applying. This has no effect if a plan file is given directly to
apply.
2014-07-25 00:53:46 +02:00
* `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
Ignored when [remote state](/docs/state/remote.html) is used.
2014-07-25 00:53:46 +02:00
* `-state-out=path` - Path to write updated state file. By default, the
`-state` path will be used. Ignored when
[remote state](/docs/state/remote.html) is used.
2014-07-25 00:53:46 +02:00
2015-04-01 01:48:54 +02:00
* `-target=resource` - A [Resource
core: -target option to also select resources in descendant modules Previously the behavior for -target when given a module address was to target only resources directly within that module, ignoring any resources defined in child modules. This behavior turned out to be counter-intuitive, since users expected the -target address to be interpreted hierarchically. We'll now use the new "Contains" function for addresses, which provides a hierarchical "containment" concept that is more consistent with user expectations. In particular, it allows module.foo to match module.foo.module.bar.aws_instance.baz, where before that would not have been true. Since Contains isn't commutative (unlike Equals) this requires some special handling for targeting specific indices. When given an argument like -target=aws_instance.foo[0], the initial graph construction (for both plan and refresh) is for the resource nodes from configuration, which have not yet been expanded to separate indexed instances. Thus we need to do the first pass of TargetsTransformer in mode where indices are ignored, with the work then completed by the DynamicExpand method which re-applies the TargetsTransformer in index-sensitive mode. This is a breaking change for anyone depending on the previous behavior of -target, since it will now select more resources than before. There is no way provided to obtain the previous behavior. Eventually we may support negative targeting, which could then combine with positive targets to regain the previous behavior as an explicit choice.
2017-06-16 03:15:41 +02:00
Address](/docs/internals/resource-addressing.html) to target. For more
information, see
[the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
2015-03-27 23:24:15 +01:00
2016-07-12 00:37:51 +02:00
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
can be set multiple times. Variable values are interpreted as
[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
specified via this flag.
2014-07-25 00:53:46 +02:00
* `-var-file=foo` - Set variables in the Terraform configuration from
2017-06-22 03:22:07 +02:00
a [variable file](/docs/configuration/variables.html#variable-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files
specified by `-var-file` override any values set automatically from files in
the working directory. This flag can be used multiple times.