在云端漫步与 Ansible

今天是个好日子，当我们遇到这样的日子时，我们常常会感觉像是在云端漫步。随着最新的 Red Hat Ansible Certified Collections 公告于 11 月 28 日发布，我相信许多云从业者会期待他们云自动化技术的未来会是什么样的。

在过去的几个月里，Ansible 团队一直在进行相当多的活动，展示了 Red Hat Ansible Automation Platform 如何扩展和连接不同的技术。这对许多客户来说，一直是 Ansible 在云自动化方面取得成功的关键因素。

云自动化需要能够执行许多不同的复杂任务，并涵盖同样多的领域。通常，组织使用不同的技术来满足特定的需求和需求。广泛使用的技术之一是 Terraform。

我们最近发布了许多关于此主题的博客文章，内容从使用 Terraform 与 Ansible Automation Platform 的简单示例，到深入探讨工具之间的差异。AnsibleFest 2022 甚至提供了一个实验室，让我们能够通过自动化控制器使用 Terraform，允许我们集中使用 Terraform 对云基础设施进行配置和取消配置，同时通过 Ansible 运行配置后配置。

传统上，用于与 Terraform 协作的模块来自社区，但是，随着对具有 Red Hat 支持的官方集合的需求增加，我们宣布了 cloud.terraform，一个针对 Terraform 的 Red Hat Ansible Certified Collection。

那么，cloud.terraform 集合是什么呢？

此集合已于今天在 Ansible 自动化中心发布，允许在自动化执行环境中使用 Terraform 对云基础设施进行管理和配置。该集合目前包含两个模块和示例角色，以帮助您将 Terraform 工作负载以认证和支持的方式引入 Ansible Automation Platform。

这些模块允许 Ansible 应用 Terraform 计划以及配置和取消配置基础设施。目前，我们支持 AWS、Azure 和 Google Cloud 作为 Terraform 的提供商，并支持 azurerm、gcs 和 s3 作为后端。值得注意的是，我们不支持 Terraform 的本地后端，主要原因有两个。首先，许多 Terraform 从业者同意，在生产环境中使用本地后端并不是最佳实践，其次，由于我们从执行环境触发自动化，因此本地后端存储在每次执行时并不持久或相同。

让我们看看在 Ansible Playbook 中模块的使用情况如何。

模块： cloud.terraform.terraform

此模块取代了当前的 community.general.terraform 模块，用于提供通用功能。

… example:

- name: Apply plan
  cloud.terraform.terraform:
    project_path: "{{ repo_dir }}"
    plan_file: "{{ plan_file }}"
    state: present  # applying a plan doesn't have a switch for this
    # optional config
    state_file: "{{ terraform_options.state_file | default(omit) }}"
    force_init: "{{ terraform_options.force_init | default(omit) }}"
    binary_path: "{{ terraform_options.binary_path | default(omit) }}"
    plugin_paths: "{{ terraform_options.plugin_paths | default(omit) }}"
    workspace: "{{ terraform_options.workspace | default(omit) }}"
    lock: "{{ terraform_options.lock | default(omit) }}"
    lock_timeout: "{{ terraform_options.lock_timeout | default(omit) }}"
    parallelism: "{{ terraform_options.parallelism | default(omit) }}"

模块： cloud.terraform.output

此模块允许我们从 Terraform 状态文件提取值，并允许您将其存储为事实。

… example:

- name: Read outputs from state file
  cloud.terraform.terraform_output:
    state_file: "{{ state_file }}"
  register: terraform_output_state_file
  when: state_file is defined

- name: Add hosts from terraform_output
  ansible.builtin.add_host:
   name: "{{ item[mapping_variables.name] }}"
    groups: "{{ item[mapping_variables.group] }}"
    ansible_host: "{{ item[mapping_variables.ip] }}"
    ansible_user: "{{ item[mapping_variables.user] }}"
  loop: "{{ terraform_output.outputs[mapping_variables.host_list].value }}"
  vars:
    terraform_output: "{{ (terraform_output_project_path is success) | ternary(terraform_output_project_path,
terraform_output_state_file) }}”

除了这些模块之外，该集合还包含两个示例角色，用于从 Git 存储库检索项目文件，以及一个用于在上述示例中创建内存中清单的角色。

Ansible Automation Platform 与 Terraform，为什么呢？

虽然 Ansible 和 Terraform 都可以配置基础设施和云工作负载，但许多客户发现他们使用 Terraform 的原因是它易于使用基础设施即代码，然而，在配置完成后，Terraform 工具存在一个差距。能够使用 Ansible 使我们能够解决这个问题，并为这两个工具带来一个完全自动化的工作流程。这也意味着那些花费时间和金钱构建 Terraform 清单的客户无需替换 Terraform，而是允许 Ansible Automation Platform 协调配置和配置管理。这些工具协作效果更佳！

这仅仅是开始，但未来将会更加美好！

使用更新的 Ansible 内容集合批量查找和删除 ServiceNow 记录

您是否曾经需要查询和删除很长的 ServiceNow 记录列表？是的，直到最近我还没有这样做。没有人入侵我的实例，这不是一次性操作，我只是碰巧维护一个实例，我们使用它来测试针对 ServiceNow ITSM 的 Red Hat Ansible Certified Content Collection。

为了设置环境，我使用一个演示系统和另一个工作流程来创建一个随机用户，然后让学习者使用完整的 Red Hat Ansible Automation Platform 部署和共享的 ServiceNow 实例来完成一些挑战。因为这是一个真实的实例，所以无法知道学习者会创建哪些类型的记录。因此，我最近不得不开发一些自动化功能来清理这些演示用户帐户创建的记录。

虽然我的用例是清理演示用户帐户，但这同样可以是一个需要清理错误记录的关键 ServiceNow 实例。此集合可以用来创建、更新、修改或删除 ServiceNow 上几乎任何内容。

如果您正在关注，请确保安装 servicenow.itsm 集合的版本，该版本等于或大于 2.0.0（社区在 Ansible Galaxy | 认证在 Ansible 自动化中心）。

我是如何做到的？

使用 sys_tags

我在 ServiceNow 中设置了一个标签，该标签会应用于这些演示用户创建的所有内容。我喜欢这种方法，因为标签创建和自动应用标签是可以通过权限限制到具有高级权限的帐户的操作。该标签会应用于用户创建的任何记录，作为我的动手实验室的一部分，这有助于我找到和清理这些特定用户创建的任何内容。首先，我需要获取标签的 sys_id（这类似于特定记录的全局 ID）。为此，我利用 servicenow.itsm 集合中针对 ServiceNow 标签表的 API 模块。

- name: Find tag ID by name
  servicenow.itsm.api_info:
    resource: label
    sysparm_query: name={{ tag_name }}
      columns:
        - name
        - sys_id
  register: tag_info

找到合适的标签后，我可以在事件表中查询具有该标签应用的活动记录。

- name: Get tagged incidents
  servicenow.itsm.incident_info:
    sysparm_query:
    sys_tags.{{ tag_info.record[0].sys_id }}={{ tag_info.record[0].sys_id }}
    ^active=true
    sysparm_display_value: false
  register: incidents

什么是 sysparm_display_value？ 好吧，这是一个好问题。此参数指示我的查询返回实际值，而不是显示值。显示值根据字段类型而有所不同，在这种情况下，sys_tags 不包含查询返回的标签名称。将此参数设置为 false 表示此查询返回实际值。

在查询了事件表中具有该标签应用的所有活动记录，并将输出注册为名为 incidents 的变量后，我想通过创建一个包含事件编号和打开日期/时间的对象数组来简化操作。

- name: query incident number and creation time
  ansible.builtin.set_fact:
    incident_list: '{{ incident_list + [{"number": item.number, "opened_at": item.opened_at}] }}'
  loop: "{{ incidents.json.result }}"
  when: incidents

数组中的每个对象应类似于

- number: INC00001234
  opened_at: 2022-04-26 18:34:16

对于我的用例，拥有记录创建的时间非常有用。我不想销毁创建不到两小时的记录。毕竟，我不想删除学习者在进行挑战时正在使用的记录。

最后一个任务是获取我的事件列表，如果它们超过两个小时，则删除它们。为此，我使用 servicenow.itsm.incident 模块和一些针对记录创建时间的条件检查。

- name: close old incidents from list
  servicenow.itsm.incident:
    state: closed
    number: "{{ item.number }}"
    close_code: "Solved (Permanently)"
    close_notes: "Closed with ansible servicenow.itsm"
  loop: "{{ incident_list }}"
  when:
    - incident_list is defined
    - (( (ansible_date_time.date + ' ' + ansible_date_time.time) | to_datetime) - (item.opened_at | to_datetime)).total_seconds() > 7200

请注意 when 下的第二行？ 它的外观并不完美，但它基本上确保了两种时间格式相同，然后才尝试评估两个日期之间的秒差。第一个日期/时间是当前执行时间，第二个日期/时间是记录创建的时间。如果差异大于两小时（7200 秒），则条件为真，任务继续执行，记录被关闭。

不使用 sys_tags

如果我没有将标签自动应用于所有这些记录，该怎么办？在这种情况下，我可以使用 servicenow.itsm.*_info 模块按其他键查询记录。例如，我可以查询和关闭由特定用户创建的所有活动事件记录。

- name: find user created incidents
  servicenow.itsm.incident_info:
    query:
        - sys_created_by: = {{ username }}
        active: = true
  register: incidents

- name: query incident number and creation time
  ansible.builtin.set_fact:
    incident_list: '{{ incident_list + [{"number": item.number, "opened_at": item.opened_at}] }}'
  loop: "{{ incidents.records }}"
  when: incidents

- name: close incidents from list
  servicenow.itsm.incident:
    state: closed
    number: "{{ item.number }}"
    close_code: "Solved (Permanently)"
    close_notes: "Closed with ansible servicenow.itsm"
    other:
      active: false
  loop: "{{ incident_list }}"
  when:
    - incident_list is defined

完成图片

我有一些执行类似任务的任务，用于不同的记录类型，例如问题、变更请求等，但它们都遵循与上面显示的任务相同的模式。我将这些任务安排在自动化控制器中的工作流程中，该工作流程每天执行以保持此 ServiceNow 实例整洁。

ServiceNow ITSM 的 2.0.0 版本通过引入性能改进和新的 API 模块来执行任意表上的操作，使所有这些任务变得更加容易。例如，您可能希望将角色附加到用户。通过针对 sys_user_has_role 表利用 API 模块，这变得非常容易。

- name: attach role to new user
  servicenow.itsm.api:
    resource: sys_user_has_role
    action: post
    data:
      user: "{{ username }}"
      role: "{{ role }}"

太棒了！

这可能是非标准操作。您通常为什么要销毁或关闭组织的事实来源中的记录？我不确定！我所知道的是，通过利用 Ansible Automation Platform 和针对 ServiceNow ITSM 的 Red Hat Ansible 认证内容集合，将您组织的自动化策略扩展到其他主要 ITSM 流程变得更加容易。

还有其他问题吗？

是的！您知道有一个地方可以获得 Ansible Automation Platform 的实践经验吗？就在 这里！在那里您将找到我的 ServiceNow 自动化挑战，这些挑战将引导您完成我用来保持我的实例整洁并更新 CMDB 的集合的功能。