Bullhorn #62
Ansible 开发者社区通讯 第 62 期,2022 年 6 月 10 日 (往期回顾)
欢迎来到 The Bullhorn,这是我们面向 Ansible 开发者社区的通讯。如果您有任何疑问或想要分享的内容,欢迎在 Matrix 上的 Ansible 社交室 与我们聊天,并提及 newsbot
以将您的新闻条目标记以供审核,用于下一期周报!
Ansible 开发者社区通讯 第 62 期,2022 年 6 月 10 日 (往期回顾)
欢迎来到 The Bullhorn,这是我们面向 Ansible 开发者社区的通讯。如果您有任何疑问或想要分享的内容,欢迎在 Matrix 上的 Ansible 社交室 与我们聊天,并提及 newsbot
以将您的新闻条目标记以供审核,用于下一期周报!
在自动化和敏捷的世界中,信息技术基础设施库 (ITIL) 似乎已经不再发挥作用,被视为“老旧”的框架。在作为众多 IT 组织流程指南和蓝图服务了这么长时间后,它是否真的走到了尽头?
本系列文章展示了自动化,更具体地说,Red Hat Ansible Automation Platform 和基础设施即代码 (IaC) 的原则,如何帮助将一些 ITIL 主题融入到敏捷和自动化的美好体验中。
因此,让我们进入配置管理的主题,以及每个人仍然熟知的 CMDB(配置管理数据库)的概念,即使 ITIL 很久以前就将其命名为 CMS(配置管理系统)。名称的更改旨在强调该功能可以通过多个数据库和工具的组合来实现,但这在这里并不重要,因此我们将坚持使用臭名昭著的 CMDB 术语。
您是否喜欢您的 CMDB?根据我与众多客户的经验,可能不是。数据通常过时且错误,被认为毫无用处,这意味着维护它被视为一项苦差事。这意味着它以尽可能少的努力进行维护,以一种粗心大意的方式,使其变得更加过时,并陷入一个恶性循环。
为了避免崩溃,我们首先需要了解 CMDB 和相关的配置管理有两个主要目的
鉴于上述缺点,我们需要首先更清晰地构建我们的数据库,因为它包含多种类型的数据
由于数据可能仅为期望状态、仅为实际状态或两者兼而有之,因此我们有三个类别,为了简单起见,我们将用 A 到 C 来引用它们
由于管理员不想维护两次期望状态,因此您在 CMDB 中使用期望状态(类型 A 和 B)作为 Ansible Automation Platform 的清单源,以从中配置您的环境。管理员知道,CMDB 中的数据越好,现实世界中的结果就越好,从而减少工作量。这应该足以成为快速提高 CMDB 数据质量的动力。
因为 CMDB 不会将类别 A 数据的期望状态和实际状态混合在一起,所以您可以检测到差异,决定如何修复它,并再次使用 Ansible 进行自动化修复。这应该可以帮助您快速使现实与期望状态保持一致,并拥有正确的数据来做出决策。
类型 C 的数据对自动化没有多大用处,旨在在您的变更管理流程中进行决策,尽管您可以在磁盘过满的情况下决定跳过修补周期。也就是说,您不应该将此方面与监控混淆;监控磁盘满的情况并快速进行纠正属于事件管理,而不是配置管理。
一旦您完成了这个第一阶段,就可以进入下一级,并使用 Ansible Automation Platform 自动填充 CMDB 中的期望状态。
假设您有一个服务门户,客户可以在其中订购新服务或修改和停用它们,使用服务目录和一个引导他们完成所需选择的对话框。使用通过对话框获取的输入变量,服务门户可以使用自动化控制器的 API 触发工作流来履行服务。然后,工作流的第一步之一是将这些输入变量作为期望状态(类型 A 和 B)输入到 CMDB 中。它具有以下优点:如果工作流作业失败,您仍然有记录的期望状态,并且可以在修复故障根本原因后再次触发该操作。
现在,最好像在 Git 中一样拥有提交、分支和标记功能,以便轻松回滚此类更改。但也许有人会根据本文发明一个具有此类功能的 CMDB。在此期间,将 Ansible Automation Platform 连接到您的 CMDB,并通过自动化为您的 CMDB 添加价值和质量。
了解有关将 Ansible Automation Platform 用于配置管理的更多信息
这段 8 分钟的概述视频 突出显示了 Ansible Automation Platform 最新版本中包含的组件和功能,以及它们如何协同工作以提供全面的企业自动化体验。
Ansible 开发者社区通讯 第 61 期,2022 年 6 月 2 日 (往期回顾)
欢迎来到 The Bullhorn,这是我们面向 Ansible 开发者社区的通讯。如果您有任何疑问或想要分享的内容,欢迎在 Matrix 上的 Ansible 社交室 与我们聊天,并提及 newsbot
以将您的新闻条目标记以供审核,用于下一期周报!
自动化内容导航器与 Red Hat Ansible Automation Platform 2.0 同时发布,并改变了内容创建者构建和测试 Ansible 自动化的方式。导航器 1.0 将多个 Ansible 命令行工具(如 ansible-playbook、ansible-doc、ansible-config 等)整合在一起,并不断积累非常有用的新功能,以帮助为自动化创建者提供更大的灵活性。
随着 Ansible Automation Platform 2.2 的发布,导航器 2.0 引入了对现有功能的改进以及其他功能,以帮助开发自动化内容。
在导航器 2.0 中,您将找到
在导航器 2.0 发布之前,需要一个单独的命令行应用程序 (ansible-builder) 从人类可读的 YAML 文件构建执行环境映像。在此版本中,ansible-navigator 安装了 ansible-builder 并包含一个新的 build 命令,用于将参数传递给 ansible-builder,允许内容创建者从一个熟悉的界面创建映像。
可以从 ansible-navigator 利用 ansible-builder 的所有增强功能。此功能有助于巩固导航器在内容创建者工作流程中的作用,不仅允许内容创建和环境自省,还允许从导航器内部支持执行环境构建。
==> ./builder/execution-environment.yml
--- version: 1 build_arg_defaults: EE_BASE_IMAGE: "registry.redhat.io/ansible-automation-platform-21/ee-supported-rhel8:latest" dependencies: galaxy: requirements.yml system: "" python: ""
==> ./builder/requirements.yml
--- collections: - arista.avd
$ ansible-navigator builder build --workdir builder
通过一个新的子命令 exec,自动化创建者现在可以打开默认执行环境中的 shell。这允许创建者进一步检查执行环境并利用安装在执行环境中的实用程序,而无需将其安装在本地工作站上。
例如,假设您正在创建一些新的工作流,并且您需要利用 Ansible 自动化中心的其他集合。无需在本地工作站上安装 ansible-galaxy 命令行工具,您可以在导航器中运行一个命令以在与新工作流相同的目录中安装该集合。因为当前工作目录已绑定安装到正在运行的容器中,所以安装的集合放置在本地文件系统上。
ansible-navigator exec -- ansible-galaxy collection install servicenow.itsm -p ./collections
运行上述命令后,您的当前工作目录 (CWD) 中应该会存在一个名为“Collections”的新目录。此目录将在运行时提供给执行环境,因为 CWD 在运行时已绑定安装。这使您始终能够了解在执行环境中安装了哪些集合以及哪些集合已绑定安装到容器中。
Navigator 降低了创建新内容的门槛!创建者现在只需要安装 ansible-navigator 即可开始创建新的自动化。利用执行环境,内容创建者甚至不需要安装 ansible-core!Navigator 会提取一个包含 ansible-core 和常见 Ansible 命令行实用程序(如 ansible-galaxy)的默认执行环境。exec 命令允许从默认执行环境中利用这些实用程序,而不是依赖于工作站配置。
$ echo secret_vault_password > password_file $ ansible-navigator exec -- ansible-vault encrypt_string --vault-password-file password_file 'secret' !vault | $ANSIBLE_VAULT;1.1;AES256 64323039613737313538666239363032396361613464393033343165663631653835356232373139 Encryption successful
$ ansible-navigator exec -- env ANSIBLE_CACHE_PLUGIN=jsonfile DESCRIPTION=Red Hat Ansible Automation Platform Minimal Execution Environment SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
设置命令从导航器内部显示本地环境的配置。从设置屏幕,创建者能够查看默认值和本地配置参数更改的值。在 VS Code 等集成开发环境 (IDE) 中利用这一点特别有用,可以使用命令+单击等功能在编辑器中打开文件路径。例如,创建者能够看到导航器正在使用本地 ansible.cfg 或 ansible-navigator.yml 文件,并且可以直接从导航器设置屏幕在配置的编辑器中打开该文件。
Ansible 很灵活!可以为多个自动化项目使用系统范围的配置文件。能够查看默认配置、哪些配置参数已在本地配置文件中定义以及当前项目正在使用哪些文件,这对内容创建者非常有帮助。所有这些都增强了内容创建者更易于预测的简化创建者工作流程。
假设您是一位自动化内容创建者,正在启动一个新项目。您知道这个新项目将
此外,您可能希望自定义导航器以使用您首选的代码编辑器。
导航器示例设置允许创建者显示一个示例 ansible-navigator.yml 配置文件,其中所有参数都已注释掉。这允许创建者选择要为新项目调整的设置。诸如默认执行环境映像名称、映像拉取策略、从导航器打开文件时使用哪个代码编辑器等,都配置在 ansible-navigator.yml 中。此外,此示例设置文件可以写入本地文件系统,在那里,在为新项目编辑后,可以由导航器获取。
$ ansible-navigator settings --sample > my.yaml
多个自动化项目通常意味着需要定义多个执行环境作为相应项目的默认执行环境。通过允许从导航器创建设置文件,创建者无需依赖内存来定义自定义和部署其项目所需的參數。
$ ansible-navigator settings
$ ansible-navigator settings --effective
$ ansible-navigator settings --sources
导航器包含一个文本用户界面 (TUI),默认情况下在交互模式下运行。在交互模式下,创建者通过使用一系列按键来运行命令并导航界面。导航器 1.0 支持某些命令的标准输出模式。这意味着,创建者无需打开完整的交互式用户界面,就可以运行命令并查询有关本地环境的信息,而无需打开 TUI。例如,在 CI/CD 管道中,标准输出模式很有用,因为不需要交互式运行命令。
在导航器 2.0 中,更多命令支持标准输出模式。例如,collections 子命令现在可以在标准输出模式和交互模式下运行。对于自动化创建者来说,查看环境中有哪些集合非常有用,以便确定可以在自动化工作流中利用哪些模块。
此外,导航器现在支持仅在单一模式下提供的命令的自动模式选择。以前,对于仅支持模式标准输出的命令,需要使用 --mode
命令行参数。
导航器可以轻松适应各个创建者的工作流程和偏好。更重要的是,通过为更多命令添加标准输出支持,导航器现在可以用于自动化构建环境。
--mode stodut
。$ ansible-navigator run --help-playbook
$ ansible-navigator builder --help-builder
交互模式的一个非常好的用途是在新添加的和实验性的 Ansible 内容 lint 功能中。lint 子命令与 Ansible Playbook 的路径或 Ansible 内容目录结合使用时,会在导航器中打开一个新屏幕,在该屏幕上显示传递给 lint 命令的文件的问题和建议。随着问题文件的更正和保存,问题和建议列表会缩小。结合代码编辑器能够使用 control+click 打开文件路径的功能,编辑存在潜在问题的文件非常快,并且与创建者体验的其余部分很好地融合在一起。
一致的内容产生可靠的自动化。Lint 支持允许创建者确保生成的内容符合最佳实践。
$ ansible-navigator lint site.yaml --eei quay.io/ansible/creator-ee:latest
自动化内容导航器 2.0 现已可用!导航器对创作和测试体验进行了改进。因此,自动化内容创建者拥有更多工具来协助创建和维护自动化工作流。
Ansible 开发者社区通讯 第 60 期,2022 年 5 月 27 日 (往期回顾)
欢迎来到 The Bullhorn,这是我们面向 Ansible 开发者社区的通讯。如果您有任何疑问或想要分享的内容,欢迎在 Matrix 上的 Ansible 社交室 与我们聊天,并提及 newsbot
以将您的新闻条目标记以供审核,用于下一期周报!