hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.34k stars 9.49k forks source link

Introduce commandline switch to entirely ignore backend for local testing #23818

Open jeanpaulsmit opened 4 years ago

jeanpaulsmit commented 4 years ago

Current Terraform Version

0.12.19

Use-cases

The typical approach to start testing the Terraform script is to run it locally with a local backend which you can easily dispose during that process. In a CI/CD environment however the backend is stored separately. Basically this means that in the local development we comment out the backend part so the tfstate file is created in the same folder. Obviously we every now and then forget to add the backend part again when checked in which leads to errors in CI/CD.

Attempted Solutions

No work around

Proposal

It would be great to have a commandline switch to init and apply to ignore the backend configuration entirely. In this way you keep production-like script for testing locally. At first I thought the --backend switch would do what I was looking for, but it turned out it's not.

References

-

crawfs commented 4 years ago

I"m going through this as well currently with an azure storage account as the remote backend for our terraform pipeline deployments. You can't leave the:

terraform {
    backend "azurerm" {
    }
}

Block out of your template because the pipeline will fail but you also can't run this deployment locally without making a code change to the deployment to remove the remote backend configuration. I don't suppose anyone has an implementation they use to easily run terraform deployments locally without interacting with the remote backend?

Also: The alternative to this proposal would be to allow the -backend-config argument to specify what the backend actually is (local/remote/s3/azurerm etc) rather than just being able to define the values for one type of backend configuration. This way I could create a terraform template intended to run in a pipeline with a remote backend that doesn't actually have an explicit remote backend in the file and I could allow my pipeline to manage that and local deployments would default to using the local backend.

vanneback commented 4 years ago

I'm having a similar issue were we would like to give our users the option to choose between different backends. So being able to use backend=type would be great.

And if thats not possible at least provide the option to run it locally from the command line.

fyhertz commented 3 years ago

Same here! What is the recommended workflow when you want to test your terraform deployments locally ? Being able to specify the backend provider in the backend config would make things a lot easier. That or the solution proposed by OP.

tbutler-qontigo commented 1 year ago

I use a state.tf file to hold my remote backend state config, which is checked in. I also have a state_override.tf file locally which is NOT checked in (listed in .gitignore) and is simply:

terraform {
  backend "local" {
  }
}

So I can easily test locally with local state. The problem then is when I want locally to connect to remote state, I have to remember to remove or rename my state_override.tf file...so not ideal, but better than editing the actual state.tf file and having to remember to undo the changes before I do a check in.

Since terraform already offers the -backend-config="key=value" command line option to update the parameters of the backend config, it would make sense for some variation of this to allow you to specify the actual backend itself...or indeed for the file you can specify to -backend-config to change the backend - e.g looking like the override file I specified above rather the file just specifying properties of the configured backend.

codyspeck-ppa commented 7 months ago

Still looking for a solution for this in 2024. We can manually manipulate the Terraform files that contain backend configuration in CI / CD pipelines, but it sure would be cleaner if there was a natively supported method.