Отчасти с Вами согласен, но это только и только в том случае, когда переменные там не ожидаются, так как уже применяются group_vars и часть логики в них. Добавьте сюда host_vars и переменные в плейбуках - вот уж где можно потеряться неподготовленному зрителю. Фактически так у нас до рефакторинга и было.
Мы же просто объединили group_vars и инвентори - теперь всё в одном месте и так стало прозрачнее и удобнее. В какое одно место мы могли бы еще всё свести? Решили в инвентори.
Мы не описываем новую всеобъемлющую методологию ведения проектов на Ансибл. Мы показали реальный кейс как сделать просто и в то же время оставить возможность роста и усложнения по мере необходимости.
Главная цель этого рефакторинга - сделать репозиторий понятным и удобным команде заказчика. У нас получилось. И да, у нас практически нулевое переиспользование переменных из инвентори, поскольку эти переменные либо относятся фактически к одной группе (а инвентори создан на эту группу), либо являются флагами для работы ролей.
Как бы мы изменили DNS на всех хоста? - в конкретно нашем случае dns мы меняем на dhcp-сервере, но в целом что-то глобальное меняется в базовой роли, а не в инвентори. Есть другой пример - раскатка файлбита. В инвентори мы указываем роль, что файлбит в принципе нужен и переменной определяем пресет, который уже заложен в роль. Добавить новый пресет - идем в роль. У роли в пресете, например, живет адрес эластика.
Я вас прекрасно понимаю, но сделать академически правильно и сделать просто и удобно - в данном случае оказалось разными вещами.
"Переменные в инвентори - это антипаттерн".
Отчасти с Вами согласен, но это только и только в том случае, когда переменные там не ожидаются, так как уже применяются group_vars и часть логики в них. Добавьте сюда host_vars и переменные в плейбуках - вот уж где можно потеряться неподготовленному зрителю. Фактически так у нас до рефакторинга и было.
Мы же просто объединили group_vars и инвентори - теперь всё в одном месте и так стало прозрачнее и удобнее. В какое одно место мы могли бы еще всё свести? Решили в инвентори.
Мы не описываем новую всеобъемлющую методологию ведения проектов на Ансибл. Мы показали реальный кейс как сделать просто и в то же время оставить возможность роста и усложнения по мере необходимости.
Спасибо за комментарий.
Главная цель этого рефакторинга - сделать репозиторий понятным и удобным команде заказчика. У нас получилось. И да, у нас практически нулевое переиспользование переменных из инвентори, поскольку эти переменные либо относятся фактически к одной группе (а инвентори создан на эту группу), либо являются флагами для работы ролей.
Как бы мы изменили DNS на всех хоста? - в конкретно нашем случае dns мы меняем на dhcp-сервере, но в целом что-то глобальное меняется в базовой роли, а не в инвентори. Есть другой пример - раскатка файлбита. В инвентори мы указываем роль, что файлбит в принципе нужен и переменной определяем пресет, который уже заложен в роль. Добавить новый пресет - идем в роль. У роли в пресете, например, живет адрес эластика.
Я вас прекрасно понимаю, но сделать академически правильно и сделать просто и удобно - в данном случае оказалось разными вещами.
Спасибо, что заметили опечатку! Поправил