New to terraform; apologies if this question seems basic.
I would like to see the effect of adding new resources on a terraform plan, in order to test some code before merge. In theory this would be a simple command, but with a caveat:
We use terraform cloud to spin up our development environments, and we turn off the dev environment when not in use. This means that when I run terraform plan right now, it shows EVERYTHING that would need to be created- but I am only interested in incremental changes.
If there a way to run terraform plan against an old version of the remote state? (“show me what would change relative to last week, when the dev server was still running”)
Broadly, what is the recommended best practice to develop and verify terraform configs when infrastructure is not running?
Hi @abought,
Terraform is not designed to support the specific workflow you are describing here. Terraform’s assumption is that you are intending to move from the current real infrastructure settings to the settings described in the configuration, and the Terraform state is really just an implementation detail that helps Terraform keep track of the bindings between the remote objects and the configuration.
There are some mechanisms you could use that might allow you to approximate this, but it will be quite clunky because you’ll be using Terraform in a way it wasn’t designed to be used:
-
You can run terraform plan with the option -refresh=false to tell Terraform to trust that the latest state snapshot is accurate rather than asking the provider to return up-to-date information about all of the managed objects.
However, if you’re using any data blocks in your configuration which depend on objects that don’t currently exist then this will fail, because -refresh=false only disables the step of updating the state to match real objects that this configuration is managing, and not the step of reading information about external dependencies that the data blocks represent.
-
You can use terraform state pull to obtain a local copy of the raw data from the latest state snapshot stored in the backend. If you redirect that output to a file then you have something that is in principle compatible with Terraform’s local backend.
However, for that to be useful you’ll also need to temporarily disable any backend "remote" or cloud blocks in your configuration and use the local backend instead. Terraform assumes that switching between backends is a rare event because doing so incorrectly can cause confusion about what is the correct “latest state”, so constantly switching between local and remote is likely to be inconvenient.
If you’re able to start up your infrastructure first and then develop changes to it I think you’ll have an easier time. Otherwise, unfortunately I think you’ll run into a bunch of features that are intended to prevent mistakes, even though in your case those “mistakes” are really you intentionally using Terraform in an unusual way.