HashiCorp 和 Ansible Automation Platform 入门


Red Hat Ansible Automation Platform 2.6

将 HashiCorp 产品与 Ansible Automation Platform 集成

Red Hat Customer Content Services

摘要

了解如何使用 Terraform 和 Vault 配置 Ansible Automation Platform,并从社区版本迁移。

对红帽文档提供反馈

如果您对本文档有任何改进建议,或发现错误,请通过 https://access.redhat.com 联系技术支持来创建一个请求。

第 1 章 Terraform 集成

1.1. 关于 Terraform 集成

了解 IBM HashiCorp 产品和 Red Hat Ansible Automation Platform 支持的集成、集成工作流和迁移路径,以帮助确定您的环境的最佳选项。

1.1.1. 简介

很多机构发现自己使用 Ansible Automation Platform 和 Terraform Enterprise 或 HCP Terraform,认为这些机构能够以损害的方式为开发人员和运维团队创建更好的体验。

虽然 Terraform Enterprise 和 HCP Terraform excel 在 Infrastructure as Code (IaC)上用于置备和取消置备云资源,但 Ansible Automation Platform 是一个通用的自动化解决方案,非常适合跨不同域进行配置管理、应用部署和编排复杂 IT 工作流。

此集成直接解决常见挑战,如管理不同自动化工具,确保跨混合云环境进行一致的配置并加快部署周期。通过将 Terraform 的声明方法引入到使用 Ansible Automation Platform 过程配置和编配方法进行基础架构置备,用户可以实现:

  • 优化的成本: 减少云浪费、最小化手动流程以及打下复杂工具。这种集成可显著降低基础架构成本和高投资回报。
  • 降低风险: 降低漏洞的风险,强制实施策略,并显著减少计划外停机时间。在工作流中应用 Terraform 计划输出前,可以在带有批准步骤的工作流中查看 Terraform 计划输出,从而增强了安全性和合规性。
  • 更快的价值实现时间: 提高开发人员的工作效率并更快地部署新的计算资源,从而加快产品面市时间。这可以通过第 0 天(配置)、第 1 天(配置)和第 2 天(进行管理)操作的统一生命周期管理和自动化来实现。

通过启用 Ansible Automation Platform 和 Terraform Enterprise 或 HCP Terraform 之间的直接调用,组织可以通过创建组合工作流来节省时间,并通过增强的产品集成来降低风险,并使用 Ansible Automation Platform 内容和实践增强基础架构即即代码。这允许统一生命周期管理,使初始置备和配置中的任务能够持续进行健康检查、事件响应、修补和基础架构优化。

1.1.2. 集成工作流

根据您的现有设置,您可以从 Ansible Automation Platform 或 Terraform 中集成这些产品。为社区用户提供迁移路径,并从 cloud.terraform 集合进行迁移,使其具有hicorp.terraform

1.1.2.1. ansible-initiated 工作流

Ansible Automation hub 集合允许 Ansible Automation Platform 用户利用 Terraform Enterprise 或 HCP Terraform 置备功能。

hashicorp.terraform collection

这个集合提供了 Ansible Automation Platform 和 Terraform Enterprise 或 HCP Terraform 之间的 API 集成。此解决方案与 Ansible Automation Platform 原生工作,并降低设置复杂性,因为它不需要二进制安装,且包含默认的执行环境。

cloud.terraform collection

此集合提供 Ansible Automation Platform 和 Terraform Enterprise 或 HCP Terraform 之间的 CLI 集成。要使用此集合,您必须安装一个二进制文件并创建执行环境。

虽然支持此集合,但我们建议使用 hashicorp.terraform 集合来利用其 API 功能。

1.1.2.2. 迁移工作流

社区版本用户可以迁移到 Terraform Enterprise 或 HCP Terraform,然后使用 cloud.terraform (CLI)集合集成 Ansible Automation Platform 功能。但是,我们建议使用 hashicorp.terraform (API)集合替代。

如果您已使用 cloud.terraform 集合,您可以迁移到 hicorp.terraform

1.1.2.3. Terraform-initiated 工作流

对于现有的 Terraform Enterprise 或 HCP Terraform 用户,Terraform 可以在置备结束时直接调用 Ansible Automation Platform,以进行更加无缝的安全工作流。这可让 Terraform Enterprise 或 HCP Terraform 用户通过 Ansible Automation Platform 第 2 天自动化功能增强其不可变基础架构自动化,并管理基础架构更新和生命周期事件。

1.2. 从 Ansible Automation Platform 集成

作为管理员,您可以从 Ansible Automation Platform 用户界面配置集成。使用与安装的集合相关的流程。

1.2.1. 对hicorp.terraform 进行身份验证

安装或迁移到 有hicorp.terraform 后,管理员在 Ansible Automation Platform 用户界面中配置自定义凭证类型,以向 Terraform Enterprise 或 HCP Terraform 进行身份验证。然后,用户创建用于 Ansible Automation Platform 中的作业模板的凭证。

1.2.1.1. 创建自定义凭证类型

管理员设置自定义凭证类型,以便于 Ansible Automation Platform 和 Terraform Enterprise 或 HCP Terraform 之间的身份验证。

此准备有助于确保凭证自动提供给执行环境,从而消除手动更新 playbook 的需要。

另外,您可以为 Vault 配置自定义凭证,以利用使用 Ansible Automation Platform 的 Terraform Enterprise 或 HCP Terraform 和 Vault 的高级功能。

先决条件

  • 您必须具有 Terraform API 令牌
  • 安装来自自动化中心的认证 hicorp.terraform 集合。(您需要 Ansible 订阅才能访问和下载 Automation Hub 上的集合。)

流程

  1. 登录到 Ansible Automation Platform。
  2. 在导航面板中,选择 Automation ExecutionInfrastructureCredential Types
  3. 单击 Create credential typeCreate Credential Type 页面将打开并显示 Details 选项卡。
  4. 对于 Name 字段,输入凭证类型名称。
  5. Input configuration 字段中输入以下参数和值:

    fields:
      - id: token
        type: string
        label: token
        secret: true
  6. Injector 配置 字段中,输入以下配置:

    env:
      TF_TOKEN:  ‘{{ token }}’
  7. 要保存配置,请再次点击 Create Credential Type。创建新凭证类型。

后续步骤

创建凭证

1.2.1.2. 创建凭证

用户必须创建一个凭据,以用于 Ansible Automation Platform 中的作业模板。

前提条件

流程

  1. 登录到 Ansible Automation Platform。
  2. 在导航面板中,选择 Automation ExecutionInfrastructureCredentials,然后选择 Create credential
  3. Credential type 列表中,选择凭证类型。显示的字段取决于凭证类型。
  4. Token 字段中输入 Terraform API 令牌。
  5. (可选)编辑 Description 字段,并从 Organization 列表中选择 TF 机构。
  6. 单击 Save credential。您已准备好在作业模板中使用凭证。

1.2.2. 与 cloud.terraform 集成

cloud.terraform 集成时,您必须创建凭证,构建执行环境,并在 Ansible Automation Platform 中启动作业模板。

1.2.2.1. 创建凭证

您可以直接从 Ansible Automation Platform 用户界面设置凭证。为执行环境提供凭证,Ansible Automation Platform 会在此处读取它们。这消除了手动更新每个 playbook 的需要。

先决条件

  • 您必须具有 Terraform API 令牌
  • 从自动化中心安装经认证的 cloud.terraform 集合。(您需要 Ansible 订阅才能访问和下载 Automation Hub 上的集合。)

流程

  1. 登录到 Ansible Automation Platform。
  2. 在导航面板中,选择 Automation ExecutionInfrastructureCredential Types
  3. 单击 Create credential typeCreate Credential Type 页面将打开并显示 Details 选项卡。
  4. 对于 凭据类型, 请输入名称。
  5. Input configuration 字段中输入以下 YAML 参数和值:

    fields:
       - id: token
         type: string
         label: token
         secret: true
  6. Injector 配置 字段中,输入以下配置。

    • 对于 Terraform Enterprise,主机名是您部署 TFE 的位置:

      env:
        TF_TOKEN_<hostname>:  ‘{{ token }}’
    • 对于 HCP Terraform,请使用:

      env:
        TF_TOKEN_app_terraform_io:   ‘{{ token }}’
  7. 要保存配置,请再次点击 Create Credential Type。创建新凭证类型。
  8. 要创建新凭证类型的实例,请选择 Automation ExecutionInfrastructureCredentials 页面,然后选择 Create credential
  9. Credential type 中选择您之前创建的凭证类型的名称。
  10. Token 字段中输入 Terraform API 令牌。
  11. (可选)编辑 Description 并从 Organization 列表中选择 TF 机构。
  12. 单击 Save credential

您必须使用自动化控制器构建执行环境,以便 Ansible Automation Platform 可以提供使用自动化功能所需的凭证。

先决条件

  • 在使用自动化控制器创建前,您需要一个具有最新版本的 cloud.terraform 集合的预先存在的执行环境。您不能使用 Ansible Automation Platform 提供的默认执行环境,因为默认环境不包括 terraform CLI 二进制文件。

    注意

    如果您已从 Terraform 社区版迁移,您可以继续使用现有的执行环境,并将其更新至最新版本的 cloud.terraform

  • 在预先存在的执行环境中安装 terraform CLI 二进制文件。有关二进制文件的链接,请参阅下面的 附加资源

流程

  1. 在导航面板中,选择 Automation ExecutionInfrastructureExecution Environments
  2. 单击 Create execution environment

    创建新的执行环境页面
  3. 对于 Name,输入 Ansible Automation Platform 执行环境的名称。
  4. 对于 Image,输入到您预先存在的执行环境的镜像的存储库链接。
  5. 单击 Create execution environment。您新添加的执行环境已准备好在作业模板中使用。
1.2.2.3. 创建并启动作业模板

创建并启动作业模板来完成集成并使用 Ansible Automation Platform 中的自动化功能。

流程

  1. 在导航面板中,选择 Automation ExecutionTemplates
  2. 选择 Create template > Create Job Template
  3. Execution Environment 列表中,选择您创建的环境。
  4. Credentials 列表中,选择您之前创建的凭据实例。如果没有看到凭证,请点击 Browse 来查看列表中的更多选项。
  5. 为必填字段输入任何其他信息。
  6. 单击 Create job template
  7. Launch template
  8. 要启动作业,请单击 NextFinish。作业输出显示作业已运行。

验证

要查看作业已从 Terraform 用户界面中成功运行,请选择 Workspaces > Ansible-Content-Integration > Run。Run 列表显示通过 CLI 作业触发的状态。您可以看到它从 Queued 变为 Plan Finished 状态。

1.3. 从其他版本进行迁移

从早期的集合或社区版本迁移,以使用 HashiCorp 和 Ansible Automation Platform 集成的最高级功能。

1.3.1. 从 cloud.terraform 迁移到 hashicorp.terraform

如果您使用现有的 cloud.terraform (CLI-form)集合,您可以将现有的 playbook 迁移到具有hicorp.terraform (API)集合的 hashicorp.terraform。需要配置的 hashicorp.terraform 的主要模块是 hicorp.terraform.configuration_version,并且有 hicorp.terraform.run

要迁移到 hashicorp.terraform 集合,您必须配置 hashicorp.terraform.configuration_version 模块。此模块管理 Terraform Enterprise 或 HCP Terraform 中的配置版本。

先决条件

  • 安装 Ansible Automation Platform 认证 有hicorp.terraform 集合。
  • 验证在 Terraform Enterprise 或 HCP Terraform 中正确设置了有效的机构和工作区。

流程

  1. cloud.terraform 模块中复制您的自动化任务。

    示例

    - 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
  2. 配置以下所需参数:

    • workspace_idworkspace + organization 将创建配置版本的工作区 ID 或工作区名称和组织,该文件将被上传(表示 state: present)。
    • configuration_files_path 上传所需 Terraform Enterprise 或 HCP Terraform 文件的路径来创建配置版本(用于 state: present)。模块接受 configuration_files_path 的两个文件类型:

      • 目录: 包含 Terraform Enterprise 或 HCP Terraform 文件的任何文件夹。模块会自动从所有内容中自动创建 .tar.gz 文件。
      • .tar.gz Archive: Pre-compressed gzip tarball.模块验证 TAR 格式和 gzip 压缩。
    • configuration_version_id 要存档的配置版本 ID (状态: archive)。此操作会删除关联的上传的 .tar.gz 文件。注意以下几点:

      • 仅上传使用 API 或 CLI 创建的版本,没有活跃的运行,且不是任何工作区的当前版本可以被归档。
      • 如果未指定 configuration_version_id,Terraform Enterprise 或 HCP Terraform 在工作区中选择最新的批准的 configuration_version_id
    • auto_queue_runs : 确定 Terraform Enterprise 或 HCP Terraform 是否在配置上传后自动启动(默认为true ),或者需要手动启动(false)。
  3. 根据需要设置其他 可选参数
1.3.1.2. 配置 hashicorp.terraform.run 模块

hashicorp.terraform.run 模块可让您使用 create, apply, cancel, 和 discard 操作来管理 Terraform Enterprise 或 HCP Terraform 运行。您可以使用可自定义设置在指定的工作区上触发计划或应用操作。

先决条件

  • 确保正确配置了有效的 Terraform API 令牌,以便与您的 Terraform Enterprise 或 HCP Terraform 环境进行身份验证。
  • 验证在 Terraform Enterprise 或 HCP Terraform 中正确设置了有效的机构和工作区。

流程

  1. 创建 run 模块。

    示例

    - 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
  2. 配置以下所需参数:

    • workspace_idworkspace + organization 将创建配置版本的工作区 ID 或工作区名称和组织,该文件将被上传(表示 state: present)。
    • run_id 要应用、取消或丢弃操作的目标的唯一标识符。
    • tf_token: Terraform API 身份验证令牌。如果没有设置这个值,则使用 TF_TOKEN 环境变量。
  3. (可选)配置内置的轮询选项,以确定 Terraform Enterprise 或 HCP Terraform 操作的等待周期完成:

    • poll: true :(默认)每 poll_interval 秒(默认为 5s)检查运行状态,直到达到 completion 或 poll_timeout (default: 25s)为止,返回最终状态。
    • poll: false : 在启动运行后立即返回,而不等待。
  4. 根据需要设置其他 可选参数
1.3.1.3. 带有corp.terraform 模块的迁移示例

这些示例前后用于帮助用户了解如何在真实环境中配置模块。

1.3.1.3.1. 示例 1:仅计划
  • 之前(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
  • After (hicorp.terraform reference):

    • configuration_version 模块:

      - 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
    • 使用 run 模块运行 plan_only

      - 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"
1.3.1.3.2. 示例 2:计划和应用
  • 之前(cloud.terraform.terraform):

    1. 生成计划:

      - 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
    2. 应用计划:

      - 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
  • 之后(隐藏corp.terraform.run):

    1. configuration_version 模块:

      - 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
    2. run 模块具有两个用于计划和应用工作流的选项:
  • 选项 1: 使用 auto_apply 参数来处理计划并应用工作流:

    - 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
  • 选项 2: 使用两个子步骤来创建 save_plan 运行,然后应用它:

    1. 创建计划:

      - 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
    2. 应用计划。您可以从 run 模块任务的输出中获取 run_id

      - 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

1.3.2. 从 Terraform 社区版本迁移

如果要将 Ansible Automation Platform 与 Terraform Enterprise (TFE)或 HCP Terraform 搭配使用,且您当前正在使用 Terraform 社区版本(TCE),您必须迁移到 TFE 或 HCP Terraform,然后更新 Ansible Automation Platform 配置以使用 TFE 或 HCP Terraform。

1.3.2.1. 从社区版本迁移

当您从 TCE 迁移到 TFE 或 HCP Terraform 时,您不会迁移集合本身。相反,您要调整现有 TCE 使用量以使用 TFE 或 HCP Terraform。

迁移后,您必须更新 Ansible Automation Platform 凭证、执行环境和作业模板。

注意

cloud.terraform 集合只支持 HCP Terraform 中的 CLI 驱动的工作流。

先决条件

  • 使用最新支持的 Terraform 版本(1.11 或更高版本)。
  • 按照下面的 附加资源 下的 tf-migrate CLI 指令进行操作。
  • 确保 HCP Terraform 或 TFE 工作区没有设置为自动应用计划。

流程

  1. 要防止针对 TFE 或 HCP Terraform 运行 playbook 时的错误,请在运行 playbook 前执行以下操作:

    1. 确认执行环境中的 Terraform 版本与 TFE 或 HCP Terraform 中声明的版本相同。
    2. 在 TFE 或 HCP Terraform 中执行初始化:

      terraform init
    3. 如果您在执行环境中有一个本地状态文件,请删除本地状态文件。
    4. 从 HCP Terraform 或 Terraform Enterprise 获取令牌,您将用来在后续步骤中创建凭证。确保令牌具有必要的权限,基于团队或用户令牌在 playbook 中执行所需的功能。
    5. 从 playbook 定义中删除后端配置文件和文件。
    6. 如果要在 TF 配置中的默认设置或环境变量中添加工作区,如果要定义在更新 playbook 本身外的工作空间。

      注意

      您可以将工作区添加到 playbook 中,以扩展工作空间利用率。

  2. 在 Ansible Automation Platform 用户界面中:

  3. (可选)在迁移完成后,您可以从执行环境中的集合运行额外的模块和插件:

1.4. 从 Terraform 集成

如果您已经置备了 Terraform Enterprise 的环境,您可以使用 Terraform 官方供应商来利用 Ansible Automation Platform 自动化功能。

1.4.1. 配置供应商

您必须将供应商配置为允许 Terraform 引用和管理 Ansible Automation Platform 资源的子集。

供应商配置属于 Terraform 配置的根模块。子模块从 root 模块接收其提供程序配置。

先决条件

  • 已安装并配置了 Terraform Enterprise 或 HCP Terraform
  • 您已从 Terraform registry 安装了 terraform-provider-aap 的最新发行版本。

    注意

    Terraform registry 中的默认最新版本可能是一个预发布版本(如 1.2.3-beta)。选择一个支持的发行版本,它使用 1.2.3 格式而无需横线。

  • 您已为 Ansible Automation Platform 创建用户名和密码或 API 令牌。也支持环境变量。

    注意

    建议使用令牌身份验证,因为用户可以管理特定集成的令牌(如 Terraform),限制令牌访问,并完全控制令牌生命周期。

流程

  1. 创建 Terraform 配置(.tf)文件。包括一个 provider block。block 标头中指定的名称是要配置的提供程序的本地名称。https://developer.hashicorp.com/terraform/language/providers/requirements#local-names此提供程序应已包含在 required_providers 块中

    示例

    # 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"
      token = "my-aap-token" # Do not record credentials directly in the Terraform configuration. Provide your token using the AAP_TOKEN environment variable.
    }
    
    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
      ]
    }
  2. 添加配置参数,如上例中所示。您必须配置主机和凭证。在 aap 供应商发行版本的 Terraform registry 中提供了受支持的模式的完整列表。

    • Host: (字符串)AAP 服务器 URL。也可以使用 AAP_HOST 环境变量进行配置。
    • insecure_skip_verify: (Boolean)如果为 true,请将提供程序配置为跳过 TLS 证书验证。也可以通过设置 AAP_INSECURE_SKIP_VERIFY 环境变量来配置。
    • Password : (字符串,问题单敏感)密码用于基本身份验证。如果设置了令牌,则忽略。请注意,出于安全原因,不建议硬编码凭证。最佳实践是使用 AAP_PASSWORD 环境变量替代的。
    • 超时 (Number) Timeout 为向 AAP 服务器发出的请求指定时间限制。如果没有提供,则默认为 5。超时值为零表示没有超时。也可以通过设置 AAP_TIMEOUT 环境变量来配置。
    • Token : (字符串,问题单敏感):用于令牌身份验证的令牌。请注意,出于安全原因,不建议硬编码凭证。最佳实践是使用 AAP_TOKEN 环境变量替代的。
    • 用户名 :( 字符串)用于基本身份验证的用户名。如果设置了令牌,则忽略。也可以通过设置 AAP_USERNAME 环境变量来配置。
  3. (可选)您可以在这些配置参数的值中使用 表达式,但只能引用应用配置前已知的值。
  4. (可选)您还可以使用由 Terraform 定义并可用于所有供应商块 的别名 meta-argument别名 可让您为不同的资源使用不同的配置相同的供应商。

1.4.2. 使用 TF 操作和 Ansible Automation Platform

在 Ansible Automation Platform 中使用 Terraform (TF)操作在基础架构置备后触发自动配置。

Terraform (TF) 操作向 HCL 语言添加一个强制操作 块,允许您在置备基础架构后执行步骤,而无需保留声明性 Terraform 工作流。这会使整个基础架构和配置过程在 Terraform 配置中可见。

TF Actions 可用于触发用于配置管理的 Ansible 自动化,如向 Ansible Automation Platform 发送事件和有效负载来配置新置备的虚拟机。

Ansible Automation Platform 的 Terraform 供应商实现了两个操作:

  • 直接启动作业:将作业 作为直接、直接执行请求运行到 Ansible Automation Platform。您必须明确定义 TF Action 应该调用哪些特定的 Ansible Automation Platform 作业模板。
  • 使用 Event-Driven Ansible: 向 Ansible Automation Platform 发送事件,然后使用规则手册智能决定根据事件有效负载运行哪个 playbook。这可以实现更动态、可扩展和被动自动化。
1.4.2.2. 使用 TF 操作作为直接作业

当您使用 TF Actions 通过 Ansible Automation Platform 直接启动作业时,此过程将精简和顺序。

这种方法的好处是一个干净的可预测状态:Ansible 作业在 Terraform 应用周期内启动,Terraform 收到一个明确的二进制状态。请注意,每个更改都会启动一个具有相同配置的独立作业。

当您要对新调配的服务器执行 Ansible 自动化时,此方法非常有用。例如,最后的恶意配置或在新主机上应用常规安全补丁作业。

先决条件

  • 您已配置了 AAP Terraform 供应商来使用 Ansible Automation Platform 进行身份验证。
  • 您已配置了 AWS Terraform 供应商,以通过 Amazon Web Services 进行身份验证

    注意

    以下示例使用 Amazon Web Services (AWS),并需要一个可能会收取费用的 AWS 帐户。您可以调整模式,以使用不同的云供应商。

  • 您已配置了作业模板:

    • 清单设置为 启动时提示
    • 与本地文件中可用的公钥匹配的机器凭据(私钥)。

流程

  1. 在 5.2. tf 文件中定义 aap_job_launch 操作。
  2. 添加生命周期作业块,以定义在正确的生命周期事件触发器期间调用哪些操作。

    示例

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }

    aap = {
      source  = "ansible/aap"
      version = "~> 1.4.0"
    }
  }
}

provider "aap" {
  # Configure authentication as needed.
}

provider "aws" {
  region = "us-west-1"
  # Configure authentication as needed.
}

variable "public_key_path" {
  type        = string
  description = "Local path to a public key file to inject into the VM. Your AAP Job Template must have the matching private key configured as a machine credential."
}

resource "aws_key_pair" "key_pair" {
  key_name   = "aap-terraform-actions-demo-key"
  public_key = file(var.public_key_path)
}

data "aws_ami" "rhel_ami" {
  most_recent = true

  filter {
    name   = "name"
    values = ["RHEL-9*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["309956199498"] # Red Hat
}

resource "aws_instance" "instance" {
  ami                         = data.aws_ami.rhel_ami.id
  instance_type               = "t2.micro"
  associate_public_ip_address = true
  key_name                    = aws_key_pair.key_pair.key_name
}

# Look up Organization ID

data "aap_organization" "organization" {
  name = "Default"
}

# Create an inventory

resource "aap_inventory" "inventory" {
  name         = "Actions Demo Inventory"
  organization = data.aap_organization.organization.id
}

data "aap_job_template" "job_template" {
  name              = "Demo Job Template"
  organization_name = data.aap_organization.organization.name
}

#
# Direct job launch action example
#

resource "aap_host" "host" {
  inventory_id = aap_inventory.inventory.id
  name         = resource.aws_instance.instance.public_ip
  # Setting a value of 10 for SSH retries because terraform will mark the
  # instance 'created' before it is ready to accept connections from Ansible.
  variables = jsonencode(
    {
      "ansible_ssh_retries" : 10
    }
  )
  # Configure a job launch after the host is created in inventory
  lifecycle {
    action_trigger {
      events  = [after_create]
      actions = [action.aap_job_launch.job_launch]
    }
  }
}

action "aap_job_launch" "job_launch" {
  config {
    inventory_id        = aap_inventory.inventory.id
    job_template_id     = data.aap_job_template.job_template.id
    wait_for_completion = true
  }
}
  1. (必需)将本示例中的作业模板名称和清单名称改为您的对应变量。
  2. (可选)您可以将所有者设置为 Red Hat RHEL 镜像 ID,以便每次作业运行时都会使用最新的镜像。
  3. (可选)根据需要设置 附加参数。例如,您可以将 wait_for_completion 设置为 true,然后 Terraform 将等待到创建此作业并达到任何最终状态,然后再继续。您还可以设置 wait_for_completion_timeout_seconds 来控制超时限制。
  4. 更新并提交 Terraform 代码。
  5. 执行 Terraform 计划并应用它。
1.4.2.3. 使用带有 Event-Driven Ansible 的 TF 操作

event-Driven Ansible 是一个自动化功能,它允许 Ansible Automation Platform 对实时事件做出反应,而不是根据调度或手动请求触发。

1.4.2.3.1. 配置事件流

要将 TF 操作与 Event-Driven Ansible 搭配使用,您必须首先在 Ansible Automation Platform 中配置事件流。TF 操作将事件发布到此流。

先决条件

  • 您已配置了 AAP Terraform 供应商来使用 Ansible Automation Platform 进行身份验证。
  • 您已配置了 AWS Terraform 供应商,以通过 Amazon Web Services 进行身份验证

    注意

    以下示例使用 Amazon Web Services (AWS),并需要一个可能会收取费用的 AWS 帐户。您可以调整模式,以使用不同的云供应商。

Default 组织中有一个名为 EDA Actions Demo Inventory 的 Ansible Automation Platform 清单。

您已配置了作业模板:

  • 清单设置为 EDA Actions Demo Inventory
  • 与本地文件中可用的公钥匹配的机器凭据(私钥)。

流程

  1. 登录到 Ansible Automation Platform 用户界面。
  2. 导航到 Automation DecisionsEvent Streams
  3. Create event stream
  4. Create event stream 页面中,编辑字段:

    • 名称 : 您的事件流的描述性、唯一名称(如 Terraform provider_Events)。
    • Organization : 选择此事件流将属于的机构(通常为 Default 或 your specific organization)。
    • event stream type : 选择与您要接收事件匹配的类型。此集成支持 基本事件流 (用户名/密码)。
    • 凭证 : 选择一个您预先创建用于使用此事件流进行身份验证的凭证。
    • headers :(可选)输入您要包含在转发到规则规则的事件有效负载中的以逗号分隔的 HTTP 标头键。保留此为空以包括所有标头。
    • 将事件转发到规则手册激活 : 此选项通常默认启用。禁用它可用于测试和诊断您的连接和传入的数据,而不会意外地触发任何自动化。
  5. Create event stream。然后导航到 Automation DecisionsEvent Streams,以验证事件流是否已创建并查看目前收到的事件数量。

    您还可以点击特定流来查看其详细配置,包括机构、事件流类型、关联的凭证和事件转发设置。

  6. 设置 规则手册激活。确保:

    1. 将事件流添加到规则手册中。
    2. (推荐)选择 启用 Rulebook 激活? 选项,以在创建后自动启动激活。
    3. 激活规则手册。
  7. 选择 Automation DecisionsRulebook Activations,以验证规则手册是否活跃并检查其状态。
1.4.2.3.2. 配置 TF 操作

要将事件流连接到 Terraform 操作,您可以在 Terraform 中配置主 TF 文件( {tf)。

流程

  1. 添加一个 lifecycle 块,将 Event-Driven Ansible 事件流调用到您的 storageclasstf 文件。after_create 操作将触发 action.aap_eda_eventstream_post.create

    示例

    以下示例显示了添加到 AWS EC2 服务器的置备 生命周期 块。调配新的服务器后,操作将运行。

    terraform {
      required_providers {
        aws = {
          source  = "hashicorp/aws"
          version = "~> 6.0"
        }
    
        aap = {
          source  = "ansible/aap"
          version = "~> 1.4.0"
        }
      }
    }
    
    provider "aap" {
      # Configure authentication as needed.
    }
    
    provider "aws" {
      region = "us-west-1"
      # Configure authentication as needed.
    }
    
    variable "public_key_path" {
      type        = string
      description = "Local path to a public key file to inject into the VM. Your AAP Job Template must have the matching private key configured as a machine credential."
    }
    
    variable "event_stream_username" {
      type = string
    }
    
    variable "event_stream_password" {
      type = string
    }
    
    resource "aws_key_pair" "key_pair" {
      key_name   = "aap-terraform-actions-demo-key"
      public_key = file(var.public_key_path)
    }
    
    data "aws_ami" "rhel_ami" {
      most_recent = true
    
      filter {
        name   = "name"
        values = ["RHEL-9*"]
      }
    
      filter {
        name   = "virtualization-type"
        values = ["hvm"]
      }
    
      owners = ["309956199498"] # Red Hat
    }
    
    resource "aws_instance" "instance" {
      ami                         = data.aws_ami.rhel_ami.id
      instance_type               = "t2.micro"
      associate_public_ip_address = true
      key_name                    = aws_key_pair.key_pair.key_name
    }
    
    # Look up an inventory
    
    data "aap_inventory" "inventory" {
      name              = "EDA Actions Demo Inventory"
      organization_name = "Default"
    }
    
    #
    # EDA Event launch action example
    #
    
    resource "aap_host" "host" {
      inventory_id = data.aap_inventory.inventory.id
      name         = resource.aws_instance.instance.public_ip
      # Configure an EDA eventstream POST after the host is created in inventory
      lifecycle {
        action_trigger {
          events  = [after_create]
          actions = [action.aap_eda_eventstream_post.event_post]
        }
      }
    }
    
    data "aap_eda_eventstream" "eventstream" {
      name = "TF Actions Event Stream"
    }
    
    action "aap_eda_eventstream_post" "event_post" {
      config {
        limit             = "all"
        template_type     = "job"
        job_template_name = "Demo Job Template"
        organization_name = "Default"
        event_stream_config = {
          username = var.event_stream_username
          password = var.event_stream_password
          url      = data.aap_eda_eventstream.eventstream.url
        }
      }
    }
  2. (必需)配置以下参数:

    • event-Driven Ansible 事件流的event_stream_config: (Attributes) Details。您必须包括:

      • 用户名 :( 字符串)在执行 POST 到事件流 URL 时使用的用户名
      • Password : (字符串)在执行 POST 到事件流 URL 时使用的密码
      • URL : (字符串)用于接收事件 POST 的 URL
    • 限制 (字符串)Ansible Automation Platform 对作业执行的限制
    • organization_name :( 字符串)机构名称
    • template_type: (字符串)模板类型: jobworkflow_job
  3. (可选)您可以将所有者设置为 Red Hat RHEL 镜像 ID,以便每次作业运行时都会使用最新的镜像。
  4. (可选)根据需要设置 附加参数
  5. 配置与事件有效负载规格和目标规则手册映射的操作集成。

    示例:

- name: Dispatch TF Workflow Job Template Action
      condition: event.payload.template_type == "workflow"
      throttle:
        once_after: 1 minute
        group_by_attributes:
          - event.payload.workflow_template_name
          - event.payload.limit
          - event.payload.organization_name
      actions:
        - debug:
            msg: "Executing Workflow Template {{ event.payload.workflow_template_name }}"
        - run_workflow_template:
            name: "{{ event.payload.workflow_template_name }}"
            organization: "{{ event.payload.organization_name }}"
        - debug:
            msg: "Executed Workflow Job Template {{ event.payload.workflow_template_name }}"
1.4.2.3.3. 创建并应用计划

在将 Terraform 计划配置为包含 Event-Driven Ansible 事件后,您可以创建并应用计划来触发事件。

流程

  1. 运行 terraform init 以初始化您的工作目录。
  2. 使用 terraform 计划 提交来创建计划。以下示例将计划保存到名为 tfplan.out 的文件,但您可以为计划指定任何名称。保存计划是自动化的最佳做法,因为保存的计划严格强制执行。

    terraform plan -out=tfplan.out
  3. 检查计划输出。
  4. 应用已保存的计划。

    terraform apply tfplan.out

    这会创建事件并将其发送到指定的事件流。当创建每个资源时,会调用 TF 操作,并按顺序执行对应的 Ansible Automation Platform playbook。

验证

  1. 验证在 Terraform 用户界面中是否更新了运行。深入到资源上,以查看调用该操作和执行后事件。
  2. 在 Ansible Automation Platform 用户界面中,验证事件是否被(EDAName})成功接收,并触发适当的规则手册激活:

    1. 检查 Event Streams 仪表板,以查看收到 TF Actions 事件。
    2. 检查 Jobs 仪表板,以查看按顺序运行的作业以及 Success 状态。
    3. 检查 Inventory 仪表板,以查看更新。例如,如果您创建了新的服务器,请检查 Terraform 置备清单的 Hosts 选项卡。
1.4.2.3.4. 规则手册示例

以下规则手册示例演示了如何使用 TF 操作和 Event-Driven Ansible 侦听 webhook 上的事件。

- name: Listen for events on a webhook
  hosts: all

  ## Define our source for events

  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
      filters:
        - ansible.eda.insert_hosts_to_meta:
            host_path: payload.limit

  ## Define the conditions we are looking for

  rules:
    - name: Dispatch TF Job Template Action
      condition: event.payload.template_type == "job"
      throttle:
        once_after: 1 minute
        group_by_attributes:
          - event.payload.job_template_name
          - event.payload.limit
          - event.payload.organization_name
      actions:
        - debug:
            msg: "Executing Job Template {{ event.payload.job_template_name }}"
        - run_job_template:
            name: "{{ event.payload.job_template_name }}"
            organization: "{{ event.payload.organization_name }}"
        - debug:
            msg: "Executed Job Template {{ event.payload.job_template_name }}"
    - name: Dispatch TF Workflow Job Template Action
      condition: event.payload.template_type == "workflow"
      throttle:
        once_after: 1 minute
        group_by_attributes:
          - event.payload.workflow_template_name
          - event.payload.limit
          - event.payload.organization_name
      actions:
        - debug:
            msg: "Executing Workflow Template {{ event.payload.workflow_template_name }}"
        - run_workflow_template:
            name: "{{ event.payload.workflow_template_name }}"
            organization: "{{ event.payload.organization_name }}"
        - debug:
            msg: "Executed Workflow Job Template {{ event.payload.workflow_template_name }}"

第 2 章 Vault 集成

2.1. 关于 Vault 集成

Red Hat Ansible Automation Platform 和 IBM HashiCorp Vault 的集成为 Vault 提供完全自动化的生命周期管理。

2.1.1. 简介

通过 vault,您可以安全地集中存储和管理 secret。Ansible Automation Platform 认证的 hashicorp.vault 集合为 Vault 提供完全自动化的生命周期和操作管理。您可以通过 playbook 创建、更新和删除 secret。

  • 现有 community.hashi_vault 用户: hashicorp.vault 解决方案旨在替换不受支持的 community.hashi_vault 集合。使用迁移路径保留现有的 playbook。有关迁移的更多信息,请参阅从 community.hashi_vault 迁移。
  • 新的 Vault 用户: hashicorp.vault 集合包含在来自自动化中心支持的执行环境中。
注意

虽然 hashicorp.vaulthashi.terraform 集合相互独立工作,但专为不同的任务设计,您可以在高级工作流中同时使用它们。

2.2. 向 hashicorp.vault进行身份验证

安装或迁移到 hashicorp.vault 集合后,会在 Ansible Automation Platform 用户界面中配置身份验证。管理员创建自定义凭证类型来向 Vault 进行身份验证。然后,用户创建用于作业模板的凭证。

2.2.1. 身份验证架构

hashicorp.vault 集合通过环境变量和客户端初始化来管理身份验证。这种方法通过防止敏感凭据直接作为 playbook 任务中的模块参数传递来提高安全性。

hashicorp.vault 集合使用环境变量将凭证注入到作业模板中,因此您可以在确保身份验证详情保持安全的情况下获得更简单、干净的任务定义。

支持以下身份验证类型:

  • Approle 身份验证 : 在使用 appRole 身份验证时,使用以下方法之一:

    • 设置 VAULT_APPROLE_ROLE_IDVAULT_APPROLE_SECRET_ID 环境变量。使用环境变量时,还必须创建一个将传递给作业模板的自定义凭证类型和凭证。
    • role_idsecret_id 参数直接传递给任务,例如:

      - name: Create a secret with AppRole authentication
        hashicorp.vault.kv2_secret:
          url: https://vault.example.com:8200
          auth_method: approle
          role_id: "{{ vault_role_id }}"
          secret_id: "{{ vault_secret_id }}"
          path: myapp/config
          data:
            api_key: secret-api-key
  • 令牌身份验证 : 设置 VAULT_TOKEN 环境变量。

    另外,您可以为令牌配置参数。如果没有提供参数,则模块将使用环境变量。

2.2.2. 创建自定义凭证类型

作为管理员,您可以在 Ansible Automation Platform 中创建安全凭证类型,用于向 Vault 进行身份验证。

您可以配置基于角色的(appRole)身份验证,或者允许用户直接提供令牌。

先决条件

执行以下操作之一

流程

  1. 登录到 Ansible Automation Platform。
  2. 在导航面板中,选择 Automation ExecutionInfrastructureCredential Types
  3. 单击 Create a credential typeCreate Credential Type 页面将打开。
  4. 在对应的字段中输入名称和描述。
  5. 如果要为单个用户配置令牌身份验证:

    1. 对于 输入配置,请输入:

      fields:
       - id: vault_token
         type: string
         label: Hashicorp Vault Token
         secret: true
    2. 对于 Injector 配置,请输入:

      env:
         VAULT_TOKEN: '{{ vault_token }}'
  6. 如果要使用 role_idsecret_id 配置 appRole 身份验证:

    1. 对于 输入配置,请输入:

      fields:
        - id: vault_approle_role_id
          type: string
          label: Hashicorp Vault appRole Role ID
          secret: true
        - id: vault_approle_secret_id
          type: string
          label: Hashicorp Vault appRole Secret ID
          secret: true
    2. 对于 Injector 配置,请输入:

      env:
          VAULT_APPROLE_ROLE_ID: '{{ vault_approle_role_id }}'
          VAULT_APPROLE_SECRET_ID: '{{ vault_approle_secret_id }}'
  7. 单击 Create credential type

后续步骤

其他资源

2.2.3. 创建自定义凭证

Vault 用户必须创建一个自定义凭证,以用于 Ansible Automation Platform 中的作业模板。

前提条件

  • 您的管理员创建了 Vault 凭证类型。

流程

  1. 登录到 Ansible Automation Platform。
  2. 在导航面板中,选择 Automation ExecutionInfrastructureCredentials,然后选择 Create credential
  3. 在对应的字段中输入名称和描述。
  4. (可选)从 Organization 列表中选择一个机构。
  5. Credential type 列表中,选择 Vault 凭据类型。显示的字段取决于凭证类型。
  6. 执行以下操作之一

    1. 对于令牌身份验证,请添加 Vault 令牌并根据需要编辑任何字段。
    2. 对于 appRole 验证方法,在 appRole 角色 ID 和 appRole Secret ID 字段中输入 ID。根据需要编辑任何其他字段。
  7. 单击 Save credential。您已准备好在作业模板中使用凭证。

2.3. 从 community.hashi_vault迁移

如果使用 community.hashi_vault 集合,您可以将现有的 playbook 迁移到 hashicorp.vault 集合。

2.3.1. 配置 KV1 模块

如果您将 KV1 与 community.hashi_vault 集合搭配使用,请在 hashicorp.vault 集合中配置对应的模块。

2.3.1.1. 配置 hashicorp.vault.kv1_secret 模块

流程

  • 迁移不需要配置此模块,因为 community.hashi_vault 中没有对应的模块。但是,您可能想要在迁移后为 auth_methodstate 配置除默认值以外的内容。您可以使用 Ansible Automation hub 上的示例进行参考。
2.3.1.2. 配置 hashicorp.vault.kv1_secret_info 模块

hashicorp.vault.kv1_secret_info 模块读取 KV1 secret。

对应的 community.hashi_vault 模块有:

  • community.hashi_vault.vault_kv1_get : 从 HashiCorp Vault KV 版本 1 secret 存储检索 secret。
  • community.hashi_vault.vault_kv1_get 查找 从 HashiCorp Vault KV 版本 1 secret 存储检索 secret。

流程

  1. community.hashi_vault 模块 复制到以下 hashicorp.vault.kv1_secret_secret_info 参数。

      engine_mount_point:
        description: KV secrets engine mount point.
        default: secret
        type: str
        aliases: [secret_mount_path]
      path:
        description:
          - Specifies the path of the secret.
        required: true
        type: str
        aliases: [secret_path]
    extends_documentation_fragment:
      - hashicorp.vault.vault_auth.modules
  2. (必需)配置 path 参数。这是 community.hashi_vault.hashi_vault 模块中 secret 的路径。alias: secret_path
  3. 如果需要,配置 可选参数
2.3.1.3. 配置 hashicorp.vault.kv1_secret_get 查找插件

hashicorp.vault.kv1_secret_get 查找插件模块读取 KV1 secret。

对应的 community.hashi_vault 模块有:

  • community.hashi_vault.hashi_vault : 从 HashiCorp Vault 中检索 secret。
  • community.hashi_vault.vault_kv1_get 查找 从 HashiCorp Vault KV 版本 1 secret 存储获取 secret。

流程

  1. community.hashi_vault 模块复制到以下 hashicorp.vault.kv1_secret_get 参数。

    auth_method:
      description: Authentication method to use.
      choices: ['token', 'approle']
      default: token
      type: str
    engine_mount_point:
      description:
        - The KV secrets engine mount point.
      default: secret
      type: str
      aliases: ['mount_point', 'secret_mount_path']
    secret:
      description:
        - The Vault path to the secret being requested.
      required: true
      type: str
      aliases: ['secret_path']
  2. (必需)配置 secret 参数。这会映射到 community.hashi_vault.hashi_vault 模块中的 secret。alias: secret_path
  3. 如果需要,配置 可选参数

后续步骤

以下示例显示了 hashicorp.vault.kv1_secret_info 模块的 before 和 after 配置。

示例:

before (community.hashi_vault)

- name: Read a kv1 secret from Vault (community collection)
  community.hashi_vault.vault_kv1_get:
    url: https://vault:8201
    token: "{{ vault_token }}"
    path: hello
  register: response

after (hashicorp.vault)

- name: Read a kv1 secret from Vault (hashicorp.vault collection)
  hashicorp.vault.kv1_secret_info:
    url: https://vault.example.com:8201
    token: "{{ vault_token }}"
    path: sample

以下示例显示了 KV1 secret get lookup。

示例:

before (community.hashi_vault)

- name: Retrieve a secret from the Vault
  ansible.builtin.debug:
    msg: "{{ lookup('community.hashi_vault.vault_kv1_get', 'hello', url='https://vault:8201') }}"

after (hashicorp.vault)

- name: Retrieve a secret from the Vault
  ansible.builtin.debug:
    msg: "{{ lookup('hashicorp.vault.kv1_secret_get',
                    secret='hello',
                    url='https://myvault_url:8201') }}"

2.3.2. 配置 KV2 模块

如果您将 KV2 与 community.hashi_vault 集合搭配使用,请在 hashicorp.vault 集合中配置对应的模块。

2.3.2.1. 配置 hashicorp.vault.kv2_secret 模块

hashicorp.vault.kv2_secret 模块通过统一接口在 KV2 secret 上执行 Create、Update 和 Delete (CRUD)操作。

对应的 community.hashi_vault 模块有:

  • community.hashi_vault.vault_kv2_write - Write KV2 secret。
  • community.hashi_vault.vault_kv2_delete - Delete KV2 secret。

先决条件

  • 安装 Ansible Automation Platform 认证的 hashicorp.vault 集合。

流程

  1. 将两个 community.hashi_vault 模块中的自动化任务复制到以下 hashicorp.vault.kv2_secret 参数。hashicorp.vault.kv2_secret 参数与 community.hashi_vault 类似。

    auth_method:
     description: Authentication method to use
     type: str
     choices: [token, approle]
     default: token
     required: false
    
    cas:
     description: Perform a check-and-set operation.
     type: int
     required: false
    
    data:
     description: KV2 secret data to write.
     type: dict
     required: true
    
    engine_mount_point:
     description: The path where the secret backend is mounted.
     type: str
     default: secret
     required: false
     aliases: [secret_mount_path]
    
    namespace:
     description: Vault namespace where secrets reside.
     type: str
     default: admin
     aliases: [vault_namespace]
    
    path:
     description: Vault KVv2 path to be written to.
     type: str
     required: true
     aliases: [secret_path]
    
    url:
     description: URL of the Vault service
     type: str
     aliases: [vault_address]
     required: true
    
    versions:
     description: One or more versions of the secret to delete.
     type: list of int
     required: false
    
    state:
     description: Desired state of the secret
     type: str
     choices: [present, absent]
     default: present
  2. 您必须将 state 参数添加到 hashicorp.vault.kv2_secret 模块中,如上所示。有效选项有:

    • present 这等同于在 community.hashi_vault.vault_kv2 模块中创建或更新。
    • absent 这等同于在 community.hashi_vault.vault_kv2 模块 中删除 secret
2.3.2.2. 配置 hashicorp.vault.kv2_secret_info 模块

hashicorp.vault.kv2_secret_info 模块读取 KV2 secret。

对应的 community.hashi_vault 模块为:

  • community.hashi_vault.vault_kv2_get 从 HashiCorp Vault KV 版本 2 secret 存储获取 secret。

流程

  1. community.hashi_vault 模块复制到以下 hashicorp.vault.kv2_secret_info 参数。

      engine_mount_point:
        description: KV secrets engine mount point.
        default: secret
        type: str
        aliases: [secret_mount_path]
      path:
        description: Path to the secret.
        required: true
        type: str
        aliases: [secret_path]
      version:
        description: The version to retrieve.
        type: int
    extends_documentation_fragment:
      - hashicorp.vault.vault_auth.modules
  2. 配置所需参数:

    • Path : secret 位于 community 中的路径。hashi_vault.hashi_vault 模块。alias: secret_path
    • URL :映射到 community.hashi_vault.hashi_vault 模块中的 url。使用与 vault_address 相同的别名。
  3. 如果需要,配置 可选参数
2.3.2.3. 配置 hashicorp.vault.kv2_secret_get 查找插件

hashicorp.vault.kv2_secret_get 查找插件模块读取 KV2 secret。

对应的 community.hashi_vault 模块有:

  • community.hashi_vault.hashi_vault : 从 HashiCorp Vault 中检索 secret。
  • community.hashi_vault.vault_kv2_get 查找 : 从 HashiCorp Vault KV 版本 2 secret 存储获取 secret。

流程

  1. community.hashi_vault 模块复制到以下 hashicorp.vault.kv2_secret_get 参数。

    auth_method:
     description: Authentication method to use
     type: str
     choices: [token, approle]
     default: token
     required: false
    
    mount_point:
     description: Vault mount point
     type: str
     required: false
     aliases: [secret_mount_path]
    
    namespace:
     description: Vault namespace where secrets reside.
     type: str
     default: admin
     aliases: [vault_namespace]
    secret:
     description: Vault path to the secret being requested in the format path[:field]
     type: str
     required: true
     aliases: [secret_path]
    
    url:
     description: URL of the Vault service
     type: str
     aliases: [vault_address]
     required: true
    
    version:
     description: Specifies the version to return. If not set the latest is returned.
     type: int
     required: false
  2. 使用以下指导来配置 hashicorp.vault.kv2_secret_get 参数:

    • auth_method: 映射与 community.hashi_vault.hashi_vault.hashi_vault 模块中的 auth_method 相同。
    • mount_point :映射到 community.hashi_vault.hashi_vault 模块中的 mount_point别名: secret_mount_path
    • Namespace :映射到 community.hashi_vault.hashi_vault 模块中的命名空间。别名: vault_namespace.
    • Secret :映射到 community.hashi_vault.hashi_vault 模块中的 secret
    • URL :映射到 community.hashi_vault.hashi_vault 模块中的 url。使用与 vault_address 相同的别名。
    • Version : 映射到 community.hashi_vault.hashi_vault 模块中的 版本

后续步骤

2.3.2.4. hashicorp.vault.kv2_secret 模块的迁移示例

以下示例显示了 hashicorp.vault.kv2_secret 模块配置的基本前后配置。

注意

KV2 删除 操作是软删除

示例 1: Basic Secret Write/Create

before (community.hashi_vault):

- name: Write/create a secret
  community.hashi_vault.vault_kv2_write:
    url: https://vault:8200
    path: hello
    data:
      foo: bar

之后(使用corp.vault):

- name: Write/create a secret
  hashicorp.vault.kv2_secret:
    url: https://vault:8200
    path: hello
    data:
      foo: bar

示例 2:基本 Secret 删除

before (community.hashi_vault):

- name: Delete the latest version of the secret/mysecret secret.
  community.hashi_vault.vault_kv2_delete:
    url: https://vault:8201
    path: secret/mysecret

之后(使用corp.vault):

- name: Delete the latest version of the secret/mysecret secret.
  hashicorp.vault.kv2_secret:
    url: https://vault:8201
    path: secret/mysecret
    state: absent

示例 3: Secret Delete - 特定版本

before (community.hashi_vault):

- name: Delete versions 1 and 3 of the secret/mysecret secret.
  community.hashi_vault.vault_kv2_delete:
    url: https://vault:8201
    path: secret/mysecret
    versions: [1, 3]

之后(使用corp.vault):

- name: Delete versions 1 and 3 of the secret/mysecret secret.
  hashicorp.vault.kv2_secret:
    url: https://vault:8201
    path: secret/mysecret
    versions: [1, 3]
    state: absent

以下示例显示 hashicorp.vault.kv2_secret_info 模块的 before 和 after 配置。

示例 1:使用令牌身份验证读取 secret

before (community.hashi_vault)

- name: Read the latest version of a kv2 secret from Vault  community.hashi_vault.vault_kv2_get:
    url: https://vault.example.com:8200
    token: "{{ vault_token }}"
    path: myapp/config
  register: response

after (hashicorp.vault)

- name: Read a secret with token authentication
  hashicorp.vault.kv2_secret_info:
    url: https://vault.example.com:8200
    token: "{{ vault_token }}"
    path: myapp/config

示例 2:使用特定版本读取 secret

before (community.hashi.vault)

- name: Read version 5 of a secret from kv2
  community.hashi_vault.vault_kv2_get:
    url: https://vault.example.com:8200
    path: myapp/config
    version: 5

after (hashicorp.vault)

- name: Read a secret with a specific version
  hashicorp.vault.kv2_secret_info:
    url: https://vault.example.com:8200
    path: myapp/config
    version: 1

以下示例显示了获取最新版本的 KV2 secret get lookup。

示例:

before (community.hashi_vault)

- name: Return latest KV v2 secret from path
  ansible.builtin.debug:
    msg: "{{ lookup('community.hashi_vault.hashi_vault', 'secret=secret/data/hello
  token=my_vault_token
  url=http://myvault_url:8200') }}"

之后(hicorp.vault)

name: Return latest KV v2 secret from path
  ansible.builtin.debug:
    msg: "{{ lookup('hashicorp.vault.kv2_secret_get', 'secret=secret/data/hello
  url=http://myvault_url:8200') }}"

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部