1

Referring to : http://scienceofficersblog.blogspot.com/2016/02/testing-ansible-with-inspec.html

There are so many posts mentioning use of Chef inspec for Ansible testing. But they usually give example like:

Ansible:

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

Chef Inspec:

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

So, if I execute the same Ansible block it will give me surety that the apache2 package is installed. Similarly there are so many examples like port 80 should be open, for that also if we execute the same playbook in chech mode (dry run) then also I will get to know whether port 80 is listening or not.

So, why can't we use Ansible itself? and what is the exact necessity of Chef inspec when we can do almost everything by using Ansible ?

ZIA UR REHMAN
  • 119
  • 12
  • I have not used chef inspec but ansible and chef quite for all infra related stuff as well as for deployments. As per my understanding inspec by chef is used as a testing framework on the infra side. Chef inspec can be used before and after the playbook execution for comparing the results. I agree that it is unnecessary specically when the configuration management tool is ansible – error404 Jul 08 '19 at 14:31

2 Answers2

2

Mostly that's because the examples are very very very simple.

For the same ansible block, I assume you expect apache to be installed, running and listening to port 80, a better inspec example would be:

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

But the main point is that coding the configuration desired and the test to ensure what was planned separately allows for a TDD approach.

Inspec has also another interesting point in the formater side, where it can return audit information in various format.

At the end of the day, there's nothing requiring Inspec to test Ansible, that's a practice to get separated "tests" and "actions" so an error in ansible code making apache listen to port 800 wouldn't be catch by ansible as it would be what you asked it to set (and that's just normal), having them separated ensure the test are not derived by the action code.

Tensibai
  • 15,557
  • 1
  • 37
  • 57
1

I'm not sure why people seem to think Chef Inpec is necessary for this. Ansible has an assert module that allows to ensure things evaluate to true so effectively you register the output of a task and assert things about it are as you expect.

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

In fact, this is how almost all the Ansible integration tests are written upstream https://github.com/ansible/ansible/tree/devel/test/integration/targets

Adam Miller
  • 872
  • 4
  • 6