Deploying a module

For each run, the terraform_module role works through the same steps:

  • Write a root module (main.tf.json) that calls the module given in terraform_module_source as module.this, with terraform_module_inputs as its inputs, the backend from terraform_module_backend_config and any extra blocks from terraform_module_extra

  • Run terraform init and terraform plan, saving the plan to a file, and display the plan

  • If the plan has changes, wait for an operator to type yes, unless terraform_module_interactive is false

  • Apply the saved plan, so exactly what was shown is what is applied

  • Store the outputs of module.this in the host variable named by terraform_module_outputs_var (terraform_module_outputs by default)

  • Remove the temporary working directory

terraform_module_action selects what the run does:

apply

Plan and apply. This is the default.

destroy

Plan a destroy and apply it.

plan-apply, plan-destroy

Plan only. The plan is displayed and nothing is changed.

In check mode the role still plans and displays the plan, but never applies or destroys.

Warning

By default the role works in a temporary directory that is deleted at the end of the run. The state must therefore be kept somewhere else: set terraform_module_backend_config to a remote backend, or set terraform_module_workdir to a directory that is kept. With a local backend and a relative path the state is written to the temporary directory and lost.

Approval prompts are shown once per batch of hosts, so a single yes approves the plan for every host in the batch. Where there is no terminal (for example in AWX or CI), the prompt cannot be answered and the role fails before applying anything: set terraform_module_interactive to false for unattended runs.

Task results that can contain sensitive values (the plan in JSON form, outputs, apply results and the generated configuration) are hidden from the output, even with -v or --diff. Set terraform_module_no_log to false when debugging a run.