Мониторинг рулит

смешно, да

Что?

Всяко лучше солта

и вообще смешно, и в этом проекте особенно

А кто-то уже пилит оркестрацию/cd на болте?

Не какой-то конкретный вопрос, а как оно вообще в сравнении с велосипедными решениями

@dk выдел что понаделал “спец от папета” у меня для клиента … С болтом пока ужасно. Есть некий реп с ютилами, в ютилы ложим болт таски (хотя они могут так же частью любого другого репа). После атача на клиент можно ранить таски на агенте. Как по мне - это что-то похожее на плагин мколектив по запуску команд на ремоуте с контроллера, но с улучшениями - теперь можно ранить не только команду но и скрипт на ремоуте. Протестировать еще не получилось - еще руки не дошли.

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

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

Это в choria точно можно

choria умеет запускать паппетные таски, та же хуйня с другим (более пиздатым) транспортом

У чории свои плейбуки есть

я думал, чувак их забросил в пользу тасок

буду посмотреть

но когда выбор между ебаным ямлом (я же правильно плейбуки помню) и относительно вменяемым языком, я особенно не думаю :)

было бы еще куда это приткнуть сейчас

неправильно ты помнишь

в ансибле плейбуки на ямлях

в чории на пупет дсл

о, переделал что ли?

тогда интереснее

не, судя по всему, я все перепутал. В бложике у чувака тоже ничего не нашел про плейбуки в ямле

https://choria.io/docs/playbooks/basics/ > The PLAYBOOK is a YAML file or Puppet Plan describing the tasks но других следов не нашлось

@dk выдел что понаделал “спец от папета” у меня для клиента … С болтом пока ужасно. Есть некий реп с ютилами, в ютилы ложим болт таски (хотя они могут так же частью любого другого репа). После атача на клиент можно ранить таски на агенте. Как по мне - это что-то похожее на плагин мколектив по запуску команд на ремоуте с контроллера, но с улучшениями - теперь можно ранить не только команду но и скрипт на ремоуте. Протестировать еще не получилось - еще руки не дошли.

Я только не понял - почему ужасно ?

Мне интересна идея планов для ролей (модулей), которые потом можно параметризованно дергать, типа bolt plan run myservice::update --param1=A --param2=B. А myservice - полностью описывающий сервис модуль, все в одной корзине. И это можно автоматизировать, написав, например, CD для теггированных коммитов, только нужно будет какой-то механизм запилить, который будет искать нужный модуль из чейджлога коммита в хиере/модулях.

@dkguest у меня проблема была с тестированием ) рдк проганяет толко линтировку, но вот если ты заюзал какие-то нативные штуки (переопраделил аунпут на свой собственный) но получиш кашу. Стало быть нужно потратить больше времени на ковыряние. Спе от паписа (может быть такой же как и я) запилил скрипт, а описание не оставил. Или есть модуль - но без тестов (имхо потом я их должен написать без ТЗ и документации ))) По описании - да, болт отличный тул. Рекомендую просмотреть последнюю конфу, где были примеры использования.

ну и тестирование болт тасков для меня все еще актуальна … Контрол репо, модуля и все такое - там rspec, onceover etc.

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

Author: Aleksei Mikheev <aleksei.mikheev@lazada.com> Date: Wed Oct 24 17:18:27 2018 +0700 Redefine sudoversion fact to workaround sudo segfaults saz-sudo module executes `sudo -V` to resolve `sudoversion` facts. Unfortunately, sudo segfaults (sic!) on AMI hosts when executed by root and sudo/sss integration is enabled. To workaround this problem, a **static** `sudoversion` fact is provided via `site/auth/facts.d/sudoversion`. It contains 1.8.6, the minimal version currently found across project's infrastructure. diff --git a/site/auth/facts.d/sudoversion.yaml b/site/auth/facts.d/sudoversion.yaml new file mode 100644 index 0000000..fe1c641 --- /dev/null +++ b/site/auth/facts.d/sudoversion.yaml @@ -0,0 +1,2 @@ +--- +sudoversion: 1.8.6 кажется, самый отвратительный хак в моей жизни

прекрасно!

но я б наверное сделал всё-таки проверку на амазон линукс

это тогда надо целый факт на рубях писать, и про has_weight помнить

на самом деле там почти сплошь амазон, и по паре тачек с бубунтой (ниибу) и центосью (новые инфрасервисы, типа паппета)

зачем? хуярь шеллом

там хуярить нечего. sudo -V сегфолтится, а писать два парсера для rpm и для dpkg на шелле - я хлебал

конфайнить такие факты нельзя же

вот и был выбор - либо по-честно с конфайнами написать еще один resolution для факта (и дебажить руби и ждать похожих проблем на других осях), либо быстро и грязно, накостылить под один проект без будущего

version-$(sudo -V) [[ $? == 139 ]] && version=1.8.6 echo sudoversion=$version

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

version-$(sudo -V) [[ $? == 139 ]] && version=1.8.6 echo sudoversion=$version

sudo -V - сегфолтится!

аааа

ну или через трап

норкоман, но годно

такой себе костылик

разве что из любви к искусству)