terraform/website/source/docs/enterprise/runs/how-runs-execute.html.md

59 lines
3.0 KiB
Markdown
Raw Normal View History

2017-03-16 20:42:33 +01:00
---
2017-03-17 20:24:20 +01:00
layout: "runs"
page_title: "Runs: How Runs Execute"
sidebar_current: "docs-enterprise-runs-execute"
description: |-
How runs execute in Terraform Enterprise.
2017-03-16 20:42:33 +01:00
---
2017-03-17 20:24:20 +01:00
# How Terraform Runs Execute
2017-03-16 20:42:33 +01:00
This briefly covers the internal process of running Terraform plan and
2017-03-17 20:24:20 +01:00
applies. It is not necessary to know this information, but may be
valuable to help understand implications of running or debugging failed
2017-03-16 20:42:33 +01:00
runs.
## Steps of Execution
1. A set of Terraform configuration and directory of files is uploaded via Terraform Push or GitHub
2017-03-20 19:44:03 +01:00
2. Terraform Enterprise creates a version of the Terraform configuration and waits for the upload
2017-03-16 20:42:33 +01:00
to complete. At this point, the version will be visible in the UI even if the upload has
not completed
2017-03-17 20:24:20 +01:00
3. Once the upload finishes, Terraform Enterprise creates a run and queues a `terraform plan`
4. In the run environment, the package including the files and Terraform
2017-03-16 20:42:33 +01:00
configuration are downloaded
2017-03-17 20:24:20 +01:00
5. `terraform plan` is run against the configuration in the run environment
6. Logs are streamed into the UI and stored
7. The `.tfplan` file created in the plan is uploaded and stored
8. Once the plan completes, the environment is torn down and status is
2017-03-16 20:42:33 +01:00
updated in the UI
2017-03-17 20:24:20 +01:00
9. The plan then requires confirmation by an operator. It can optionally
2017-03-16 20:42:33 +01:00
be discarded and ignored at this stage
2017-03-17 20:24:20 +01:00
10. Once confirmed, the run then executes a `terraform apply` in a new
2017-03-16 20:42:33 +01:00
environment against the saved `.tfplan` file
2017-03-17 20:24:20 +01:00
11. The logs are streamed into the UI and stored
12. Once the apply completes, the environment is torn down, status is
updated in the UI and changed state is saved back
2017-03-16 20:42:33 +01:00
Note: In the case of a failed apply, it's safe to re-run. This is possible
because Terraform saves partial state and can "pick up where it left off".
### Customizing Terraform Execution
2017-03-17 20:24:20 +01:00
As described in the steps above, Terraform will be run against your configuration
2017-03-16 20:42:33 +01:00
when changes are pushed via GitHub, `terraform push`, or manually queued in the
2017-03-17 20:24:20 +01:00
UI. There are a few options available to customize the execution of Terraform.
2017-03-16 20:42:33 +01:00
These are:
- The directory that contains your environment's Terraform configuration can be customized
to support directory structures with more than one set of Terraform configuration files.
2017-03-17 20:24:20 +01:00
To customize the directory for your Environment, set the _Terraform Directory_
2017-03-20 19:44:03 +01:00
property in the [_GitHub Integration_](/docs/enterprise/vcs/github.html) settings for your environment. This is equivalent to
2017-03-16 20:42:33 +01:00
passing the `[dir]` argument when running Terraform in your local shell.
- The directory in which Terraform is executed from can be customized to support directory
structures with nested sub-directories or configurations that use Terraform modules with
2017-03-20 19:44:03 +01:00
relative paths. To customize the directory used for Terraform execution in your Environment, set the `TF_ATLAS_DIR`
[environment variable](/docs/enterprise/runs/variables-and-configuration.html#environment-variables)
2017-03-16 20:42:33 +01:00
to the relative path of the directory - ie. `terraform/production`. This is equivalent to
changing directories to the appropriate path in your local shell and then executing Terraform.