Я использовал Puppet для развертывания инфраструктуры, и большую часть работы я выполняю с компаниями Web 2.0, которые активно занимаются разработкой своих веб-приложений на основе тестирования. Кто-нибудь здесь использует тестовый подход к разработке своих конфигураций сервера? Какие инструменты вы используете для этого? Насколько глубоки ваши испытания?
Ответы:
Я не думаю, что вы могли бы использовать разработку через тестирование . Но вы наверняка можете попробовать юнит-тестирование на новых серверах.
В основном вам нужно будет развернуть серверы, запустить службы в тестовом режиме, а затем запустить тесты с других серверов (или серии серверов) для этих служб. Затем, наконец, запустить их в производство.
Возможно использование сценариев python для подключения к базам данных, веб-страницам и службам ssh. А затем верните ПРОПУСК / НЕУДАЧУ. Было бы хорошим началом для вас.
Или вы можете просто свернуть это в решение для мониторинга, такое как Zenoss, Nagios или Munin. Затем вы можете проверить, во время развертывания; И монитор во время производства.
Я думаю, что Джозеф Керн находится на правильном пути с инструментами мониторинга. Типичный цикл TDD: написать новый тест, который не проходит, а затем обновить систему, чтобы пройти все существующие тесты. Это было бы легко адаптировать к Nagios: добавьте неудачную проверку, настройте сервер, перезапустите все проверки. Если подумать, я иногда делал именно это.
Если вы хотите получить действительно хардкорное ядро, вы должны написать сценарии для проверки всех соответствующих аспектов конфигурации сервера. Система мониторинга, такая как Nagios, может не подходить для некоторых из них (например, вы не можете «отслеживать» версию своей ОС), но нет никаких причин, по которым вы не могли бы смешивать и сопоставлять соответствующим образом.
Хотя я пока не смог сделать TDD с манифестами Puppet, у нас есть довольно хороший цикл, чтобы предотвратить ввод изменений в производство без тестирования. У нас есть два мастера кукловодов, один из них - наш мастер производства кукол, а другой - наш мастер кукловодов. Мы используем «окружение» Puppet для настройки следующего:
Наши разработчики приложений работают на виртуальных машинах, которые получают свои конфигурации Puppet из среды тестирования Puppetmaster. Когда мы разрабатываем манифесты Puppet, мы обычно настраиваем виртуальную машину, которая будет выполнять роль тестового клиента в процессе разработки, и направляем ее в нашу личную среду разработки. Как только мы довольны нашими манифестами, мы отправляем их в среду тестирования, где разработчики приложений получают изменения на своих виртуальных машинах - они обычно громко жалуются, когда что-то ломается :-)
На репрезентативной подгруппе наших производственных машин есть второй puppetd, работающий в режиме noop и указывающий на среду тестирования. Мы используем это для выявления потенциальных проблем с манифестами до того, как их отправят в производство.
После того, как изменения пройдены, то есть они не ломают машины разработчика приложений и не выдают нежелательный вывод в журналах процесса «noop» puppetd производственных машин, мы запускаем новые манифесты в производство. У нас есть механизм отката, поэтому мы можем вернуться к более ранней версии.
Я работал в среде, которая находилась в процессе перехода к модели работы TDD. Для некоторых вещей, таких как скрипты мониторинга, это работало очень хорошо. Мы использовали buildbot для настройки среды тестирования и запуска тестов. В этом случае вы подходите к TDD с точки зрения «Устаревшего кода». В TDD «Legacy Code» есть существующий код, который не имеет тестов. Таким образом, первые тесты не дают ошибок, они определяют правильную (или ожидаемую) работу.
Для многих заданий по настройке первым шагом является проверка возможности анализа конфигурации службой. Многие сервисы предоставляют некоторые возможности для этого. Nagios имеет режим предпечатной проверки, cfagent не имеет никаких действий, apache, sudo, bind и многие другие имеют аналогичные возможности. Это в основном безвыходное положение для конфигураций.
Например, если вы используете apache и отдельные файлы конфигурации для разных частей, вы можете протестировать части, а также просто использовать другой файл httpd.conf, чтобы обернуть их для запуска на тестовом компьютере. Затем вы можете проверить, что веб-сервер на тестовом компьютере дает правильные результаты там.
Каждый шаг по пути вы следуете той же базовой модели. Напишите тест, пройдите тест, проведите рефакторинг проделанной вами работы. Как упомянуто выше, при следовании по этому пути тесты не всегда могут терпеть неудачу принятым способом TDD.
Rik
Я считаю, что следующие ссылки могут быть интересны
cucumber-nagios - проект, который позволяет превратить ваш набор Cucumber в плагин 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