Як перевірити забезпечення та конфігурацію в налаштуваннях Ansible?

Дивлячись на спробу створити деяку стійкість у нашій програмі Ansible, яка стосується забезпечення та конфігурації.

Я розумію декілька методів тестування на конфігураційній стороні речей, але мені цікаво, як найкраще реалізувати тестування на забезпеченні речей, і чи є якісь інструменти, які можуть допомогти з цим типом реалізації.

В даний час велика частина нашого тестування проводиться серійно під час ігрової книги, що має багато сенсу для таких речей, як "з'явилася служба; доступна vip; чи закінчено це завдання асинхронізації", але мене дійсно стосується наша здатність керувати дрейфом конфігурація як для програми, так і для рівня забезпечення (наприклад, конфігурація VM). Я знаю, що Ansible - це не найкращий інструмент для роботи з конфігурацією, але мені цікаво побачити власну думку.

Якщо у вас є щось, щоб повністю автоматизувати процес ще краще. (у нас є кілька потворних сценаріїв, які щодня повідомляють про слабкість).

Примітка . Зараз у нас є кілька умов, коли може статися перепрограція (наприклад, перебудова з резервного копіювання, критична проблема системи), але, як правило, вона просто перебирає деякі відповідні завдання налаштування і не думає про це більше.

Деякі варіанти там ..

Інструменти для тестування: відсортовано за зірками github

• Serverspec - Рубін, найпопулярніший інструмент там, побудований на rspec ruby
• Goss - YAML, простий, <10 МБ автономний двійковий файл, надзвичайно швидкий, може генерувати тести із стану системи
• Інспек - Рубі, подумайте про це як про вдосконалений сервер, майже такий же синтаксис, який створили хлопці-кухарі. Побудований для розширення легше, ніж серверспец
• Testinfra - Python, має цікаву особливість того, що можна використовувати інвентаризацію / варси Ansible

Основні відмінності між ними:

Зрештою, я б запропонував провести день, експериментуючи з усіма ними, щоб відчути їх, перш ніж вирішити для себе.

• За винятком Goss, всі рамки можуть працювати проти віддаленої машини (наприклад, над ssh). Goss працює лише локально або в docker w / dgoss.
• Усі рамки можна запустити локально на сервері, але для встановлення або вбудовування потрібні Python або Ruby. Inspec забезпечує автономний пакет <150 Мб із вбудованою версією рубіну. Goss - це одинарний <10 МБ бінарний файл без зовнішніх залежностей.
• Goss вбудував підтримку виходу нагіо / сенсу, що дозволяє легше інтегруватися з інструментами моніторингу.
• Тести Goss, як правило, простіші, але менш гнучкі, оскільки засновані на YAML. Інші рамки дозволяють використовувати всю потужність основної мови Python / Ruby для написання тестів або розширення функціональності інструменту. (простота та гнучкість)
• Goss дозволяє генерувати тести з поточного стану системи
• Наскільки мені відомо, Testinfra - це єдиний, який має вбудовану підтримку ангібельних інвентарів та змінних
• Інспек підтримує шеф-кухаря

Безперервне / дивергенційне тестування:

• Chef Compliance - працює з Inspec, щоб постійно перевіряти ваші сервери, платний продукт
• Goss - Легко підключитися до Nagios або Sensu. Також підтримує виставлення тестів сервера як кінцевої точки http.

Тестування джгутів на розробку:

• кухня - інструмент тестування джгутів, запускає екземпляр, запускає конфігураційний код управління, запускає тестовий набір. Зроблено хлопцями-кухарями
• Молекула - схожа з тестовою кухнею, але написана спеціально для ансиб

Повне розкриття: Я автор пліток

ОНОВЛЕННЯ: InSpec 4.x або вище використовує змішану комерційну / відкриту ліцензію - див. Коментарі.

Для цього я бачив два інструменти: InSpec та ServerSpec . Serverspec - це інструмент на основі Ruby, який будується на RSpec . InSpec натхненний RSpec та ServerSpec.

Я використовував ServerSpec. Це круто, але, можливо, не на 100% стабільно. У мене виникли проблеми з тестуванням конкретних версій програмного забезпечення на Ubuntu.

Я читав документи InSpec, але глибоко не копався. Це по суті те саме, що і Serverspec.

Судячи з зобов’язань Github, схоже, що робота над ServerSpec дещо зменшилася, тоді як InSpec просто посилюється.

ОНОВЛЕННЯ: InSpec 4.x або вище використовує змішану комерційну / відкриту ліцензію - див. Коментарі.

При використанні інструментів управління конфігурацією, таких як Ansible, сам інструмент несе відповідальність за запобігання зрушення конфігурації. Після того як ви використовували Ansible для встановлення певної конфігурації, повторне виконання Ansible забезпечить вашу конфігурацію такою, якою ви її визначили. Це також вимагає, щоб ваш Відповідальний код був написаний таким чином, що є ідентичним.

З огляду на вищезазначене, забезпечення тестуванням може бути досягнуто шляхом виконання ваших ігрових книг Ansible в циклі з якогось сервера. Наприклад, робота з крон, або Дженкінс, може виконувати ігрові книги кожні 30 хвилин і повідомляти про будь-яку помилку. Якщо відмов немає, це означає, що ваша конфігурація перевірена, а помилки означають, що існує проблема з переходом серверів у потрібний стан .

У випадку, коли ви не можете довіряти своєму коду, щоб він був записаний як idempotent, і, отже, ви не можете реально виконувати Ansible повторно в циклі з автоматичного сервера, вирішення існує. Ви можете зробити те саме, що описано вище (запустити Ansible в циклі), але використовувати його режим " сухого виконання" . Кожен раз, коли Ansible повідомляє, що потрібні зміни, завдання Jenkins (або завдання cron) може повідомити вас про зміну вашої передбаченої конфігурації та сервери не в бажаному стані .

Щоб переконатися, що ваш код Ansible насправді робить те, що, на вашу думку, слід робити, застосовуються рішення, згадані Дейвом Сверським. І InSpec, і Serverspec - це інструменти, які по- різному підтверджують, чи справді ваші ігрові книги виконують те, що ви маєте на увазі. Прекрасний спосіб виконання подібних інструментів у тестових умовах (навіть докер-контейнери) - це використання kitchen.ci, який обробляє весь клей між різними інструментами тестування інфраструктури та виконанням ваших ігор / модулів / кулінарних книг.

Kitchen.ci спочатку використовувався для тестування кулінарних книг шеф-кухарів, але додатки існують і для інструментів Ansible та інших інструментів CM.

Тест-кухня має плагін для перевірки коду відповіді. Це не так глибоко, як інтеграція шеф-кухаря, але це робить роботу в більшості випадків. Існує також останній проект Molecule, який є спеціалізованою системою тестування Ansible.

Ви можете відстежувати невідповідності конфігурації / інфраструктури за допомогою Outthentic , легко створити тестовий набір, щоб "виправити" бажаний стан і повторно запустити його щоразу, коли потрібно відстежувати небажані зміни.