使用 Ansible 审计您的 VMware vCenter Server

vCenter 有一个图形用户界面，如果您想与其交互，但如果您管理多个 vCenter 服务器并想要自动化审计或维护这些服务器怎么办？在本博文中，我们将了解如何使用 Ansible 直接检索有关 VMware vCenter Server 的详细信息。博文中概述的做法将帮助负责管理多个 vCenter 服务器的系统管理员。此外，Ansible 自动化在开发环境中对于在您的 CI/CD 管道中针对多个实例进行测试变得至关重要。

新的 vmware.vmware_rest 集合最近已发布，并附带一组专用于 vCenter Server (VCSA) 管理的新模块。

VMware vSphere (包含 vCenter Server 和其他功能的产品包) 7.0.2 (又名 7.0U2) 附带一些新的 REST 端点。此 REST API 并不涵盖通过 SOAP 接口公开的所有功能。vmware.vmware_rest 集合中的模块构建在此 API 之上，并面临相同的限制。

vmware.vmware_rest 集合包含以下模块，这些模块受 Red Hat 支持，可在 Ansible 自动化中心 上获取。

从 Ansible 验证 vCenter Server 实例的状态

以我们自己的狗食为例（或喝我们自己的香槟！），我们的云/基础设施团队维护一个 CI 来验证 VMware Ansible 模块。每次提交新的更改时，都会针对新部署的 VMware 实验室运行完整的测试套件。初始部署需要 15 分钟，因此我们不能在运行数十个测试之前生成新的环境。因此，保持测试环境尽可能干净变得很重要。

我们使用这些新的设备模块来构建测试套件运行前后的 vCenter 实例的审计报告。这样，更容易发现测试运行之间的任何不一致。

设备模块涵盖以下用例。

• 访问→本地帐户，审计和控制控制台、直接控制台 UI、Shell 或 SSH。
• 运行状况→检索有关系统组件状态的信息。
• 网络→收集有关网络配置的信息并对其进行调整。
• 系统→管理服务，重启系统，获取存储配置，获取更新状态等。
• 时间管理→配置 NTP 服务器，调整时区。

如何开始使用这些模块

在 Ansible 自动化中心 上提供的 vmware_rest 集合的最新版本支持 vSphere 7.0.2 及更高版本。

我们可以通过一些环境变量或模块参数传递身份验证密钥。在以下示例中，我们使用第一个选项。例如

VMWARE_HOST=<vsphere_host>
VMWARE_PASSWORD=<vsphere_password>
VMWARE_USER=<vsphere_username>

注意：community.vmware 集合使用相同的环境变量。

我们将在下面尝试解释一些示例用例，以便读者了解如何开始使用这些模块。

收集有关 VCSA 实例的信息

在第一个示例中，我们通过关闭任何潜在的用户界面来保护设备。模块使用的 REST 接口仍然可用。以下是如何使用可用模块来检查这一点。

- name: Shell access should be disabled
  vmware.vmware_rest.appliance_access_shell_info:
- name: The Direct Console User Interface should also be disabled
  vmware.vmware_rest.appliance_access_dcui_info:
- name: We need the SSH access
  vmware.vmware_rest.appliance_access_ssh_info:

响应

{
    "changed": false,
    "value": {
        "enabled": false,
        "timeout": 0
    }
}

{
    "changed": false,
    "value": false
}

{
    "changed": false,
    "value": true
}

运行状况状态

我们可以依赖设备_运行状况模块或其他信息模块来审计 VCSA 的状态。例如，这里我们检查系统负载和数据库是否处于绿色状态。

- name: Ensure the database health status is green
  vmware.vmware_rest.appliance_health_database_info:


- name: Get the system load status
  vmware.vmware_rest.appliance_health_load_info:


- name: Get the system load status
  vmware.vmware_rest.appliance_health_system_info:

响应

{
    "changed": false,
    "value": {
        "messages": [
            {
                "message": {
                    "args": [],
                    "default_message": "DB state is Degraded",
                    "id": "desc"
                },
                "severity": "WARNING"
            }
        ],
        "status": "DEGRADED"
    }
}

{
    "changed": false,
    "value": "gray"
}

{
    "changed": false,
    "value": "gray"
}

在此示例中，我们的数据库处于降级状态，系统其余部分未处于最佳 GREEN 状态。

网络配置

Ansible 还能够读取和设置 VCSA 的网络配置。设备_网络_信息模块返回网络配置的系统范围概述

- name: Get network information
  vmware.vmware_rest.appliance_networking_info:

响应： 

{
    "changed": false,
    "value": {
        "dns": {
            "hostname": "vcenter.test",
            "mode": "DHCP",
            "servers": [
                "192.168.123.1"
            ]
        },
        "interfaces": {
            "nic0": {
                "ipv4": {
                    "address": "192.168.123.8",
                    "configurable": true,
                    "default_gateway": "192.168.123.1",
                    "mode": "DHCP",
                    "prefix": 24
                },
                "mac": "52:54:00:c9:06:64",
                "name": "nic0",
                "status": "up"
            }
        },
        "vcenter_base_url": "https://vcenter.test:443"
    }
}

但我们也可以收集一个特定 NIC 的详细信息

- name: Get details about one network interfaces
  vmware.vmware_rest.appliance_networking_interfaces_info:
    interface_name: nic0

响应

{
    "changed": false,
    "id": "nic0",
    "value": {
        "ipv4": {
            "address": "192.168.123.8",
            "configurable": true,
            "default_gateway": "192.168.123.1",
            "mode": "DHCP",
            "prefix": 24
        },
        "mac": "52:54:00:c9:06:64",
        "name": "nic0",
        "status": "up"
    }
}

DNS 配置

设备_网络_dns_主机名_信息模块可用于检索 VCSA 的主机名。

- name: Get the hostname configuration
  vmware.vmware_rest.appliance_networking_dns_hostname_info:

响应

{
    "changed": false,
    "value": "vcenter.test"
}

使用设备_网络_dns_服务器_信息获取当前使用的 DNS 服务器

- name: Get the DNS servers
  vmware.vmware_rest.appliance_networking_dns_servers_info:

响应

{
    "changed": false,
    "value": {
        "mode": "dhcp",
        "servers": [
            "192.168.123.1"
        ]
    }
}

结论和下一步

这些新模块有助于快速从运行的 VCSA 实例检索信息，而无需依赖 SSH。输出非常适合常规 Ansible 剧本。最后，您还可以使用它们来调整系统的配置（网络、防火墙等）。此集合的未受支持版本也已在 Ansible Galaxy 上提供。

自从我在 Ansible & Matrix 上发表我的想法后，过去几天我收到了一些很棒的问题和评论 - 感谢大家！

出现了两个主题，它们非常适合数据丰富的博客文章，它们是

1. 我们如何知道有用户想要使用 Matrix？
2. 与 IRC 的桥梁不是经常断开吗？

这些都是合理的问题 - 我们想知道我们做出了正确的选择，无论是对于社区的未来，还是对于那些希望留在 IRC 上的人。但是我们如何回答这些问题呢？收集有关这些方面的数据并不容易，但在本文中，我将尽力而为 - 如果您知道更多/更好的数据来源，我很乐意 告诉我们！

用户群规模

好的，为此，我们有一些不错的数据来源。让我们先解决 IRC。我知道的最好的数据来源是 https://netsplit.de/networks/top10.php，它让我们了解了用户随时间的变化情况。这是一个示例

遗憾的是，图表是预制的图片/帖子，因此我们没有原始数据，但我粗略地说，在 2021 年 7 月，这十个加起来大约有 180k 用户（Libera 本身大约有 50-55k）。但 Netsplit 有历史数据

那是 2016 年，这里加起来大约有 250k，Freenode 有 90k。让我们再做一个

再回到 5 年前的 2011 年，数字更高 - 2021 年只是 2011 年的一小部分。我花了一些时间浏览其他年份，很容易说服自己 IRC 正在下降。这只是一个数据点，但其他数据点呢？

好吧，Ansible 社区已经否决了使用专有选项（在我看来，这是正确的）。但为了完整起见，让我们快速浏览一下。在这个领域，有很多“企业在敲自己的鼓”，但我确实找到了这张图表

我很难找到更新的内容，但 2019 年的 1000 万现在肯定更高了。Discord 声称有 1.5 亿（https://discord.com/company）。这很好，但两者都需要一个单独的服务器和每个社区的登录，无论如何社区都拒绝了。让我们回到 FOSS...

我很难找到任何关于 Rocket.Chat、Mattermost 等的信息，而 Gitter 已经合并到 Matrix 了。事实上，许多 FOSS 解决方案都是自托管的，这使得在任何情况下都很难获得准确的数据。

Matrix 呢？这也被证明是一个令人惊讶地难以回答的问题，但原因非常不同。由于其分布式性质，您没有一个单一的数据源可以查询。Matt Broberg 的这张幻灯片 将 Element 定位在 1800 万（Slack 定位在 4400 万，哇），虽然我不知道 Matt 从哪里获得的这些数字，但对我来说似乎很高。

也许我们可以尝试获得自己的价值。据我所知，Matrix 中有两个“旅行者机器人”，它们的工作是加入任何他们看到提到的公共房间，以收集匿名统计数据。一个是“#@voyager:t2bot.io”，它已经运行了大约 3 年，并且已经看到了超过 300 万个唯一的 Matrix ID；另一个是“@server_stats:nordgedanken.dev”，它更新得多，但已经在其生命周期中看到了大约 50 万个 ID。

但是，Matrix 帐户（和使用情况）变得更加奇怪。极有可能旅行者机器人看到的许多这些唯一 ID 实际上是来自其他网络的桥接用户。现在，您可能会合理地争辩说，这意味着Matrix 的原生用户更少，您是对的。但是，我认为这并不重要，因为我们真正关心的是“可寻址 ID” - 也就是说，我可以和谁交谈。Matrix 在跨网络构建社区的能力具有价值，我们应该在我们的统计数据中允许这一点。

即使你不同意我的观点，我们也来做个悲观的比较。从Libera的50k用户和Matrix的500k用户（Nordgedanken机器人价值）开始，然后因为桥接减去Libera（因此为450k），那么Matrix仍然是Libera的9倍大。如果你同意我的观点，我们选择两个机器人之间的值（例如，为了简单起见，为100万），那么Matrix是Libera的20倍大，是整个IRC的3倍大。

活跃用户

作为对此的脚注，我想再谈一件事。到目前为止，我们只查看了房间/频道中的任何用户ID，这显然包括闲置用户。那么活跃用户呢？

我去获取了我两个IRC频道（#ansible 和 #ansible-community）的过去一个月（6月19日->7月19日）的日志（很高兴，我可以使用Matrix来做到这一点：P）。我还将对完全非官方的Matrix房间“ansible:matrix.org”（顺便说一下，该房间是在20**16**年创建的）进行同样的操作。以下是我们看到的情况

我在这里得到了一些启示。首先，正如我们从许多其他地方了解到的那样，我们的社区非常“头重脚轻”——只有一小部分人负责大多数的聊天。

其次，Matrix房间很有意思——它没有那么活跃，当然，但我们完全没有对它进行推广。它完全是自发的，但它拥有相当数量的成员和一个相当数量的单月消息数（仍然每天约 7 条消息）。

最后，让我们考虑更大的范围。我们在Reddit上有 42k 名成员，在 Twitter 上有 59k 名粉丝，"ansible-project" 邮件列表有 13k 名订阅者。我们只有几百人在真正交谈。这...令人担忧。它几乎可以忽略不计（273/59k == 0.005），你可以说我们有 0 个人在讨论 Ansible。如果我们真的想让社区自给自足，我们必须改变这种情况。

稳定性

进入下半部分！让我们谈谈稳定性...

Matrix 的主要优势之一是 桥接——能够与其他平台的用户聊天。这就是我建议将 Matrix 用于 Ansible 社区的原因，因为它使我们能够不完全放弃 IRC。然而，这依赖于 Libera 桥接的稳定性。这是我经常听到的一件事——桥接不稳定，这使得 IRC 和 Matrix 的体验都成为了问题。

这不是不公平的——桥接问题的结果是社区分裂。消息无法在网络之间传递，并且可能永远丢失，无法到达另一侧的接收者。这很不幸，但我现在要争辩说，这种情况在 IRC 上也会发生——通过网络分裂。

从用户体验的角度来看，网络分裂与桥接问题没有太大区别。无论哪种方式，一部分社区（通常大约 5-15%）都会与其他社区失去联系，并且不会收到在此期间发送的消息。那么，这种情况有多常见呢？

我询问了拥有很长时间 IRC 日志的同事，让他们搜索网络分裂，以下是我们得到的结果

（我在此添加了一个简单的猜测，用于估计受影响的总用户数，以房间成员数（今天）的 7% 作为受影响用户的数量，并将其乘以。这是完全假设的，但说明了如此多次分裂的可能影响。）

因此，在 #ansible 中大约每周出现 2 次网络分裂。还有一个有趣的现象是，网络分裂随着时间的推移变得越来越频繁——很明显，这有一个上限，不应该将这种趋势太远地预测，但这仍然是一个令人担忧的趋势。

至于 IRC<->Matrix 桥接，这要难得多。Element 告诉我他们没有记录桥接问题，而且当出现问题时，桥接基本保持沉默。然而，人们可以寻找所有 Matrix 用户从 IRC 侧掉线的时候——显然，这不会捕捉到桥接缓慢而不是失效的问题，但它是一些东西。结果是，反过来也是真的，桥接变得更稳定了。

结论

我们在这里考察了 3 个关键方面——整体规模、活跃用户和稳定性。虽然许多数据都很模糊，但每个部分都强化了这个故事——作为一个整体，我认为可以说，Matrix 已经比 IRC 更大了，而 IRC 正在衰落，虽然桥接问题很糟糕，但它们正在随着时间的推移而减少。

我们还必须记住，桥接会尝试恢复（而 Matrix 本身是最终一致的），因此消息经常会延迟到达，而不是像网络分裂那样完全无法到达（尽管一些桥接问题确实会导致消息丢失，但这不能保证 100% 的情况）。

我的第一篇关于 Matrix 的帖子概述了我对 Ansible 的想法的“什么”和“如何”——这篇文章为“为什么”增添了一些力量。我仍然认为它是我们社区未来发展的正确选择——希望我也能说服你。