Почему мы не можем использовать только Ansible вместо Chef inspect?

Ссылаясь на: http://scienceofficersblog.blogspot.com/2016/02/testing-ansible-with-inspec.html

Есть так много сообщений, в которых упоминается использование Chef inspec для тестирования 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 должен быть открыт, для этого также, если мы запустим ту же книгу воспроизведения в режиме проверки (пробный запуск), тогда я также узнаю, прослушивает ли порт 80 или нет.

Итак, почему мы не можем использовать сам Ansible? и в чем именно необходимость Chef inspec, когда мы можем сделать почти все, используя Ansible?


testing roles ansible inspec chef-infra
person ZIA UR REHMAN    schedule 08.07.2019    source источник
comment
Я не использовал шеф-повар inspec, но ansible и шеф-повар вполне для всех вещей, связанных с инфраструктурой, а также для развертывания. Насколько я понимаю, проверка от шеф-повара используется в качестве основы для тестирования на внутренней стороне. Chef inspec можно использовать до и после выполнения плейбука для сравнения результатов. Я согласен с тем, что в этом нет необходимости, особенно когда доступен инструмент управления конфигурацией.   -  person error404    schedule 08.07.2019

Ответы (2)


arrow_upward
2
arrow_downward

В основном потому, что примеры очень-очень простые.

Я предполагаю, что для того же блока ansible вы ожидаете, что apache будет установлен, запущен и прослушивает порт 80, лучшим примером проверки будет:

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 есть еще один интересный момент на стороне формирователя, где он может возвращать информацию аудита в различном формате.

В конце концов, Inspec не требует тестирования Ansible, это практика разделения «тестов» и «действий», поэтому ошибка в коде ansible, заставляющая apache прослушивать порт 800, не будет обнаружена ansible, как это было бы быть тем, что вы просили установить (и это нормально), разделив их, убедитесь, что тест не выводится кодом действия.

person Tensibai    schedule 12.07.2019

arrow_upward
1
arrow_downward

Я не уверен, почему люди думают, что для этого необходим Chef Inpec. У Ansible есть модуль assert, который позволяет гарантировать, что вещи оцениваются как истинные, настолько эффективно, что вы регистрируете выходные данные задачи и утверждаете, что все о ней соответствует вашим ожиданиям.

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

Фактически, именно так пишутся почти все интеграционные тесты Ansible вверх по течению https://github.com/ansible/ansible/tree/devel/test/integration/targets

person Adam Miller    schedule 09.07.2019