Я использую марионетку для развертывания инфраструктуры, и большую часть работы я выполняю с компаниями Web 2.0, которые активно занимаются разработкой своих веб-приложений через тестирование. Кто-нибудь здесь использует подход, основанный на тестах, для разработки конфигураций своих серверов? Какие инструменты вы используете для этого? Насколько глубоко проходит ваше тестирование?
Я не думаю, что ты мог бы использовать разработка через тестирование. Но ты, конечно, можешь попробовать юнит-тестирование на новых серверах.
В основном вам нужно будет развернуть серверы, запустить службы в тестовом режиме, а затем запустить тесты с другого сервера (или серии серверов) для этих служб. Затем наконец запустили их в производство.
Возможно, с помощью скриптов Python для подключения к базам данных, веб-страницам и службам ssh. И затем верните PASS / FAIL. Было бы для тебя хорошее начало.
Или вы можете просто превратить это в решение для мониторинга, такое как Zenoss, Nagios или Munin. Затем вы можете протестировать во время развертывания; И контролировать во время производства.
Хотя я еще не смог выполнить TDD с манифестами Puppet, у нас есть довольно хороший цикл, чтобы предотвратить внесение изменений в производственную среду без тестирования. У нас есть два кукловода: один - наш постановщик кукол, а другой - наш кукловод в разработке. Мы используем "среду" Puppet, чтобы настроить следующее:
Наши разработчики приложений выполняют свою работу на виртуальных машинах, которые получают свои конфигурации Puppet из среды «тестирования» Puppetmaster. Когда мы разрабатываем манифесты Puppet, мы обычно настраиваем виртуальную машину в качестве тестового клиента в процессе разработки и направляем ее на нашу личную среду разработки. Когда мы довольны нашими манифестами, мы отправляем их в среду тестирования, где разработчики приложений получат изменения на своих виртуальных машинах - они обычно громко жалуются, когда что-то ломается :-)
На репрезентативном подмножестве наших производственных машин есть второй puppetd, работающий в режиме noop и указывающий на среду тестирования. Мы используем это, чтобы выявить потенциальные проблемы с манифестами до того, как они будут запущены в производство.
После того, как изменения прошли, т.е. они не ломают машины разработчика приложений и не производят нежелательный вывод в журналах марионеточного процесса «noop» производственных машин, мы запускаем новые манифесты в производство. У нас есть механизм отката, поэтому мы можем вернуться к более ранней версии.
Я думаю, что Джозеф Керн на правильном пути с инструментами мониторинга. Типичный цикл TDD таков: напишите новый тест, который не прошел, затем обновите систему, чтобы все существующие тесты прошли. Это было бы легко адаптировать к Nagios: добавить неудачную проверку, настроить сервер, повторно запустить все проверки. Если подумать, я иногда делал именно это.
Если вы хотите получить действительно хардкорное ядро, вам следует обязательно написать сценарии для проверки всех соответствующих аспектов конфигурации сервера. Система мониторинга, такая как Nagios, может не подходить для некоторых из них (например, вы можете не «отслеживать» версию своей ОС), но нет причин, по которым вы не могли смешивать и сочетать нужным образом.
Я работал в среде, которая находилась в процессе перехода на операционную модель TDD. Для некоторых вещей, например сценариев мониторинга, это сработало очень хорошо. Мы использовали buildbot для настройки тестовой среды и запуска тестов. В этом случае вы подходите к TDD с точки зрения «устаревшего кода». В TDD «Legacy Code» - это существующий код, не имеющий тестов. Итак, первые тесты не терпят неудачу, они определяют правильную (или ожидаемую) работу.
Для многих заданий по настройке первым шагом является проверка возможности анализа конфигурации службой. Многие службы предоставляют некоторые средства для этого. У Nagios есть предполетный режим, у cfagent нет act, apache, sudo, bind и многие другие имеют аналогичные возможности. Это, по сути, пробег для конфигураций.
Например, если вы используете apache и отдельные файлы конфигурации для разных частей, вы также можете протестировать части, просто используя другой файл httpd.conf, чтобы обернуть их для запуска на тестовой машине. Затем вы можете проверить, что веб-сервер на тестовой машине дает там правильные результаты.
На каждом шагу вы следуете одному и тому же основному шаблону. Напишите тест, проведите его успешно, проведите рефакторинг проделанной работы. Как упоминалось выше, при следовании по этому пути тесты не всегда могут завершиться с ошибкой принятым методом TDD.
Рик
Я считаю, что следующие ссылки могут быть интересны
огурец-нагиос - проект, который позволит вам превратить Огурец пакет в плагин Nagios и содержит определения шагов для SSH, DNS, Ping, AMQP и общих типов задач «выполнить команду»
http://auxesis.github.com/cucumber-nagios/
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Есть также некоторые усилия в отношении Puppet / Python. http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php