HCP Terraform runs support many of the same modes and options available in the Terraform CLI.
The default run mode of HCP Terraform is to perform a plan and then apply it. If you have enabled auto-apply and are using a VCS or API workflow, a successful plan applies immediately. Otherwise, the run waits for user confirmation before applying.
terraform apply
(without providing a saved plan file).Destroy mode instructs Terraform to create a plan which destroys all objects, regardless of configuration changes.
terraform plan -destroy
or terraform destroy
is-destroy
option.This option creates a speculative plan. The speculative plan shows a set of possible changes and checks them against Sentinel policies, but Terraform can not apply this plan.
You can create speculative plans with a different Terraform version than the one currently selected for a workspace. This lets you check whether your configuration is compatible with a newer Terraform version without changing the workspace settings.
Plan-only runs ignore the per-workspace run queue. Plan-only runs can proceed even if another run is in progress, can not become the workspace's current run, and do not block progress on a workspace's other runs.
plan-only
option to true
and specify an available terraform version using the terraform-version
field.Version note: Using saved plans from the CLI with HCP Terraform requires at least Terraform CLI v1.6.0.
Saved plan runs are very similar to standard plan and apply runs: they perform a plan and then optionally apply it. There are three main differences:
Saved plans are ideal for interactive CLI workflows, where you can perform many exploratory plans and then choose one to apply, or for custom continuous integration workflows where the default run queue behavior isn't suitable.
terraform plan -out <FILE>
to perform and save a plan, then use terraform apply <FILE>
to apply the saved plan. Use terraform show <FILE>
to inspect a saved plan before applying it.save-plan
option when creating a run. If you create a new configuration version for a saved plan run, use the provisional
option so that it will not become the workspace's current configuration version until you decide to apply the run.A no-operation (empty) apply enables HCP Terraform to apply a run from a plan that contains no infrastructure changes. During apply, Terraform can upgrade the state version if required. You can use this option to upgrade the state in your HCP Terraform workspace to a new Terraform version. Only some Terraform versions require this, most notably 0.13.
To make such upgrades easier, empty apply runs will always auto-apply if their plan contains no changes.
Warning: HCP Terraform cannot guarantee that a plan in this mode will produce no changes. We recommend checking the plan for drift before proceeding to the apply stage.
allow-empty-apply
field to true
.Hands-on: Try the Use Refresh-Only Mode to Sync Terraform State tutorial.
Version note: Refresh-only support requires a workspace using at least Terraform CLI v0.15.4.
Refresh-only mode instructs Terraform to create a plan that updates the Terraform state to match changes made to remote objects outside of Terraform. This is useful if state drift has occurred and you want to reconcile your state file to match the drifted remote objects. Applying a refresh-only run does not result in further changes to remote objects.
terraform plan -refresh-only
or terraform apply -refresh-only
.refresh-only
option.The -refresh=false
option is used in normal planning mode to skip the default behavior of refreshing Terraform state before checking for configuration changes.
terraform plan -refresh=false
or terraform apply -refresh=false
.refresh
option.Version note: Replace support requires a workspace using at least Terraform CLI v0.15.2.
The replace option instructs Terraform to replace the object with the given resource address.
terraform plan -replace=ADDRESS
or terraform apply -replace=ADDRESS
.replace-addrs
option.Resource Targeting is intended for exceptional circumstances only and should not be used routinely.
terraform plan -target=ADDRESS
or terraform apply -target=ADDRESS
.target-addrs
option.The usual caveats for targeting in local operations imply some additional limitations on HCP Terraform features for remote plans created with targeting:
Sentinel policy checks for targeted plans will see only the selected subset of resource instances planned for changes in the tfplan
import and the tfplan/v2
import, which may cause an unintended failure for any policy that requires a planned change to a particular resource instance selected by its address.
Cost Estimation is disabled for any run created with -target
set, to prevent producing a misleading underestimate of cost due to resource instances being excluded from the plan.
You can disable or constrain use of targeting in a particular workspace using a Sentinel policy based on the tfrun.target_addrs
value.
Version note: Support for import
blocks and generating configuration requires a workspace using at least Terraform CLI v1.5.0.
When using import
blocks to import existing resources, Terraform can automatically generate configuration during the plan for any imported resources that don't have an existing resource
block. This option is enabled by default for runs started from the UI or from a VCS webhook.
terraform plan -generate-config-out=generated.tf
.allow-config-generation
option.You can find generated configuration displayed in the plan UI. If you're using the CLI workflow, Terraform will write generated configuration to the file you specify when running terraform plan
.
Once Terraform has generated configuration for you, you'll need to review it, incorporate it in your Terraform configuration (including committing it to version control), then run another plan. If you try to directly apply a plan with generated configuration, the run will error.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4