command backend

[pauldraper]

Terraform Version

-

Use Cases

I want to implement a custom backend, e.g. MySQL, MongoDB, Vault. Currently there is no general extension mechanism. #5877

Attempted Solutions

There is a HTTP backend that can be used as an extension mechanism. That is awkward, because it requires starting an HTTP server, controlling authentication so that other processes cannot access, etc.

Proposal

Invoke commands with an external process.

terraform {
  backend "command" {
    command = ["executable", "arg1"]
    environment = {
      name = "value"
    }
    working_directory = "dir"
  }
}

Terraform would specify env var TF_ACTION as read, write, lock, or unlock, with the lock information being in TF_LOCK.

The executable would read stdin/write stdout.

References

No response

[crw]

I believe this is a duplicate of #5877

The prescribed solution is extremely specific, so I will bring this to triage to see if it makes sense keeping this one open due to its specificity.

Thanks for the request!

[pauldraper]

Yes, #5877 would solve this.

But it's 7 years old, and ambitious.

[ei-grad]

Voted for this issue since #5877 proposes the use of plugin system, while this one propose a simple and flexible solution which can be built-in like the "local" backend and doesn't require to code in go.

Seriously, one could think that Hashicorp is looking for the world-wide infrastructure control, making secure .tfstate management so nontrivial... other reason for this could be TFCloud promotion, but wait... O_O

[ei-grad]

Though I would prefer to specify read / write / lock / unlock commands in separate parameters to get rid of writing the "switch" inside of command (and effectively requiring it to be a shell script / custom program).

And don't think that environment variables should be configured (they can be just inherited from env in which terraform runs). Working directory as of me also should be treated in "convention over configuration" way (should be equal to terraform working directory). Both this can be specified using bash -c "..." if needed.

What do you think?

[ei-grad]

Hmm. With "local-exec" having working_dir and environment parameters, it is better to have them too in the "command" backend which looks similar to "local-exec" in semantics. And looking on "local-exec" maybe command parameter should be plain string and interpreter should be added..?

[pauldraper]

Using an env var is somewhat odd, but presents some more flexibility with programs accepting CLI vars.

The command/interpreter is awkward, but matches the local-exec paradigm.

Neither are highly significant to the overall benefit/functionality/ergonomics.