SparrowHub — репозиторий готовых утилит для системного администрирования

    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.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 10
    • 0
      Ну и как оно решает непереносимость написанных на коленке скриптов? Идея с чекпоинтами — интересная, вот всегда во всех скриптах мечтал увидеть описание среды, где этот скрипт работал как ожидалось. Но это желание относится скорее к культуре программиста\админа, который может описать среду, а может и не описать. Да и не возможно оно в принципе — поменялось что-то в зависимостях и уже не работает.
      • +1

        Приветствую!


        Отвечая на ваш вопрос. Дело в том что у обычных кастомных скриптов написанных "на коленке" есть свои ограничения с точики зрения их дистрибуции, приведу некоторые:


        • как правило отсутствие унифицированного способа доставки скрипта на целевую машину. В лучшем случае это будет чекаут из системы контроля версий, в худшем копирование руками скрипта на сервер.


        • как правило отсутствие версионирования скриптов. что если мы разработали новую версию скрипта и что-то пошло не так и мы хотим быстро откаттится на старую? и так далее ...


        • как правило отсутствие стандартного интерфейса дающего нам понимание какие входные параметры принимает скрипт и какой их смысл, зачастую скрипт пишется для себя, и вся документация ( если таковая присутствует ) и описание входных параметров, хранится прямо в исходном коде


        • как правило отсутствие управления зависимостями — т.е. если скрипт использует какие-то библиотеки и тулзы, как их автоматически доставить при установке скрипта?

        Ок, sparrow частично реашает эти проблемы, частично потом что некоторые вопросы с сожелению невозможно 100% автоматизировать.


        • унифицированный способо доставки — он есть, везде, на всех серверах один и тот же — $ sparrow plg install


        • стандартный интерфейс — решается частично, конечно же sparrow не сделает автоматическое документирование скрипта, но из коробки есть такая фича как конфигурация плагина, ( то что в статье назавается конфигурацей чекпоинта ) — собственно автор плагина всегда может задать, описать входные параметры ввиде параметров INI файла, который пользователь должен определить, что бы все работало, sparrow автоматически передаст проиниицализированный INI файл ввиде хэш структуры внутрть плагина, эта штука удобная для разработчика. конечно все это может не помочь если разработчик не отразит в документации (README.md) описание конфигурации. Документация кстати также отражается на странице плагина на SparrowHub.


        • ну и насчет управления зависимостями — решается в том смысле, что sparrow плагин по сути что-то очень схожее со CPAN модулем, и написан фактически на миксе Perl кода и DSL, и значит там могут использоваться другие CPAN модули, у правления зависимостями для которых происходит через carton+cpanfile. Возможно в будующем я сделаю поддержку не только Perl но пока так.
        • 0
          gitlab+saltstack решает проблемы версионности\доставки\удобного управления версиями. Понимание работы скрипта — это отсыл к его документированности и культуре написания. Скрипт без единого коментария и с переменными типа br, i, j, td и пр. хоть как документируй — придется каждый раз пытаться понять, что он делает.
          • 0

            Смотрите мой предыдущий обобщенный ответ. Версионировнность не в плане системы контроля версий для хранения исходного кода, а в плане версионированности пакетов устанавливаемого по, это разные все же вещи. Опять таки же использования configuration management tool + система контроля версий вполне себе вариант, но все же предпочтительнее использовать именного целевые решения вида пакетных менеджеров, и да для массированных установок можно сверху ещё прикрутить configuration management tool какой нибудь.

            • 0

              Да и по поводу документирования скрипта, с вами абсолютно согласен, никакой системой нельзя заставить документировать свои программы :-), другой вопрос, что можно предоставить дополнительные возможности с целью упрощения процесса документирования или фиксирования паблик интерфейса, как хотите назовите. В sparrow такой возможностью является встроенный механизм конфигурирование плагина, т.е. автору нового плагина нет необходимости создавать свой механизм инициализации, он может воспользоваться существующим, по другому можно ещё сказать так, если автор не воспользовался возможностью и не определили входные параметры скрипта ввиде переменных конфига, то он написал недобросовестный код, который может работать неправильно.


              Другой вопрос, когда у разработчика нет подобной автоматической возможности определить настройки, и ему приходится создавть такой механизм с нуля самому, знаю по себе, неминуемо появляется желания "засунуть" эти настройки вглубь скрипта или же ожидать передачи параметров через переменное окружения, о которых нигде, кроме как в коде скрипта не упомянуто: -)

        • 0
          Вопрос такой — могу ли я использовать sparrow с приватным набором плагинов?

          И немного по Вашему комментарию:

          Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.

          что касается:
          унифицированный способо доставки — он есть, везде, на всех серверах один и тот же — $ sparrow plg install

          есть wget / fetch а с ними и репы с готовыми скриптами. В случае с массовыми чеками, инсталами, etc. — chef / ansible. В случае с последними — проблема стандартного интерфеса, версионирование, управление зависимостями — уже не проблемы.

          P.S. и руками время от времени равно нужно что-то писать — забыть всё можно :)
          • 0
            Вопрос такой — могу ли я использовать sparrow с приватным набором плагинов?

            Да, в sparrow как раз есть тип плагинов, называемыми приватными, в двух словах вы можете держать исходный код плагина в remote гит репозитария и ставить плагин прямо оттуда, репозитарий соответсвенно может быть любым, публичным или закрытым, главное что это был гит репозитарий. Как раз было придумано для того, чтобы люди могли расшаривать например в пределах одной фирмы плагины, при этом не размещая их в публичный доступ. Подробнее читайте об этом в документации. На другие вопросы отвечу отдельно :)

            • 0
              Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.

              Простите, не совсем понял что вы здесь хотите сказать, универсальность использования это что? значит ли универсальность использования гарантирует и переносимость — ( простую ) возможность установить и запустить скрипт на потенциально любом другом дистрибутиве линукса с минимальными усилиями по доставке и конфигурации?

              • 0
                Сервера которые я администрирую работают под управлением разных дистрибутивов (RH, CentOS(5 — 7), Debian(6 — 8), Ubuntu(12.04, 14.04) ,FreeBSD(7 — 10)).
                Есть скрипты написанные под семейства, есть более унифицированные linux or bsd, есть универсальные. Универсальные — именно те, запуск которых гарантирован на всех обслуживаемых серверах. Что касается переносимости — все доставляется по средствам скачивания с единого сервера хранения таких скриптов ( к примеру s.example.com ) — все имеют стандартизированные названия, что без особого труда позволяет получить нужный скрипт. Да этот вариант подвержен тому, что по сути версионирование отсутсвует.
                • 0

                  Попытаюсь ответить на все предыдущие комментарии вкупе. Во многих системах есть понятие пакетных менеджеров, например, apt в дебиане, yum в центос, cpan в perl, ruby gems в ruby, ну и так далее, примеров можно приводить много, все они решают более и менее одни те же задачи, а именно — управляют пакетами программного обеспечения, собственно, sparrow так же пакетный менеджер, со своей конечно спецификой и своей целевой аудиторией. То что вы описали в вашем случае, то же, наверное, попытка написать свой пакетный менеджер, хотя конечно версиоонирование отсутствующее в нем, важная вещь, как вы сами думаю пониамаете. Я пытаюсь презентовать sparrowhub как решение доступное для многих, не только для меня или моей компании. Т.е сделать, скажем так, обобщенный, не привязанный к одной конкретно системе репозитарий, в который люди из комьюнити смогут выкладывать свои пакеты, но следуя, конечно, определенному воркфлоу, т.е если вас устраивает ваше решение, то и отлично, но возможно через какое то время вы найдёте на sparrowhub плагины полезные и вам. :-) вот как то так.


                  Да, и по поводу средств управления конфигурациями, таких как шеф или ansible, они как раз чаще всего взаимодействуют со специализированными пакетными менеджерами, хотя опять так же простой вариант с wget и архивным сервером тоже возможен, но скорее всего как раз когда нет API соответствуещего пакетного менеджера, который абстрагирует подобную логику доставки софта на сервер .

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.