HashiCorp 和 Ansible Automation Platform 入门
将 HashiCorp 产品与 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 上的集合。)
流程
- 登录到 Ansible Automation Platform。
- 在导航面板中,选择 → → 。
- 单击 。Create Credential Type 页面将打开并显示 Details 选项卡。
- 对于 Name 字段,输入凭证类型名称。
在 Input configuration 字段中输入以下参数和值:
fields: - id: token type: string label: token secret: true在 Injector 配置 字段中,输入以下配置:
env: TF_TOKEN: ‘{{ token }}’- 要保存配置,请再次点击 Create Credential Type。创建新凭证类型。
后续步骤
1.2.1.2. 创建凭证 复制链接链接已复制到粘贴板!
用户必须创建一个凭据,以用于 Ansible Automation Platform 中的作业模板。
前提条件
- 您必须具有 Terraform API 令牌。
- 您的管理员创建了自定义凭证类型。
流程
- 登录到 Ansible Automation Platform。
- 在导航面板中,选择 → → ,然后选择 。
- 从 Credential type 列表中,选择凭证类型。显示的字段取决于凭证类型。
- 在 Token 字段中输入 Terraform API 令牌。
- (可选)编辑 Description 字段,并从 Organization 列表中选择 TF 机构。
- 单击 。您已准备好在作业模板中使用凭证。
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 上的集合。)
流程
- 登录到 Ansible Automation Platform。
- 在导航面板中,选择 → → 。
- 单击 。Create Credential Type 页面将打开并显示 Details 选项卡。
- 对于 凭据类型, 请输入名称。
在 Input configuration 字段中输入以下 YAML 参数和值:
fields: - id: token type: string label: token secret: true在 Injector 配置 字段中,输入以下配置。
对于 Terraform Enterprise,主机名是您部署 TFE 的位置:
env: TF_TOKEN_<hostname>: ‘{{ token }}’对于 HCP Terraform,请使用:
env: TF_TOKEN_app_terraform_io: ‘{{ token }}’
- 要保存配置,请再次点击 。创建新凭证类型。
- 要创建新凭证类型的实例,请选择 → → 页面,然后选择 。
- 从 Credential type 中选择您之前创建的凭证类型的名称。
- 在 Token 字段中输入 Terraform API 令牌。
- (可选)编辑 Description 并从 Organization 列表中选择 TF 机构。
- 单击 。
1.2.2.2. 在 Ansible Automation Platform 中构建执行环境 复制链接链接已复制到粘贴板!
您必须使用自动化控制器构建执行环境,以便 Ansible Automation Platform 可以提供使用自动化功能所需的凭证。
先决条件
在使用自动化控制器创建前,您需要一个具有最新版本的
cloud.terraform集合的预先存在的执行环境。您不能使用 Ansible Automation Platform 提供的默认执行环境,因为默认环境不包括terraformCLI 二进制文件。注意如果您已从 Terraform 社区版迁移,您可以继续使用现有的执行环境,并将其更新至最新版本的
cloud.terraform。-
在预先存在的执行环境中安装
terraformCLI 二进制文件。有关二进制文件的链接,请参阅下面的 附加资源。
流程
- 在导航面板中,选择 → → 。
单击 。
- 对于 Name,输入 Ansible Automation Platform 执行环境的名称。
- 对于 Image,输入到您预先存在的执行环境的镜像的存储库链接。
- 单击 。您新添加的执行环境已准备好在作业模板中使用。
1.2.2.3. 创建并启动作业模板 复制链接链接已复制到粘贴板!
创建并启动作业模板来完成集成并使用 Ansible Automation Platform 中的自动化功能。
流程
- 在导航面板中,选择 → 。
- 选择 Create template > Create Job Template。
- 从 Execution Environment 列表中,选择您创建的环境。
- 从 Credentials 列表中,选择您之前创建的凭据实例。如果没有看到凭证,请点击 来查看列表中的更多选项。
- 为必填字段输入任何其他信息。
- 单击 。
- 点 。
- 要启动作业,请单击 和 。作业输出显示作业已运行。
验证
要查看作业已从 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。
1.3.1.1. 配置 hashicorp.terraform.configuration_version 模块 复制链接链接已复制到粘贴板!
要迁移到 hashicorp.terraform 集合,您必须配置 hashicorp.terraform.configuration_version 模块。此模块管理 Terraform Enterprise 或 HCP Terraform 中的配置版本。
先决条件
-
安装 Ansible Automation Platform 认证
有hicorp.terraform集合。 - 验证在 Terraform Enterprise 或 HCP Terraform 中正确设置了有效的机构和工作区。
流程
从
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配置以下所需参数:
-
workspace_id或workspace+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)。
-
- 根据需要设置其他 可选参数。
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 中正确设置了有效的机构和工作区。
流程
创建 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配置以下所需参数:
-
workspace_id或workspace+organization: 将创建配置版本的工作区 ID 或工作区名称和组织,该文件将被上传(表示state: present)。 -
run_id: 要应用、取消或丢弃操作的目标的唯一标识符。 -
tf_token: Terraform API 身份验证令牌。如果没有设置这个值,则使用TF_TOKEN环境变量。
-
(可选)配置内置的轮询选项,以确定 Terraform Enterprise 或 HCP Terraform 操作的等待周期完成:
-
poll: true:(默认)每poll_interval秒(默认为 5s)检查运行状态,直到达到 completion 或poll_timeout(default: 25s)为止,返回最终状态。 -
poll: false: 在启动运行后立即返回,而不等待。
-
- 根据需要设置其他 可选参数。
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):生成计划:
- 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应用计划:
- 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):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 模块具有两个用于计划和应用工作流的选项:
选项 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运行,然后应用它:创建计划:
- 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应用计划。您可以从 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-migrateCLI 指令进行操作。 - 确保 HCP Terraform 或 TFE 工作区没有设置为自动应用计划。
流程
要防止针对 TFE 或 HCP Terraform 运行 playbook 时的错误,请在运行 playbook 前执行以下操作:
- 确认执行环境中的 Terraform 版本与 TFE 或 HCP Terraform 中声明的版本相同。
在 TFE 或 HCP Terraform 中执行初始化:
terraform init- 如果您在执行环境中有一个本地状态文件,请删除本地状态文件。
- 从 HCP Terraform 或 Terraform Enterprise 获取令牌,您将用来在后续步骤中创建凭证。确保令牌具有必要的权限,基于团队或用户令牌在 playbook 中执行所需的功能。
- 从 playbook 定义中删除后端配置文件和文件。
如果要在 TF 配置中的默认设置或环境变量中添加工作区,如果要定义在更新 playbook 本身外的工作空间。
注意您可以将工作区添加到 playbook 中,以扩展工作空间利用率。
在 Ansible Automation Platform 用户界面中:
(可选)在迁移完成后,您可以从执行环境中的集合运行额外的模块和插件:
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),限制令牌访问,并完全控制令牌生命周期。
流程
创建 Terraform 配置(
.tf)文件。包括一个providerblock。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 ] }添加配置参数,如上例中所示。您必须配置主机和凭证。在
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环境变量来配置。
-
- (可选)您可以在这些配置参数的值中使用 表达式,但只能引用应用配置前已知的值。
-
(可选)您还可以使用由 Terraform 定义并可用于所有供应商块
的别名meta-argument。别名可让您为不同的资源使用不同的配置相同的供应商。
1.4.2. 使用 TF 操作和 Ansible Automation Platform 复制链接链接已复制到粘贴板!
在 Ansible Automation Platform 中使用 Terraform (TF)操作在基础架构置备后触发自动配置。
1.4.2.1. 关于 Terraform 操作和 Ansible Automation Platform 复制链接链接已复制到粘贴板!
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 帐户。您可以调整模式,以使用不同的云供应商。
您已配置了作业模板:
- 清单设置为 启动时提示。
- 与本地文件中可用的公钥匹配的机器凭据(私钥)。
流程
-
在 5.2.
tf文件中定义aap_job_launch操作。 添加生命周期作业块,以定义在正确的生命周期事件触发器期间调用哪些操作。
示例
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
}
}
- (必需)将本示例中的作业模板名称和清单名称改为您的对应变量。
-
(可选)您可以将所有者设置为 Red Hat RHEL 镜像 ID,以便每次作业运行时都会使用最新的镜像。
-
(可选)根据需要设置 附加参数。例如,您可以将
wait_for_completion设置为true,然后 Terraform 将等待到创建此作业并达到任何最终状态,然后再继续。您还可以设置wait_for_completion_timeout_seconds来控制超时限制。 - 更新并提交 Terraform 代码。
- 执行 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。
- 与本地文件中可用的公钥匹配的机器凭据(私钥)。
流程
- 登录到 Ansible Automation Platform 用户界面。
- 导航到 → 。
- 点 。
在 Create event stream 页面中,编辑字段:
-
名称 : 您的事件流的描述性、唯一名称(如
Terraform provider_Events)。 -
Organization : 选择此事件流将属于的机构(通常为
Default或 your specific organization)。 - event stream type : 选择与您要接收事件匹配的类型。此集成支持 基本事件流 (用户名/密码)。
- 凭证 : 选择一个您预先创建用于使用此事件流进行身份验证的凭证。
- headers :(可选)输入您要包含在转发到规则规则的事件有效负载中的以逗号分隔的 HTTP 标头键。保留此为空以包括所有标头。
- 将事件转发到规则手册激活 : 此选项通常默认启用。禁用它可用于测试和诊断您的连接和传入的数据,而不会意外地触发任何自动化。
-
名称 : 您的事件流的描述性、唯一名称(如
点 。然后导航到 → ,以验证事件流是否已创建并查看目前收到的事件数量。
您还可以点击特定流来查看其详细配置,包括机构、事件流类型、关联的凭证和事件转发设置。
设置 规则手册激活。确保:
- 将事件流添加到规则手册中。
- (推荐)选择 启用 Rulebook 激活? 选项,以在创建后自动启动激活。
- 激活规则手册。
- 选择 → ,以验证规则手册是否活跃并检查其状态。
1.4.2.3.2. 配置 TF 操作 复制链接链接已复制到粘贴板!
要将事件流连接到 Terraform 操作,您可以在 Terraform 中配置主 TF 文件( {tf)。
流程
添加一个 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 } } }(必需)配置以下参数:
event-Driven Ansible 事件流的
event_stream_config: (Attributes) Details。您必须包括:-
用户名:( 字符串)在执行 POST 到事件流 URL 时使用的用户名 -
Password : (字符串)在执行 POST 到事件流 URL 时
使用的密码 -
URL : (字符串)用于接收事件 POST 的 URL
-
-
限制: (字符串)Ansible Automation Platform 对作业执行的限制 -
organization_name:( 字符串)机构名称 -
template_type: (字符串)模板类型:job或workflow_job
-
(可选)您可以将所有者设置为 Red Hat RHEL 镜像 ID,以便每次作业运行时都会使用最新的镜像。
- (可选)根据需要设置 附加参数。
配置与事件有效负载规格和目标规则手册映射的操作集成。
示例:
- 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 事件后,您可以创建并应用计划来触发事件。
流程
-
运行
terraform init以初始化您的工作目录。 使用
terraform 计划提交来创建计划。以下示例将计划保存到名为tfplan.out的文件,但您可以为计划指定任何名称。保存计划是自动化的最佳做法,因为保存的计划严格强制执行。terraform plan -out=tfplan.out- 检查计划输出。
应用已保存的计划。
terraform apply tfplan.out这会创建事件并将其发送到指定的事件流。当创建每个资源时,会调用 TF 操作,并按顺序执行对应的 Ansible Automation Platform playbook。
验证
- 验证在 Terraform 用户界面中是否更新了运行。深入到资源上,以查看调用该操作和执行后事件。
在 Ansible Automation Platform 用户界面中,验证事件是否被(EDAName})成功接收,并触发适当的规则手册激活:
- 检查 Event Streams 仪表板,以查看收到 TF Actions 事件。
- 检查 Jobs 仪表板,以查看按顺序运行的作业以及 Success 状态。
- 检查 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.vault 和 hashi.terraform 集合相互独立工作,但专为不同的任务设计,您可以在高级工作流中同时使用它们。
2.2. 向 hashicorp.vault进行身份验证 复制链接链接已复制到粘贴板!
安装或迁移到 hashicorp.vault 集合后,会在 Ansible Automation Platform 用户界面中配置身份验证。管理员创建自定义凭证类型来向 Vault 进行身份验证。然后,用户创建用于作业模板的凭证。
2.2.1. 身份验证架构 复制链接链接已复制到粘贴板!
hashicorp.vault 集合通过环境变量和客户端初始化来管理身份验证。这种方法通过防止敏感凭据直接作为 playbook 任务中的模块参数传递来提高安全性。
hashicorp.vault 集合使用环境变量将凭证注入到作业模板中,因此您可以在确保身份验证详情保持安全的情况下获得更简单、干净的任务定义。
支持以下身份验证类型:
Approle 身份验证 : 在使用 appRole 身份验证时,使用以下方法之一:
-
设置
VAULT_APPROLE_ROLE_ID和VAULT_APPROLE_SECRET_ID环境变量。使用环境变量时,还必须创建一个将传递给作业模板的自定义凭证类型和凭证。 将
role_id和secret_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)身份验证,或者允许用户直接提供令牌。
先决条件
执行以下操作之一 :
-
新用户: 从 Automation Hub 安装 Ansible Automation Platform 认证的
hicorp.vault集合。https://www.redhat.com/en/technologies/management/ansible/automation-hub -
community.hashi_vault集合用户: 从community.hashi_vault迁移。如需更多信息,请参阅从community.hashi_vault迁移。
流程
- 登录到 Ansible Automation Platform。
- 在导航面板中,选择 → → 。
- 单击 。Create Credential Type 页面将打开。
- 在对应的字段中输入名称和描述。
如果要为单个用户配置令牌身份验证:
对于 输入配置,请输入:
fields: - id: vault_token type: string label: Hashicorp Vault Token secret: true对于 Injector 配置,请输入:
env: VAULT_TOKEN: '{{ vault_token }}'
如果要使用
role_id和secret_id配置 appRole 身份验证:对于 输入配置,请输入:
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对于 Injector 配置,请输入:
env: VAULT_APPROLE_ROLE_ID: '{{ vault_approle_role_id }}' VAULT_APPROLE_SECRET_ID: '{{ vault_approle_secret_id }}'
- 单击 。
后续步骤
其他资源
2.2.3. 创建自定义凭证 复制链接链接已复制到粘贴板!
Vault 用户必须创建一个自定义凭证,以用于 Ansible Automation Platform 中的作业模板。
前提条件
- 您的管理员创建了 Vault 凭证类型。
流程
- 登录到 Ansible Automation Platform。
- 在导航面板中,选择 → → ,然后选择 。
- 在对应的字段中输入名称和描述。
- (可选)从 Organization 列表中选择一个机构。
- 从 Credential type 列表中,选择 Vault 凭据类型。显示的字段取决于凭证类型。
执行以下操作之一 :
- 对于令牌身份验证,请添加 Vault 令牌并根据需要编辑任何字段。
- 对于 appRole 验证方法,在 appRole 角色 ID 和 appRole Secret ID 字段中输入 ID。根据需要编辑任何其他字段。
- 单击 。您已准备好在作业模板中使用凭证。
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_method和state配置除默认值以外的内容。您可以使用 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。
流程
将
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-
(必需)配置
path参数。这是community.hashi_vault.hashi_vault模块中 secret 的路径。alias:secret_path - 如果需要,配置 可选参数。
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。
流程
将
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']-
(必需)配置 secret 参数。这会映射到
community.hashi_vault.hashi_vault模块中的 secret。alias:secret_path - 如果需要,配置 可选参数。
后续步骤
2.3.1.4. hashicorp.vault.kv1_secret_info 模块的迁移示例 复制链接链接已复制到粘贴板!
以下示例显示了 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
2.3.1.5. hashicorp.vault.kv1_secret_get 查找的迁移示例 复制链接链接已复制到粘贴板!
以下示例显示了 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集合。
流程
将两个
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您必须将
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。
流程
将
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配置所需参数:
-
Path: secret 位于 community 中的路径。hashi_vault.hashi_vault模块。alias:secret_path -
URL:映射到community.hashi_vault.hashi_vault模块中的url。使用与vault_address相同的别名。
-
- 如果需要,配置 可选参数。
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。
流程
将
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使用以下指导来配置
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
2.3.2.5. hashicorp.vault.kv2_secret_info 模块的迁移示例 复制链接链接已复制到粘贴板!
以下示例显示 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
2.3.2.6. hashicorp.vault.kv2_secret_get 查找的迁移示例 复制链接链接已复制到粘贴板!
以下示例显示了获取最新版本的 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') }}"