Comments 26
Sparrow — противоположная крайность, т.е. запутанная и очень сложная, в основе которой все та же идея — не дать разработчику сценария свернуть не туда (или они думают, что такое решение действительно упрощает решение задачи деплоя?), а это в итоге приводит к порождению множества костылей всех форм и размеров.
Приветствую!
Использовать YAML для разработки сценариев — это боль. Не учили видать разработчики Ansible историю, и продолжают настойчиво продвигать свою идею.
здесь согласен
Sparrow — противоположная крайность, т.е. запутанная и очень сложная, в основе которой все та же идея — не дать разработчику сценария свернуть не туда
вот здесь хочется конкретики. в чем сложность то? здесь imho все просто -
- пишем плагин на чем хотим, который решает нашу задачу.
- используем его в sparrowdo как черный ящик
- если не подходит это конкретно черный ящик — делаем другой и переходим в пункт 1
:)
как то так, по моему так просто. А вообще насколько просто кодировать конфигурации на sparrowdo/sparrow вы можете посмотреть тут — https://github.com/melezhik/sparrowdo/blob/master/core-dsl.md — это типа набор плагинов, которые вы уже можете использовать ( в обще-то их больше — полный список тут — https://sparrowhub.org/search )
да и по поводу:
не дать разработчику сценария свернуть не туда
в sparrowdo как раз свернуть можно где угодно и как угодна это же просто Perl6 (высокий уровень) — полная свобода — просто код в любом стиле + строительные блоки ( плагины ) — там тоже свободы хоть отбавляй (((:
по моему так по сравнению с кодирование на YAML в стиле ansible — свобода полная ((((:
свобода полная
Полная свобода написания каких угодно костылей — вот как я это понимаю. Польза от такого подхода весьма сомнительна.
давайте еще раз сформулирую.
вы изначально писали — " в основе которой все та же идея — не дать разработчику сценария свернуть не туда"
когда я вам в ответ написал, что sparrowdo/sparrow дает вам свободу, я вам всего лишь хотел донести, что данный инструмент в обще-то ничего не навязывает ( вы употребили выражение "не дать разработчику свернуть ни туда"), ну а уж как разработчик этой свободой распорядится, это в общем то него самого зависит ( опыта и знаний ) будет ли он писать костыли или же вменяемый код
но опять таки же я не вижу что sparrow/sparrowdo что-то там навязывал или форсировал кого-то к чему-то, правильнее сказать он предоставляет некий удобный набор инструментов для задач автоматизации, фреймоврк если хотите, извините, конечно же это термин в наше время сильно перегружен :))))…
в чем сложность то?
Если пишем на чем хотим, то откуда взялись ограничения (Perl, Ruby, Bash)? Если бы было бы просто, то наверно таких ограничений не было бы, согласитесь?
вопрос понятен. давайте так сформулирую.
1) концептуально sparrow плагин может писаться на любом языке, так как это просто набор скриптов или там один скрипт, не важно
2) но unified api — некий API который попросту упрощает разработку и добавляет некоторые очень полезные функции реализован пока для Perl5, Ruby, Bash
теперь, добавление ( реализация API) для нового языка не что называется rocket sience, вот, например в ближайшее время добавлю по запросу пользователя поддержку Python, вы же кстати тоже, судя по профилю на Python пишите?
Итак у нас будет Perl5,Bash,Ruby, Python, вам еще мало? :))))))))
PS А чисто концептуально, если вы зайдете на https://sparrowhub.org — вы там прочтете — "SparrowHub — reusable automation scripts." И это на самом деле весь "концепт" — скрипты автоматизации ( на разных языках )
вам еще мало?
на самом деле как раз наоборот, черезчур много. Ведь все это надо будет поддерживать — а это большая ответственность. У Ansible и без того уже давно наблюдаются проблемы с поддержкой плагинов. А кто будет поддерживать эти reusable automation scripts? Стоит ли разводить всю эту мешанину из различных способов, если потом нельзя будет точно сказать что будет работать, что уже deprecated, а что вообще уже не работает.
дак в этом и вся сложность проектирования любой системы, которую вы бы хотили передать в пользование другим… ну дак вот что я хочу здесь сказать — что называется by desing функции, реализованные в unified API — их немного и они очень простые, меняться там сильно нечему, sparrow более-менее уже стабилизировался, что с ним может происходить в будующем дак это добавление ( поддержка ) новых языков ( если будет потребность ) — самая спецификация, API сильно не изменится. Это первый уровень системы, скажем так базовый.
теперь если уже говорить o sparrowdo — высокуровневых сценариях на Perl6 — там все еще очень изменичиво и динамично, но это нормально, т.к. кирпичики (плагина) которыми оперирует sparrowdo с ним никак не связаны ( loosely coupled )
Такой дизайн дает нам большую гибкость с одной стороны (sparrowdo) и стабильность (sparrow)
А кто будет поддерживать эти reusable automation scripts?
да и еще момент хотел прояснить в духе моего предыдущего ответа. Sparrow — очень простая по своей сути система, она просто реализует некий набор полезных функций для языков разработки сценриев, плюс предоставляет систему дистрибуции данных скритов, сценариев. Тут как раз ключевой момент, что сами скрипты ( плагины ) — пишут пользователи, пишут на том языке, какой им нравится, и решая те задачи что они хотят, да и фактически кодирая скрипты в свободном стиле. Sparrow просто своего рода клей, плюс набор очень полезных базовых функций. Вот, собсвенно и все — систем простая и не сильно связанная внутри себя
вы упоминаете что скрипты используют unix way (обработка сигналов, коды возврата), неужели этого оказалось мало и понадобился отдельный unified API?
да мало. например я хочу передавать простым способом параметры в скрипты, причем не зависимо от языка и не писать каждый раз с нуля для этого код. попробуйте например в bash скрипт передать на вход что-то типа хэша — набор вложенных параметров и потом его там распарсить. там вот sparrow это предоставляет из коробки. или еще вот пример — вам очень часто будет хотется определять некие дефотные значения для параметров, если он не заданы. Давайте добавим сюда возможность передавать входные параметры в разных форматах, не только command line, я хочу например JSON и это нормально. И я не хочу каждый раз для это писать вспомогательный код. Да и вы делали разбор JSON на bash? :)) и так далее — как видете возникают "мелочи" — но которые сильно упрощают и ускоряют разработку кода. А еще я хочу написать свой набор скриптов, запаковать его и отправить на другой сервер, что бы там это все разаработало, без шаманства. Да и это тоже sparrow умеет. И присваиание версий своим скриптам и их установка по версиям и удаление и поиск и т.д. Думаете это все мелочи? Вся правда в том, что как раз не имея под рукой решения для подобного рода вещей люди и начинают изобретать велосипеды. Я кстати уже подробно этом писал, в том числе и на хабре
Если вы избавитесь от него, то система станет намного проще и гибче, без необходимости взваливать на себя груз поддержки 72+
да и тут груза то особого нет. он был бы если бы API который нужно было реализовывать был бы сложным, а, так как это всегда ( я уже говорил не раз ) — простой ( но жизненоважный ) набор функций, то его поддержка — если он и есть вобще не обремительна. Как говорится — там ломаться нечему :)))
ну да, еще забыл про тестирование. я иногда хочу не просто проверить что скрипт завешился с нулевым кодом, иногда этого недостаточно. Например по регескпам или еще каким-нибудь способом проверить, ЧТО вернул это скрипт. Для написания скриптов в стиле — мониторинг или аудит или blackbox тесты — это вобще супер удобная штука. Ну дак вот в sparrow скриптах, в независимости от языка написания плагина вы можете пользоваться встроенным DSL для этого. Да и еще sparrow иттегрируется (умеет зарускать) со swat — вид sparrow плагинов для тестирвания web сервисов
или вот еще кейс ( последний, хотя их может быть много ) — ближе к обычному админству. вот есть у вас замечательный скипт, но только с очень сложным набором входных параметров, и вы хотите запускать его в зависимости от задачи каждый разными парамтрами. и вот что бы все это не держать в голове и не полагаться на файл history вы просто биндите набор параметро на скрипт — в sparrow это называется задача. очень удобно. черех пару недель, когда вы уже забыли какие параметры нужны скрипту, вы просто запусаете эту задачу. очень удобно, проверено на опыте. да и еще задачи можно группировать, удобно когда их много.
просто, как видите порой все не укладываетя в один exit code :))))
Поясните пожалуйста.
Приветсвую! Я лично на yaml сценариев не пишу :)… вопрос для меня больше в том что yaml чисто декларативный язык, создавать на нем императивные конструкции типа условных операторов или циклов очень неудобно, если и возможно. А в сценариях по управлению конфигурациями данные конструкции очень упрощают жизнь. Вот как то так.
They implemented in terms of sparrowdo tasks ( relying on sparrowdo API ) rather then with sparrow tasks.
особо ничего не дает. Что за sparrowdo API?
Но в sparrowDO есть еще и модули, судя по документации.
Да, модули — это можно сказать третья сущность в sparrowdo ( наряду с core-dsl и task-run ). На самом деле вот что такое sparrowdo модули
- во-первых это обычные Perl6 модули ( примеры на modules.perl6.org — https://modules.perl6.org/#q=sparrow )
- во вторых модуль должен реализовать функцию tasks — которая как правило просто вызывает одну или несколько функций task-run — все это сильно похоже как реализованы функции core-dsl
- в третьих вы можете инклюдить готовый модуль в своем sparrowdo сценарии и запускать его как
module_run 'module-name' %parametersПараметры %parameters просто передадутся в реализованную в модуле функцию tasks, которая разберет их и сделает одни или несколько вызовов функций task-run. На самом деле ровно так же реализованы функции core-dsl. Можно смотреть на модули как third-party дополнения к sparrowdo которые по определенным причинам не включены в core-dsl, в принципе, если модуль достаточно полезный и часто используемый — он может быть хорошим кандидатом на миграцию в core-dsl, как-то так.
Здравствуйте. Спасибо за вопросы. Отвечу по порядку.
Несколько раз вы говорили про CoreDSL и PluginDSL для него. Насколько я понял, разница лишь в самом синтаксисе в sparrowfile. Т.е. в первом случае создается json и кидается на целевой хост, который исполняется клиентом, во втором — параметры передаются напрямую
В обоих случаях ( и core-dsl API и plugin API ) — это просто функции, написанные на Perl6 ( в случае с Plugin API — это только одна функция — task-run(...)), которые в конечно счете генерируют на выходе некую мета информацию — taskbox ( она сериализуется в JSON и определяет какие плагины, с какими параметрами и в каком порядке запускать ) — которая в виде JSON файла копируется на целевой хост, далее на этом же целевом хосте запускается sparrow клиент, который на вход получает файл с этой самой мета информацией ( task box ) и по данным в ней устанавливает, настраивает ( передает параметры ) и запускает sparrow плагины по порядку определенному в файле taskbox.
На самом деле, что бы было понятнее — если посмотреть в сам taskbox файл — это просто массив, задающий задачи, например так:
[
{
"plugin" : "user",
"task" : "create user zookeeper",
"data" : { "name" : "zookeeper", "action" : "create" }
},
{
"plugin" : "directory",
"task" : "create directory /var/data/zoo",
"data" : { "path" : "/var/data/zoo", "action" : "create" }
},
{
"plugin" : "file",
"task" : "create file /var/data/zoo/birds.txt",
"data" : {
"owner" : "zookeeper",
"action" : "create",
"target" : "/var/data/zoo/birds.txt"
}
}
]
Кстати обо всем можно почитать на блог сайте sparrowdo, например в этой статье — sparrow plugins evolution
Насколько я понял, разница лишь в самом синтаксисе в sparrowfile
и в синтаксисе тоже. Plugin dsl — это вызов плагина через функцию task-run, используя его API как есть ( API плагина всегда доступен ввиде его документации в sparrowhub ).
Core-dsl — это набор определенных заранее в Sparrowdo функций ( поэтому и core ) — оберток вокруг вызовов одного или нескольких плагинов — нетрудно догадаться или же если посмотреть код, что любая функция core-dsl на самом деле не что инное как один ( сейчас пока что все функции core dsl мэпятся одна функция — одни плагин, но вообще говоря это может быть подругому ) или несколько вызовов функции task-run: task-run(params), task-run(params), и т.д. По сути core-dsl функции — это сконструированные более сложные черные ящики из более мелких черных ящиков — плагинов (task-run). Таким образом, core-dsl — абстракции более высокого уровня, собранные из "примитивов" — task-run. Сейчас они во основном добавляют syntax sugar, что бы можно было писать короткие вызовы типа file вместо task-run 'file'… и валидация входных параметров.
They implemented in terms of sparrowdo tasks ( relying on sparrowdo API ) rather then with sparrow tasks.
Имеется ввиду как раз то, что функции core-dsl оперируют/реализованы через вызовы task-run ( sparrowdo tasks ) — эти абстракции не нужно путать с сильно похожими на них абстракция в предметной области самого sparrow клиента — который также выполняет задачи (tasks) — ( sparrow task — абстракция для именованной пары — плагин + параметры ) — которые изначально описываются в sparrowdo сценариях задачами ( функции task-run — абстракция для вызова sparrow task через sparrowdo )
Насколько я понял, разница лишь в самом синтаксисе в sparrowfile.
Я имел ввиду, что для пользователя (обывателя). Я понимаю, что core-dsl это обертка.
Но все-таки, насчет модулей не совсем понятно. Это набор тасков из названия. Я правильно понимаю, что можно в них использовать циклы и ветвления, в отличие от core|plugin-dsl в sparrowfile?
для обычно пользователя:
- plugins API — это функция task-run для вызова конкретного sparrow плагина с парамтерами
- core-dsl — набор готовых функций — пользователь не знает КАК они устроены, он просто их запускает, но де-факто, функции core-dsl устроены так, что они запускают один или несколько sparrow плагинов с параметрами
- модули — это с одной стороны готовые для использования расширения sparrowdo — поставляемые в виде обычных Perl6 модулей ( вот их список ) — по своей сути очень похожие на то, что делают функции core-dsl — вам опять таки же не нужно знать как они устроены внутри, вы просто их используете, исходя из документации,
с другой стороны модули — это API для разработчика расширений, задокументированное тут и вот здесь вы просто пишите произвольный Perl6 код, как хотите, с ветвлениями, циклами и чем угодно. Основное требование с точки API разработки — вы должны реализовать внутри модуля функциюtasks, принимающую на вход хэш параметры, что она будет делать это вобщем=то ваше дело, но де факто — ( посмотрите примеры и документацию ) она скорее всего сделает один или несколько вызовов функций task-run или core-dsl функций — что бы сделать что-то полезное ((:
ок, что бы было еще проще (:, извиняюсь если сложно объясняю:
core-dsl — функции, plugin API — функция task-run — просто функции, которые пользователи вызывают в sparrowdo сценариях, вам не надо их писать, если кто и добавляет новые функции в core-dsl — это разработчик sparrowdo, то бишь я.
sparrowdo modules — вы можете использовать готовые в своих sparrowdo сценариях или можете написать свои и так же их использовать. Создание своего sparrowdo модуля подразумевает создание обычного Perl6 модуля в неймспейсе Sparrowdo:: и реализации в нем функции tasks принимающей на вход хэш параметры. Вот как то так. Конкретно по написание модулей на Perl6 — это уже в Perl6 комьюнити — у них отличный irc канад — они всегда готовы помочь, ну и конечно сайт https://perl6.org/
Sparrow плагины и Ansible модули — сравнительный анализ