Комментарии 7
Достаточно оригинальный вызов ролей. Мне понравилось. :)
Но со многим не согласен. Особенно с формурировкой что заказчик хотел экономить время.
Вот такая структура:
├── group_vars/
│ └── all.yml — файл номер 1
├── inventories/
│ └── yandex/
│ └── nexus.yml — файл номер 2
говорит ни о чем ином, как о том что у вас нулевое переиспользование переменных. И все переменные плоским перечислением лежат в одном файле и все группы плоские.
Такая конфигурация супер удобная... до того момента когда вам не придется её редактировать.
Когда вам нужно будет изменить настройки предположим DNS на всех хостах (тривиальный пример, практический рефакторинг может быть гораздо сложнее), вы будете делать это в 100 файлах!
А что будет если инстансов будет 1000? Будете писать "плейбук" который редактирует 1000 инвентори? (Это грустная автоматизация, редактировать структуры в ямлах не затрагивая комментарии и форматирование используемое вокруг. Сам таким, бывало, занимался не от хорошей жизни - не рекомендую.)
Кажется что вариант с наследованием настроек через группы выглядел бы чище. Только действительно нужно строго следить за тем чтобы группы покрывали строго одну понятную из её названия сущность. Чтобы потом не искать: где-что.
Кстати у вас избыточность: hostvars[inventory_hostname].group_roles
У вас group_roles объявлена в скоупе конкретного хоста и таску в play вы запускаете над этим же хостом, достаточно group_roles.
Мне показалось что тут как раз два уровня переменных: общие переменные а group_vars/all.yml и переменные в инвентаре.
Спасибо за комментарий.
Главная цель этого рефакторинга - сделать репозиторий понятным и удобным команде заказчика. У нас получилось. И да, у нас практически нулевое переиспользование переменных из инвентори, поскольку эти переменные либо относятся фактически к одной группе (а инвентори создан на эту группу), либо являются флагами для работы ролей.
Как бы мы изменили DNS на всех хоста? - в конкретно нашем случае dns мы меняем на dhcp-сервере, но в целом что-то глобальное меняется в базовой роли, а не в инвентори. Есть другой пример - раскатка файлбита. В инвентори мы указываем роль, что файлбит в принципе нужен и переменной определяем пресет, который уже заложен в роль. Добавить новый пресет - идем в роль. У роли в пресете, например, живет адрес эластика.
Я вас прекрасно понимаю, но сделать академически правильно и сделать просто и удобно - в данном случае оказалось разными вещами.
редактировать структуры в ямлах не затрагивая комментарии и форматирование используемое вокруг
У нас такая автоматизация есть. Пакет yaml для Node.js умеет читать и обновлять ямлы, не разрушая структуру. Он загружает файл как DOM-дерево (не путать с HTML DOM), а потому не трогает ни форматирование, ни комментарии, ни пустые строки в тех узлах, которые не были обновлены. Думаю, что для питона и других языков должны найтись похожие библиотеки.
Стоило ли так упрощать, сводить всё в одному плейбуку и к переменным только в инвентори?
Совершенно не кажется упрощением. И даже наоборот - это усложнение. Выглядит так, что мухи от котлет отделены таки были, но затем измельчены и перемешаны в однородную массу. В ходе рефакторинга были причесаны переменные и вынесены в инвентори. Кажется, было вполне достаточно только первого.
Переменные в инвентори - это антипаттерн, которого следует избегать. Инвентори должен содержать только настройки подключения и групп. По сути получается хордкод переменных и ролей в одном файле, что потенциально усложняет его поддержку и развитие. Относительно простая роль может содержать десятки переменных, которые должны быть заранее определены для каждого хоста/группы только в инвентори без возможности использования каких-то условий. Сами переменные не равнозначны между собой (для этого с самого начала и придумали их приоритет group_vars/host_vars/roles_defaults/roles_vars) и поэтому переопределение - самый лучший путь.
На всякий антипаттерн найдётся кейс где именно так получается лучше. У меня часто в инвентаре одна группа с небольшим количеством хостов и переменных. Я тоже сначала делил это на файл с хостами и отдельно group_vars, но со временем решил, что это избыточно.
"Переменные в инвентори - это антипаттерн".
Отчасти с Вами согласен, но это только и только в том случае, когда переменные там не ожидаются, так как уже применяются group_vars и часть логики в них. Добавьте сюда host_vars и переменные в плейбуках - вот уж где можно потеряться неподготовленному зрителю. Фактически так у нас до рефакторинга и было.
Мы же просто объединили group_vars и инвентори - теперь всё в одном месте и так стало прозрачнее и удобнее. В какое одно место мы могли бы еще всё свести? Решили в инвентори.
Мы не описываем новую всеобъемлющую методологию ведения проектов на Ансибл. Мы показали реальный кейс как сделать просто и в то же время оставить возможность роста и усложнения по мере необходимости.
Infrastructure as Code на практике: как мы рефакторили сложный Ansible-репозиторий