TFE Docs text/spelling changes
This commit is contained in:
Chris Riley
Seth Vargo
parent
a800616af9
commit
d6a5c027ca
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
layout: "artifacts"
|
||||
page_title: "Artifact Provider"
|
||||
sidebar_current: "docs-enterprise-Provider"
|
||||
sidebar_current: "docs-enterprise-artifact-provider"
|
||||
description: |-
|
||||
Terraform has a provider for managing Atlas artifacts called `atlas_artifact`.
|
||||
Terraform has a provider for managing artifacts called `atlas_artifact`.
|
||||
---
|
||||
|
||||
# Artifact Provider
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: "artifacts"
|
||||
page_title: "Creating AMI Artifacts"
|
||||
sidebar_current: "docs-enterprise-amis"
|
||||
sidebar_current: "docs-enterprise-artifact-amis"
|
||||
description: |-
|
||||
Creating AMI Artifacts with Packer.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: |-
|
|||
Terraform Enterprise can be used to store artifacts for use by Terraform. Typically, artifacts are stored with Packer.
|
||||
---
|
||||
|
||||
# About Terraform Artifacts in Atlas
|
||||
# About Terraform Artifacts
|
||||
|
||||
Terraform Enterprise can be used to store artifacts for use by Terraform. Typically,
|
||||
artifacts are [stored with Packer](https://packer.io/docs).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: "artifacts"
|
||||
page_title: "Managing Artifact Versions"
|
||||
sidebar_current: "docs-enterprise-Provider"
|
||||
sidebar_current: "docs-enterprise-artifact-versions"
|
||||
description: |-
|
||||
Artifacts are versioned and assigned a version number, here is how to manage the versions.
|
||||
---
|
||||
|
|
@ -12,7 +12,7 @@ Artifacts stored in Terraform Enterprise are versioned and assigned a version nu
|
|||
Versions are useful to roll back, audit and deploy images specific versions
|
||||
of images to certain environments in a targeted way.
|
||||
|
||||
This assumes you are familiar with the [Atlas artifact provider](https://terraform.io/docs/providers/atlas/index.html)
|
||||
This assumes you are familiar with the [artifact provider](https://terraform.io/docs/providers/atlas/index.html)
|
||||
in Terraform.
|
||||
|
||||
### Finding the Version of an Artifact
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: |-
|
|||
|
||||
# Terraform Enterprise Features
|
||||
|
||||
[Terraform](https://www.hashicorp.com/products/terraform/) is a tool for safely and
|
||||
[Terraform Enterprise](https://www.hashicorp.com/products/terraform/) is a tool for safely and
|
||||
efficiently changing infrastructure across providers.
|
||||
|
||||
This is a list of features specific to Terraform Enterprise.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ description: |-
|
|||
</div>
|
||||
</div>
|
||||
|
||||
Atlas can optionally automatically apply successful Terraform plans to your
|
||||
You can automatically apply successful Terraform plans to your
|
||||
infrastructure. This option is disabled by default and can be enabled by an
|
||||
organization owner on a per-environment basis.
|
||||
|
||||
|
|
@ -28,7 +28,6 @@ organization owner on a per-environment basis.
|
|||
|
||||
## Enabling Auto-Apply
|
||||
|
||||
To enable auto-apply for an environment, visit the environment settings page in
|
||||
Atlas and check the box labeled "auto apply" and click the save button to
|
||||
To enable auto-apply for an environment, visit the environment settings page check the box labeled "auto apply" and click the save button to
|
||||
persist the changes. The next successful Terraform plan for the environment will
|
||||
automatically apply without user confirmation.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ runs.
|
|||
## Steps of Execution
|
||||
|
||||
1. A set of Terraform configuration and directory of files is uploaded via Terraform Push or GitHub
|
||||
2. Atlas creates a version of the Terraform configuration and waits for the upload
|
||||
2. Terraform Enterprise creates a version of the Terraform configuration and waits for the upload
|
||||
to complete. At this point, the version will be visible in the UI even if the upload has
|
||||
not completed
|
||||
3. Once the upload finishes, Terraform Enterprise creates a run and queues a `terraform plan`
|
||||
|
|
@ -48,12 +48,11 @@ 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.
|
||||
To customize the directory for your Environment, set the _Terraform Directory_
|
||||
property in the _GitHub Integration_ settings for your environment. This is equivalent to
|
||||
property in the [_GitHub Integration_](/docs/enterprise/vcs/github.html) settings for your environment. This is equivalent to
|
||||
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
|
||||
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#environment-variables)
|
||||
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)
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Terraform plans and applies below.
|
|||
During the plan phase of a run, the command `terraform plan` is executed.
|
||||
Terraform performs a refresh and then determines what actions are necessary to
|
||||
reach the desired state specified in the Terraform configuration files. A
|
||||
successful plan outputs an executable file that is securely stored in Atlas
|
||||
successful plan outputs an executable file that is securely stored in Terrafrom Enterprise
|
||||
and may be used in the subsequent apply.
|
||||
|
||||
Terraform plans do not change the state of infrastructure, so it is
|
||||
|
|
@ -45,9 +45,9 @@ While Terraform plans are safe to run multiple times, Terraform applies often
|
|||
change active infrastructure. Because of this, the default behavior
|
||||
is to require user confirmation as part of the
|
||||
[Terraform run execution](/docs/enterprise/runs/how-runs-execute.html). Upon
|
||||
user confirmation, Atlas will queue and execute the Terraform apply. It is also
|
||||
possible to configure Atlas to
|
||||
[automatically apply](/docs/enterprise/runs/automatic-applies.html), but this option is
|
||||
user confirmation, the Terraform apply will be queued and executed. It is also
|
||||
possible to configure
|
||||
[automatic applies](/docs/enterprise/runs/automatic-applies.html), but this option is
|
||||
disabled by default.
|
||||
|
||||
## Environment Locking
|
||||
|
|
|
|||
|
|
@ -37,6 +37,6 @@ persist the changes. An initial plan may immediately run, depending
|
|||
on the state of your environment, and then will automatically
|
||||
plan at the specified interval.
|
||||
|
||||
If you have manually run a plan separately, Atlas will not queue a new
|
||||
plan until the alloted time after the manual plan ran. This means that
|
||||
Atlas simply ensures that a plan has been executed at the specified schedule.
|
||||
If you have manually run a plan separately, a new
|
||||
plan will not be queued until the allotted time after the manual plan ran. This means that
|
||||
the platform simply ensures that a plan has been executed at the specified schedule.
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ description: |-
|
|||
---
|
||||
|
||||
|
||||
# Starting Terraform Runs in Atlas
|
||||
# Starting Terraform Runs
|
||||
|
||||
There are a variety of ways to queue a Terraform run in Atlas. In addition to
|
||||
`terraform push`, you can connect your [environment](/help/glossary#environment)
|
||||
to GitHub and have Atlas queue Terraform runs based on new commits. Atlas can
|
||||
There are a variety of ways to queue a Terraform run in Terraform Enterprise. In addition to
|
||||
`terraform push`, you can connect your environment
|
||||
to GitHub and runs based on new commits. You can
|
||||
also intelligently queue new runs when linked artifacts are uploaded or changed.
|
||||
Remember from the [previous section about Terraform runs](/help/terraform/runs)
|
||||
Remember from the [previous section about Terraform runs](/docs/enterprise/runs)
|
||||
that it is safe to trigger many plans without consequence since Terraform plans
|
||||
do not change infrastructure.
|
||||
|
||||
|
|
@ -21,8 +21,8 @@ do not change infrastructure.
|
|||
## Terraform Push
|
||||
|
||||
Terraform `push` is a [Terraform command](https://terraform.io/docs/commands/push.html)
|
||||
that packages and uploads a set of Terraform configuration and directory to Atlas. This then creates a run
|
||||
in Atlas, which performs `terraform plan` and `terraform apply` against the uploaded
|
||||
that packages and uploads a set of Terraform configuration and directory to the platform. This then creates a run
|
||||
which performs `terraform plan` and `terraform apply` against the uploaded
|
||||
configuration.
|
||||
|
||||
The directory is included in order to run any associated provisioners,
|
||||
|
|
@ -32,8 +32,8 @@ that executes a shell script.
|
|||
By default, everything in your directory is uploaded as part of the push.
|
||||
|
||||
However, it's not always the case that the entire directory should be uploaded. Often,
|
||||
temporary or cache directories and files like `.git`, `.tmp` will be included by default. This
|
||||
can cause Atlas to fail at certain sizes and should be avoided. You can
|
||||
temporary or cache directories and files like `.git`, `.tmp` will be included by default, which
|
||||
can cause failures at certain sizes and should be avoided. You can
|
||||
specify [exclusions](https://terraform.io/docs/commands/push.html) to avoid this situation.
|
||||
|
||||
Terraform also allows for a [VCS option](https://terraform.io/docs/commands/push.html#_vcs_true)
|
||||
|
|
@ -46,14 +46,14 @@ basically does a `git ls-files`.
|
|||
|
||||
Optionally, GitHub can be used to import Terraform configuration. When used
|
||||
within an organization, this can be extremely valuable for keeping differences
|
||||
in environments and last mile changes from occurring before an upload to Atlas.
|
||||
in environments and last mile changes from occurring before an upload.
|
||||
|
||||
After you have [connected your GitHub account to Atlas](/settings/connections),
|
||||
you can connect your [environment](/help/glossary#environment) to the target
|
||||
GitHub repository. The GitHub repository will be linked to the Atlas Terraform
|
||||
configuration, and GitHub will start sending webhooks to Atlas. Certain
|
||||
After you have [connected your GitHub account to Terraform Enterprise](/docs/enterprise/vcs/github.html),
|
||||
you can connect your environment to the target
|
||||
GitHub repository. The GitHub repository will be linked to the Terraform Enterprise
|
||||
configuration, and GitHub will start sending webhooks. Certain
|
||||
GitHub webhook events, detailed below, will cause the repository to be
|
||||
automatically ingressed into Atlas and stored, along with references to the
|
||||
automatically ingressed into Terraform and stored, along with references to the
|
||||
GitHub commits and authorship information.
|
||||
|
||||
Currently, an environment must already exist to be connected to GitHub. You can
|
||||
|
|
@ -75,7 +75,7 @@ Supported GitHub webhook events:
|
|||
- ingress when a tag is created
|
||||
- ingress when the default branch is updated
|
||||
- note: the default branch is either configured on your configuration's
|
||||
integrations tab in Atlas, or if that is blank it is the GitHub
|
||||
integrations tab, or if that is blank it is the GitHub
|
||||
repository's default branch
|
||||
- create (off by default)
|
||||
- ingress when a tag is created
|
||||
|
|
@ -84,35 +84,32 @@ Supported GitHub webhook events:
|
|||
|
||||
## Artifact Uploads
|
||||
|
||||
Upon successful completion of a Terraform run, Atlas parses the remote state and
|
||||
detects any [Atlas artifacts](/help/terraform/artifacts/artifact-provider) that
|
||||
were referenced. When new versions of those referenced artifacts are uploaded
|
||||
to Atlas, you have the option to automatically queue a new Terraform run.
|
||||
Upon successful completion of a Terraform run,the remote state is parsed and
|
||||
any [artifacts](/docs/enterprise/artifacts/artifact-provider.html) are detected that
|
||||
were referenced. When new versions of those referenced artifacts are uploaded, you have the option to automatically queue a new Terraform run.
|
||||
|
||||
For example, consider the following Terraform configuration which references an
|
||||
Atlas artifact named "worker":
|
||||
artifact named "worker":
|
||||
|
||||
resource "aws_instance" "worker" {
|
||||
ami = "${atlas_artifact.worker.metadata_full.region-us-east-1}"
|
||||
instance_type = "m1.small"
|
||||
}
|
||||
|
||||
When a new version of the Atlas artifact "worker" is uploaded either manually
|
||||
or as the output of a [Packer build](/help/packer/builds/starting.html), Atlas
|
||||
can automatically trigger a Terraform plan with this new artifact version.
|
||||
When a new version of the and artifact "worker" is uploaded either manually
|
||||
or as the output of a [Packer build](https://atlas.hashicorp.com/help/packer/builds/starting), a Terraform plan can be automatically triggered with this new artifact version.
|
||||
You can enable this feature on a per-environment basis from the
|
||||
[environment](/help/glossary#environment) settings page in Atlas.
|
||||
environment settings page.
|
||||
|
||||
Combined with
|
||||
[Terraform auto apply](/help/terraform/runs/automatic-applies), you can
|
||||
continuously deliver infrastructure using Terraform and Atlas.
|
||||
[Terraform auto apply](/docs/enterprise/runs/automatic-applies.html), you can
|
||||
continuously deliver infrastructure using Terraform and Terraform Enterprise.
|
||||
|
||||
## Terraform Plugins
|
||||
|
||||
If you are using a custom [Terraform Plugin](https://www.terraform.io/docs/plugins/index.html)
|
||||
binary for a provider or provisioner that's not currently in a released
|
||||
version of Terraform, you can still use this in Atlas.
|
||||
version of Terraform, you can still use this in Terraform Enterprise.
|
||||
|
||||
All you need to do is include a Linux AMD64 binary for the plugin in the
|
||||
directory in which Terraform commands are run from; Atlas will then use
|
||||
the plugin the next time you `terraform push` or ingress from GitHub.
|
||||
directory in which Terraform commands are run from; it will then be used next time you `terraform push` or ingress from GitHub.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: "runs"
|
||||
page_title: "Runs: Variables and Configuration"
|
||||
sidebar_current: "docs-enterprise-runs-schedule"
|
||||
sidebar_current: "docs-enterprise-runs-variables"
|
||||
description: |-
|
||||
How to configure runs and their variables.
|
||||
---
|
||||
|
|
@ -18,7 +18,7 @@ define the parameterization of Terraform configurations and are important
|
|||
for sharing and removal of sensitive secrets from version control.
|
||||
|
||||
Variables are sent with the `terraform push` command. Any variables in your local
|
||||
`.tfvars` files are securely uploaded. Once variables are uploaded, Terraform will prefer the Atlas-stored variables over any changes you
|
||||
`.tfvars` files are securely uploaded. Once variables are uploaded, Terraform will prefer the stored variables over any changes you
|
||||
make locally. Please refer to the
|
||||
[Terraform push documentation](https://www.terraform.io/docs/commands/push.html)
|
||||
for more information.
|
||||
|
|
@ -92,7 +92,7 @@ Set the [variables](https://www.terraform.io/docs/configuration/variables.html)
|
|||
}
|
||||
}
|
||||
|
||||
`terraform push` any "Terraform Variables" to Atlas:
|
||||
`terraform push` any "Terraform Variables":
|
||||
|
||||
$ terraform push -name $ATLAS_USERNAME/example -var "private_key=$MY_PRIVATE_KEY"
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: |-
|
|||
|
||||
# Collaborating on Terraform Remote State
|
||||
|
||||
Atlas is one of a few options to store [remote state](/docs/enterprise/state).
|
||||
Terraform Enterprise is one of a few options to store [remote state](/docs/enterprise/state).
|
||||
|
||||
Remote state gives you the ability to version and collaborate on Terraform changes. It
|
||||
stores information about the changes Terraform makes based on configuration.
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@ named `terraform.tfstate`, but it can also be stored remotely, which
|
|||
works better in a team environment.
|
||||
|
||||
Terraform Enterprise is a remote state provider, allowing you to store, version and
|
||||
collaborate on state with Atlas.
|
||||
collaborate on states.
|
||||
|
||||
Remote state gives you more than just easier version control and safer
|
||||
storage. It also allows you to delegate the outputs to other teams.
|
||||
This allows your infrastructure to be more easily broken down into
|
||||
components that multiple teams can access.
|
||||
|
||||
Read [more about remote state](https://www.terraform.io/docs/state/remote/index.html).
|
||||
Read [more about remote state](https://www.terraform.io/docs/state/remote.html).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: "vcs"
|
||||
page_title: "Git Integration"
|
||||
sidebar_current: "docs-enterprise-vcs"
|
||||
sidebar_current: "docs-enterprise-vcs-git"
|
||||
description: |-
|
||||
Git repositories can be integrated with Terraform Enterprise by using push command.
|
||||
---
|
||||
|
|
@ -14,7 +14,7 @@ Terraform configuration when changes are committed. When Terraform
|
|||
configuration is imported using `terraform push` a plan is automatically queued.
|
||||
|
||||
_**Note:** This integration is for Git repositories **not** hosted on GitHub.
|
||||
For repositories on GitHub, there is native [GitHub Integration](/help/terraform/vcs/github).
|
||||
For repositories on GitHub, there is native [GitHub Integration](/docs/enterprise/vcs/github.html).
|
||||
|
||||
## Setup
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ repository, set the necessary variables, and ensure the script is executable.
|
|||
# An example hook script to push Terraform configuration to Terraform Enterprise.
|
||||
#
|
||||
# Set the following variables for your project:
|
||||
# - ENV_NAME - your Atlas environment name (e.g. org/env)
|
||||
# - ENV_NAME - your environment name (e.g. org/env)
|
||||
# - TERRAFORM_DIR - the local directory to push
|
||||
# - DEFAULT_BRANCH - the branch to push. Other branches will be ignored.
|
||||
|
||||
|
|
@ -58,10 +58,10 @@ fi
|
|||
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
|
||||
|
||||
if [ "$current_branch" == "$DEFAULT_BRANCH" ]; then
|
||||
echo "pre-push hook: Pushing branch [$current_branch] to Atlas environment [$ENV_NAME]."
|
||||
echo "pre-push hook: Pushing branch [$current_branch] to environment [$ENV_NAME]."
|
||||
terraform push -name="$ENV_NAME" $TERRAFORM_DIR
|
||||
else
|
||||
echo "pre-push hook: NOT pushing branch [$current_branch] to Atlas environment [$ENV_NAME]."
|
||||
echo "pre-push hook: NOT pushing branch [$current_branch] to environment [$ENV_NAME]."
|
||||
fi
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: "vcs"
|
||||
page_title: "GitHub Integration"
|
||||
sidebar_current: "docs-enterprise-vcs"
|
||||
sidebar_current: "docs-enterprise-vcs-github"
|
||||
description: |-
|
||||
GitHub repositories can be integrated with Terraform Enterprise by using push command.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -15,5 +15,5 @@ source control.
|
|||
Different capabilities within Terraform Enterprise are available depending on the integration
|
||||
in use. The available integration options are below.
|
||||
|
||||
- [Git](/docs/enterprise/vcs/git)
|
||||
- [GitHub](/docs/enterprise/vcs/github)
|
||||
- [Git](/docs/enterprise/vcs/git.html)
|
||||
- [GitHub](/docs/enterprise/vcs/github.html)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
</li>
|
||||
|
||||
<li<%= sidebar_current(/^docs-enterprise-artifact-/) %>>
|
||||
<a href="/docs/enterprise/artifact/index.html">Artifact</a>
|
||||
<a href="/docs/enterprise/artifacts/index.html">Artifact</a>
|
||||
<ul class="nav nav-visible">
|
||||
<li<%= sidebar_current("docs-enterprise-artifact-provider") %>>
|
||||
<a href="/docs/enterprise/artifacts/artifact-provider.html">Artifact Provider</a>
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
<li<%= sidebar_current("docs-enterprise-artifact-versions") %>>
|
||||
<a href="/docs/enterprise/artifacts/managing-versions.html">Managing Versions</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-enterprise-artifact-ami") %>>
|
||||
<li<%= sidebar_current("docs-enterprise-artifact-amis") %>>
|
||||
<a href="/docs/enterprise/artifacts/creating-amis.html">Creating AMI Artifacts</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
<li<%= sidebar_current("docs-enterprise-runs-applies") %>>
|
||||
<a href="/docs/enterprise/runs/automatic-applies.html">Automatic Applies</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-enterprise-runs-scheduling") %>>
|
||||
<li<%= sidebar_current("docs-enterprise-runs-schedule") %>>
|
||||
<a href="/docs/enterprise/runs/scheduling-runs.html">Scheduling Runs</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-enterprise-runs-variables") %>>
|
||||
|
|
|
|||
Loading…
Reference in New Issue