Comments 10
Приветствую!
Отвечая на ваш вопрос. Дело в том что у обычных кастомных скриптов написанных "на коленке" есть свои ограничения с точики зрения их дистрибуции, приведу некоторые:
как правило отсутствие унифицированного способа доставки скрипта на целевую машину. В лучшем случае это будет чекаут из системы контроля версий, в худшем копирование руками скрипта на сервер.
как правило отсутствие версионирования скриптов. что если мы разработали новую версию скрипта и что-то пошло не так и мы хотим быстро откаттится на старую? и так далее ...
как правило отсутствие стандартного интерфейса дающего нам понимание какие входные параметры принимает скрипт и какой их смысл, зачастую скрипт пишется для себя, и вся документация ( если таковая присутствует ) и описание входных параметров, хранится прямо в исходном коде
- как правило отсутствие управления зависимостями — т.е. если скрипт использует какие-то библиотеки и тулзы, как их автоматически доставить при установке скрипта?
Ок, sparrow частично реашает эти проблемы, частично потом что некоторые вопросы с сожелению невозможно 100% автоматизировать.
унифицированный способо доставки — он есть, везде, на всех серверах один и тот же —
$ sparrow plg install
стандартный интерфейс — решается частично, конечно же sparrow не сделает автоматическое документирование скрипта, но из коробки есть такая фича как конфигурация плагина, ( то что в статье назавается конфигурацей чекпоинта ) — собственно автор плагина всегда может задать, описать входные параметры ввиде параметров INI файла, который пользователь должен определить, что бы все работало, sparrow автоматически передаст проиниицализированный INI файл ввиде хэш структуры внутрть плагина, эта штука удобная для разработчика. конечно все это может не помочь если разработчик не отразит в документации (README.md) описание конфигурации. Документация кстати также отражается на странице плагина на SparrowHub.
- ну и насчет управления зависимостями — решается в том смысле, что sparrow плагин по сути что-то очень схожее со CPAN модулем, и написан фактически на миксе Perl кода и DSL, и значит там могут использоваться другие CPAN модули, у правления зависимостями для которых происходит через carton+cpanfile. Возможно в будующем я сделаю поддержку не только Perl но пока так.
Смотрите мой предыдущий обобщенный ответ. Версионировнность не в плане системы контроля версий для хранения исходного кода, а в плане версионированности пакетов устанавливаемого по, это разные все же вещи. Опять таки же использования configuration management tool + система контроля версий вполне себе вариант, но все же предпочтительнее использовать именного целевые решения вида пакетных менеджеров, и да для массированных установок можно сверху ещё прикрутить configuration management tool какой нибудь.
Да и по поводу документирования скрипта, с вами абсолютно согласен, никакой системой нельзя заставить документировать свои программы :-), другой вопрос, что можно предоставить дополнительные возможности с целью упрощения процесса документирования или фиксирования паблик интерфейса, как хотите назовите. В sparrow такой возможностью является встроенный механизм конфигурирование плагина, т.е. автору нового плагина нет необходимости создавать свой механизм инициализации, он может воспользоваться существующим, по другому можно ещё сказать так, если автор не воспользовался возможностью и не определили входные параметры скрипта ввиде переменных конфига, то он написал недобросовестный код, который может работать неправильно.
Другой вопрос, когда у разработчика нет подобной автоматической возможности определить настройки, и ему приходится создавть такой механизм с нуля самому, знаю по себе, неминуемо появляется желания "засунуть" эти настройки вглубь скрипта или же ожидать передачи параметров через переменное окружения, о которых нигде, кроме как в коде скрипта не упомянуто: -)
И немного по Вашему комментарию:
Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.
что касается:
унифицированный способо доставки — он есть, везде, на всех серверах один и тот же — $ sparrow plg install
есть wget / fetch а с ними и репы с готовыми скриптами. В случае с массовыми чеками, инсталами, etc. — chef / ansible. В случае с последними — проблема стандартного интерфеса, версионирование, управление зависимостями — уже не проблемы.
P.S. и руками время от времени равно нужно что-то писать — забыть всё можно :)
Вопрос такой — могу ли я использовать sparrow с приватным набором плагинов?
Да, в sparrow как раз есть тип плагинов, называемыми приватными, в двух словах вы можете держать исходный код плагина в remote гит репозитария и ставить плагин прямо оттуда, репозитарий соответсвенно может быть любым, публичным или закрытым, главное что это был гит репозитарий. Как раз было придумано для того, чтобы люди могли расшаривать например в пределах одной фирмы плагины, при этом не размещая их в публичный доступ. Подробнее читайте об этом в документации. На другие вопросы отвечу отдельно :)
Как правило скрипты, которые собираются «на коленке» и используются не один раз и и не на одном сервере — обрастают проверками и условиями запуска для универсального использования.
Простите, не совсем понял что вы здесь хотите сказать, универсальность использования это что? значит ли универсальность использования гарантирует и переносимость — ( простую ) возможность установить и запустить скрипт на потенциально любом другом дистрибутиве линукса с минимальными усилиями по доставке и конфигурации?
Есть скрипты написанные под семейства, есть более унифицированные linux or bsd, есть универсальные. Универсальные — именно те, запуск которых гарантирован на всех обслуживаемых серверах. Что касается переносимости — все доставляется по средствам скачивания с единого сервера хранения таких скриптов ( к примеру s.example.com ) — все имеют стандартизированные названия, что без особого труда позволяет получить нужный скрипт. Да этот вариант подвержен тому, что по сути версионирование отсутсвует.
Попытаюсь ответить на все предыдущие комментарии вкупе. Во многих системах есть понятие пакетных менеджеров, например, apt в дебиане, yum в центос, cpan в perl, ruby gems в ruby, ну и так далее, примеров можно приводить много, все они решают более и менее одни те же задачи, а именно — управляют пакетами программного обеспечения, собственно, sparrow так же пакетный менеджер, со своей конечно спецификой и своей целевой аудиторией. То что вы описали в вашем случае, то же, наверное, попытка написать свой пакетный менеджер, хотя конечно версиоонирование отсутствующее в нем, важная вещь, как вы сами думаю пониамаете. Я пытаюсь презентовать sparrowhub как решение доступное для многих, не только для меня или моей компании. Т.е сделать, скажем так, обобщенный, не привязанный к одной конкретно системе репозитарий, в который люди из комьюнити смогут выкладывать свои пакеты, но следуя, конечно, определенному воркфлоу, т.е если вас устраивает ваше решение, то и отлично, но возможно через какое то время вы найдёте на sparrowhub плагины полезные и вам. :-) вот как то так.
Да, и по поводу средств управления конфигурациями, таких как шеф или ansible, они как раз чаще всего взаимодействуют со специализированными пакетными менеджерами, хотя опять так же простой вариант с wget и архивным сервером тоже возможен, но скорее всего как раз когда нет API соответствуещего пакетного менеджера, который абстрагирует подобную логику доставки софта на сервер .
SparrowHub — репозиторий готовых утилит для системного администрирования