Ок, а я правильно понимаю, что сгенеренные 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, как-то так.
Здравствуйте. Спасибо за вопросы. Отвечу по порядку.
Несколько раз вы говорили про CoreDSL и PluginDSL для него. Насколько я понял, разница лишь в самом синтаксисе в sparrowfile. Т.е. в первом случае создается json и кидается на целевой хост, который исполняется клиентом, во втором — параметры передаются напрямую
В обоих случаях ( и core-dsl API и plugin API ) — это просто функции, написанные на Perl6 ( в случае с Plugin API — это только одна функция — task-run(...)), которые в конечно счете генерируют на выходе некую мета информацию — taskbox ( она сериализуется в JSON и определяет какие плагины, с какими параметрами и в каком порядке запускать ) — которая в виде JSON файла копируется на целевой хост, далее на этом же целевом хосте запускается sparrow клиент, который на вход получает файл с этой самой мета информацией ( task box ) и по данным в ней устанавливает, настраивает ( передает параметры ) и запускает sparrow плагины по порядку определенному в файле taskbox.
На самом деле, что бы было понятнее — если посмотреть в сам taskbox файл — это просто массив, задающий задачи, например так:
Кстати обо всем можно почитать на блог сайте 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 )
Добрый день. Вы имеет ввиду 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, как-то так.Здравствуйте. Спасибо за вопросы. Отвечу по порядку.
В обоих случаях ( и core-dsl API и plugin API ) — это просто функции, написанные на Perl6 ( в случае с Plugin API — это только одна функция — task-run(...)), которые в конечно счете генерируют на выходе некую мета информацию — taskbox ( она сериализуется в JSON и определяет какие плагины, с какими параметрами и в каком порядке запускать ) — которая в виде JSON файла копируется на целевой хост, далее на этом же целевом хосте запускается sparrow клиент, который на вход получает файл с этой самой мета информацией ( task box ) и по данным в ней устанавливает, настраивает ( передает параметры ) и запускает sparrow плагины по порядку определенному в файле taskbox.
На самом деле, что бы было понятнее — если посмотреть в сам taskbox файл — это просто массив, задающий задачи, например так:
Кстати обо всем можно почитать на блог сайте sparrowdo, например в этой статье — sparrow plugins evolution
и в синтаксисе тоже. 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'… и валидация входных параметров.Имеется ввиду как раз то, что функции core-dsl оперируют/реализованы через вызовы task-run ( sparrowdo tasks ) — эти абстракции не нужно путать с сильно похожими на них абстракция в предметной области самого sparrow клиента — который также выполняет задачи (tasks) — ( sparrow task — абстракция для именованной пары — плагин + параметры ) — которые изначально описываются в sparrowdo сценариях задачами ( функции task-run — абстракция для вызова sparrow task через sparrowdo )