SparrowHub — проект, целью которого является распространение различных готовых решений для задач системного администрирования и не только.
Несмотря на то, что существует масса решений по автоматизации задач системного администрирования, определенная ниша в этой области все же остается незанятой. Что мы делаем, когда хотим решить какую-то специфическую задачу? Например, проверить логи нашего ssh сервиса на наличие неудачных попыток логинов с целью позаботиться о секьюрности наших серверов? — Берем и пишем однострочник, состоящий из bash команд вида grep, sed, awk и так далее, ну, или можем написать скрипт на Perl. Отлично, все работает. Eсть решение, которое устраивает нас. И мы пользуемся им. Вопрос в том, как мы хотим сохранить результаты наших трудов, что бы поделиться ими с другими или же когда пройдет время снова воспользоваться придуманным решением. Вот тут и возникает проблема.
Кастомные скрипты, написанные "на коленке" хороши, когда нужно что-то сделать прямо здесь и сейчас, но с ними есть проблемы:
- они плохо переносимы
- они легко забываются ( у них зачастую невнятный интерфейс и "захардкоженная" конфигурация )
Тут и возникает идея репозитария переносимых утилит. В принципе, это может быть все что угодно — проверки оставшегося места на диске, поиск определенной группы процессов в списке, учет времени работы отдельных программ, анализ логов на наличие определенных событий и так далее. Вы пишите утилиту, точнее, в терминах SparrowHub — плагин, загружаете его в репозиторий, и, вуаля — он становится доступным для других!
Достаточно установить на своем сервере утилиту sparrow которая предоставляет интерфейс к репозитарию SparrowHub и начать пользоваться готовыми плагинами.
Вот как это выглядит в моей случае, приведу несколько примеров. И хотя кому-то они могут показаться тривиальными с точки зрения замены их своими кастомными решениями, все же вспоминаем то, с чего я начал свой топик — почему кастомные скрипты могут быть проблематичны в использовании. И потом, т.к. SparrowHub проект достаточно молодой, на нем еще не успело накопится достаточное количество плагинов, собственно данный пост и нацелен на то, что бы привлечь в коммьюнити новых разработчиков!
Итак, ставим сначала sparrow, это — CPAN модуль:
$ cpanm SparrowИз не Perl зависимостей нам еще понадобится curl:
$ yum install curlПроверяем, что sparrow клиент установлен:
$ sparrowДалее создаем проект. Проект — это просто контейнер для плагинов, которые мы будет устанавливать и использовать. Можно иметь несколько проектов, для разбиения используемых плагины на логические группы. Например, проект system — для системных проверок, например места на диске или отслеживания долго работающих процессов, проект nginx — для различных проверок nginx сервера, и так далее.
$ sparrow project create systemДалее мы можем поискать различные плагины. Альтернативным способом будет являться посещение ресурса https://sparrowhub.org и поиском через web интерфейс.
$ sparrow index update # получим обновления индекса из SpаrrowHub
$ sparrow plg searchПоследняя приведенная команда выдаст нам список всех доступных плагинов. Выбираем df-check — плагин для проверки оставшегося места на диске. Устанавливаем плагин:
$ sparrow plg install df-check Ок. В принципе уже можно запустить плагин как есть командой:
$ sparrow plg run df-checkИ убедится, что места на диске на сервере достаточно. Но добавим еще один шаг, сделав наш плагин настраиваемым. Для это воспользуемся концепцией чекпоинтов или контрольных точек, извиняюсь за невольную тафтологию :) Чекпоинт в sparrow — это абстракция позволяющая связывать отдельный плагин с конкретной конфигурацией. Таким образом, вы можете использовать один и тот же плагин с разными конфигурациями, не трудно догадаться, что в этом случае мы будем иметь несколько чекппоинтов. Чекпоинты добавляются в проекты, связываются с установленными плагинами ( здесь и происходит разбивка плагинов по логическим группам ) и затем настраиваются.
Создадим чекпоинт:
$ sparrow check add system diskСвяжем чекпоинт с плагином:
$ sparrow check set system disk df-checkИ теперь самое интересное… настоим чекпоинт или плагин, что в данном случае одно и тоже ...
$ export EDITOR=nano
$ sparrow check ini system disk
[disk]
# установить в процентном соотношении допустимый размер занятого места на диске
threshold = 70Отлично. Теперь запустим чекпоинт, точнее плагин с настройками, определенными для данного чекпоинта:
$ sparrow check run system diskНа моей машине результат будет выглядеть так:
vagrant@Debian-jessie-amd64-netboot:~/my/outthentic$ sparrow check run system disk
# running cd /home/vagrant/sparrow/plugins/public/df-check && carton exec 'strun --root ./ --ini /home/vagrant/sparrow/proj$
/tmp/.outthentic/13248/home/vagrant/sparrow/plugins/public/df-check/disk-shortage/story.t ..
ok 1 - perl /home/vagrant/sparrow/plugins/public/df-check/disk-shortage/story.pl succeeded
ok 2 - stdout saved to /tmp/.outthentic/13248/KopZcyueYX
# threshhold: 70
# verify ... /dev/sda1
# verify ... udev
# verify ... tmpfs
# verify ... tmpfs
# verify ... tmpfs
# verify ... tmpfs
# verify ... none
# verify ... none
ok 3 - output match /(\S+)\s+(\S+)\s+(\S+)\s+(\S+)\s+(\S+)/
ok 4 - enough disk space (84%) on /dev/sda1
ok 5 - enough disk space (0%) on udev
ok 6 - enough disk space (1%) on tmpfs
ok 7 - enough disk space (1%) on tmpfs
ok 8 - enough disk space (0%) on tmpfs
ok 9 - enough disk space (0%) on tmpfs
ok 10 - enough disk space (92%) on none
ok 11 - enough disk space (92%) on none
1..11
ok
All tests successful.
Files=1, Tests=11, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.00 csys = 0.07 CPU)
Result: PASSСобственно на этом ознакомление co SparrowHub в его практическом применении можно закончить. Существует, конечно же ряд других интересных утилит, разработанных и выложенных мной на SparrowHub — среди них например — stale-proc-check — плагин по поиску долгоиграющих ( устаревших — stale ) процессов или logdog — утилиты по поиску записей в логах за заданный период времени с возможностью группировки и фильтрации. Статьи по практическому применению данных плагинов были недавно написаны мной на английском и размещены на сайтe blogs.perl.org :
Заключение.
В этой статье я коснулся только основных возможностей, предоставляемых репозитарием SparrowHub, всего конечно не расскажешь, да и не в этом цель. Задавайте вопросы, пишите комменты, загружайте свои плагины, используйте существующие или кидайте реквесты на разработку новых — было бы очень интересно узнать что именно требуются другим людям и реализовать это в виде плагинов. В конце концов выиграют все!
PS> для мердж реквестов и issues на утилиту sparrow используйте https://github.com/melezhik/sparrow, туда же можно постить запросы на новые плагины.
PS2> первая статья про sparrow была написано мной какое-то время назад и с ее текстом можно ознакомиться здесь, предупреждение — за это время многое изменилось.
Алексей Мележик, автор sparrow и SparrowHub.
Комментарии (10)
KuniLinux
17.04.2016 00:29Вопрос такой — могу ли я использовать sparrow с приватным набором плагинов?
И немного по Вашему комментарию:
Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.
что касается:
унифицированный способо доставки — он есть, везде, на всех серверах один и тот же — $ sparrow plg install
есть wget / fetch а с ними и репы с готовыми скриптами. В случае с массовыми чеками, инсталами, etc. — chef / ansible. В случае с последними — проблема стандартного интерфеса, версионирование, управление зависимостями — уже не проблемы.
P.S. и руками время от времени равно нужно что-то писать — забыть всё можно :)
alexey_melezhik
17.04.2016 09:36Вопрос такой — могу ли я использовать sparrow с приватным набором плагинов?
Да, в sparrow как раз есть тип плагинов, называемыми приватными, в двух словах вы можете держать исходный код плагина в remote гит репозитария и ставить плагин прямо оттуда, репозитарий соответсвенно может быть любым, публичным или закрытым, главное что это был гит репозитарий. Как раз было придумано для того, чтобы люди могли расшаривать например в пределах одной фирмы плагины, при этом не размещая их в публичный доступ. Подробнее читайте об этом в документации. На другие вопросы отвечу отдельно :)
alexey_melezhik
17.04.2016 09:48Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.
Простите, не совсем понял что вы здесь хотите сказать, универсальность использования это что? значит ли универсальность использования гарантирует и переносимость — ( простую ) возможность установить и запустить скрипт на потенциально любом другом дистрибутиве линукса с минимальными усилиями по доставке и конфигурации?
KuniLinux
17.04.2016 18:41Сервера которые я администрирую работают под управлением разных дистрибутивов (RH, CentOS(5 — 7), Debian(6 — 8), Ubuntu(12.04, 14.04) ,FreeBSD(7 — 10)).
Есть скрипты написанные под семейства, есть более унифицированные linux or bsd, есть универсальные. Универсальные — именно те, запуск которых гарантирован на всех обслуживаемых серверах. Что касается переносимости — все доставляется по средствам скачивания с единого сервера хранения таких скриптов ( к примеру s.example.com ) — все имеют стандартизированные названия, что без особого труда позволяет получить нужный скрипт. Да этот вариант подвержен тому, что по сути версионирование отсутсвует.alexey_melezhik
17.04.2016 20:26Попытаюсь ответить на все предыдущие комментарии вкупе. Во многих системах есть понятие пакетных менеджеров, например, apt в дебиане, yum в центос, cpan в perl, ruby gems в ruby, ну и так далее, примеров можно приводить много, все они решают более и менее одни те же задачи, а именно — управляют пакетами программного обеспечения, собственно, sparrow так же пакетный менеджер, со своей конечно спецификой и своей целевой аудиторией. То что вы описали в вашем случае, то же, наверное, попытка написать свой пакетный менеджер, хотя конечно версиоонирование отсутствующее в нем, важная вещь, как вы сами думаю пониамаете. Я пытаюсь презентовать sparrowhub как решение доступное для многих, не только для меня или моей компании. Т.е сделать, скажем так, обобщенный, не привязанный к одной конкретно системе репозитарий, в который люди из комьюнити смогут выкладывать свои пакеты, но следуя, конечно, определенному воркфлоу, т.е если вас устраивает ваше решение, то и отлично, но возможно через какое то время вы найдёте на sparrowhub плагины полезные и вам. :-) вот как то так.
Да, и по поводу средств управления конфигурациями, таких как шеф или ansible, они как раз чаще всего взаимодействуют со специализированными пакетными менеджерами, хотя опять так же простой вариант с wget и архивным сервером тоже возможен, но скорее всего как раз когда нет API соответствуещего пакетного менеджера, который абстрагирует подобную логику доставки софта на сервер .
usefree
Ну и как оно решает непереносимость написанных на коленке скриптов? Идея с чекпоинтами — интересная, вот всегда во всех скриптах мечтал увидеть описание среды, где этот скрипт работал как ожидалось. Но это желание относится скорее к культуре программиста\админа, который может описать среду, а может и не описать. Да и не возможно оно в принципе — поменялось что-то в зависимостях и уже не работает.
alexey_melezhik
Приветствую!
Отвечая на ваш вопрос. Дело в том что у обычных кастомных скриптов написанных "на коленке" есть свои ограничения с точики зрения их дистрибуции, приведу некоторые:
как правило отсутствие унифицированного способа доставки скрипта на целевую машину. В лучшем случае это будет чекаут из системы контроля версий, в худшем копирование руками скрипта на сервер.
как правило отсутствие версионирования скриптов. что если мы разработали новую версию скрипта и что-то пошло не так и мы хотим быстро откаттится на старую? и так далее ...
как правило отсутствие стандартного интерфейса дающего нам понимание какие входные параметры принимает скрипт и какой их смысл, зачастую скрипт пишется для себя, и вся документация ( если таковая присутствует ) и описание входных параметров, хранится прямо в исходном коде
Ок, sparrow частично реашает эти проблемы, частично потом что некоторые вопросы с сожелению невозможно 100% автоматизировать.
унифицированный способо доставки — он есть, везде, на всех серверах один и тот же —
$ sparrow plg installстандартный интерфейс — решается частично, конечно же sparrow не сделает автоматическое документирование скрипта, но из коробки есть такая фича как конфигурация плагина, ( то что в статье назавается конфигурацей чекпоинта ) — собственно автор плагина всегда может задать, описать входные параметры ввиде параметров INI файла, который пользователь должен определить, что бы все работало, sparrow автоматически передаст проиниицализированный INI файл ввиде хэш структуры внутрть плагина, эта штука удобная для разработчика. конечно все это может не помочь если разработчик не отразит в документации (README.md) описание конфигурации. Документация кстати также отражается на странице плагина на SparrowHub.
usefree
gitlab+saltstack решает проблемы версионности\доставки\удобного управления версиями. Понимание работы скрипта — это отсыл к его документированности и культуре написания. Скрипт без единого коментария и с переменными типа br, i, j, td и пр. хоть как документируй — придется каждый раз пытаться понять, что он делает.
alexey_melezhik
Смотрите мой предыдущий обобщенный ответ. Версионировнность не в плане системы контроля версий для хранения исходного кода, а в плане версионированности пакетов устанавливаемого по, это разные все же вещи. Опять таки же использования configuration management tool + система контроля версий вполне себе вариант, но все же предпочтительнее использовать именного целевые решения вида пакетных менеджеров, и да для массированных установок можно сверху ещё прикрутить configuration management tool какой нибудь.
alexey_melezhik
Да и по поводу документирования скрипта, с вами абсолютно согласен, никакой системой нельзя заставить документировать свои программы :-), другой вопрос, что можно предоставить дополнительные возможности с целью упрощения процесса документирования или фиксирования паблик интерфейса, как хотите назовите. В sparrow такой возможностью является встроенный механизм конфигурирование плагина, т.е. автору нового плагина нет необходимости создавать свой механизм инициализации, он может воспользоваться существующим, по другому можно ещё сказать так, если автор не воспользовался возможностью и не определили входные параметры скрипта ввиде переменных конфига, то он написал недобросовестный код, который может работать неправильно.
Другой вопрос, когда у разработчика нет подобной автоматической возможности определить настройки, и ему приходится создавть такой механизм с нуля самому, знаю по себе, неминуемо появляется желания "засунуть" эти настройки вглубь скрипта или же ожидать передачи параметров через переменное окружения, о которых нигде, кроме как в коде скрипта не упомянуто: -)