BS
потому что человека у которого куплен tower я не встречал
Size: a a a
2020 September 13
SM
это вообще разные вещи, я надеюсь ты сравниваешь паппет и awx
я ни с чем не сравниваю папет, потому что он ненужное в системе решето
BS
Ок задача мигрировать из Azure к примеру в гугл Cloud тоже докером )?
Я всё же предпочту Terraform + Ansible
Я всё же предпочту Terraform + Ansible
когда у тебя есть тераформ тебе пофигу какой провайдер
AS
это вообще разные вещи, я надеюсь ты сравниваешь паппет и awx
Зачем нужен awx если есть gitlab?
AS
когда у тебя есть тераформ тебе пофигу какой провайдер
Meh пацаны нас наебали это наброс. Расходимся
SM
потому что человека у которого куплен tower я не встречал
я встречал, но он тоже не особо нужен, если у тебя нормальный CI pipeline с деплоем ансиблом поверх тераформа
SM
Meh пацаны нас наебали это наброс. Расходимся
да не слушай ты его. он же троль:)
BS
немножко)
BS
но я все равно за стейт, паппет такое дает
SM
Ок задача мигрировать из Azure к примеру в гугл Cloud тоже докером )?
Я всё же предпочту Terraform + Ansible
Я всё же предпочту Terraform + Ansible
кста, в Pyventory уже есть экспорт и в тераформ vars, пока не GA и в реальности не использовалось, но оно типа работает. идея в том, чтобы дергать тераформ и ансибл с одними исходными данными, типа DRY
BS
мне неинтересно где эта нода и как к ней подключиться, я хочу чтобы она была в определенном состоянии и репортовала
W
кста, в Pyventory уже есть экспорт и в тераформ vars, пока не GA и в реальности не использовалось, но оно типа работает. идея в том, чтобы дергать тераформ и ансибл с одними исходными данными, типа DRY
я вобще тока щас про него услышал, сижу доку читаю пытаюсь понять зачем рон нужен
SM
мне неинтересно где эта нода и как к ней подключиться, я хочу чтобы она была в определенном состоянии и репортовала
в системах чуть сложнее чайника этот подход — путь в траты сотен тысяч баксов на "девопсов", которые будут всякое хитрое писать тебе в папет, что делает действия, реагируя на состояния, которые вызвыны другими действиями.
я лично мигрировал такое говно на ансибл с уменьшением LOC number в репе на два порядка
я лично мигрировал такое говно на ансибл с уменьшением LOC number в репе на два порядка
BS
ты прав, паппет на 1 проект не нужен
BS
но в 5м паппете это не в 3м, если у тебя уже есть описанная структура, это 0 трудозатрат
BS
я вот тут даже с kitchen посидел и мне понравилось
W
кста, в Pyventory уже есть экспорт и в тераформ vars, пока не GA и в реальности не использовалось, но оно типа работает. идея в том, чтобы дергать тераформ и ансибл с одними исходными данными, типа DRY
типа ансибл который знает текущее состояние сервера?
SM
я вобще тока щас про него услышал, сижу доку читаю пытаюсь понять зачем рон нужен
док пока мало, но они скоро будут с тутором нормальным.
основная идея — ты выкидываешь все инишники с группами и хостами, весь инвентори и пишешь всё на небольшом подмножестве Python, который становится твоим декларативным DSL. Там работает наследование, ленивое вычисление значений и есть абстрактные атрибуты. Ты его прописываешь в базовом классе, как
основная идея — ты выкидываешь все инишники с группами и хостами, весь инвентори и пишешь всё на небольшом подмножестве Python, который становится твоим декларативным DSL. Там работает наследование, ленивое вычисление значений и есть абстрактные атрибуты. Ты его прописываешь в базовом классе, как
NotImplemented и если оно потом не будет определено в наследниках и дойдет так до финального инстанса (хоста), то оно тебе прямо напишет, что и где ты не указал и выпадет без запуска плейбукаSM
типа ансибл который знает текущее состояние сервера?
не не не, вообще не о том. но! ты можешь такое провернуть на Pyventory, если в
hosts.py его как-то сам запросишь где-то и передашь в сгенерированный инвентори, а дальше ансибл может реагировать, как будто это его инвенториBS
а такой путь не будет стоить тонны времени?