Доброе время суток! В данном посте я расскажу о том, как просто и быстро писать различные скрипты проверки состояния инфраструктуры с помощью инструментов Bash, Outthentic и Sparrow ... Задача — у нас есть сервер, на который мы устанавливаем приложения и делаем настройку конфигурации. Хочется написать скрипт, который быстро даст нам ответ, что с сервером все хорошо, и приложение настроено и работает корректно. Этакий smoke тест, который будет нам полезен, когда мы будем заниматься поиском проблем или же просто проверять, что очередной деплоймент ничего не сломал. Предвидя возможные вопросы, я знаю, что уже существуют инструменты, которые делают что-то подобное ( inspec ), тем не менее, хочу рассказать об альтернативном походе. ( Будет интересно сравнить ). Итак, почему Bash? Потому что он достаточно прост в использовании и позволяет быстро и эффективно писать разного рода скрипты, imho я бы не стал использовать Bash для более сложных задач, но для данного рода проблем он вполне подходит. Затем, что такое Outthentic и как он нам здесь пригодится? Outthentic — это фреймворк для написания скриптов, позволяющий быстро написать, настроить и запустить ваш скрипт ( в данном случае, написанный на Bash, но можно и на других языках ), так же, что немаловажно, Outthentic имеет встроенный DSL, подходящий под написание скриптов в стиле автоматизированных тестов, что может быть удобным при написании скриптов мониторинга. И последнее — почему ( или что-то такое ) Sparrow и как он нам поможет? Sparrow — это платформа и среда выполнения пользовательских скриптов, позволяющая распространять и настраивать готовые скрипты в виде т.н. Sparrow плагинов. Основной выхлоп в том, что когда наш скрип написан и оттестирован, вы можете упаковать его в виде плагина, загрузить в Sparrow репозитарий и передать далее в отдел эксплуатации и/или любым другим коллегам, которые захотят воспользоваться вашим скриптом.  Пример отчасти основан на реальной практике, и отчасти сознательно упрощен, что бы не перегружать статью излишними деталями. Более-менее подобного рода проверки мне приходится делать постоянно, поэтому я и решил написать для них скрипт автоматизации, итак, будем проверять, что на целевом сервере target-server: запущен tomcat, то есть виден в списке процессов http запросы на некоторые ресурсы приложения ( развернутого на сервере )
возвращают успешный http код (200) — GET 127.0.0.1:8080/healthcheck Да, и важно отметить, что все проверки выполняются прямо на целевом сервере: В данном случае скрипт будет тривиальным: Запустив скрипт на целевом сервере получим в выводе что-то похоже на это: ( на данном этапе пока никаких проверок не происходит, просто убедимся, что скрипт отрабатывает ): Вся суть нашего мониторинга — возможность последовательного запуска нескольких команд и далее анализ их вывода с помощью набора простых правил, здесь и вступает в игру Outthentic. Для начала установим пакет как CPAN модуль: Далее слегка модифицируем наш скрипт, что бы его можно было запускать через Outthentic: Получим вывод, аналогично тому, когда мы запускали скрипт напрямую. Пока, что польза Outthentic не очевидна. Доходим до использования DSL. Создадим несколько простых проверочных правил для валидации вывода скрипта и положим правила в файл story.check: Запустим снова strun: Мы видим, что проверочные правила сработали и, что вывод от скрипта успешно прошел все проверки, а это все что нам нужно от нашего мониторинга. Формат отчетов strun настраивается и имеет несколько вариантов, например, мы можем выбрать более лаконичный вывод, который выдаст всю детализацию, только в случае ошибки: Вот как будет выглядеть отчет в случае если, по каким-то причинам, у нас не запущен tomcat сервер: Outthentic еще удобен и тем, что он позволяет просто добавлять и настраивать входные параметры для ваших скриптов. Допустим, чисто теоретически, мы захотим задавать хост и порт для сервера баз данных. Добавим дефолтные значения входных параметров через suite.yaml — файл для хранения дефолтных настроек в терминологии Outthentic: В данном случае иерархия конфигурационного файла может быть произвольной, просто я хочу показать, как легко и просто с помощью Outthentic передавать входные параметры, описанные в виде иерархический структуры данных и использовать их даже внутри Bash скриптов ( не применяя дополнительного парсинга ): Чуть-чуть изменим скрип мониторинга, что бы он брал свои входные параметры из-вне : Теперь мы можем запустить наш скрипт с дефолтными параметрами: Или же переопределить параметры через командную строку: Идем дальше, все что нам осталось сделать — это передать скрипт в эксплуатацию всем заинтересованным лицам, для этого нам понадобится Sparrow. Sparrow предоставляет две основные возможности дистрибуции скриптов — посредством публичного репозитария SparrowHub и посредством приватных репозитаиев, построенных на использовании удаленных репозиториях Git. Скорее всего, когда мы пишем чисто внутренние скрипты, нам больше подходит второй способ. Он к тому же еще и более простой, так как требует только того, что бы исходники скрипта лежали в некотором удаленном Git репозитарии, что же сделаем это: Добавив основные файлы проекта (story.bash и story.check ), нам остается настроить файл с мета данными ( который собственно и дает понять, что это не просто скрипт, а Sparrow плагин ) : На самом деле файл с мета данными может содержать гораздо большее число параметров, но мы ограничимся здесь для простоты минимальным набором. Окей, мы фактически сделали наш первый Sparrow плагин, осталось отправить файлы в git remote: Это самая интересная часть в том смысле, что он показывает как Sparrow облегчает процесс установки и интеграции ваших скриптов сторонними командами. Для начала, что бы использовать созданный нами плагин на каком-то целевом сервере, нам необходимо установить на этом сервере Sparrow клиент: Далее все просто, т.к. плагин — приватный и не будет загружен с общего репозитариия, уведомляем об этом Sparrow: Пара значений которую мы должны положить в локальный индексный файл ~/sparrow.list это название плагина ( не обязательно должно совпадать с тем, что мы использовали в предыдущей части и URL удаленного репозитария, где лежит исходный код плагина ) Теперь обновляем индекс sparrow, что бы стал доступен добавленный нами плагин: И устанавливаем сам плагин: Теперь мы можем запустить плагин как есть: Или же, передав ему параметры: И наконец-то, все тоже самое можно запустить в виде Sparrow задачи: Последний вариант запуска удобен тем, что вы можете создать несколько задач ( с разными конфигурациями ) для запуска одного и того же плагина. По сути задача — это именованная конфигурация запуска Sparrow плагина, а проект — группа задач. На этом все. Если кому-то будет интересно, вот о чем я еще не сказал: приватные Sparrow репозитарии можно настраивать не только через локальные индекс файлы ~/sparrow.list ( что неудобно при большом количестве плагинов ), но и через Sparrow::Nest — API управления приватными Sparrow репозитариями. Sparrow плагины можно запускать удаленно на серверах ( через ssh ) с автоматической предустановкой Sparrow клиента — добро пожаловать в проект Sparrowdo. Там есть еще Perl6 API для Sparrow и много другого (-: ! Как всегда — вопросы, замечания, предложения, конструктивная критика — приветствуется. С уважением. Алексей devops, developer, open-source enthusiast