-
Notifications
You must be signed in to change notification settings - Fork 21
add arm support docs #558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add arm support docs #558
Changes from all commits
677fb5e
20c883d
726c02a
68d97a1
7dfae9e
52acdbc
1bb6d42
df45b21
450cd1e
67a1409
89bbae8
93f2f05
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,19 +4,19 @@ description: >- | |
Use HCP Terraform agents to manage infrastructure in private networks. Learn how to install, configure, and run agents on your own infrastructure. | ||
--- | ||
|
||
# Install and Run Agents | ||
# Install and run agents | ||
|
||
@include 'agents.mdx' | ||
|
||
The agent software runs on your own infrastructure. The token you provide when starting the agent assigns it to an HCP Terraform [agent pool](/terraform/cloud-docs/agents/agent-pools). | ||
|
||
If you have your Agent pool and token already set up, [start the agent using the official Docker image](/terraform/cloud-docs/agents/agents#run-an-agent-with-docker). | ||
|
||
## Operational Considerations | ||
## Operational considerations | ||
|
||
Agents do not guarantee a clean working environment per Terraform execution. Each execution occurs in its own temporary directory with a clean environment, but references to absolute file paths or other machine state may cause interference between Terraform executions. We strongly recommend that you write your Terraform code to be stateless and idempotent. You may also want to consider using [single-execution mode](#optional-configuration-single-execution-mode) to ensure your agent only runs a single workload. | ||
|
||
### Run Multiple Agents | ||
### Run multiple agents | ||
|
||
You may choose to run multiple agents within your network, up to the organization's purchased agent limit. If there are multiple agents available within an organization, HCP Terraform selects the first available agent within the target pool. | ||
|
||
|
@@ -38,7 +38,7 @@ To customize this update behavior, pass the flag `-auto-update` or set the envir | |
| `patch` | The agent only updates to the newest patch version, new minor versions require a manual update. | | ||
| `disabled` | Disables automatic updates, all updates are manual. | ||
|
||
## Run an Agent with Docker | ||
## Run an agent with Docker | ||
|
||
To start the agent with the official Docker image and connect it to an HCP Terraform agent pool: | ||
|
||
|
@@ -54,7 +54,7 @@ docker run --platform=linux/amd64 -e TFC_AGENT_TOKEN -e TFC_AGENT_NAME hashicorp | |
|
||
Once complete, your agent and its status appear on the **Agents** page in the HCP Terraform UI. Workspaces can now use this agent pool for runs. Refer to [Configure Workspaces to Use the Agent](/terraform/cloud-docs/agents/agent-pools#configure-workspaces-to-use-the-agent) for details. | ||
|
||
## Run an Agent Using the Binary | ||
## Run an agent using the binary | ||
|
||
To download and install the agent: | ||
|
||
|
@@ -75,11 +75,11 @@ export TFC_AGENT_NAME=your-agent-name | |
``` | ||
Once complete, your agent and its status appear on the **Agents** page in the HCP Terraform UI. Workspaces can now use this agent pool for runs. Refer to [Configure Workspaces to Use the Agent](/terraform/cloud-docs/agents/agent-pools#configure-workspaces-to-use-the-agent) for details. | ||
|
||
## Optional Configuration | ||
## Optional configuration | ||
|
||
The optional configurations for customizing the agent include building a custom Docker image that grants sudo privileges for software installation, running in single-execution mode to process a single workload before terminating, and enabling request forwarding for secure access to private resources. | ||
|
||
### Customize the Agent Docker image | ||
### Customize the agent Docker image | ||
|
||
The Docker image executes the `tfc-agent` process as the non-root `tfc-agent` user. For some workflows, you may need to build a customized version of the agent Docker image for your internal use. For example, if your workflow needs to install software using `apt-get` during `local-exec` scripts. | ||
|
||
|
@@ -100,19 +100,19 @@ USER tfc-agent | |
|
||
The above customized Dockerfile lets an agent install additional software using `sudo apt-get`. | ||
|
||
### Single-Execution Mode | ||
### Single-execution mode | ||
|
||
You can also configure the agent to run in single-execution mode, which ensures that the agent only runs a single workload, then terminates. You can use this configuration in combination with Docker and a process supervisor to ensure a clean working environment for every Terraform run. | ||
|
||
To use single-execution mode, start the agent with the `-single` command line argument. | ||
|
||
### Request Forwarding | ||
### Request forwarding | ||
|
||
You can configure the agent to accept forwarded requests from HCP Terraform. Request forwarding enables HCP Terraform to securely access private infrastructure resources, such as private VCS systems. See [Request Forwarding](/terraform/cloud-docs/agents/request-forwarding) for more details. By default, request forwarding is disabled. To enable it, start the agent with the `-request-forwarding` command line argument. | ||
|
||
Agents handle forwarded requests separately from other workloads and may process requests in parallel to plans, applies, policy checks, etc. You can modify this behavior by enabling or disabling certain workload types via the `-accept` parameter, and selectively setting the `-request-forwarding` flag on certain agent(s) only. For example, you may have a pool of 4 agents, where two are configured to handle only plans and applies, and the other two are configured to handle only request forwarding. | ||
|
||
## Stop the Agent | ||
## Stop the agent | ||
|
||
~> **Important:** We strongly recommend that you only terminate the agent using one of these methods. Abruptly terminating an agent by forcefully stopping the process or power cycling the host does not let the agent deregister and results in an **Unknown** agent status. Abrupt termination may cause further capacity issues. Refer to [capacity issues](/terraform/cloud-docs/agents/agent-pools#agent-capacity-usage) for details. | ||
|
||
|
@@ -123,12 +123,64 @@ The agent maintains a registration and a liveness indicator within HCP Terraform | |
|
||
After initiating a graceful shutdown by either of these methods, the terminal user or parent program should wait for the agent to exit. The amount of time this exit takes depends on the agent's current workload. The agent waits for any current operations to complete before deregistering and exiting. | ||
|
||
## Address provider compatibility errors | ||
trujillo-adam marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
If a provider does not support your agent’s architecture, the following error appears in the agent’s TRACE logs, the CLI, or the UI: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Will this error text show up in the agent logs and not just the run logs @natalie-todd? I'd think no, since those provider incompatibility errors are emitted to stdout by the Terraform CLI during There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It shows at a trace level:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Aaah, so we dump the CLI's stdout into the agent logs when logging at trace level, TIL! Cool, I just wanted to make sure we're giving accurate info about detecting provider incompatibility errors. |
||
|
||
```plaintext | ||
Error: Incompatible provider version | ||
|
||
Provider registry.terraform.io/<namespace>/<name_version> does not have a | ||
package available for your current platform, <os_architecture>. | ||
|
||
Provider releases are separate from Terraform CLI releases, so not all | ||
providers are available for all platforms. Other versions of this provider | ||
may have different platforms supported. | ||
``` | ||
|
||
You can call the [Terraform provider registry API](/terraform/internals/provider-registry-protocol#list-available-versions) to confirm the architectures available for a provider. | ||
|
||
Sample request: | ||
|
||
```shell-session | ||
$ curl 'https://registry.terraform.io/v1/providers/hashicorp/random/versions' | ||
``` | ||
|
||
Sample response: | ||
|
||
```json | ||
{ | ||
"versions": [ | ||
{ | ||
"version": "2.0.0", | ||
"protocols": ["4.0", "5.1"], | ||
"platforms": [ | ||
{"os": "darwin", "arch": "amd64"}, | ||
{"os": "linux", "arch": "amd64"}, | ||
{"os": "linux", "arch": "arm"}, | ||
{"os": "windows", "arch": "amd64"} | ||
] | ||
}, | ||
{ | ||
"version": "2.0.1", | ||
"protocols": ["5.2"], | ||
"platforms": [ | ||
{"os": "darwin", "arch": "amd64"}, | ||
{"os": "linux", "arch": "amd64"}, | ||
{"os": "linux", "arch": "arm"}, | ||
{"os": "windows", "arch": "amd64"} | ||
] | ||
} | ||
] | ||
} | ||
``` | ||
|
||
<!-- | ||
WARNING: This the CLI options section is auto-generated during agent release process. | ||
Do not edit this section directly as your changes will be overwritten. | ||
--> | ||
|
||
# CLI Options | ||
# CLI options | ||
|
||
|
||
* `-name <name>`: | ||
|
Uh oh!
There was an error while loading. Please reload this page.