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

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

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

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

сейчас это 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. Чтобы код не ставить

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

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

Слушай, а вы же докеры используете ?

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

останется по факту управления нодами пользователи\пакеты\шипинг логов. А тут как бы по факту пофигу уже, ssh там трансорт или какой то быстрый. не ?

Или вы используете salt аля как fabric ?

Мы его используем и так и так. Конфиг менеджемент, оркестрация. Докеры мы только начали пользовать, и я так понимаю с адаптацияй уйдет куча менеджмента конфигов. С другой стороны, перенос конфигурации в докерфайлы мне пока что видится как децентрализация конфигурации, что с собой ведет проблемы peer reviews и всего прочего.

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

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

только не в докерфайлах, а компоузах

в итоге я ансиблом раскатываю компоузы в основном

Докер кажется что мало смысла имеет там где базы данных

Если у тебя всё в докере, а бд не в докере это неконсистентно

но да, конкретно в случае с БД чисто от докера профита немного

База данных в докере мне пока что непонятна. Не то, что как - зачем?

Например чтобы одним компоузом поднимать всё приложение целиком

например на машине девелопера

Это да. А прод?

Докер в проде это вообще takoe

Я вот в деве-то с ним трахаюсь перманентно

Мы в проде юзаем на ура. Для микросервисов. А вот все что связано с данными... я пока не понял как и боюсь :)

А для сервисов связка nomad + docker нас радует ужасно

у Никиты какие то проблемы с Номадом были

У всех с ним проблемы. Он сыроват, но хаши принцип меня тоже купил. Равно как и Го.

Мы в проде юзаем на ура. Для микросервисов. А вот все что связано с данными... я пока не понял как и боюсь :)

имхо да и ненужно базу в докер пихать

Вот и мне так кажется.

Особенно там, где RDBMS & single master concept.

скажем так, что работа с персистентными данными и их перемещение вместе с интснатсами проблема.

А без докера не проблема? :)

без докера нет желания двигать )

Ну началось

Без докера проблема понятна. Докер с идеологией "инстанс непостоянен" не вселяет в меня понимания как это реализовать.

персистить данные на внешних томах

есть же решения типа flocker

ручками связывая это с label контейнеров и label volume контейнеров

можно наверно с этим как то управляться

Можно наверное. Вопрос только -зачем?

Семен троль )

Што опять? :)

У меня бд в докере

Если что

Show us, how big your data is

а

Чувак скорее всего Иранец

они странные

Show us, how big your data is

Моя мама всегда говорила, что размер - это не главное.

Мама про размер? Фуууу

Обычно это говорят на всяких ток-шоу про пиписьки

пошловато :)