Comments 67
Хм, для каких случаев разумнее использовать это, а не обычные команды? Ведь в них должна быть только установка и настройка чего-то. Или я не прав?
Приветствую! Попытаюсь ответить на два последних комментария одним своим комментом. Да, вы правы, впринципе обычных bash скриптов может быть достаточно для написания конфигурационных сценариев. Sparrow это по сути и есть некоторые скрипты, которые можно запустить. Окей, не просто скрипты конечно же, Sparrow предлагает дополнительные ( killer? ;-) фичи из коробки:
скрипты можно писать на одном из трёх языков — Perl, Ruby, Bash, последний был выбран мной при написании статьи, но выбор им не ограничивается
- вне зависимости какой из языков вы используете, из коробки гарантировано Sparrow API, на который вы можете положится, а именно: 1) входные данные в виде конфигурационных файлов (yaml, Config::General ) или параметров командной строки 2) модульность — возможность вызывать одни сценарии из других с передачей параметров ввиде хэшей ( попробуйте это сделать на снуля на bash ) 3) встроенная система тестирования сценариев Outthentic::DSL
Резюмируя, в первом приближении Sparrow сильно похож на Bash ( если только вы пишите Sparrow сценарии на Bash ), но при более глубоком рассмотрении Sparrow это такого рода фреймворк или так скажем "клей" для запуска различных сценариев со встроенной системой верификации ( тестирования )
Ещё пара важных фич Sparrow, нераскрытых здесь:
отчеты Sparrow предоставляются в формате TAP, переносимом на многи системы
- Sparrow плагины — переносимые пакеты пользовательских скриптов, имеющие свои версии и распространяемые через центральный репозитарий https://sparrowhub.org, в данной статье я использовал вариант с так называемыми приватными плагинами, которые устанавливаются через удаленные git репозитории, но в общем случае вы всегда можете опубликовать в публичный доступ, все это поощряет повторное использование кода в контексте конфигурационных пользовательских скриптов, аналогия chef рецепты или ansible плейбуки, толко sparrow плагины более общие в том смысле они не навязывают никакого DSL при их написании ( как в случае с шефом или ансиблом ) идеология Sparrow такова вы выбираете комфортный для вас язык разработки( сейчас это один из трёх — Perl, Ruby или Bash, впрочем добавление других типа Python илиGo не так сложно ) а Sparrow просто добавляет все вышеперечисленные фичи и дань возможность опубликовать ваши сценарии и распространять их ввиде пакетов. ( sparrow плагинов )
Вообщем как то так ...
Спарроу тащит все три зависимости внутрь? Кстати, можно же писать на них и без спарроу.
Нет конечно. Изначально только Perl, т.к. Sparrow на нем написан. Он ставится как cpan модуль ( в будущем может соберу rpm,deb ) — и зависимостей у него не так много от других cpan модуйлей
Насчет остального — предполагается, что ruby или bash доступен в системе, плюс возможность подгружать зависимости при установки именно плагинов ( а не самого Sparrow ) — т.е. пользователь может определить свои зависимости от CPAN, rubygems посредством файлов cpanfile или Gemfile
На счет конфигурации, в мире докера вроде принято делать все через переменные окружения. Их можно группировать в файлы .env (идеально совмещаются с docker-compose) и/или передавать через командную строку.
Sparrow этому не противоречит, в статье я как раз и пытался это выразить. Т.е. базовые настройки можно проталкивать через Dockerfile конвекционно. Но, что, если у нас сложная конфигурация с иерархической структурой ( вложенностью ), боюсь, что переменные окружения здесь будут неудобны, а вот Sparrow умеет из коробки работать со сложными конфигурационными файлами в формате Config::General или YAML, причем независимо от языка на котором пишется сценарий
Вот тестирование — интересно, хотя не ясно, что тестировать в случае инсталляционного скрипта. Ведь вы что-то скриптуете относительно известной и фиксированной версии ОС.
Согласен. Но все равно бывают во-первых более сложные случае, когда не возможно все задать на уровне входных данных ( версии пакетов и т.д.) и во вторых — это такой подход в тестировании — вы валидируете stdout от вашего тестового сценария, иногда это бывает очень удобно и полезно просто. Хотя соглашусь, что пожалуй именно в случае с деплойментом и конфигурацией это не так очевидно. Можно это так же воспринимать как дополнительный аудит состояния системы после ее настройки, вот кстати типовые кейсы:
- проверить что процесс существует (виден) в списке процессов
- проверить контент файла
Плагины… Вот некоторые вещи можно было бы выразить в виде плагинов, например установку хитрой версии чего-нибудь не из стандартного репозитория, требующие какие-то хитрые манипуляции с AppArmor и т.д.
Да, да. В этом и фишка Sparrow. Вы пишите что-то сложное и нестандартное ( а таких задач на самом деле немало ) — потом пакетируете это в виде Sparrow плагина и выкладываете на https://sparrowhub.org — теперь другие могут использовать это. Примеры плагинов — https://sparrowhub.org/search
прошу прощения, опечатался в предыдущем комментарии:
вы валидируете stdout от вашего тестового сценария
да и вот еще важный момент, простите не сразу сообразил :)
Кстати, можно же писать на них и без спарроу.
В этом и суть, Sparrow и не является еще одним языком или DSL, все верно, вы изначально пишите на каком-то из трех языков, а потом с минимальными усилиями портируете свой набор скриптов ( или один скрипт ) в Sparrow плагин, получая те самые фичи о которых я говорил в предыдущих комментариях.
Если сценарий сборки нетривиален и содержит множество инструкций, нужно как-то выкручиваться. Помимо того, что Dockerfile не может содержать более 120 слоев ( насколько я правильно понял из документации по Docker ), иметь дело с развесистым Dockerfile не очень приятно.
Подумал. Прочитал ещё раз… Малость испугался.
А вы точно уверены, что вам необходимы такие развесистые «скрипты развертывания»? Может что-то не так с самой идеей такой сложной настройки образа?
P.S. А можно ли какой-то пример из вашей практики, чтоб ощутить необходимость такого сложного контейнерного образа?
Например, сборка приложений со сложными конфигурациями, где необходимо использование шаблонизаторов. Или пробрасывание кастомных yum репозитариев, или приложения где используется одновременно несколько языков программирования, среды для которых нужно строить с нуля.
Но суть использования Sparrow не в том, что все тоже самое нельзя написать в терминах только Dockerfile. Sparrow подход ортогонален Docker проектам, вы можете например написать плагин для установки Ruby,rvm и использовать этот плагин в разных Docker проектах. А если все то же самое написано прямо в Dockerfile или даже внутри bash скрипта это становится сложно переносить и повторно использовать, особенно об этом я писал тут.
1. Правильно ли я понял, что вы таки используете Docker образы в своём проекте?
2. Являются ли созданные вами образы независимыми от окружения, в котором они будут запускаться? Может ли один и тот же образ быть запущен локально (или в тестовом окружении) и на production?
3. Включаете ли вы секреты в образ или же они запрашиваются в момент старта контейнера?
4. Я не знаком с Ruby. Правильно ли я понял, что eye оборачивает ruby-процесс и для вас выглядит как некий launcher — вы запускаете его, а он запускает ваш ruby код?
Эти вопросы я задаю, так как у меня сложилось впечатление, что вашем случае есть некое смешение того, является частью образа (image build time) и что должно быть частью развернутого контейнера (deployment time).
Следуя аналогии дедушки Мартина (Fowler), такой сложный образ начинает отдавать душком (smells). Возможно вам стоит разбить один образ на несколько и запускать их как совокупность?
Вот тут про то, как образы могут быть декомпозированы в kubernetes — http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html Но мне кажется, всё то же самое может сделать Docker Compose.
начинаем, правильнее будет сказать
пока все в стадии разработки, только недавно встал вопрос с применением докер контейнеров, и нет разделения ( это я про докер ) на окружения, но мы к этому придем, когда потребуется
сейчас они вживляются в образ, но могут быть и другие варианты ...
- eye один супервизор ( написан на ruby имеет ruby API ) — коих десятки — он просто следит за системными процессами ( не обязательно связанными с ruby приложением, за любыми )
Эти вопросы я задаю, так как у меня сложилось впечатление, что вашем случае есть некое смешение того, является частью образа
(image build time) и что должно быть частью развернутого контейнера (deployment time).
не вопрос, можно растащить все на отдельные имиджи и потом делать "наследование" через FROM:, Sparrow опять таки же не противоречит этой концепции — вы можете:
1) иметь отдельные части системы на уровне вложенных докер образов — первая степень свободы
2) вы можете деплоить отдельные части системы — отдельными sparrow плагинами — вторая степень свободы
вы сами выбираете в какой степени вы больше сдвигаетесь в сторону 1) или в сторону 2), и да могут быть частные случаи когда вы используете только 1) или только 2), но что-то мне подсказывает что истина в том, что зачастую комбинировать оба подхода гораздо удобнее и эффективнее
да, извиняюсь, не очень внимательно прочел ваш комментарий, по поводу этого
декомпозированы
здесь те же мысли, что и при использование докера по схеме, указанной alexkunin в https://habrahabr.ru/post/302278/#comment_9642488 (см. также мой ответ ему ), даже при должной декомпозиции и разбиении системы на более простые куски, самый простой кусочек может аналогично деплоится через sparrow плагин или плагины ( в зависимости таки от сложности кусочка ), кроме того, при таком подходе можно получить чистую и никак не связанную с самими докером (по крайней мере сильно ) систему строительных блоков ( плагинов ) — "параллельную" множеству имиджей, используемых в системе…
да, конечно, все так.
но на мой взгляд использование \ ну по крайней мере черезмерное усложняет читаемость докерфайла, но да не в этом дело, как уже сказал, что можно все вынести в сторонние bash скрипты и потом использовать их ( будь то ADD, CMD, ENTRYPOINT ) — но по сравнению со Sparrow — эти скрипты будут жестко привязаны к контексту конкретного Docker проекта, вот, например вы захотите их использовать повторно в другом проекте, что бы не писать все сначала, или сделать какой-нибудь рефакторинг, что бы выделить базовые вещи, общие для разных проектов ( сборок ) — в случае с прямым подходом Dockerfile/bash/ADD/CMD/ENTRYPOINT это будет сделать гораздо сложнее, чем со Sparrow — т.к. в нем by desing предусмотрена модульность и переносимость скриптов. Sparrow в этом смысле более гибок и агностичен где он используется ( Docker или любые другие задачи автоматизации ), а bash скрипты как есть — IMHO- хороши для решения задачи здесь и сейчас — но сложны для повторного использования и дистрибуции, т.е. в перспективе с ними могут быть проблемы на большом кол-ве проектов.
Да, и повторюсь еще раз. В контексте сборок Docker контейнеров Sparrow — это те же Bash скрипты, с идеей их простого повторного использования ( + плюс встроенная система конфигурации скриптов — suite.ini / yaml ) в других проектах ...
:) Интересно, нужно подумать. Прямо сейчас должен отлучится. А давайте может так… У вас есть какие-нибудь задачи по конфигурации? Что-нибудь сложное? :)) Приведите здесь исходные данные, напишем вместе Sparrow plugin вместе с Dockerfile :)…
Спасибо за ваш пример. А само приложение ( на php, как я понимаю? ) как деплоится?
Ясно. Ну в таком случае ваш вариант вполне годится, думаю. Но, если бы, например, у вас был бы деплой самого приложения. Можно было бы подумать вот о чем:
разделить деплой на три части — деплой зависимостей (php, apache, и все остальные пакеты ), настройка самого апача и деплой приложения
тогда если скажем у вас бы было несколько проектов вы могли бы как минимум части первую и вторую использовать повторно
- а вот что бы пункт предыдущий был осуществим я бы через Sparrow сделал бы это так:
1) плагин basic-app (ну или какое нибудь более удачное название ) — для деплоя первой части системы
2) плагин apache-config (для настройки и запуска апача ) — часть вторая
3) плагин(ы) app-*-install (для деплоя различных php приложений ) — часть третья
С помощью монолитных Dockerfiles это было бы сделать более проблематично — или пришлось много копировать повторяющихся кусков кода.
Вот как-то так.
Т.е. я к тому, что сложность она не только в том, что отдельные компоненты сложно настраивать, а и в том, что зачастую один и тот же типовой компонент (basic, apache и т.д.) может потребоваться поставить больше чем одни раз на множество контейнеров, серверов, классика жанра для devops )))…
Мне нравится ваш ход мыслей :) Отчасти смотрите мой ответ MaverickCGRey по поводу образа с душком. Но вот что еще можно добавить:
даже базовые образы нужно как-то "готовить" — вы уже не можете дробить их до бесконечности, то же апач может настраиваться sparrow плагином и т.д — для каждого очередного имида в иерархии — свой sparrow плагин
у такого подхода все же есть ограничение — наследование дистрибутива OS ( в самом базовом имидже ), в то время как Sparrow сценарии могут быть кроссплатформены ( а если завтра на будет нужен Debian? :)))) — все это выглядит слегка умозрительными, но об этом нельзя забывать
- но главное конечно не это. А то, что Sparrow не противоречит указанной вами архитектуре — еще раз повторюсь — никто не мешает разбивать очередной имидж в вашей иерархии на логические, более мелкие слои и настраивать их через Sparrow плагины ...
Правда, разница между скриптом рядом с докерфайлом и скриптом в репозитории спарроу от меня опять ускользает.
еще раз — разница это — возможность (простого) повторного использования плагина
вот вам кровь из носу нужно засунуть все приложение в единственный контейнер, начальник приказал
такое бывает часто ;))
На сколько я понимаю, последующий слой может делать с предыдущим что угодно: изменять файлы и даже удалять их.
Хотелось бы только добавить, что не стоит процессу внутри контейнера менять своё состояние. Контейнер умер и был поднят на другой машине… вот вам и привет всем настройкам и плагинам, которые вы ему наставили.
Не понимаю зачем пытаться все конфигурирование запихнуть в Dockerfile? — на мой взгляд это неправильно.
Dockerfile — нужен непосредственно для создания самого образа и должен включать в себя такие операции как: скачивание исходников, сборка, установка необохожимых пакетов и зависимостей, добавление конфигов и вспомогательных скриптов, а так же для объявление volumes и портов, но не больше.
Все конфигурирование должно выполняться уже при запуске конкретного контейнера, например, стартовым скриптом, который выполняет предварительную настройку(установку?) приложения, исходя из переданных пользователем переменных окружения, непосредственно перед запуском самого приложения.
не вопрос… возможно, написав эту статью я зацепил много тем и ньюансов ))) тот же самый Sparrow аналогичным образом можно использовать и в таком виде конфигурации. В докерфайле прописываем только установку требуемых Sparrow плагинов, а уже на запущенном контейнере запускаем плагины, которые делают всю остальную работу по тонкой конфигурации.
Правда таки предложенный вами способ — более затратный по времени ( оно потребуется для того, что настроить все уже на работающем контейнере ), по сравнению с тем, что мы берем уже готовый имидж, и просто инстанциируем его запуская контейнер…
В целом Sparrow выглядит довольно неплохо, возможно он и сможет помочь в конфигурировании образа.
Про конфигурирование во время сборки образа, здесь вопрос скорее в принципах его построения. Вы предлагаете оперировать образами так же, как и контейнерами: каждый отдельно взятый случай и уже неизбежна пересборка образа.
Это определенно имеет место быть когда у вас есть в этом необходимость, но если честно я так и не смог придумать такую необходимость, при которой нельзя было бы записать все инструкции в обычный Dockerfile.
Повторюсь, я имею ввиду именно установку и сборку ПО, а не его конфигурирование. Под конфигурированием я имею ввиду такие операции, как например: сгенерировать SSL-сертификат, создать базу данных $DATABASE, создать пользователя $USER с паролем $PASSWORD в приложении и т.д.; так как эти операции никак нельзя учесть при создании образа и они должны определяться пользователем при запуске контейнера.
Именно такой подход обеспечивает простое управление контейнерами и правильную работу внутренних механизмов --link в docker, а так же избавляет вас необходимости пересобирать образ для каждой нестандартной ситуации.
Ведь будь вы пользователем, все что вам нужно, это указать значение нужного параметра при запуске контейнера.
Кстати, насколько я понимаю Phusion в своем baseimage исполюзуют тот же подход, что и у вас.
1. Зачем генерировать сертификат? Можно ли его передать контейнеру снаружи?
2. А где находятся файлы данных базы? В контейнере?
3. Зачем создавать базу при старте контейнера? Почему нельзя подключиться к уже существующей и управляемой отдельно?
Затем, что вы не можете сделать этого заранее. Вы не знаете ни доменного имени которое будет указанно только при запуске контейнера, и конечно же вы не хотите, что бы у всех кто запустит ваш образ были одинаковые ключи.
Можно сделать и так чтобы можно было передать сертификат снаружи, все зависит только от вашей фантазии и функций которые желаете реализовать в вашем образе. :)
Если это контейнер базы данных, то вся персистентная информация должна быть вынесена в data volume.
желательно еще оставить возможность подключать внешнюю директорию на место этого volume (многие недолюбливают и недоверяют консепцию docker data volumes)
- Я лишь привел в пример те операции которые должны выполняться внутри контейнера, если это контейнер базы данных, вам нужно создать базу данных с определенным именем, пользователем и паролем, которые, опять же, передает пользователь в виде переменных окружения (взгляните на официальный образ mysql)
Позже, контейнер вашего приложения при помощи--linkполучает эти переменные и себе, автоматически подключается к этой базе данных, создает таблицы, правит свои конфиги и наконец запускается (примерно так же устроен официальный образ wordpress, за исключением того, что таблицы он создает при начальной установке в браузере)
Если я правильно понимаю, в терминах Спарроу это будут два плагина: для апача и для пхп.
Думаю в таком раскладе плагинов может быть сильно больше. Т.е. в плагины удобно выделить что-то что вы будете использовать больше чем один раз. Например (чисто умозрительно, исходя из ваших списков )
base-packages — устанавливает базовый список системных пакетов ( в вашем случае rpm ) — apache, php — базовый значит заведомо требуемый в каждом вашем проекте
apache-config — настраивает головной конфиг апача — причем тип настройки можно указывать как параметр плагина — типа хочу такой конфиг или такой; устанавливает, настраивает дополнительные апачевские модули и конфиги хостов
- php-modules — устанавливает, настраивает конфигурацию модулей php — тоже самое — тип настройки можно указывать как параметр плагина — типа хочу такой список модулей, с такими конфигами, или что-то другое, включение, выключение php5-odbc, php5-mysql можно задавать исходя из выбранного типа конфигурации
PS можно было бы разбить все еще на более мелкие куски ( плагины ), но не зная всей специфики проекта сложно сказать как лучше. В любом случае Sparrow достаточно гибок, что бы оперировать как с крупными, так и с мелкими частями системы, все зависит от разработчика плагинов и архитектора системы ...
Каким образом спарроу спасет меня от написания двух отдельных скриптов для разных систем, учитывая различия,
таки да, в какой то момент ( когда уже нечего выделять в общее ) вы пишите два разных скрипта ( или там набора скриптов ) либо два разных Sparrow плагина, но вся разница в том, что в будущем когда в дизайне системе что-то поменяется ( а оно поменяется с шансами… ) проще выделить снова общие сущности или сделать рефакторинг системы, когда вы оперируете плагинами, а не просто наборами скриптов ( или inline прямо в Dockerfile ) разбросанными по разным проектам. Фактически удачно придуманная система плагинов дает вам больше возможностей делать полезные модификации системы в целом, а не мыслить только в терминах отдельных докер контейнеров или скриптов… Эта просто сущность более общего порядка, а это всегда лучше, чем просто набор скриптов…
- Можно сделать по-разному. Например один php, Apache модуль — отдельный плагин. Или же наоборот один плагин даёт на выбор устанавливать жестко заданные наборы php, апач модулей, или же третий вариант, есть плагин который принимает на вход ( как команд Лайн параметр или параметр плагина ) массив php, апач модулей для установки — этот вариант самый общий. Вобщем выбирать исходя из контекста задачи.
Ответы на вопросы. В обратном порядке.
Сам по себе Спароу как уже не раз говорилось предоставляет некий базовый API, но он больше связан с организацией плагинов, вся реализация конечных сценариев Спароу не касается, разработчик пишет их сам. Ответ такой придётся реализовывать самому. Или шаблонизатором, если конфиг собирается снуля, или редактированием по месту ( как вы предлагаете ). Понимаю на самом дела ваш кейс, сам часто с таким сталкиваюсь. Но опять таки же можно попробовать динамические, меняемые секции в общем кофиге ввиде либо параметров модулей ( downstream историй ), либо ввиде входных параметров отдельного плагина, который настраивает конфиг, это может помочь не идти путём sed патчинга.
Хороший кейс. Сейчас такого понятия как зависимости плагинов друг от друга нет, однако смотрите идею с таск боксами — коллекциями плагинов — см. В документации по Спароу, отчасти решает данную проблему.
ответил отдельным комментом тут :)
1. «Я подключаюсь к контейнеру по ssh или через Docker CLI и запускаю клиент супервизора для выяснения ситуации с сервером.»
2. «Супервизор сам открывает порт и выставляет свою web-морду, на которой я вижу что происходит с сервером.»
3. «Супервизор экспортирует показатели сторонней системе (через файл или сетевое соединение), а я использую эту систему для автоматического мониторинга.»
Опишите свой случай, пожалуйста, если я промазал.
А как вы или другая система снаружи узнает, что у такого контейнера все нормально? Как вы его мониторите?
Не берите в голову. Это я так, чисто для расширения своих горизонтов спросил.
А если у вас больше одного контейнера с таким «воркерами» и один из них «встал колом», но остальные работают. Как глядя на движущуюся очередь вы понимаете, что один контейнер «отлынивает»? В вашем случае «отряд не заметит потери бойца».
Не буду больше ковырять. Как я вижу, для вас это все в самом начале и у вас у самого больше вопросов, чем ответов. Спасибо.
Supervisord обычно используется в качестве инит системы для запуска и контроля ваших сервисов.
В официальной документации docker предлагается тогда, когда существует необходимость использовать несколько сервисов одновременно в одном образе.
Так же помогает решить проблему с PID 1 zombie reaping (если она есть).
2. Правильно ли я понял, что «PID 1 zombie reaping» результат особенностей Docker ранних версий и на данный момент она не актуальна?
Концепция верная, всегда правильно пытаться ее придердиваться, но все же периодически возникает такая необходимость, например тогда, когда сервису для нормального функционирования нужны такие служюы как cron и rsyslog. Еще иногда находятся отдельно взятые моменты, когда зависящие друг от друга сервисы просто нецелесобразно пытаться разделить.
- Насколько я понял, здесь проблема не сколько в Docker, а сколько в отсутствии нормального init'а. Проблема остается если вы запускаете программу которая плодит кучу процессов. При отсутствии нормального inita, может возникнуть данная ситуация.
Мне кажется, что мы из разных миров. А чувствую, что ваши слова подкреплены вашей реальность, примерами из вашей жизни. Но для меня они звучат странно.
Для меня процесс — это запущенный в кластере контейнер. И обычно, одно приложение — это не один контейнер, а множество.
В моем мире ситуация запуска в контейнере одного процесса другим возможна. Например, когда python скрипт запускает JVM, но это исключение. Обычно, запускается одиночный процесс.
Для меня, сron — внешняя система, которая просит надзирателя над кластером запустить контейнеры.
Процесс помогающий работать с логами основного контейнера — это ещё один контейнер, запущенный в паре с основным. По типу sidecar описанному тут http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
Когда вы сами пишите приложение, то да, учесть все это и сделать по правильному намного проще, чем тогда когда вы докеризируете уже написанное кем-то приложение, особенно если оно очень крупное (комбайн), состоящий из множества связанных между ссобой сервисов. Вот вам в качестве примера: gitlab, kolab, или и тот же самый postfix, который без rsyslog логи писать не будет.
Я не говорю что это правильно, я рассказал для чего ипользуется.
@alexkunin спасибо что так много написали. не хочется отвечать по всем пунктам — будет слишком много деталей и мелочей, а кажется важно понять принципиальные вещи. :))
Вот как я вижу идеологию Sparrow
система плагинов решающая различные задачи автоматизации
Sparrow это не силвер балет он сам по себе не решает из коробки ВСЕ задачи — это некая инфраструктура упрощающая и поощряющая повторное использование кода то бишь скриптов в задачах автоматизации, но внимание — сами эти задачи решают конкретные плагины, которые пишут конкретные люди ( хорошо или плохо это уже другой вопрос )
вот что дает Sparrow из коробки
возможность написать свой полезный скрипт и сделать его публичным ( или условно публичным — приватным, — см. док-ю по Sparrow — приватные и публичные плагины ) — что бы кто-то другой смог его повторно использовать ( не важно в рамках вашей же компании, проекта или в обще)
скрипт становится распространяемым пакетом — Sparrow плагином, у которого есть своя версия, в дальнейшем разработчик плагина может поддерживать плагин, релизя новые версии, Sparrow клиент дает возможность обновлять или ставить конкретные версии плагинов.
В случае с публичными плагинами немаловажно, что есть web интерфейс к репозитарию таких плагинов — https://sparrowhub.org позволяющий поискать нужные плагина и посмотреть дополнительную полезную информацию, связанную с плагином — авторство, документация, ссылки на исходники и т.д.
Все это поощряет и упрощает повторное использования уже кем-то написанных и протестированных скриптов-плагинов
В добавок к этому разработчику плагинов из коробки обеспечивается API по конфигурации плагинов — другими словами вам не надо писать самому то, что скорее всего вам потребуется — а именно обработку входных параметров своих скриптов. Это API реализован для трех форматов данных — параметры командной строки, YAML, Config::General.
Sparrow поддерживает модульность — когда у вас есть группа сценариев, которые могу вызваться в определенный последовательности или когда один сценарий вызывает другой с передачей параметров, опять таки же вам не нужно это писать с нуля, я называю это модульностью в том смысле что сценарий модуля в рамках одного плагина — могут вызываться больше чем один раз с различными параметрами. Подробнее об этом на страницах док-и (upstream, downstream strories)
Sparrow предоставляет встроенную систему тестирования работы сценариев Outthentic::DSL с генерацией отчетов в переносимом на многие системы формате TAP
И наконец все эти фичи не зависят от того, на каком из трех языков вы пишите сценарий — Perl, Ruby, Bash
- Это те ценности, которые вы получаете из коробки, когда вы пишите свой скрипт не просто на Bash или Perl или Ruby, а в контексте Sparrow плагина, по-моему немало
Далее:
порог вхождения в Sparrow архитектуру — не такой уж большой, т.к. повторюсь еще раз и еще раз — Sparrow не навязывает своего DSL или нового языка разработки — вы всегда пишите на одном из трех языков — Bash, Perl или Ruby
Sparrow не является никакой заменой пакетных менеджеров, да это врэпер, но с таким же успехом скрипт внутри которого вы написали что-то типа
yum install apacheтоже будет врэпером
- Вот заменой чего он точно является так это кастомных репозитариев скриптов, я уже писал в другой статье почему IMHO это может быть лучше
Целью статьи не было описание API sparrow, поэтому отдельные моменты без чтения документации или ознакомления с основами, будет сложно понять, я об этом предупредил вначале )) это насчёт "тарабарщины".
не вижу никакого отличия от просто скрипта, который пишется кем-то, от просто скрипта который опять таки же пишется кем-то и затем "упаковывается" в плагин. И там и и там скрипт -) и там и там yum install или что-то аналогичное
возможности повторно использования. Согласен с вашей ремаркой, но опять таки же нельзя в одной статье рассказать все -)
насчёт того что бы продать и отсыл к известным популярным проектам, опять таки же полностью с вами согласен -) стараюсь… Поэтому пишу статьи и собираю ценные отзывы пользователей, спасибо ещё раз и за ваши комменты, хотя как видите не со всем из сказанного вами соглашаюсь -)
- да и за примерами — сходите на спароухаб, там конечно не "космические" Корабли, но позволяют понять подход в Спароу методологии, да и ещё статьи на blogs.perl.org — http://blogs.perl.org/mt/mt-search.fcgi?limit=20&search=Sparrow очень полезны в этом плане
Так же в ваших плагинах встречаются .ini-файлы, только вот они не .ini, а что-то другое (похоже, вместо "=" разделителем является пробел, но это мои домыслы).
Да тут есть нестыковка по названию, дело в том что в более раних версиях формат был именно ini style, затем я перешёл на Config::General, а затем добавил поддержку yaml. Но название самих файлов осталось старым suite.ini, что согласен вводит в заблуждение, но опять таки же в документации все расписано. Да и в этой статьи используется формат кончиков Config:: General ...
Еще раз предлагаю: возьмите реальную задачу, которую люди трудоемко выполняют довольно часто, и покажите, как легко она делается с помощью спарроу. Я предлагал вордпресс, вам не понравилось.
Я не сказал, что не понравилось ))) Можно и написать будет, почему нет? )))
Проведите опрос: что бы люди хотели бы увидеть? Увидите, скажем, 10 вариантов настройки апача, сделайте плагин, если будет удачный — реклама проекту, благодарность людей.
Да я как бы и не против. Кстати есть проекты, которые для которых плагины существую, и вроде как людям нравится
И нашел тривиальные скрипты в 1-2 строки, завернутые в плагины с помощью нескольких дополнительных файлов.
Не совсем так. Есть действительно простые вещи ( не вижу в этом ничего зазорного, если на данном этапе 1-2 комманды — это все что нужно, то и окей, если кому-то нужно что-то еще — есть github можно создать issues или pull request сделать, законтрибутить в плагин ), но например посмотрите loggod или stale-proc-check или gtiprep ...
@alexkunin в целом я вас понял, спасибо за отзыв, и за ценные советы, будем работать ))))
- Извиняюсь отпечатался, logdog
- да GitPrep, тоже отпечатался
- stale-proc-check, сейчас могу за давностью времени ошибаться, но etimes не со всех линуксах есть, писал на perl, потому что просто было удобнее, попробуйте на чистом bash манипулировать с датами ввиде 1 weeks, 2 days, 4 minutes. В перле это уже все есть, через модуль DateTime
Разработка Docker контейнеров с помощью системы многоцелевых сценариев Sparrow