Собственно я сейчас разрываюсь: 1. Делать обработку тасков с помощью ansible и не ставить ничего на конечных хостах. 2. Не иметь себе мозг, делать агента для конечных хостов и убрать целый уровень абстракции. Но потерять универсальность и всё делать самому кодом без типа универсального конфигуратора. И да, на хостах будет доступ к очередям, некооторым метаданным управлялки и так далее

Зачем делать агента самому, если уже за тебя все написали 20 раз?

Зачем делать агента самому, если уже за тебя все написали 20 раз?

О, а можно ссылочку на агента управления шаред хостингом. Я прямо сейчас всё своё выкину и поставлю

с паппета и мколлектив

mco мне никогда не нравился тем, что под ним надо держать queue отдельный, salt меня этим и купил частично.

О, а можно ссылочку на агента управления шаред хостингом. Я прямо сейчас всё своё выкину и поставлю

define “управление” :) писать таски прийдется хоть так, хоть сяк. я к тому, что движков, которые для этого можно использовать уже есть много.

> 2. Не иметь себе мозг, делать агента для конечных хостов Если я конечно правильно понял, что ты имеешь в виду под словом “делать агента"

define “управление” :) писать таски прийдется хоть так, хоть сяк. я к тому, что движков, которые для этого можно использовать уже есть много.

ммм... ну собственно у меня вопрос можно раскрыть как "использовать ansible/salt или тупо самому написать"? Там для всего всё равно придётся писать кастомные плагины. нету у ansible стандартного "сделай бэкап по такой схеме вон того и обзови его так". или "вот должен быть апач с такой=то версией php и с такой-то, а с другими не должно быть, а конфиги вот".

я бы все же пользовал или salt или ansible или хоть тот же fabric.

> 2. Не иметь себе мозг, делать агента для конечных хостов Если я конечно правильно понял, что ты имеешь в виду под словом “делать агента"

я имел ввиду - полностью самописный обработчик тасков. всё вообще сам делает

я бы все же пользовал или salt или ansible или хоть тот же fabric.

а почему?

ну собственно потому что уже кто-то написал, есть community, не надо все делать/писать/чинить/ломать самому, и грабли у всех одни и те же в принципе. Одна голова хорошо…

круглее круглого колесо не выпилишь все равно. кроме как доказать себе, что ты тоже можешь сделать круглое колесо - особого смысля я не вижу. кроме случая, если есть реальное понимание почему не надо ползьвать все, что уже есть, а надо сделать свое, потому что ХХХ будет намного лучше.

но и там, я сначала бы подумал не впилить ли этот ХХХ уже в какой-то готовый продукт.

Я, конечно, мал и глуп, но придумать новый queue или pub/sub, который будет кардинально лучше того, что уже есть я пока не смог :)

makes sense?

в salt’e мне лично нравится отсутствие любой экстра инфраструктуры, кроме самого салта. ansible в принципе то же самое, но, как я уже сказал выше - SSH как транспорт меня настораживает. Хотя может я старомоден.

http://events.linuxfoundation.org/sites/events/files/slides/presentation_5.pdf

два чая за бимер и латех )

в паппете, особенно в четвертом, мне очень сильно разонравилось куда они идут со всем продуктом. Clojure как язык, отсутствие homogenic orchestration, большой толчок в сторону “купите наш ентерпрайз и вам будет счастье”

в salt’e мне лично нравится отсутствие любой экстра инфраструктуры, кроме самого салта. ansible в принципе то же самое, но, как я уже сказал выше - SSH как транспорт меня настораживает. Хотя может я старомоден.

А разве в ансибле есть централизованной хранилище для всяких фактов? В бесплатной версии

плюс, поговорив с людьми из салта, и таки купив у них опенсорс саппорт - они очень адекватны и очень хотят помочь своим кастомерам, в отличие от Люка и его новой политики

А разве в ансибле есть централизованной хранилище для всяких фактов? В бесплатной версии

Честно - не знаю, ансибл меня в своей архитектуре никогда не привлекал, я его никогда плотно не использовал. У нас есть две команды, которые его юзают в хвост и гриву - могу спросить на неделе.

в салте есть точно :)

в паппете ессно тоже :)

Хотя мне кажется, что ansible, по природе своей не имеет никаких storages вообще.

(опять же, as good a guess as any at this point)

Хотя мне кажется, что ansible, по природе своей не имеет никаких storages вообще.

По-моему у них это только в ынтерпрайз версии есть

Кстати, если кто тут пользует ansible.. скажите пожалуйста. Мне всегда казалось, что он был сделан как orchestration engine, к которому потом прилепили CM.

Salt мне понравился тем, что они сразу поставили себе цель сделать… блин, кто-то просил не говорить “как это будет по-русски”, но… homogenic? гомогенное? есть такое слово? :) объединенную инфраструктуру для оркестрации и конфиг менеджмента.

Паппет прикупил поделку нашего коллеги в виде mcollective, но реально нормально интеграции между продуктами так и нет. Да, факты можно через зад читать. И все.

В салте просто охрененный концепт реакторов.

Триггеры orchestration на какие-то события в инфраструктуре. Причем не отходя от кассы, с общей базой данный о инфраструктуре, и т.д.

Salt мне понравился тем, что они сразу поставили себе цель сделать… блин, кто-то просил не говорить “как это будет по-русски”, но… homogenic? гомогенное? есть такое слово? :) объединенную инфраструктуру для оркестрации и конфиг менеджмента.

Тебе не нравится что они пытаются провести границу? По-моему это одно и то же, не стоит разделять. Это вообще возможно?

Мне нравится, что они как раз не пытаются этого делать.

В салте просто охрененный концепт реакторов.

В соли слишком много всяких концептов добавилось с тех пор, как я её крутил/смотрел последний раз она была сильно меньше. Первое впечатление "о боже, теперь ещё и это!"

Мне нравится, что они как раз не пытаются этого делать.

ОК. Неужели это в принципе можно сделать?! И зачем? Цель понятна, а мотивы? Это разделение предполагается как-то монетизировать в дальнейшем что ли?

Ты меня сейчас совсем потерял :)

Переспрошу по-украински.. ШО?

Точнее, по-харьковски ;)

Переспрошу по-украински.. ШО?

Он наркотиками балуется, не обращай внимания

Бывает :)

о, homogenous - однородный! :D

Так. Давай порпроще возьмём. Смотри. Мне нужен rsnapshot грубо говоря. На каждый хост. Но. Я хочу между синхронизацией текущих файлови и удалением самой дальней копией вломится с возможностью восстановления. И после снапщота, хочу, чтобы актуальное состояние метаинфы улетело обратно в управлялку. Там делов на день с отладкой и кофе. Мучаюсь неделбю с архитектурой и реализацией. Ок. Есть Task Queue. Вот есть где-то расположенный в вакууме Task Worker (бьез разницы - Celery там, или вообще сам по REST что-то поллю, или хоть SELECT в MySQL делаю). Назовем его Обработчик-1. Поймал он задачу "делай снапшот". У меня есть варианты: 1. На хосте стоит ещё один мой Обработчик-2 с API, или лежать мои скрипты. Обработчик-1 задач выуживает из моей управлялки метаинфу по бэкапу, куда обращать, куда делать, что делать и фигачит на хост вот в это API обработчика-2 или по SSH скриптам (транспорт не важен, я для примера). Те что-то там делают (rsync например) и возвращают обрабтчику "мы сделали rsync, последний снапшт называется так-то, сделан тогда-то). Обработичик-1 задач записывает это куда-то к мне и ставит таске статус "готово". 2. Обработчик-1 выуживает из моей управлялки метаинфу по бэкапу, куда обращать, куда делать, что делать, создаёт инвентори и фигачит ansible-playbook с этим инвентори и соответствующей ролью. На хосте в итоге стоит только python или ansible agent (или как он там именуется) и настроены доступы. Обработчика-2 не существует. Однако. Код моего обработчика-2 влетает в плагины или роли ansible у обработчика-1.

я щас буду звучать так, как будто у меня акции saltstack :) но....

https://docs.saltstack.com/en/latest/topics/reactor/

документация у них говно. но. reactor у них для этого именно и сделан.

есть таски, по результату тасков можно засунуть event в message bus. на сей event можно повесить еще задачи.

Да это хер с ним. Проблема не в обработке и ловле. Проблема в сделать самому или взять ansible, где всё равно сделать самому. Или salt, где всё равно сделать самому

бизнес логику прийдется все равно делать самому, чтоб ты не взял.

Так скажем, вопрос уже за пределами t/e queue

вопрос в том, будешь ли ты еще сам делать то, что будет обрабатывать эту логику

или возьмешь что-то готовое.

У меня ступор в том, что я не понимаю - я вообще получу что-то от ansible/salt кроме двух трёх готовых библиотек типа хандлеров там и шаблонов, или легче просто сразу самому сделать

или не в этом вопрос?

самому не легче никогда, как мне кажется. Потому что сам - сам. Сам сделал, сам налажал, сам саппортишь.

а один хрен арзитекутуру я саппорчу

И я сейчас опятъ же о транспорте, а не о имплементации бизнес логики.

ну вот транспорт - хрен с ним

да вот как раз не хрен с ним :)

да хрен с ним. потока задач такого нет, чтобы просто табличка в MySQL не справилась и поллинг

потому что если есть уже устоявшийся транспорт - нахрена тебе топтаться по граблям, по которым уже прошли племена краснолицых?

и не будет даже на 10000 хостов

проблема - бизнес лдогику вкорячивать в ansible, или не трогать его вообще

а если его не трогать, куда вкорячивать бизнес логику?

ну илди в salt - в контексте не принципиально

а если его не трогать, куда вкорячивать бизнес логику?

его это кого?

его = salt, ansible, puppet, mcollective, fabric, …. шото готовое

а что оно для меня готовое? общение с последним хостом? возможность handle в отличии от make? красивый copy?

а это мне даст больше, чем изучение как плагин писать?

ERROR: S client not available

у меня нет ответа

готовое то, что тебе не надо думать как оно доедет до хоста, как делать обработки ошибок если оно не доехало и т.д. или я чего-то не понимаю в твоей задаче, или разница как раз в том - пишешь ли ты только бизнес логику, или еще и то, как эта бизнес логика будет доставляться, выполняться, и т.д.

сейчас это bourne shell скрипт о 15 строчках. я уже неделю какой-то звездолет изобретаю

сейчас это bourne shell скрипт о 15 строчках. я уже неделю какой-то звездолет изобретаю

Это интересный поворот :) если все работает скриптом в 15 строчек, то собсно… “работает - не трогай” не подходит? Или скрипт все же чем-то не устраивает?

Если скрипт надо заменить только потому, что “это ж ща круто и девопс” - я бы не трогал :)

Это интересный поворот :) если все работает скриптом в 15 строчек, то собсно… “работает - не трогай” не подходит? Или скрипт все же чем-то не устраивает?

он не сохраняет результата. он висит прямо на сервере. он не разделен на "синхронизировал", "проверил не хотят ли восстановления", "удалил край"

Если хочется написать что-то самому и сохранить контроль над всем. Fabric видел?

Я на нем в свое время написал взю нашу систему деплойментов. Работает как кирпич. Пока не придумали nomad :)

Задача стаяла воткнуть в него что-то кроме "сделай цикл снапшота". Ну я решил заодно универсализировать Task Queue и само исполнение. У меня там всё так, рано или поздо надо будет и апачи так же делать и бэкапы mysql, и вот это всё

Если хочется написать что-то самому и сохранить контроль над всем. Fabric видел?

нет. fabric.io?

Честно, я наверное не понимаю твоего душевного порыва, но я бы в любой такой задаче спросил себя сначала “кто уже такие проблемы решил и как” и выбрал бы путь наименьшего сопротивления. Написать самому для меня таковым не всегда (почти никогда) не явлается.

нет. fabric.io?

Не. http://www.fabfile.org/

Задача стаяла воткнуть в него что-то кроме "сделай цикл снапшота". Ну я решил заодно универсализировать Task Queue и само исполнение. У меня там всё так, рано или поздо надо будет и апачи так же делать и бэкапы mysql, и вот это всё

Сейчас у меня таблица в mysql, там номер сервера, статус исполнения, имя скрипта, 8 текстовых аргументов. На каждом сервере poll таблицы, что прилетело - запускается скрипт с таким названием и аргументами, по коду возврата - ok или error

Вот собсно fabric – набор отверток с мотором. Крути шо хочешь, но куда болты и куда шурупы - сам решай. И как и с какой скоростью тоже. Недо-ansible в своем роде.

Ой какая штука

если я все понял правильно - тебе должно подойти

няняня

Да мне и ansible подошёл бы. Вопрос насколько затратно для поддержки и разработки

Ее автора знаю лично - мега дядька :)

Ну вот я 5 лет назад на фабрик напоролся - мне хватило на много лет.

Ибо просто, minimal abstraction, удобно, и без каких-то мега изъебов с инфраструктурой вокруг.

Честно, я наверное не понимаю твоего душевного порыва, но я бы в любой такой задаче спросил себя сначала “кто уже такие проблемы решил и как” и выбрал бы путь наименьшего сопротивления. Написать самому для меня таковым не всегда (почти никогда) не явлается.

А разве мой вопрос не так звучал? :)))) Просто мне сложно переложить вопросы шареда на общепринятую терминологию. Но мне вроде удалось в итоге

Ибо просто, minimal abstraction, удобно, и без каких-то мега изъебов с инфраструктурой вокруг.

Похоже на то что надо. Потому что у мен иъёбы забиты в панель управления. И она там уже решает чо как.

А разве мой вопрос не так звучал? :)))) Просто мне сложно переложить вопросы шареда на общепринятую терминологию. Но мне вроде удалось в итоге

Я наверное biased, но я почему-то понял вопрос как “что выбрать из списка ansible, salt, puppet, whatever, или написать самому” :)

И как по мне - написать самому всегда плохой путь. Смотри на Алексея с вопросом как документировать написаное :) Если не сам написал, то там уже и документировано заодно :)

И как по мне - написать самому всегда плохой путь. Смотри на Алексея с вопросом как документировать написаное :) Если не сам написал, то там уже и документировано заодно :)

Ну понятно, что сделав уже два кастомных хостинга, я все время хожу по граблям - а как это поддерживать. Вот у меня скрипт юэкапа 2002 года с двумя изменениями

Хотя, по поводу fabric - word of warning. bitprophet (его автор) он похоже утратил все возможности его девелопить. Он время отвремени просыпается, педалит как не в себя, и уходит в спячку на год.

С другой стороны, он забрал себе maintenance paramiko (python SSH), автор которого по-моему совсем ушел из мира сего. по крайней мере в техническом смысле.

С третьей стороны, фабрик прост как двери и дальше там вобщем-то девелопить мало чего интересно.

Но меня он реально купил в свое время.

Ну и да. Пункт три - я хочу свою управлялку продавать. Типа ISPManager. Чтобы код не ставить

Например своим же клиентам