为什么我们不能只使用 Ansible 而不是 Chef 检查？答案

【问题标题】：Why can't we use Ansible only instead of Chef inspect?为什么我们不能只使用 Ansible 而不是 Chef 检查？
【发布时间】：2019-11-17 16:44:05
【问题描述】：

参考：http://scienceofficersblog.blogspot.com/2016/02/testing-ansible-with-inspec.html

有很多帖子提到使用 Chef inspec 进行 Ansible 测试。但他们通常会给出这样的例子：

Ansible：

- hosts: all
  user: root
  tasks:
  - debug: msg="debug {{inventory_hostname}}"
  - apt: name=apache2 state=present

主厨检查：

impact 0.7
title "Test some simple resources"
describe package('apache2') do
    it { should be_installed }
end

所以，如果我执行相同的 Ansible 块，它将确保安装了 apache2 包。同样有很多例子，比如应该打开 80 端口，因为如果我们在 chech 模式（试运行）下执行相同的剧本，那么我也会知道端口 80 是否正在监听。

那么，为什么我们不能使用 Ansible 本身呢？当我们几乎可以使用 Ansible 完成所有事情时，Chef inspec 的确切必要性是什么？

【问题讨论】：

我没有使用 chef inspec，但是 ansible 和 chef 用于所有基础设施相关的东西以及部署。根据我的理解，厨师的 inspec 被用作底层的测试框架。可以在 playbook 执行前后使用 Chef inspec 来比较结果。我同意配置管理工具是ansible的时候不需要特别说明

标签： testing ansible chef-infra roles inspec

【解决方案1】：

这主要是因为示例非常非常简单。

对于相同的 ansible 块，我假设您希望 apache 被安装、运行并监听端口 80，一个更好的 inspec 示例是：

impact 0.7
title "Test some simple resources"
describe package('apache2') do
    it { should be_installed }
end
describe service('apache2') do
    it { should be_installed }
    it { should be_enabled }
    it { should be_running }
end
describe port(80) do
  it { should be_listening }
  its('processes') {should include 'apache2'}
end

但主要的一点是，对所需的配置和测试进行编码以确保单独计划的内容允许采用 TDD 方法。

Inspec 在 formater 方面还有另一个有趣的地方，它可以返回各种格式的审计信息。

归根结底，没有什么要求 Inspec 测试 Ansible，这是一种将“测试”和“操作”分开的做法，因此 ansible 代码中的错误使 apache 监听端口 800 不会被 ansible 捕获因为这将是您要求它设置的（这很正常），将它们分开确保测试不是由操作代码派生的。

【讨论】：

【解决方案2】：

我不确定为什么人们似乎认为 Chef Inpec 对此很有必要。 Ansible 有一个断言模块，它可以确保事情评估为真，如此有效地注册任务的输出并断言关于它的事情是你所期望的。

https://docs.ansible.com/ansible/latest/modules/assert_module.html

事实上，几乎所有的 Ansible 集成测试都是这样在上游编写的 https://github.com/ansible/ansible/tree/devel/test/integration/targets

【讨论】：