我们希望听到您的声音!帮助我们深入了解 Ansible 生态系统现状。
参与 Ansible 项目 2024 年调查

牛角号 #2

Ansible Bullhorn banner

牛角号

Ansible 开发者社区通讯

欢迎阅读牛角号,这是我们面向 Ansible 开发者社区的通讯。如果您有任何问题或想要分享的内容,请发送邮件至 [email protected] 联系我们。


AWX 项目发布 11.2.0 版本

4 月 29 日,AWX 团队发布了最新版本的 AWX,即 11.2.0。值得注意的变化包括:默认情况下,对于 Ansible 2.9 及更高版本,使用基于集合的插件;新的功能,能够在 CLI 中监视正在运行的作业和工作流作业的标准输出;增强了 Hashicorp Vault 凭据插件;以及一些错误修复。阅读 Rebeccah Hunter 的公告 此处。如需获取更频繁的 AWX 更新,您可以加入 AWX 项目邮件列表


Jeff Geerling 带你了解 Ansible 101:第 7 集

在他 Ansible 101 系列的 最新视频 中,Jeff Geerling 探讨了 Ansible Galaxy、ansible-lint、Molecule 以及基于其畅销书《Ansible for DevOps》内容的 Ansible 角色和剧本测试。您可以在 此处 找到他所有 Ansible 视频的完整频道。
 

调查:下次 Ansible 贡献者峰会日期

我们计划在 6 月下旬或 7 月初举办下一场为期一天的 Ansible 贡献者峰会线上会议,并且我们希望征求您对拟议日期的反馈意见。Carol Chen 已发布 Doodle 投票,其中包含一些可能的日期选项;如果您有兴趣参加,请填写投票,以便我们了解哪些日期最适合所有人。我们将于 5 月 22 日星期五关闭投票。
 

概念验证:使用 Knative 的无服务器 Ansible

William Oliveira 开发了一个新的概念验证,用于使用 Ansible 和 Knative 创建事件驱动的剧本。该概念验证是一个 Web 应用程序,可以按需执行剧本并将这些事件发送到 Knative 事件代理以触发其他应用程序。您可以在 GitHub 上找到源代码 此处

 

社区指标亮点:community.general 集合

随着 Ansible 社区的不断发展,我们越来越依赖指标来跟踪我们朝着目标取得的进展。继 第 1 期 中更通用的指标之后,我们还开始考虑除了所有集合的指标之外,我们可能还需要哪些特殊处理。community.general 就是一个这样的特殊情况——作为 Ansible 中大多数模块的所在地,它见证了许多贡献者的加入和离开,并且那里的内容可能会面临无人维护的风险。我们需要密切关注此存储库,以便我们能够根据需要采取行动。

下面是我们在准备的 仪表板 中的一个图表。此图表显示了每周打开和关闭的问题数量,以及一个简单的统计检验,以查看斜率是否不为零。目前两者都基本上是平坦的,表明打开和关闭问题的数量是平衡的。我们已经在该报告中添加了几个图表,并且将来会添加更多图表。

 

 

Ansible 线上聚会

下个月 Ansible 社区将举办以下线上聚会


Ansible 明尼阿波利斯:CyberArk 与 Ansible Automation 的集成

5 月 21 日星期四 · 美国中部时间下午 6:30

https://www.meetup.com/Ansible-Minneapolis/events/sbqkgrybchbcc/

 

Ansible 北弗吉尼亚州:春季酒会!

5 月 21 日星期四 · 美国东部时间下午 4:00

https://www.meetup.com/Ansible-NOVA/events/270368639/

 

Ansible 巴黎:网络研讨会 #1

5 月 14 日星期四 · 格林威治标准时间上午 11:00

https://www.meetup.com/Ansible-Paris/events/270584272/

 

我们正在计划更多线上聚会以覆盖更广泛的受众,并且我们希望听到您的声音!您最近是否开始使用 Ansible,或者您是长期用户?Ansible 如何改善您的工作流程或扩展您的自动化?您在使用过程中遇到过哪些挑战以及吸取了哪些教训?通过在 Ansible 线上聚会上进行演讲来分享您的经验:https://forms.gle/aG5zpVkXDVMHLERX9

您可以选择预先录制演示文稿,并在聚会期间参加现场问答环节,或者现场进行演示。我们将与您一起确定最佳设置,并与您分享一些很棒的 Ansible 纪念品!

 

反馈

有任何问题想问,或希望我们讨论的主题?请发送邮件至 [email protected] 联系我们。

 




2020 年 AnsibleFest 现已成为线上体验

2020 年 AnsibleFest 现已成为线上体验

每年,AnsibleFest 都是我们最喜欢的活动之一,因为它汇聚了我们的客户、合作伙伴、社区成员和 Red Hat 员工,共同探讨开源创新和最佳实践,这些创新和最佳实践正在推动企业技术和自动化的未来。

由于与会者的安全是我们的首要任务,因此我们已决定将 2020 年 AnsibleFest 打造为线上体验。我们很高兴能够与大家在虚拟空间中互动,并期待着在全球范围内扩展我们的交流。通过改变我们的活动平台,我们希望借此机会与以往任何时候都更多的自动化爱好者进行协作、互动和交流。能够有更多人参与自动化讨论,这令人兴奋。

AnsibleFest 线上体验将是 2020 年 10 月 12 日那一周举办的一场免费的、身临其境的为期多天的活动,它将提供及时且有用的客户主题演讲、分会场演讲、与 Ansible 专家直接互动等内容。您需要注册以保持联系并随时了解 AnsibleFest 的所有信息。

征集提案现已开放

我们仍在敲定线上活动的具体细节,但我们很高兴地宣布,提案征集现已开放,截止日期为 7 月 15 日。我们将在 Ansible 博客和 AnsibleFest 网站上发布更多信息(一旦可用)。敬请期待!

我们期待举办此次活动,并提前感谢大家为确保活动圆满成功而提供的协作。

常见问题

为什么取消了现场 AnsibleFest 活动?

我们一直在密切关注在圣地亚哥举办实体活动的可能性,并决定将 2020 年 AnsibleFest 重塑为线上活动。我们的目标是通过一场能够捕捉到 AnsibleFest 身临其境体验的线上庆祝活动来服务和支持 AnsibleFest 与会者,并让我们能够比以往欢迎更多观众。

除了现场活动之外,你们还会做些什么?

我们将举办 AnsibleFest 线上体验,这是一场 2020 年 10 月 13 日至 14 日举办的免费、身临其境的为期多天的活动,它将提供与 2020 年 AnsibleFest 相同的鼓舞人心的内容——主题演讲、分会场演讲、与专家互动等。我们仍在敲定线上活动的许多细节,但我们对有机会分享精心挑选的内容感到兴奋,这些内容将帮助您通过提供正确的自动化策略以及在不断变化的数字化旅程中取得成功所需的文化变革来改变您的组织。

在当今的云计算和 DevOps 世界中,自动化可用于实现开放的工作方式,以增强业务弹性和创新能力。

如何注册 AnsibleFest 线上体验?

注册信息和详细信息将在 6 月内公布。关注 Red Hat Ansible - \@ansible 推特,并在我们的网站 www.ansiblefest.com 上注册,以便在信息发布后第一时间获取。

AnsibleFest 线上体验是否有赞助机会?

是的,将提供赞助机会。这些机会将在今年夏天晚些时候发布。如有疑问,请联系 赞助团队

你们以后还会举办任何现场活动吗?

我们正在探索这种情况,并将宣布我们制定的任何计划。但目前,我们希望您能够在 10 月 13 日至 14 日参加我们的线上体验!

2021 年 AnsibleFest 是什么时候?

2021 年 AnsibleFest 的日期尚未确定。

观看主题演讲和与线上活动中的专家互动需要哪些软件?用户是否需要安装任何东西?

它将基于 Web,因此您只需要一台装有受支持浏览器的计算机和能够流式传输视频的互联网连接即可。此页面列出了桌面浏览器和操作系统的要求。

我已经预订了机票。我能获得退款吗?

我们提前很长时间宣布此事,希望在与会者预订旅行之前就通知到他们。不幸的是,我们无法为您预订的机票提供退款。请与您的航空公司或旅行社联系。许多航空公司都在免除更改费用或提供机票抵用券。




Active Directory 和 Ansible Tower

Active Directory & Ansible Tower

欢迎来到我们以 Windows 为中心的入门系列的第二部分!

上次我们介绍了 Ansible 如何连接到 Windows 主机。我们之前还探讨了在针对 LDAP 目录进行身份验证时登录 Ansible Tower 的方法。在这篇文章中,我们将介绍一些使用 Ansible 管理 Microsoft Active Directory 的方法。由于 AD 在许多 Windows 环境中发挥着作用,因此使用 Ansible 管理 Windows 可能包括对 Active Directory 域运行命令。

首先,设置协议

我们将使用 WinRM 连接到 Windows 主机,这意味着要确保 Ansible 或 Tower 知道这一点。Ansible Tower 中的机器凭据可以与变量一起创建和使用,但在终端中使用 Ansible 时,剧本应使用变量明确说明。

---
- name: Your Windows Playbook
  hosts: win
  vars:
    ansible_ssh_user: administrator
    ansible_ssh_pass: ThisIsWhereStrongPassesGo
    ansible_connection: winrm
    ansible_winrm_server_cert_validation: ignore

- tasks:

除了使用本地管理员帐户/密码外,WinRM 连接方法也具有特定名称。忽略证书验证的变量用于独立的非域主机,因为加入域的实例应在域上验证证书。

域在哪里?

说到域,Ansible 可以创建一个新的域(如果不存在)。

在以下示例中,Ansible(使用之前的设置)从服务器管理 win_feature 安装 AD 域服务功能,如果不存在域,则使用提供的 AD 安全模式密码 win_domain 创建新的 Active Directory 域。

- name: Install AD Services feature
  win_feature:
    name: AD-Domain-Services
    include_management_tools: yes
    include_sub_features: yes
    state: present
  register: result

- name: Create new forest
  win_domain:
    dns_domain_name: tycho.local
    safe_mode_password: RememberTheCant!
  register: result

- name: Reboot after creation
  win_reboot:
    msg: "Server config in progress; rebooting..."
  when: result.reboot_required

创建域后,服务器会向已登录的任何用户发送一条消息,告知服务器即将重新启动,然后开始重新启动。虽然这不是一个生产级剧本,但这是一个很好的例子,说明只需几个简短的 Play 即可快速配置什么。

如果已经存在一个用于测试的域,则无需创建新的域,但可能存在一台应加入现有域的测试机器。Ansible 同样可以通过几个 Play 来简化此任务。

- name: Configure DNS
  win_dns_client:
    adapter_names: "Ethernet 2"
    ipv4_addresses:
    - 10.0.0.1

- name: Promote to member
  win_domain_membership:
    dns_domain_name: tycho.local
    domain_admin_user: [email protected]
    domain_admin_password: WeNeed2Hydrate!
    state: domain
  register: domain_state

- name: Reboot after joining
  win_reboot:
    msg: "Joining domain. Rebooting..."
  when: domain_state.reboot_required

步骤不言自明,确保机器可以与目录服务器通信(win_dns_client),然后加入域(win_domain_membership)。目标重新启动以完成加入目录。快速且简单。

它能做什么?

使用 win_feature 管理角色类似于 Install-WindowsFeatureAdd-WindowsFeature Powershell cmdlet 的组合。如果您不熟悉要安装的功能的名称,请使用 Get-WindowsFeature cmdlet 列出可安装的功能。

Windows 域模块(win_domainwin_domain_controllerwin_domain_groupwin_domain_membershipwin_domain_user)涵盖了针对 Active Directory 执行的常见任务。对于大多数 Windows 模块,应将具有相应权限的域帐户设置为机器凭据(使用 DOMAIN/User 或 [email protected]),就像您对本地帐户所做的那样。

总结

在这篇文章中,我们使用 WinRM 连接到 Windows 主机,让 Ansible 使用 win_feature 模块从服务器管理安装 AD 域服务功能(或者如果不存在,则使用 win_domain 模块创建新的 Active Directory 域),确保机器可以使用 win_dns_client 与目录服务器通信,然后使用 win_domain_membership 将其加入域。

不要忘记确保 Windows 节点的剧本通过明确指定 ansible_connection: winrm(必需)以及 ansible_winrm_server_cert_validation: ignore(如果您尚未将本地 CA 添加为受信任的)来设置连接变量。如本文开头所示,这两个变量与 Ansible Playbook 中 vars: 后面的连接帐户变量一起使用。在 Ansible Tower 中,这些变量位于作业模板中。

现在您知道如何将 Ansible 与 Microsoft 的 Active Directory 配合使用!在下一篇文章中,我们将更深入地探讨 Ansible 和 Windows 提供的包管理功能!




使用 Prometheus、Node Exporter 和 Grafana 监控 Red Hat Ansible Tower

使用 Prometheus、Node Exporter 和 Grafana 监控 Red Hat Ansible Tower

自动化至关重要的一点是确保其完美运行。自动化分析可以通过提供对健康状态和组织统计信息的洞察来提供帮助。但是,通常需要监控 Ansible Tower 的当前状态。幸运的是,Ansible Tower 确实通过 API 提供指标,并且可以轻松地将其馈送到 Grafana 中。

这篇博文将概述如何通过使用 node_exporter 和 Prometheus 将 Ansible Tower 和操作系统指标馈送到 Grafana 来监控 Ansible Tower 环境。

为了实现这个目标,我们配置 Ansible Tower 指标以便 Prometheus 通过 Grafana 查看,并将使用 node_exporter 将操作系统指标导出到 Grafana 中的操作系统 (OS) 仪表板。请注意,我们在此处使用 Red Hat Enterprise Linux 8 作为运行 Ansible Tower 的操作系统。数据流如下所示

analytics data flow diagram

如您所见,Grafana 在 Prometheus 中查找数据。Prometheus 本身通过从 node_exporters 和 Ansible Tower API 导入数据将其收集到其数据库中。

在这篇博文中,我们假设一个包含三个 Ansible Tower 实例和一个外部数据库的集群。另外,请注意,这篇博文假设已经安装了 Prometheus 和 Grafana 实例。

node_exporter 设置

第一步,我们将在 Ansible Tower 服务器和外部数据库上设置 node_exporter。由于 node_exporter 在 Red Hat Enterprise Linux 8 中默认不可用,因此我们首先必须安装它。为此,我们登录到 Ansible Tower 服务器,克隆相应的 git 存储库并切换到存储库目录。请参阅下面显示的清单以供参考

$ git clone https://github.com/redhat-cop/tower_grafana_dashboards 

$ cd tower_grafana_dashboards/

$ tree
.
├── install_node_exporter.yaml
├── metric_servers.json
└── metric_tower.json

0 directories, 3 files

接下来,我们必须执行 node_exporter 的实际安装。幸运的是,包含一个用于安装它的剧本。运行 install_node_exporter.yaml 剧本来执行 node_exporter 的安装。

$ ansible-playbook install_node_exporter.yaml
...

剧本的输出如下所示

Analytics blog 2

安装后,验证 node_exporter 是否确实正在运行并在端口 9100 上监听。这可以通过 netstat 轻松完成

analytics blog 3

在其他 Ansible Tower 服务器以及外部数据库上重复这些步骤。

验证 Ansible Tower 指标

接下来,让我们将重点转向 Ansible Tower。通过访问下面的 URL 验证 Ansible Tower 指标是否正确显示

https://tower.customer.com/api/v2/metrics

访问 URL 后,我们应该会看到所有可用 Ansible Tower 指标的列表,如下所示

analytics blog 4

让我们设置 Prometheus 以收集这些数据。首先,我们需要在 Ansible Tower 上生成一个 身份验证令牌:该令牌将授予对 Ansible Tower 的访问权限,而无需每次访问时都输入用户名和密码。

要生成令牌,请访问 Ansible Tower 控制台,然后单击页面顶部显示的用户名。从那里,单击“令牌”,然后单击 + 符号。将弹出一个新窗口,您可以在其中定义令牌的详细信息并最终创建它,请参阅下图。选择范围“读取”并单击绿色的“保存”按钮。

analytics blog 5

设置 Prometheus 以接收指标

有了令牌,我们现在可以配置 Prometheus,添加 node_exporters 抓取配置和 Ansible Tower 指标的抓取。使用您选择的编辑器打开 Prometheus 安装的配置:

$ vim /etc/prometheus/prometheus.yml

接下来,添加 Ansible Tower 和操作系统的配置。下面是一个示例

## Scrape Config - Tower
  - job_name: 'tower'
    metrics_path: /api/v2/metrics
    scrape_interval: 5s
    scheme: https
    bearer_token: xxxxxxxxxxxxxxxx (your bearer token)
    static_configs:
    - targets:
      - tower.customer.com

## Add Node Exporter
  - job_name: 'tower-01'
    scrape_interval: 5s
    static_configs:
    - targets: ['172.31.66.203:9100']

  - job_name: 'tower-02'
    scrape_interval: 5s
    static_configs:
    - targets: ['172.31.65.135:9100']

  - job_name: 'tower-db-01'
    scrape_interval: 5s
    static_configs:
    - targets: ['172.31.64.218:9100']

请注意,Ansible Tower 的指标仅收集一次,而操作系统的指标则针对每台服务器收集:Ansible Tower 有助于确保所有内部指标都已收集并在集群的所有已安装服务器之间共享。但是,每个服务器上的每个操作系统都是独立的,因此具有独立的操作系统指标。

重新启动 Prometheus 以应用更改

$ systemctl restart prometheus

现在,访问 URL http://prometheus.customer.com/targets 以验证数据是否已正确抓取。确保所有端点都处于 UP 状态,如下所示

analytics blog 6

Grafana 配置以导入仪表板

现在让我们将仪表板导入 Grafana。Grafana 可以通过 json 文件进行配置。在上面提到的存储库中,我们提供了两个 json 文件来配置两个仪表板:metric_servers.json 用于操作系统指标,metric_tower.json 用于 Ansible Tower 指标。让我们将它们导入 Grafana 以启用仪表板。

为此,请访问您的 Grafana 安装并单击左侧导航菜单中的 + 符号。选择“文件夹”,输入所需的名称并创建它。

之后,我们可以选择“管理仪表板”,从那里我们可以通过上传导入准备好的 json 文件选择 json 文件 metric_tower.json,选择刚刚创建的文件夹,更改 uid 并选择 Prometheus 作为数据源,如下所示

analytics blog 7

通过按下相应的按钮启动导入。metric_tower.json 导入完成后,我们对 metric_servers.json 文件重复相同的过程。

新的 Grafana 仪表板

两个上传完成后,我们可以查看导入的仪表板

analytics blog 8

在这个 Ansible Tower 指标仪表板中,您现在可以看到以下信息

  • Ansible Tower 版本
  • Ansible Automation Platform 版本
  • 塔节点数量
  • 许可证中可用的主机数量
  • 已使用的主机数量
  • 用户总数
  • 作业成功
  • 作业失败
  • 按作业执行类型数量
  • 显示正在运行的作业和挂起作业数量的图形
  • 显示工具增长的图形,显示工作流、主机、清单、作业、项目、组织等的数量。

在操作系统指标仪表板中,我们有以下信息

  • 正常运行时间
  • vCPU 总数
  • 内存总数
  • CPU iowait
  • 内存消耗
  • CPU 繁忙
  • 交换
  • 文件系统消耗
  • 磁盘 IOPS
  • 系统负载
  • 已使用空间图
  • 包含磁盘写入和读取、网络流量和网络套接字的图形。

analytics blog 9

要点和后续步骤

在这篇文章中,我们演示了如何使用 node_exporter 导出操作系统指标以及 Prometheus 收集 Ansible Tower api 指标来创建 Ansible Tower 环境的监控,我们包含了操作系统消耗仪表板和 Ansible Tower 指标,以便您可以更全面地管理您的环境,例如容量、许可证和正在执行的作业,使用图形和计数器,您可以快速识别问题并采取措施。

如果您有兴趣了解整个自动化环境的详细视图,您也可以尝试 cloud.redhat.com 上的自动化分析。




介绍 AWX 和 Ansible Tower 集合

介绍 AWX 和 Ansible Tower 集合

Ansible 内容集合是一种分发内容(包括模块)的新方式,用于 Ansible。

AWX 和 Ansible Tower 集合允许 Ansible Playbook 与 AWX 和 Ansible Tower 交互。与通过基于 Web 的 UI 或 API 与 AWX 或 Red Hat Ansible Tower 交互类似,AWX 集合提供的模块是创建、更新或删除对象以及执行运行作业、配置 Ansible Tower 等任务的另一种方式。本文将讨论有关此集合的新更新,以及一个示例 Playbook 以及如何成功运行它的详细信息。

AWX 集合 awx.awx 是在 Ansible Galaxy 上提供的上游社区发行版。下游支持的 Ansible 集合 ansible.tower 在 Ansible Tower 3.7 发布的同时在 Automation Hub 上提供。

此集合取代了以前直接托管和维护在 Ansible 仓库 中的 Ansible Tower Web 模块。这些模块最初是在 2019 年 10 月 添加到 AWX 源代码 中的,当时集合工作开始;Ansible Core 中的 tower_* 模块 很快就被标记为正式迁移

AWX 集合的改进

Ansible Core 提供的模块和 AWX 集合的初始版本依赖于 tower-cli 项目提供的库。由于 tower-cli 已弃用,目前正在努力删除该依赖项。这导致了 AWX 集合的重大更新。

在删除 tower-cli 的过程中,我们尝试使模块与其在 Ansible Core 中发布的相应版本向后兼容。这样,如果您已经利用了 Ansible Core 中的 tower_* 模块,则切换到 AWX 集合时所需的工作量应该非常少。有关更多信息,请参阅下面的 弃用更新 部分。

此外,我们标准化了模块的操作逻辑,从而使集合模块更加统一。以前,每个模块都是单独编写的(有时由不同的作者编写)。这导致各个模块的行为存在细微差异。AWX 集合中分发的模块遵循标准模式,即使由不同的作者编写,也能提供一致性。

将集合同步到 Red Hat Ansible Tower 版本还可以使模块的参数与 Web UI 和 API 中提供的选项保持同步。作为最近更改的一部分,我们添加了一些新的 工具,并更新了许多模块,现在包含了自模块最初发布以来已添加到 Ansible Tower 的功能的参数。

该集合现在还提供了对幂等性和检查模式的更好支持。在使用检查模式的早期版本中,旧模块只会确保它们可以连接到 Ansible Tower 服务器,但不会指示它们是否真的会对 Ansible Tower 对象进行更改。AWX 集合模块现在将更准确地指示它们是否会通过检查模式更改 Tower 对象。

使用 AWX 集合

开始使用 AWX 集合非常容易;您只需从 Ansible Galaxy 安装集合即可与 Ansible Tower 交互。可以使用以下命令完成此操作

ansible-galaxy collection install awx.awx

安装集合后,我们可以开始编写 Playbook 来管理您的 Ansible Tower 实例。

注意:为了与您的 Red Hat Ansible Tower 环境通信,您需要运行一个实例,并具有专用的 Ansible Tower 主机地址。

设置身份验证

为了与 Red Hat Ansible Tower 交互,我们需要做的第一件事是提供身份验证。这可以通过多种方式完成,所有这些方式都与旧版本的模块向后兼容。以下身份验证选项可用

  • 将连接信息指定为模块参数
  • 使用连接信息提供环境变量
  • 引用包含连接信息的旧 tower_cli.cfg 文件

下面是一个 tower_cli.cfg 文件的示例

host: [$HOST_ADDRESS]
verify_ssl: False
tower_username: [$TOWER_USERNAME]
tower_password: [$TOWER_PASSWORD]
oauth_token: [$OAUTH_TOKEN] (if using oauth instead of a password)

创建 Playbook

安装 AWX 集合并确定身份验证方法后,我们可以开始 编写 Playbook 来与 Ansible Tower 交互。为了激活集合,在 Playbook 的 Play 级别需要以下代码片段

  collections:
    - awx.awx

即使您在仍然附带 tower_* 模块的 Ansible 版本上运行,这也会导致 Ansible 加载来自 AWXCollection 的模块,而不是 Ansible Core 中发布的版本。Playbook 的其余部分将与不使用集合的 Playbook 完全相同。

在下面的示例 Playbook 中,身份验证信息未在任务中指定,而是将从环境变量或 tower_cli.cfg 文件中加载

---
- name: Playbook for Using a Variety of Tower Modules
  hosts: localhost
  gather_facts: false
  collections:
    - awx.awx

  tasks:

  - name: Create a new organization
    tower_organization:
      name: "New Org"
      description: "test org"
      state: present

  - name: Create an Inventory
    tower_inventory:
      name: "New Inventory"
      description: "test inv"
      organization: "New Org"
      state: present

  - name: Create a Host
    tower_host:
      name: "New Host"
      inventory: "New Inventory"
      state: present
      variables:
        foo: bar

  - name: Create a Project
    tower_project:
      name: "New Project"
      organization: "New Org"
      scm_type: git
      scm_url: https://github.com/ansible/test-playbooks.git

  - name: Create a Team
    tower_team:
      name: "Test Team"
      description: "test team"
      organization: "New Org"
      state: present
      validate_certs: false

  - name: Create a Job Template
    tower_job_template:
      name: "Job Template to Launch"
      project: "New Project"
      inventory: "New Inventory"
      playbook: debug.yml
      ask_extra_vars: yes

  - name: Launch the Job Template (w/ extra_vars)!
    tower_job_launch:
      job_template: "Job Template to Launch"
      extra_vars:
        var1: My First Variable
        var2: My Second Variable
        var3: My Third Variable

注意:指示 Ansible 使用集合中的模块的另一种方法是使用集合命名空间完全限定模块的名称,如下例所示

 - name: Launch the Job Template (w/ extra_vars)
    awx.awx.tower_job_launch:
      job_template: "Job Template to Launch"
      extra_vars:
        var1: My First Variable
        var2: My Second Variable
        var3: My Third Variable

执行 Playbook

假设以上 Playbook 作为名为 configure_tower.yml 的文件保存在您的当前目录中,以下命令将运行此 Playbook

$ ansible-playbook -i localhost configure_tower.yml

注意:如果您的机器上存在 Python 问题,更改 ansible-playbook 命令为以下内容可能会有所帮助

$ ansible-playbook -i localhost -e ansible_python_interpreter=$(which python) configure_tower.yml

使用正确安装的集合、配置的身份验证设置和格式正确的 Playbook,您应该会看到类似于以下内容的输出

ansible-blog-screenshot-awx-collection

Playbook 完成后,如果您导航到 Red Hat Ansible Tower 服务器的 Web UI,您应该能够看到创建了以下对象

  • 一个名为“New Org”的组织
  • 一个名为“New Inventory”的清单和该清单中名为“New Host”的主机
  • 一个名为“New Project”的项目
  • 一个名为“New Team”的团队
  • 一个名为“Job Template to Launch”的作业模板

此外,您可以在“作业”页面上看到 Playbook 使用指定的 extra_vars 调用了作业模板。见下文

bianca collections tower ui

弃用更新

在删除 tower-cli 期间,我们尝试使模块尽可能相似,以方便从旧的核心模块过渡到新集合。不可避免地,必须进行一些小的更改;这些更改的详细信息可以在 AWX 集合 README.md 文件的“发布和升级”部分找到。一些需要提及的更改包括

  • extra_vars 参数不再支持通过指定 @<文件名> 符号从文件加载变量。现在,它们采用字典。如果您以前正在加载文件,请改为使用查找插件加载文件。
  • 一些模块不再以以前的方式返回值。所有返回值已在模块之间统一,并且主要返回修改的对象的 ID。

结论

使用 AWX 集合启动和运行非常简单直接。除其他事项外,集合使用户能够将其最常用的任务存储在不同的 Playbook 中,这些 Playbook 可以根据需要轻松共享。在后续的博文中,我们将讨论贡献和开发,以及如何测试您可能想要添加到集合中的任何新模块或更新的模块。