Chapter 1. Terraform integration


1.1. About the Terraform integration

Learn about the supported integrations between IBM HashiCorp products and Red Hat Ansible Automation Platform, the integration workflows, and migration paths to help determine the best options for your environment.

1.1.1. Introduction

Many organizations find themselves using both Ansible Automation Platform and Terraform Enterprise or HCP Terraform, recognizing that these can work in harmony to create an improved experience for developers and operations teams. While Terraform Enterprise and HCP Terraform excel at Infrastructure as Code (IaC) for provisioning and de-provisioning cloud resources, Ansible Automation Platform is a versatile, all-purpose automation solution ideal for configuration management, application deployment, and orchestrating complex IT workflows across diverse domains.

This integration directly addresses common challenges such as managing disparate automation tools, ensuring consistent configuration across hybrid cloud environments and accelerating deployment cycles. By bringing together Terraform’s declarative approach to infrastructure provisioning with Ansible Automation Platform’s procedural approach to configuration and orchestration, users can achieve:

  • Optimized costs: Reduce cloud waste, minimize manual processes, and combat tool sprawl. This integration can lead to a significant reduction in infrastructure costs and a high return on investment.
  • Reduced risk: Lower the risk of breaches, enforce policies, and significantly decrease unplanned downtime. The ability to review Terraform plan output before applying it in a workflow, with approval steps, enhances security and compliance.
  • Faster time to value: Boost developer productivity and deploy new compute resources more rapidly, leading to a faster time to market. This is achieved through unified lifecycle management and automation for Day 0 (provisioning), Day 1 (configuration), and Day 2 (ongoing management) operations.

By enabling direct calls between Ansible Automation Platform and Terraform Enterprise or HCP Terraform, organizations can unlock time to value by creating combined workflows, reduce risk through enhanced product integrations, and enhance Infrastructure-as-Code with Ansible Automation Platform content and practices. This allows for unified lifecycle management, enabling tasks from initial provisioning and configuration to ongoing health checks, incident response, patching, and infrastructure optimization.

1.1.2. Integration workflows

Depending on your existing setup, you can integrate these products from Ansible Automation Platform or from Terraform. Migration paths are provided for community users and for migrating from the cloud.terraform collection to hashicorp.terraform.

1.1.2.1. Ansible-initiated workflow

Ansible automation hub collections allow Ansible Automation Platform users to leverage the Terraform Enterprise or HCP Terraform provisioning capabilities.

hashicorp.terraform collection

This collection provides API integration between Ansible Automation Platform and Terraform Enterprise or HCP Terraform. This solution works natively with Ansible Automation Platform and reduces setup complexity because it doesn’t require a binary installation and it includes a default execution environment.

cloud.terraform collection

This collection provides CLI integration between Ansible Automation Platform and Terraform Enterprise or HCP Terraform. To use this collection, you must install a binary and create an execution environment.

Although this collection is supported, we recommend using the hashicorp.terraform collection instead to take advantage of its API capabilities.

1.1.2.2. Migration workflows

Community edition users can migrate to Terraform Enterprise or HCP Terraform, and then integrate the Ansible Automation Platform capabilities using the cloud.terraform (CLI) collection. However, we recommend using the hashicorp.terraform (API) collection instead.

If you are already using the cloud.terraform collection, you can migrate to hashicorp.terraform.

1.1.2.3. Terraform-initiated workflow

For existing Terraform Enterprise or HCP Terraform users, Terraform can directly call Ansible Automation Platform at the end of provisioning for a more seamless and secure workflow. This enables Terraform Enterprise or HCP Terraform users to enhance their immutable infrastructure automation with Ansible Automation Platform Day 2 automation capabilities and manage infrastructure updates and lifecycle events.

1.2. Integrating from Ansible Automation Platform

As an administrator, you configure the integration from Ansible Automation Platform user interface. Use the procedures related to the collection you have installed.

1.2.1. Authenticating to hashicorp.terraform

After installing or migrating to hashicorp.terraform, administrators configure a custom credential type in the Ansible Automation Platform user interface to authenticate to Terraform Enterprise or HCP Terraform. Then users must create credentials (based on the credential type) to use with job templates in Ansible Automation Platform.

1.2.1.1. Creating a custom credential type

Administrators set up a custom credential type to facilitate authentication between Ansible Automation Platform and Terraform Enterprise or HCP Terraform. This preparation helps ensure that credentials are provided automatically to the execution environment, eliminating the need to update playbooks manually.

Additionally, you can configure a custom credential for Vault to leverage the advanced features of Terraform Enterprise or HCP Terraform and Vault with Ansible Automation Platform.

Prerequisites

  • You must have a Terraform API token.
  • Install the certified hashicorp.terraform collection from automation hub. (You need an Ansible subscription to access and download collections on automation hub.)

Procedure

  1. Log in to Ansible Automation Platform.
  2. From the navigation panel, select Automation Execution Infrastructure Credential Types.
  3. Click Create credential type. The Create Credential Type page opens and displays the Details tab.
  4. For the Name field, enter a credential type name.
  5. In the Input configuration field, enter the following parameters and values:

    fields:
      - id: token
        type: string
        label: token
        secret: true
    Copy to Clipboard Toggle word wrap
  6. In the Injector configuration field, enter the following configuration:

    env:
      TF_TOKEN:  ‘{{ token }}’
    Copy to Clipboard Toggle word wrap
  7. To save your configuration, click Create Credential Type again. The new credential type is created.

1.2.1.2. Creating a credential

Users must create a credential to use with job templates in Ansible Automation Platform.

Prerequisite

  • You must have a Terraform API token.
  • Your administrator has created a custom credential type.

Procedure

  1. Log in to Ansible Automation Platform.
  2. From the navigation panel, select Automation Execution Infrastructure Credentials, and then select Create credential.
  3. From the Credential type list, select the credential type. The fields that display depend on the credential type.
  4. In the Token field, enter the Terraform API token.
  5. (Optional) Edit the Description field and select the TF organization from the Organization list.
  6. Click Save credential. You are ready to use the credential in a job template.

1.2.2. Integrating with cloud.terraform

When you integrate with cloud.terraform, you must create a credential, build an execution environment, and launch a job template in Ansible Automation Platform.

1.2.2.1. Creating a credential

You can set up credentials directly from the Ansible Automation Platform user interface. The credentials are provided to the execution environment and Ansible Automation Platform reads them from there. This eliminates the need to manually update each playbook.

Prerequisites

  • You must have a Terraform API token.
  • Install the certified cloud.terraform collection from automation hub. (You need an Ansible subscription to access and download collections on automation hub.)

Procedure

  1. Log in to Ansible Automation Platform.
  2. From the navigation panel, select Automation Execution Infrastructure Credential Types.
  3. Click Create credential type. The Create Credential Type page opens and displays the Details tab.
  4. For the Credential Type, enter a name.
  5. In the Input configuration field, enter the following YAML parameter and values:

    fields:
       - id: token
         type: string
         label: token
         secret: true
    Copy to Clipboard Toggle word wrap
  6. In the Injector configuration field, enter the following configuration.

    • For Terraform Enterprise, the hostname is the location where you have deployed TFE:

      env:
        TF_TOKEN_<hostname>:  ‘{{ token }}’
      Copy to Clipboard Toggle word wrap
    • For HCP Terraform, use:

      env:
        TF_TOKEN_app_terraform_io:   ‘{{ token }}’
      Copy to Clipboard Toggle word wrap
  7. To save your configuration, click Create Credential Type again. The new credential type is created.
  8. To create an instance of your new credential type, select Automation Execution Infrastructure Credentials page, and select Create credential.
  9. From the Credential type, select the name of the credential type you created earlier.
  10. In the Token field, enter the Terraform API token.
  11. (Optional) Edit the Description and select the TF organization from the Organization list.
  12. Click Save credential.

Additional resources

1.2.2.2. Building an execution environment in Ansible Automation Platform

You must build an execution environment using the automation controller so that Ansible Automation Platform can provide the credentials necessary for using its automation features.

Prerequisites

  • You need a pre-existing execution environment with the latest version of cloud.terraform collection before you can create it using an automation controller. You cannot use the default execution environment provided by Ansible Automation Platform because the default environment does not include the terraform CLI binary.

    Note

    If you have migrated from Terraform Community Edition, you can continue to use your existing execution environment and update it to the latest version of cloud.terraform.

  • Install the terraform CLI binary in your pre-existing execution environment. See Additional resources below for a link to the binary.

Procedure

  1. From the navigation panel, select Automation Execution Infrastructure Execution Environments.
  2. Click Create execution environment.

  3. For Name, enter a name for your Ansible Automation Platform execution environment.
  4. For Image, enter the repository link to the image for your pre-existing execution environment.
  5. Click Create execution environment. Your newly added execution environment is ready to be used in a job template.

1.2.2.3. Creating and launching a job template

Create and launch a job template to complete the integration and use the automation features in Ansible Automation Platform.

Procedure

  1. From the navigation panel, select Automation Execution Templates.
  2. Select Create template > Create Job Template.
  3. From the Execution Environment list, select the environment you created.
  4. From the Credentials list, select the credentials instance you created previously. If you do not see the credentials, select Browse to see more options in the list.
  5. Enter any additional information for the required fields.
  6. Click Create job template.
  7. Click Launch template.
  8. To launch the job, click Next and Finish. The job output shows that the job has run.

Verification

To see that the job has run successfully from the Terraform user interface, select Workspaces > Ansible-Content-Integration > Run. The Run list shows the state of the Triggered via CLI job. You can see it go from the Queued to the Plan Finished state.

1.3. Migrating from other versions

Migrate from earlier collections or community editions to use the most advanced features of the HashiCorp and Ansible Automation Platform integrations.

1.3.1. Migrating from cloud.terraform to hashicorp.terraform

If you are using the existing cloud.terraform (CLI-based) collection, you can migrate your existing playbooks to the hashicorp.terraform (API-based) collection. The API solution works natively with Ansible Automation Platform and reduces setup complexity. The main modules for hashicorp.terraform that you must configure are hashicorp.terraform.configuration_version and hashicorp.terraform.run.

1.3.1.1. Configuring the hashicorp.terraform.configuration_version module

To migrate to the hashicorp.terraform collection, you must configure the hashicorp.terraform.configuration_version module. This module manages configuration versions in Terraform Enterprise or HCP Terraform.

Prerequisites

  • Install the Ansible Automation Platform certified hashicorp.terraform collection.
  • Verify that a valid organization and workspace are correctly set up in Terraform Enterprise or HCP Terraform.

Procedure

  1. Replicate your automation tasks from the cloud.terraform modules.

    Example

    - name: Create configuration version with auto_queue_runs to false
      hashicorp.terraform.configuration_version:
       workspace_id: ws-1234
       configuration_files_path: "/usr/home/tf"
       auto_queue_runs: false
       tf_validate_certs: true
       poll_interval: 3
       poll_timeout: 15
       state: present
    Copy to Clipboard Toggle word wrap
  2. Configure the following required parameters:

    • workspace_id or workspace + organization: The workspace ID or the workspace name and organization where the configuration version will be created and the file will be uploaded (for state: present).
    • configuration_files_path: The path where the required Terraform Enterprise or HCP Terraform files will be uploaded to create a configuration version (for state: present). The module accepts two file types for configuration_files_path:

      • Directory: Any folder containing Terraform Enterprise or HCP Terraform files. The module auto-creates the .tar.gz file from all contents recursively.
      • .tar.gz Archive: Pre-compressed gzip tarball. The module validates TAR format and gzip compression.
    • configuration_version_id: The configuration version ID that will be archived (state: archived). This action deletes the associated uploaded .tar.gz file. Note the following:

      • Only uploaded versions that were created using the API or CLI, have no active runs, and are not the current version for any workspace can be archived.
      • When the configuration_version_id is unspecified, Terraform Enterprise or HCP Terraform selects the latest approved configuration_version_id in the workspace.
    • auto_queue_runs: Determines if Terraform Enterprise or HCP Terraform automatically starts a run after the configuration upload (true by default) or requires manual initiation (false).
  3. Set additional optional parameters as needed.

1.3.1.2. Configuring the hashicorp.terraform.run module

The hashicorp.terraform.run module lets you manage Terraform Enterprise or HCP Terraform runs using create, apply, cancel, and discard operations. You can trigger plans or apply operations on specified workspaces with customizable settings.

Prerequisites

  • Ensure that a valid Terraform API token is properly configured to authenticate with your Terraform Enterprise or HCP Terraform environment.
  • Verify that a valid organization and workspace are correctly set up in Terraform Enterprise or HCP Terraform.

Procedure

  1. Create a run module.

    Example

    - name: Create a destroy run with auto_apply
      hashicorp.terraform.run:
      workspace_id: ws-1234
      run_message: "destroy vpc"
      state: "present"
      tf_token: <your token>
      is_destroy: true
      auto_apply: true
      target_addrs:
        - "aws_vpc.vpc1"
        - "aws_vpc.vpc2"
      poll: true
      poll_interval: 10
      poll_timeout: 30
    Copy to Clipboard Toggle word wrap
  2. Configure the following required parameters:

    • workspace_id or workspace + organization: The workspace ID or the workspace name and organization where the configuration version will be created and the file will be uploaded (for state: present).
    • run_id: The unique identifier of the run to apply, cancel, or discard operations.
    • tf_token: The Terraform API authentication token. If this value is not set, the TF_TOKEN environment variable is used.
  3. (Optional) Configure the built-in polling options that determine the wait period for Terraform Enterprise or HCP Terraform operations to complete:

    • poll: true: (Default) Checks the run status every poll_interval seconds (default: 5s) until completion or poll_timeout (default: 25s) is reached, returning the final status.
    • poll: false: Returns immediately after initiating the run without waiting.
  4. Set additional optional parameters as needed.

1.3.1.3. Migration examples for hashicorp.terraform modules

These before and after examples help users understand how the modules can be configured in a real world environment.

1.3.1.3.1. Example 1: Plan Only
  • Before (cloud.terraform.terraform):
- name: Create a plan file using check mode
  cloud.terraform.terraform:
   force_init: true
   project_path: "/usr/home/tf"
   plan_file: "/usr/home/tf/terraform.tfplan"
   state: present
   check_mode: true
   check_destroy: true
   variables:
     environment: prod
Copy to Clipboard Toggle word wrap
  • After (hashicorp.terraform.*):

    • The configuration_version module:

      - name: Create configuration version with auto_queue_runs to false
        hashicorp.terraform.configuration_version:
         workspace_id: ws-1234
         configuration_files_path: "usr/home/tf_files"
         auto_queue_runs: false
         tf_validate_certs: true
         poll_interval: 5
         poll_timeout: 10
         state: present
      Copy to Clipboard Toggle word wrap
    • The plan_only run with the run module:

      - name: Create a plan only run with variables
        hashicorp.terraform.run:
         workspace_id: ws-1234
         run_message: "plan-only vpc creation"
         poll: false
         state: "present"
         tf_token: "{{ tfc_token }}"
         plan_only: true
         variables:
          - key: "env"
            value: "production"
      Copy to Clipboard Toggle word wrap
1.3.1.3.2. Example 2: Plan and apply
  • Before (cloud.terraform.terraform):

    1. Generate the plan:

      - name: Plan and Apply Workflow - Step 1 - Generate Plan
        cloud.terraform.terraform:
         force_init: true
         project_path: "/usr/home/tf"
         plan_file: "/usr/home/tf/workflow.tfplan"
         state: present
         check_mode: true
         variables:
           environment: prod
      Copy to Clipboard Toggle word wrap
    2. Apply the plan:

      - name: Plan and Apply Workflow - Step 2 - Apply Plan
        cloud.terraform.terraform:
         project_path:  "/usr/home/tf"
         plan_file: "/usr/home/tf/workflow.tfplan"
         state: present
      Copy to Clipboard Toggle word wrap
  • After (hashicorp.terraform.run):

    1. The configuration_version module:

      - name: Create configuration version with auto_queue_runs to false
        hashicorp.terraform.configuration_version:
         workspace_id: ws-1234
         configuration_files_path: "usr/home/tf_files"
         auto_queue_runs: false
         tf_validate_certs: true
         poll_interval: 5
         poll_timeout: 10
         state: present
      Copy to Clipboard Toggle word wrap
    2. The run module with two options for plan and apply workflow:
  • Option 1: Uses the auto_apply parameter to handle both the plan and apply workflows:

    - name: Create a run with auto_apply
      hashicorp.terraform.run:
       workspace_id: ws-1234
       run_message: "destroy vpc"
       state: "present"
       tf_token: "{{ tfc_token }}"
       auto_apply: true
       poll: true
       poll_interval: 10
       poll_timeout: 30
    Copy to Clipboard Toggle word wrap
  • Option 2: Uses two sub-steps to create a save_plan run and then apply it:

    1. Create the plan:

      - name: Create a save plan run
        hashicorp.terraform.run:
         workspace_id: ws-1234
         run_message: "save plan vpc creation"
         state: "present"
         tf_token: "{{ tfc_token }}"
         poll: true
         poll_interval: 10
         poll_timeout: 30
         save_plan: true
      Copy to Clipboard Toggle word wrap
    2. Apply the plan. You get the run_id from the output of the run module task:

      - name: Apply the save plan run
        hashicorp.terraform.run:
         run_id: run-1234
         state: "applied"
         tf_token: "{{ tfc_token }}"
         poll: true
         poll_interval: 10
         poll_timeout: 30
      Copy to Clipboard Toggle word wrap

1.3.2. Migrating from Terraform Community Edition

If you want to use Ansible Automation Platform with Terraform Enterprise (TFE) or HCP Terraform and you are currently using Terraform Community Edition (TCE), you must:

  • Migrate to TFE or HCP Terraform.
  • Update Ansible Automation Platform configurations to work with TFE or HCP Terraform.

1.3.2.1. Migrating from the community edition

When you migrate from TCE to TFE or HCP Terraform, you are not migrating the collection itself. Instead, you are adapting your existing TCE usage to work with TFE or HCP Terraform. After you migrate, you must update the Ansible Automation Platform credentials, execution environment, and job templates.

Note

The cloud.terraform collection only supports the CLI-driven workflow in HCP Terraform.

Prerequisites

  • Use the latest supported version of Terraform (1.11 or higher).
  • Follow the tf-migrate CLI instructions under Additional resources below.
  • Ensure that the HCP Terraform or TFE workspace is not set to automatically apply plans.

Procedure

  1. To prevent errors when running playbooks against TFE or HCP Terraform, do the following actions before running a playbook:

    1. Confirm that the Terraform version in the execution environment is the same as the version stated in TFE or HCP Terraform.
    2. Perform an initialization in TFE or HCP Terraform:

      terraform init
      Copy to Clipboard Toggle word wrap
    3. If you have a local state file in your execution environment, delete the local state file.
    4. Get a token from HCP Terraform or Terraform Enterprise, which you will use to create the credential in a later step. Ensure the token has the necessary permissions based on the team or user token to execute the desired capabilities in the playbook.
    5. Remove the backend config and files from your playbook definition.
    6. Add the workspace within the default setting in your TF config or an environment variable if you want to define the workspace outside updating the playbook itself.

      Note

      You can add the workspace to your playbook to scale your workspace utilization.

  2. From the Ansible Automation Platform user interface:

  3. (Optional) After the migration is completed and verified, you can run the additional modules and plugins from the collection in your execution environment:

Additional resources

1.4. Integrating from Terraform

If you have already provisioned your environment from Terraform Enterprise, you can use the Terraform official provider to leverage Ansible Automation Platform automation capabilities.

1.4.1. Configuring the provider

You must configure the provider to allow Terraform to reference and manage a subset of Ansible Automation Platform resources.

The provider configuration belongs in the root module of a Terraform configuration. Child modules receive their provider configurations from the root module.

Prerequisites

  • You have installed and configured Terraform Enterprise or HCP Terraform.
  • You have installed the latest release version of terraform-provider-aap from the Terraform registry.

    Note

    The default latest version on the Terraform registry might be a pre-release version (such as 1.2.3-beta). Select a supported release version, which uses a 1.2.3 format without dashes.

  • You have created a username and password.

Procedure

  1. Create a Terraform configuration (.tf) file. Include a provider block. The name given in the block header is the local name of the provider to configure. This provider should already be included in a required_providers block.

    Example

    # This example creates an inventory named `My new inventory`
    # and adds a host `tf_host` and a group `tf_group` to it,
    # and then launches a job based on the "Demo Job Template"
    # in the "Default" organization using the inventory created.
    #
    terraform {
      required_providers {
        aap = {
          source = "ansible/aap"
        }
      }
    }
    
    provider "aap" {
      host     = "https://AAP_HOST"
      username = "ansible"
      password = "test123!"
    }
    
    resource "aap_inventory" "my_inventory" {
      name         = "My new inventory"
      description  = "A new inventory for testing"
      organization = 1
      variables = jsonencode(
        {
          "foo" : "bar"
        }
      )
    }
    
    resource "aap_group" "my_group" {
      inventory_id = aap_inventory.my_inventory.id
      name         = "tf_group"
      variables = jsonencode(
        {
          "foo" : "bar"
        }
      )
    }
    
    resource "aap_host" "my_host" {
      inventory_id = aap_inventory.my_inventory.id
      name         = "tf_host"
      variables = jsonencode(
        {
          "foo" : "bar"
        }
      )
      groups = [aap_group.my_group.id]
    }
    
    data "aap_job_template" "demo_job_template" {
      name              = "Demo Job Template"
      organization_name = "Default"
    }
    
      # In order for passing the inventory id to the job template execution, the Inventory on the job template needs to be set to "prompt on launch"
    resource "aap_job" "my_job" {
      inventory_id    = aap_inventory.my_inventory.id
      job_template_id = aap_job_template.demo_job_template.id
    
      # This resource creation needs to wait for the host and group to be created in the inventory
      depends_on = [
        aap_host.my_host,
        aap_group.my_group
      ]
    }
    Copy to Clipboard Toggle word wrap
  2. Add the configuration arguments, as shown in the previous example. You must configure the host and credentials. A full list of supported schema is available on the Terraform registry for your aap provider release version.

    • host: (String) AAP server URL. Can also be configured using the AAP_HOST environment variable.
    • insecure_skip_verify: (Boolean) If true, configures the provider to skip TLS certificate verification. Can also be configured by setting the AAP_INSECURE_SKIP_VERIFY environment variable.
    • password: (String, Case Sensitive) Password to use for basic authentication. Can also be configured by setting the AAP_PASSWORD environment variable.
    • timeout: (Number) Timeout specifies a time limit for requests made to the AAP server. Defaults to 5 if not provided. A timeout of zero means no timeout. Can also be configured by setting the AAP_TIMEOUT environment variable.
    • username: (String) Username to use for basic authentication. Ignored if the token is set. Can also be configured by setting the AAP_USERNAME environment variable.
  3. (Optional) You can use expressions in the values of these configuration arguments, but can only reference values that are known before the configuration is applied.
  4. (Optional) You can also use an alias meta-argument that is defined by Terraform and is available for all provider blocks. alias lets you use the same provider with different configurations for different resources.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat