Нас тут с прошлого моего вопроса раза в два большге стало. Напомните, а что плохого в LXD 2?

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

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

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

мы переехали на saltstack для всех целей, как CM, так и orchestration

точнее переезжаем :)

мы переехали на saltstack для всех целей, как CM, так и orchestration

почему ?

почему saltstack, а не ansible?

да

и с чего ?

с паппета ?

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

почему.. та хрен его знает на самом деле. лично у меня ansible с SSH как транспорт вызывает седение волос в местах, где они седеть не должны в таком возрасте.

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

плюс 0mq он, скотина, быстр. очень. хоть и нет guaranteed message delivery

Собственно я сейчас разрываюсь: 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, …. шото готовое