age, ok := person["age"].(int) if !ok { log.Fatal("could not assert value to int") return } person["age"] = age + 1
Выглядит очень странно и корявенько, это то почему мне не нравится go ( хотя в целом язык - норм ) , платой за статическую типизацию является то что когда ты хочешь гибкости ты должен делать странные workarounds ввиде пустых интерфейсов и обратному приведению типов ( из типа пустой интерфейс в нужный тебе тип ), а любом динамическом языке - это немыслимо
Ок, а я правильно понимаю, что сгенеренные yam конфиги для monoexecl "зашиваются" через докерфайлы в докер образы? Или они позже уже деплоятся на зарущенных контейнерах ?
Спасибо, интересная статья. А вот можно прояснить следующий момент:
Далее, мы хотим передать это администраторам для дальнейшего использования. Километровую строку запуска отправлять как-то не комильфо.
Не очень ясна роль администратора в вашем воркфлоу, я так понимаю, что все происходит автоматически, без вмешательства человека, сервисы, если падают, поднимаются сами. Или все равно кто-то должен настаивать супервизор в запускаемых контейнерах… можете чуть подробнее этот момент описать?
Насчёт быстрее — это, на мой взгляд, вопрос спорный, но главное даже не это.
Здесь смысл больше в том, что подход, описаный в статье избавляет вас от необходимости для каждой отдельной конфигурации писать свой скрипт-обёртку, вы просто создаёте очередную задачу, в которой описываете все параметры, а плагин ( фактически вызываемый скрипт ) у вас всегда остаётся один и тот же. Фактически это такой паттерн, когда вы отделяете входные данные от самого скрипта. В случае когда вы не используете обертку, а просто вызываете скрипт с набором параметров, это тоже так, но тогда вы можете упереться в те, проблемы, о которых я сказал в начале статьи — когда входных параметров очень много и они сложные.
И потом достаточно удобно когда входные параметры описываются в виде структуировнных данных типа json или yaml это может быть удобно когда вы хотите вызвать скрипт с какими-то параметрами из обычной программы.
Давайте так, я дискуссию продолжать смысла не вижу, мне кажется, я уже достаточно обосновал свою позицию. Предлагаю обсуждение закрыть, не потому что мне нечего сказать на все ваши ремарки, а просто я чувствую ( может конечно субъективно ) что мы попросту впустую тратим время и разговор уходит в деструктивное русло. Вы, кстати начали с того что вы шефе не спец — ну дак возьмите и попробуйте его поиспользовать, потом soarrowdo с ним или без него и сравните, и тогда уже из вашего практического опыта можем поговорить… а сейчас что-то вам доказывать я если честно говоря устал ))) тут как бы дело добровольное. — нравится инструмент — используйте, не нравится — не используйте, никто как бы не заставляет ))) просто иногда что бы реально понять нужно оно вам или нет — необходимо хотя несколько практических примеров реализовать… по крайней мере я так всегда делаю… удачи! )))
Давайте по порядку отвечу на ваши последние комментарии
писать тесты на одном языке есть смысл если вы пишите юнит тесты, когда же речь идёт об интеграционном тестировании, что примерно наш случай, язык написания интеграционных тестов и приведения окружения в требуемое состояние совершенно не обязан быть тем же что и язык на котором написано трестируемое приложение ( в нашем случае кукбуки шеф ). В этом случае, как я уже много раз говорил, выбираем язык, исходя из удобства
вся ваша идея с использованием кукбуков для тестирования или кукбуков обёрток мне была ясна с самого начала, я сам так когда-то делал, основной минус этого подхода — сложность поддержания связанная с тем что шеф не предназначен для таких вещей и прямое подтверждение тому, что просто потому что вам нужно что-то поверить в вашей системе ( шеф сервер ) — появляется куча сущностей, которые являются для неё чужеродными. Еще раз — chef — инструмент управления конфигурациями, не надо запихивать в него ( читайте буквально — создавать кукбуки для тестирования ) сценарии тестирования — они должны быть в другом месте. Читайте внимательно мои предыдущие комментарии, я там объяснил почему.
в случае со Sparrowdo у вас код для тестирования как раз лежит рядом с тестируемых кодом, и ещё ближе чем в варианте когда у вас есть некие кукбуки обертки которыми вы тестируете ваши другие кукбуки, как я вам уже сказал вы просто кладёте Sparrowdo сценарии рядом с кодом кукбука, куда уж ближе ...
основной выйгрыш, который вы получаете со Sparrowdo — это отделение трестируемого от самих тестов ( у вас нет никаких тестовых кукбуков, сосушесвующиз совместно с трестируемыми кукбуками. ) и более короткий цикл запуска сценариев, так как у вас нет необходимости загружать из как кукбука в шеф сервер и вы просто запускаете их напряму по ssh, ваши варианты с копировннием шеф рецептов по scp и использованием шеф соло — ещё одно докозательство того, что в некоторых случаях шеф неудобен для быстрой разработки и отладки
так же Sparrowdo отвязывает разработчика пишущего интеграционный или тестируемый код от необходимости даде знать chef dsl а использовать напрямую нативные команды того дистрибутива OC для которого идёт тестирование. Что делает код сценария лаконичней и эффективнее. Шеф хорош когда вы хотите абстрагироваться от "деталей реализации" целевого сервера, но но когда вам нужно чтото подебажить на более низком уровне все приимущества шеф исчезают и он становится неуклюжим. Примеры? Попробуй написать абстрактный код на bash, и запустил его через шеф — у вас возникнет несколько неприятных моментов с этим — но это тема для отдельного поста, может быть когда нибудь об этом напишу. Только не говорите мне про ресурсы execute и bash...
Хотелось бы все же знать о величине этих накладных расходов
Вы почему-то все продолжаетесь цепляться за уже проговоренную нами тему ))) целью этой статьи было показать как разные виды задач относящиеся к разработке и отладке и тестированию рецептов шеф удобно решать с помощью разных инструментов, а не выбор инструмента которорй будет работать быстрее. И таки да, то что soarrowdo в своём цикле работы не требует промежуточного сервера я считаю плюсом по отношению к шефу запускаемым в режиме клиент-сервер. Но попытайтесь услышать меня ещё раз — это НЕ ТО почему я использую шеф в связке со Sparrowdo ( ну или наоборот, как вам угодно ) причины скорее идеологические ( разные виды задач и исходя из этого изоляция кода на уровне разных инструментов ) чем технические. Просто к слову пришлось я и сказал что вот дескать в soarrowdo такая архитектура запуска а у шеф такая-то, но в данном случае их не это главное, а главное то, что вы решаете разные задачи разными ( более подходящими ) инструментами и это хорошо. Надеюсь это поможет.
Да и кстати написание wrapper кукбука это как раз imho костыль, который можно избежать с помощью Sparrowdo.
Во-первых вы создаете некоторую сущность которая вам нужна только для тестирования и заметьте загружаете ее в шеф сервер, как только вы закончите тестирование вам как придётся этот кукбук оттуда удалить, потому что он перестанет быть нужным. И заметьте у вас всегда будет как минимум один а то и несколько таких вспомогательных кукбуков или рецептов на каждый из тестируемых. Фактически вы плодите тем самым в шефе новые сущности, за которыми потом ещё надо следить и о которых очень легко потом забыть. В случае со sparrowdo — это просто один или несколько файлов положенных в SCM вместе с кодом кукбука и все. Шеф ничего о них не знает и вы никак не "загрязняете" его пространство кодом вспомогательных рецептов. Это кстати примерно то как работает тот же test- kitchen/serverspec например.
Во-вторых сам шеф плохо подходит для тестирования инфраструктуры, все более или менее популярные решения для этого как раз вынесены за рамки шеф рецептов ( кроме пожалуй chef minitest handler, который как написано на странице проекта — in low maintainance mode ) — можете сами посмотреть если интресно — serverspec, inspec, goss и так далее — ссылки я приводил в статье )
Смотрите вы тут много чего написали, но по-моему путаете понятия. Тестовое и продакшен окружения не имеют никакого отношения к тому что я писал. Ещё раз, хотя мне кажется я уже и так достаточно ясно до этого выразился. Иногда хочется протестировать поведение шеф рецептов в некоторых условиях. Эти условия можно назвать граничными в том смысле что они с вероятностью могут привести к нештатному поведению шеф рецептов. Или ещё более крайний случай — вы поймали баг и вам необходимо убедится что баг пофикшен после изменения кода кукбука, но опять таки же баг воспроизводился при определённых условиях. Цель ваших шеф рецептов — прведение ситсемы в правильное состояние, если вы будете вносить в эти же рецепты сценарии по воспоизведениею каких-то нецелевых конфигураций вы тем самым только все усложните. Смешивание кода для тестирования ( а воспроизведение системы в состояние когда баг проявляется — так же является тестированием ) с кодом трестируемого приложения — очевидный антипаттерн в разработке, причём не важно в какой.
Как раз таки разделение сценариев на Sparrowdo / chef позволяет разделять логически разный код на уровне разных инструментов.
Примеров я вам привёл уже достаточно, я если честно не вижу смысл ещё в какой-то более подробной детализации.
Мы можем даже убрать из статьи строчку про "который в отличие от chef является push based инструментом ..." и от этого ее суть не изменится. Предалагаю вам это сделать мысленно )) и перечитать…
Смотрите, в случае когда вы запускаете шеф как клиент серверное приложение что де факто основной способ использования шеф возникают те самые накладные расходы с тем что вы все время вынуждены "прокидывать" изменения в коде через шеф сервер ввиде кукбуков. Если сравнивать шеф сервер по этому параметру с тем же ansible или Sparrowdo, то последние imho выигрывают по причине отсутствия лишнего звена в цепочки ввиде шеф сервера.
Но давайте я скажу ещё раз — акцент этой статьи не на этом. Возможно я не очень аккуратно применил термин push based в данной статье, что увело нас в сторону.
Шеф даже в случае с использованием его в режиме клиент сервер тоже хорош, но есть вещи которые удобнее, лучше и правильнее делать не через шеф.
Примеры? Мне кажется я как раз их и привёл достаточно. Ещё раз — тестирование системы после отработавшего шеф клиента, установка или настройка чего-либо что нужно по каким-то причинам прямо здесь и сейчас, но совершенно не требуется для успешной работы самих шеф кукбуков и самое главное не является целевой конфигурацией. А так же дополнительная настройка системы с целью воспроизведения граничных условий или багов. Как отработает мой шеф рецепт — если в системе уже будет установлен пакет такой-то версии или если не будет существовать такой-то пользователь? И так далее и тому подобное. Так вот — приведение трестируемого окружения к требуемому состоянию лучше из шефа выносить, так же как и сами тесты.
.
Пример с остановкой сервиса nginx перед запуском шеф кукбуков очень показателен, вам необходим выполнить остановку сервиса только ради тестирования кукбука? нет совершенно никакого смысла делать это через какой-то вспомогательный кукбуков или что ещё хуже вносить это в тестируемый кукбук. Гораздо проще это сделать "прямо и по месту" через Sparrowdo как я показал это в статье. Ведь по сути данная операция ( остановка сервиса ) вам нужна только на момент тестирования кукбука и все. Нет смысла вносить ее в шеф.
Здесь как раз хочется показать что использование только одного инструмента не всегда является best practice
Мне кажется мы начинаем уходить немного в сторону от того что я хотел сказать в статье, здесь акцент не на времени исполнения ( хотя опять таки же накладные расходы в случае с использованием chef как клиент сервер есть ) или там на сравнении pull с push архитекурой. А на том, что можно использовать шеф вместе со Sparrowdo, при отладке сценариев управления конфигурациями.
Sparrowdo выступает как обертка для запуска шеф клиента, что лично для меня весьма удобно, так позволяет легко и просто настраивать параметры запускаемых рецептов, так же Sparrowdo выступает ввиде дополнительного инструмента по тестированию или установке необязательных зависимостей в систему — всего того что бы вы на хотели запихивать в шеф кукбуки.
да, все верно, chef клиент можно запускать в таком режиме ( здесь правда уместнее говорить о команде knife ssh — но разница небольшая относительно вашего примера ).
возможно я не очень аккуратно выразился. вот что хотелось сказать — иногда мне хочется описать какую-либо конфигурацию ввиде сценария и тут же запустить все это на целевом сервере, в случае с шефом у вас всегда есть шаг связанный тем, что сценарий должен быть добавлен в виде кукбука на шеф сервер ( если это конечно не chef-solo но я здесь его не рассматриваю ) и только заетм шеф клиент ( когда вы его запускаете по ssh) запрашивает данный кукбук с шеф сервера (pull) — это определяет определенные накладные расходы на цикл разработки и тестирования кукбуков ( грубо говоря вы все время вынуждены делать knife upload каждый раз внося изменения в кукбук, плюс добавьте время когда шеф клиент скачает новую версию кукбука при запуске и т.д. ), в случае же с ansible или sparrowdo у вас нет этого лишнего шага, вы просто копируете ( в том или ином виде ) сценарий по ssh на целевой сервер и сразу же его выполняете…
В общем случае это не такая большая разница, но я считаю все же возможность быстро прогнать изменения очень важна при разработке. Так вот идея в том, что там где это уместно — писать сценарии на sparrowdo — это быстрее и проще, при этом это не отменяет основной цели — тестирования и разработки шеф кукбуков ( поэтому я и сказал в самом начале что использую эти два инструмента в связке ).
ок, что бы было еще проще (:, извиняюсь если сложно объясняю:
core-dsl — функции, plugin API — функция task-run — просто функции, которые пользователи вызывают в sparrowdo сценариях, вам не надо их писать, если кто и добавляет новые функции в core-dsl — это разработчик sparrowdo, то бишь я.
sparrowdo modules — вы можете использовать готовые в своих sparrowdo сценариях или можете написать свои и так же их использовать. Создание своего sparrowdo модуля подразумевает создание обычного Perl6 модуля в неймспейсе Sparrowdo:: и реализации в нем функции tasks принимающей на вход хэш параметры. Вот как то так. Конкретно по написание модулей на Perl6 — это уже в Perl6 комьюнити — у них отличный irc канад — они всегда готовы помочь, ну и конечно сайт https://perl6.org/
plugins API — это функция task-run для вызова конкретного sparrow плагина с парамтерами
core-dsl — набор готовых функций — пользователь не знает КАК они устроены, он просто их запускает, но де-факто, функции core-dsl устроены так, что они запускают один или несколько sparrow плагинов с параметрами
модули — это с одной стороны готовые для использования расширения sparrowdo — поставляемые в виде обычных Perl6 модулей ( вот их список ) — по своей сути очень похожие на то, что делают функции core-dsl — вам опять таки же не нужно знать как они устроены внутри, вы просто их используете, исходя из документации,
с другой стороны модули — это API для разработчика расширений, задокументированное тут и вот здесь вы просто пишите произвольный Perl6 код, как хотите, с ветвлениями, циклами и чем угодно. Основное требование с точки API разработки — вы должны реализовать внутри модуля функцию tasks, принимающую на вход хэш параметры, что она будет делать это вобщем=то ваше дело, но де факто — ( посмотрите примеры и документацию ) она скорее всего сделает один или несколько вызовов функций task-run или core-dsl функций — что бы сделать что-то полезное ((:
во вторых модуль должен реализовать функцию tasks — которая как правило просто вызывает одну или несколько функций task-run — все это сильно похоже как реализованы функции core-dsl
в третьих вы можете инклюдить готовый модуль в своем sparrowdo сценарии и запускать его как
module_run 'module-name' %parameters
Параметры %parameters просто передадутся в реализованную в модуле функцию tasks, которая разберет их и сделает одни или несколько вызовов функций task-run. На самом деле ровно так же реализованы функции core-dsl. Можно смотреть на модули как third-party дополнения к sparrowdo которые по определенным причинам не включены в core-dsl, в принципе, если модуль достаточно полезный и часто используемый — он может быть хорошим кандидатом на миграцию в core-dsl, как-то так.
Код:
age, ok := person["age"].(int)
if !ok {
log.Fatal("could not assert value to int")
return
}
person["age"] = age + 1
Выглядит очень странно и корявенько, это то почему мне не нравится go ( хотя в целом язык - норм ) , платой за статическую типизацию является то что когда ты хочешь гибкости ты должен делать странные workarounds ввиде пустых интерфейсов и обратному приведению типов ( из типа пустой интерфейс в нужный тебе тип ), а любом динамическом языке - это немыслимо
Добрый день. Вы имеет ввиду https://github.com/explore? Можете чуть подробнее раскрыть, что бы вы хотели здесь?
Ок, а я правильно понимаю, что сгенеренные yam конфиги для monoexecl "зашиваются" через докерфайлы в докер образы? Или они позже уже деплоятся на зарущенных контейнерах ?
Спасибо, интересная статья. А вот можно прояснить следующий момент:
Не очень ясна роль администратора в вашем воркфлоу, я так понимаю, что все происходит автоматически, без вмешательства человека, сервисы, если падают, поднимаются сами. Или все равно кто-то должен настаивать супервизор в запускаемых контейнерах… можете чуть подробнее этот момент описать?
Извиняюсь, ответил отдельным тредом…
Насчёт быстрее — это, на мой взгляд, вопрос спорный, но главное даже не это.
Здесь смысл больше в том, что подход, описаный в статье избавляет вас от необходимости для каждой отдельной конфигурации писать свой скрипт-обёртку, вы просто создаёте очередную задачу, в которой описываете все параметры, а плагин ( фактически вызываемый скрипт ) у вас всегда остаётся один и тот же. Фактически это такой паттерн, когда вы отделяете входные данные от самого скрипта. В случае когда вы не используете обертку, а просто вызываете скрипт с набором параметров, это тоже так, но тогда вы можете упереться в те, проблемы, о которых я сказал в начале статьи — когда входных параметров очень много и они сложные.
И потом достаточно удобно когда входные параметры описываются в виде структуировнных данных типа json или yaml это может быть удобно когда вы хотите вызвать скрипт с какими-то параметрами из обычной программы.
Давайте так, я дискуссию продолжать смысла не вижу, мне кажется, я уже достаточно обосновал свою позицию. Предлагаю обсуждение закрыть, не потому что мне нечего сказать на все ваши ремарки, а просто я чувствую ( может конечно субъективно ) что мы попросту впустую тратим время и разговор уходит в деструктивное русло. Вы, кстати начали с того что вы шефе не спец — ну дак возьмите и попробуйте его поиспользовать, потом soarrowdo с ним или без него и сравните, и тогда уже из вашего практического опыта можем поговорить… а сейчас что-то вам доказывать я если честно говоря устал ))) тут как бы дело добровольное. — нравится инструмент — используйте, не нравится — не используйте, никто как бы не заставляет ))) просто иногда что бы реально понять нужно оно вам или нет — необходимо хотя несколько практических примеров реализовать… по крайней мере я так всегда делаю… удачи! )))
Давайте по порядку отвечу на ваши последние комментарии
Я извиняюсь, добавил этот хаб по ошибке, убрал.
Вы почему-то все продолжаетесь цепляться за уже проговоренную нами тему ))) целью этой статьи было показать как разные виды задач относящиеся к разработке и отладке и тестированию рецептов шеф удобно решать с помощью разных инструментов, а не выбор инструмента которорй будет работать быстрее. И таки да, то что soarrowdo в своём цикле работы не требует промежуточного сервера я считаю плюсом по отношению к шефу запускаемым в режиме клиент-сервер. Но попытайтесь услышать меня ещё раз — это НЕ ТО почему я использую шеф в связке со Sparrowdo ( ну или наоборот, как вам угодно ) причины скорее идеологические ( разные виды задач и исходя из этого изоляция кода на уровне разных инструментов ) чем технические. Просто к слову пришлось я и сказал что вот дескать в soarrowdo такая архитектура запуска а у шеф такая-то, но в данном случае их не это главное, а главное то, что вы решаете разные задачи разными ( более подходящими ) инструментами и это хорошо. Надеюсь это поможет.
Да и кстати написание wrapper кукбука это как раз imho костыль, который можно избежать с помощью Sparrowdo.
Во-первых вы создаете некоторую сущность которая вам нужна только для тестирования и заметьте загружаете ее в шеф сервер, как только вы закончите тестирование вам как придётся этот кукбук оттуда удалить, потому что он перестанет быть нужным. И заметьте у вас всегда будет как минимум один а то и несколько таких вспомогательных кукбуков или рецептов на каждый из тестируемых. Фактически вы плодите тем самым в шефе новые сущности, за которыми потом ещё надо следить и о которых очень легко потом забыть. В случае со sparrowdo — это просто один или несколько файлов положенных в SCM вместе с кодом кукбука и все. Шеф ничего о них не знает и вы никак не "загрязняете" его пространство кодом вспомогательных рецептов. Это кстати примерно то как работает тот же test- kitchen/serverspec например.
Во-вторых сам шеф плохо подходит для тестирования инфраструктуры, все более или менее популярные решения для этого как раз вынесены за рамки шеф рецептов ( кроме пожалуй chef minitest handler, который как написано на странице проекта — in low maintainance mode ) — можете сами посмотреть если интресно — serverspec, inspec, goss и так далее — ссылки я приводил в статье )
Смотрите вы тут много чего написали, но по-моему путаете понятия. Тестовое и продакшен окружения не имеют никакого отношения к тому что я писал. Ещё раз, хотя мне кажется я уже и так достаточно ясно до этого выразился. Иногда хочется протестировать поведение шеф рецептов в некоторых условиях. Эти условия можно назвать граничными в том смысле что они с вероятностью могут привести к нештатному поведению шеф рецептов. Или ещё более крайний случай — вы поймали баг и вам необходимо убедится что баг пофикшен после изменения кода кукбука, но опять таки же баг воспроизводился при определённых условиях. Цель ваших шеф рецептов — прведение ситсемы в правильное состояние, если вы будете вносить в эти же рецепты сценарии по воспоизведениею каких-то нецелевых конфигураций вы тем самым только все усложните. Смешивание кода для тестирования ( а воспроизведение системы в состояние когда баг проявляется — так же является тестированием ) с кодом трестируемого приложения — очевидный антипаттерн в разработке, причём не важно в какой.
Как раз таки разделение сценариев на Sparrowdo / chef позволяет разделять логически разный код на уровне разных инструментов.
Примеров я вам привёл уже достаточно, я если честно не вижу смысл ещё в какой-то более подробной детализации.
Мы можем даже убрать из статьи строчку про "который в отличие от chef является push based инструментом ..." и от этого ее суть не изменится. Предалагаю вам это сделать мысленно )) и перечитать…
Смотрите, в случае когда вы запускаете шеф как клиент серверное приложение что де факто основной способ использования шеф возникают те самые накладные расходы с тем что вы все время вынуждены "прокидывать" изменения в коде через шеф сервер ввиде кукбуков. Если сравнивать шеф сервер по этому параметру с тем же ansible или Sparrowdo, то последние imho выигрывают по причине отсутствия лишнего звена в цепочки ввиде шеф сервера.
Но давайте я скажу ещё раз — акцент этой статьи не на этом. Возможно я не очень аккуратно применил термин push based в данной статье, что увело нас в сторону.
Шеф даже в случае с использованием его в режиме клиент сервер тоже хорош, но есть вещи которые удобнее, лучше и правильнее делать не через шеф.
Примеры? Мне кажется я как раз их и привёл достаточно. Ещё раз — тестирование системы после отработавшего шеф клиента, установка или настройка чего-либо что нужно по каким-то причинам прямо здесь и сейчас, но совершенно не требуется для успешной работы самих шеф кукбуков и самое главное не является целевой конфигурацией. А так же дополнительная настройка системы с целью воспроизведения граничных условий или багов. Как отработает мой шеф рецепт — если в системе уже будет установлен пакет такой-то версии или если не будет существовать такой-то пользователь? И так далее и тому подобное. Так вот — приведение трестируемого окружения к требуемому состоянию лучше из шефа выносить, так же как и сами тесты.
.
Пример с остановкой сервиса nginx перед запуском шеф кукбуков очень показателен, вам необходим выполнить остановку сервиса только ради тестирования кукбука? нет совершенно никакого смысла делать это через какой-то вспомогательный кукбуков или что ещё хуже вносить это в тестируемый кукбук. Гораздо проще это сделать "прямо и по месту" через Sparrowdo как я показал это в статье. Ведь по сути данная операция ( остановка сервиса ) вам нужна только на момент тестирования кукбука и все. Нет смысла вносить ее в шеф.
Здесь как раз хочется показать что использование только одного инструмента не всегда является best practice
Мне кажется мы начинаем уходить немного в сторону от того что я хотел сказать в статье, здесь акцент не на времени исполнения ( хотя опять таки же накладные расходы в случае с использованием chef как клиент сервер есть ) или там на сравнении pull с push архитекурой. А на том, что можно использовать шеф вместе со Sparrowdo, при отладке сценариев управления конфигурациями.
Sparrowdo выступает как обертка для запуска шеф клиента, что лично для меня весьма удобно, так позволяет легко и просто настраивать параметры запускаемых рецептов, так же Sparrowdo выступает ввиде дополнительного инструмента по тестированию или установке необязательных зависимостей в систему — всего того что бы вы на хотели запихивать в шеф кукбуки.
да, все верно, chef клиент можно запускать в таком режиме ( здесь правда уместнее говорить о команде
knife ssh
— но разница небольшая относительно вашего примера ).возможно я не очень аккуратно выразился. вот что хотелось сказать — иногда мне хочется описать какую-либо конфигурацию ввиде сценария и тут же запустить все это на целевом сервере, в случае с шефом у вас всегда есть шаг связанный тем, что сценарий должен быть добавлен в виде кукбука на шеф сервер ( если это конечно не chef-solo но я здесь его не рассматриваю ) и только заетм шеф клиент ( когда вы его запускаете по ssh) запрашивает данный кукбук с шеф сервера (pull) — это определяет определенные накладные расходы на цикл разработки и тестирования кукбуков ( грубо говоря вы все время вынуждены делать knife upload каждый раз внося изменения в кукбук, плюс добавьте время когда шеф клиент скачает новую версию кукбука при запуске и т.д. ), в случае же с ansible или sparrowdo у вас нет этого лишнего шага, вы просто копируете ( в том или ином виде ) сценарий по ssh на целевой сервер и сразу же его выполняете…
В общем случае это не такая большая разница, но я считаю все же возможность быстро прогнать изменения очень важна при разработке. Так вот идея в том, что там где это уместно — писать сценарии на sparrowdo — это быстрее и проще, при этом это не отменяет основной цели — тестирования и разработки шеф кукбуков ( поэтому я и сказал в самом начале что использую эти два инструмента в связке ).
ок, что бы было еще проще (:, извиняюсь если сложно объясняю:
core-dsl — функции, plugin API — функция task-run — просто функции, которые пользователи вызывают в sparrowdo сценариях, вам не надо их писать, если кто и добавляет новые функции в core-dsl — это разработчик sparrowdo, то бишь я.
sparrowdo modules — вы можете использовать готовые в своих sparrowdo сценариях или можете написать свои и так же их использовать. Создание своего sparrowdo модуля подразумевает создание обычного Perl6 модуля в неймспейсе Sparrowdo:: и реализации в нем функции
tasks
принимающей на вход хэш параметры. Вот как то так. Конкретно по написание модулей на Perl6 — это уже в Perl6 комьюнити — у них отличный irc канад — они всегда готовы помочь, ну и конечно сайт https://perl6.org/для обычно пользователя:
с другой стороны модули — это API для разработчика расширений, задокументированное тут и вот здесь вы просто пишите произвольный Perl6 код, как хотите, с ветвлениями, циклами и чем угодно. Основное требование с точки API разработки — вы должны реализовать внутри модуля функцию
tasks
, принимающую на вход хэш параметры, что она будет делать это вобщем=то ваше дело, но де факто — ( посмотрите примеры и документацию ) она скорее всего сделает один или несколько вызовов функций task-run или core-dsl функций — что бы сделать что-то полезное ((:Да, модули — это можно сказать третья сущность в sparrowdo ( наряду с core-dsl и task-run ). На самом деле вот что такое sparrowdo модули
Параметры
%parameters
просто передадутся в реализованную в модуле функциюtasks
, которая разберет их и сделает одни или несколько вызовов функцийtask-run
. На самом деле ровно так же реализованы функции core-dsl. Можно смотреть на модули как third-party дополнения к sparrowdo которые по определенным причинам не включены в core-dsl, в принципе, если модуль достаточно полезный и часто используемый — он может быть хорошим кандидатом на миграцию в core-dsl, как-то так.