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

Потому что отбор хостов из всего инвентори делается через "hosts: group_foo", Карл, понимаешь? Через hosts!

Только если названия хостов подпадают под паттерны. А если нет, то остаётся оперировать только на уровне названий групп, что очень удобно, когда в хостс файле более сотни хостов. Но если у вас весь хостс на 10 строк, то да

Например есть роль запускающаяся на группе kubernetes (подгруппы masters и nodes). В роли есть такси которые нужны на мастерах но не на нодах. Тут удобнее через #странность

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

Так в чем конкретно странность? В простом и понятном использовании переменной, доступной в ансибле? Или потому что в доке об этом ни слова?

А можете на более техническом уровне, нежели «странно», распедалить? Что там есть настоящего? Например, в случае when: ansible.inventory_hostname in groups будет выполнено по лишней пачке команд на каждый хост в плейбуке. В отличие от «лишней группы», когда оно выполнится ровно столько раз, сколько нужно, и ни одного больше.

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

Любой говнокод имеет право на существование.

Любой говнокод имеет право на существование.

Кстати, оверхедов на создание групп нет никаких

Только бессмысленно по нему задавать вопросы :-)

Просто не первый раз картина, приходит человек, спрашивает, как правильно подпереть тут веточкой, ему сразу говорят, что он делает херню, и он грустный уходит. Он не получает понимания, почему то, что он делает, херня. Не получает понимания, как правильно и, главное, почему правильно именно так. Возникает ощущение, что попал в снобарий, хлебнул говна и ушёл вон.

ну, всё-таки есть. увеличивается время чтения инвентори биоинтерфейсом

Там где-то далеко наверху - да. Но человек же приходит и задаёт вопрос, а не начинает читать всю историю. Может, копипасту заготовить, или теги расставить.

На сколько микросекунд?

Скоро допилю наш стайлгайд и ещё раз дам ссылку

it depends. довелось видеть достаточно кудрявые инвентори и напряжённо разбираться, куда именно что катится плейбуком. слишком много групп — тоже такое себе

Время тратится на проход по хостам и сбор фактов. Количество групп на хост роли почти не играет

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

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

Скажи - с внешним классификатором

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

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

Вы слишком шаблонно мыслите. Далеко не все наборы провиженинга должны быть универсальны для всего и на любом окружении. Внезапно бывают еще и узконаправленные, в рамках некой архитектуры и которые не будут выноситься в опен сорс. И да, там тоже нужны роли. И да, в них можно (а иногда даже нужно) хардкодить привязку по наборам параметров

Можете объяснить - зачем делать роли, которые не предполагается переиспользовать и переносить между окружениями?

Я хотя бы этим могу оправдать. Условно, есть какие-то роли, которые разрабатывает отдельный человек. Или команда. И есть человек, который их интегрирует. Или предлагаете плейбуками интегрироваться ?

Говорят лохматые бабушки просто в тренде ;)

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

Написанное выше: > Внезапно бывают еще и узконаправленные, в рамках некой архитектуры Предполагается, что плейбуки/роли никогда не будут выноситься за рамки данной архитектуры

кого его?

То что разраб наговнякал - плейбук или роль

То что разраб наговнякал - плейбук или роль

Зачем тогда нужны роли - можете объяснить?

аналогия - роль - "битлиотека", плейбук - "пользовательский код", и всякие варз - конфигурация.

А вы предлагаете все сразу в плейбук валить? Или как это должно выглядеть?

если перенос не нужен, то один толстый плейбук можно разбить на поменьше.

А вы предлагаете все сразу в плейбук валить? Или как это должно выглядеть?

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

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

Роли нужны для специфичного софта/сервисов/бутстрапов, коих может быть несколько десятков. Описывать все в одном плейбуке с вариативностью по хостам и группам - это имхо, очень тупо. В таком случае плейбук содержит только хост/группу и набор ролей, а в ролях частично используется логика “применять некий таск или пропускать” в зависимости от хоста