Sparrow — система управління користувацькими скриптами

Привіт. Протягом цього року я написав низку статей про Sparrow — системі управління користувацькими скриптами. В кінці року я хотів би зробити свого роду результуючий пост, де ще раз спробую описати основну суть цього інструменту.

image
Отже, що ж таке Sparrow? Якщо не вдаватися в різні варіанти використання даної системи, Sparrow дозволяє швидко розробляти, налагоджувати та запускати користувальницькі скрипти.
Наведу конкретний приклад. У моїй роботі мені часто доводиться заходити на безліч серверів і робити там що-те, що називається руками. При цьому хочеться що б оточення для мого акаунту було якщо не таким же, то сильно схожим на те, з чим я маю справу на власній машині. Ось що маю на увазі:
  • список встановлених пакетів, які часто потрібно мені в роботі — наприклад tree, curl, nano, git, mc
  • певна налаштування для редактора nano
  • певна налаштування для клієнта git
І так далі. Список подібного роду дрібниць у кожного може бути свій. Все це, звичайно можна налаштовувати і встановлювати вручну, як кажуть, не "rocket science", але по-перше, потрібно щоразу вводити купу команд і лізти в документацію, що б правильно налаштувати софт. По-друге, ви можете банально щось забути або упустити, адже складно тримати все в голові. Все це вимагає часу і сил. Отже, ні для кого не відкрию тут америки, потрібна звичайна автоматизація.
Окей. Відразу ж передбачаю тут коментарі виду, а чому б не використовувати для такого роду завдань якої-небудь chef або ansible. На це у мене є ряд думок, ось вони:
  • Chef або Ansible гарні для вирішення завдань промислового масштабу, коли у вас є багато серверів і типова, добре організована інфраструктура, яку легко виразити через (cook/play)буки.
  • Якщо у вас є кастомні, особисті скрипти, які, по суті, влаштовують вас і ви не хотіли б їх перетворювати в універсальні рішення — рішення типу chef або ansible вже може бути свого роду перебором.
  • Так само не можна забувати, що той же chef в своєму стандартному workflow вимагає серверної частини і правильно налаштованого шеф клієнта ( реєстрація ноди ) — погодьтеся, вже забагато для вирішення задачі типу — встановити редактор nano або налаштувати конфіг git клієнта.
  • І, нарешті, деколи у вас вже є готовий і влаштовує вас bash скрипт, який ви хочете просто запустити на цільовому сервері, при цьому абсолютно не бажаючи перетворювати його chef cookbook або ansible playbook і здійснювати додаткові "рухи", пов'язані з портированием вашого коду ( що, до речі, не завжди гладко для звичайних bash shell-скриптів — але це тема для окремого посту ) в экоситемы даних інструментів.
  • Все це наводить на думку, що потрібно просте, але при цьому достатню гнучке рішення, яке дозволяє ( розробляти ) поширювати користувальницькі скрипти на різні машини. Так з'явилася ідея Sparrow і репозитарію користувальницьких сценаріїв SparrowHub. Докладно про це я писав* в тому числі на Хабре.
(*) пост трохи застарів щодо поточної реалізації Sparrow, але основна суть там відбито.
Отже, якщо резюмувати основні особливості Sparrow, можна сказати наступне:
  • Sparrow — це оркестратор користувальницьких сценаріїв, що дозволяє розробляти, поширювати і управляти різноманітними сценаріями, упакованими і налаштованим уніфікованим способом.
  • Таким чином, скрипти завантажуються в єдиний репозиторій, мають автора, версію і документацію, все це аналогічно будь-якій системі розповсюдження пакетів, такий як apt/debian або CPAN/Perl.
  • Sparrow надає консольний клієнт дозволяє шукати (індекс репозитарію) і встановлювати і запускати скрипти.
  • Встановлення скриптів може відбуватися за останньою або заданої версії. Взагалі, версії скриптів заохочує їх використання в команді, коли розробник може вносити чергові зміни в скрипт, викладаючи його з новою версією у репозитарій, при цьому користувачі, в разі порушення зворотної сумісності завжди можуть "відкотитися" до попередніх версій сценарію. Також спрощується процес відстеження змін в скрипті, коли, знаючи версію, ви завжди можете подивитись у файлі changelog, що оновилося за останній час.
  • У випадку з приватними скриптами, коли ви не хотіли б викладати їх в публічний доступ ( режим роботи центрального сховища ), Sparrow дозволяє встановлювати скрипти, розміщені на віддалених git архівів ( так звані private sparrow plugins ).
  • Sparrow в деякій мірі — language agnostic система. Скрипти, що завантажуються в репозитарій SparrowHub можуть писатися на одній з трьох мов:
    • Perl
    • Ruby
    • Bash
Для будь-якого з цих мов реалізований Sparrow API дозволяє зручним спосіб налаштовувати скрипти і організувати многосценарные програми ( те що в Sparrow називається модулі ), так само не залежно від мови написання сценарію ви отримуєте досить потужний DSL верифікації вихідного потоку (stdout) запускаються скриптів, що робить Sparrow дуже привабливим для написання скриптів тестування, моніторингу та аудиту. ( В якості одного з прикладів подивіться проект — minoca-pkg-test — тестування зібраних пакетів в операційній системі Minoca OS ). Про все про це можна докладно почитати в документації по модулю Outthentic, реалізує середу розробку Sparrow скриптів.
  • Сам Sparrow написаний на Perl і ставиться як CPAN модуль. У нього дуже невеликий overhead по залежностях, що робить досить простим в установці.
Це основні, але не всі характеристики екосистеми Sparrow, далі що б посаду не вийшов занадто теоретичным, наведу типові варіанти використання даного інструменту, це звичайно навіть не введення, але допоможе вловити суть того, як працює Sparrow.
Установка Sparrow
Ставимо як звичайний CPAN модуль. Так само нам знадобиться curl. І на цьому все.
$ cpanm --notest -q Sparrow
$ yum install curl

Забрати оновлення індексу SparrowHub репозитарію.
Те, що ви зазвичай робите виконуючи команду
apt-get update
в Sparrow буде виглядати так:
$ sparrow index update

Пошук скриптів
Тепер, оновивши індекс, можна пошукати скрипти, які Sparrow називаються плагінами. Наприклад, мені потрібно все, що відноситься до редактора nano:
$ sparrow plg search nano

Можна використовувати пошук за регулярними виразами:
$ sparrow plg search ssh.*

Установка плагінів
Ставимо плагін так:
$ sparrow plg install nano-setup

до Речі, якщо у скрипта є залежності, вони так само будуть встановлені. Sparrow підтримує оголошення та встановлення залежностей через cpanfile Perl і Gemfile для Ruby.
Як уже говорилося можна поставити плагін за необхідної версії:
$ sparrow plg install nano-setup --version 0.1.2

Запуск плагіна
Встановивши плагін, ми можемо його запустити. Ось, наприклад як я налаштовую nano-rc файл:
$ sparrow plg run nano-setup

В залежності від плагіна ми можемо передати йому на вхід різні параметри:
$ sparrow plg run nano-setup --param tabsize=2 --param speller='hunspell -x -c'

Або ж, якщо ми плануємо запускати плагін не один раз, та/або параметрів багато, ми можемо створити задачу, в якій визначаємо параметри запускається плагіна, наприклад ось так можна створити завдання з пошуку помилок виду 500 в балці nginx, використовуючи плагін logdog:
$ sparrow plg install logdog

# проект - це контейнер для завдань
$ sparrow create project nginx

# задача має ім'я і пов'язаний з нею плагін
$ sparrow add task nginx 500-errors logdog

# тепер ми налаштовуємо завдання:
$ sparrow task ini nginx/500-errors 
<logdog>
file /var/log/nginx/access.log
time_pattern \[(\d+\/\S+\/\d+):(\S+)
time_format %d/%b%Y %T
history 5 minutes
timezone Europe/Moscow
filter HTTP\/\S+?"\s+500\s
key_field (\S+)
density 3
check_mode report
</logdog>

Тепер ми можемо запустити задачу з заданими параметрами:
$ sparrow task run nginx/500-errors

Чи ж перевизначити деякі параметри в момент запуску:
$ sparrow task run nginx/500-errors --param logdog.density=10 --param logdog.history="'1 weeks'"

Якщо ми забули як використовувати плагін, завжди можна отримати його документацію:
$ sparrow plg man nano-setup

Або ж скористатися web інтерфейсом SparrowHub знайшовши потрібний плагін:
https://sparrowhub.org/info/nano-setup
Публікація завдань
Іноді зручно зберегти власну задачу, щоб скористатися їй пізніше на іншому сервері. Наведу простий приклад. У мене є список пакетів, якими я часто користуюся в ході своєї роботи. Можна сказати, що вони з великою ймовірністю знадобляться при роботі з новим сервером. Окей, скористаємося плагіном package-generic для установки пакетів під різні дистрибутиви.
Спочатку встановимо плагін та створимо завдання:
$ sparrow plg install package-generic
$ sparrow create project utils
$ sparrow add task utils my-packages package-generic
$ sparrow task ini utils/my-packages
list tree mc nano hunspell git 

Тепер збережемо завдання на сервері SparrowHub в моєму акаунті:
$ sparrow remote task upload utils/my-packages 'my useful packages'

Тепер, зайшовши на інший сервер, не страждаючи і не згадуючи список необхідних мені пакетів, просто встановлюю їх завдання:
$ ssh new-server
$ sparrow remote task run utils/my-packages

Отримати список моїх віддалених завдань ( remote tasks ) можна так:
$ sparrow remote task list

Можна так само зробити мою віддалену завдання публічної, що б потім будь-який інший міг скористатися їй:
$ sparrow remote task share utils/my-packages

Тепер користувачі можуть запустити мою завдання:
$ sparrow remote task run melezhik@utils/my-packages

Отримати список всіх доступних віддалених завдань на SparrowHub можна так:
$ sparrow remote task public list

Розробка і публікація власних плагінів — тема для окремого топіка, кому цікаво, може подивитися мій посада* на Хабре про це.
(*) публікація злегка застаріла щодо поточної версії Sparrow але може бути корисна як відправна точка, далі можна звернутися до документації середовищі розробки Sparrow плагінів — Outthentic або ж у випадку з написанням сценаріїв тестування додатків для web — системі swat .
На цьому мабуть все, хоча, звичайно ж, це був побіжний екскурс у систему, докладніше про всіляких фичах Sparrow можна почитати на сторінках документації.
Резюме
Отже, чим може бути корисний Sparrow? Спробую підсумувати:
  • швидке збереження власних скриптів з метою їх повторного використання вами або іншими на різних серверах.
  • корисний API дає можливості "з коробки" настроювати ваші скрипти з великим набором підтримуваних "форматів" конфігурацій — INI style, Config::General, YAML, JSON, командний рядок. Підтримка зміни окремих параметрів конфігурації ( зі збереженням значень за замовчуванням ).
  • вбудований DSL для верифікації виведення скриптів дозволяє легко і швидко писати різні скрипти для моніторингу, тестування та аудиту, з застосуванням моделі BlackBox тестування.
PS: Вітаю всіх з наступаючим! Успіхів!
Так і в кінці традиційно невеликий опитувальник зі схожою тематикою.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.