Если не делать странное, то и чего-то куда-то вставлять туда, где оно не нужно, тоже не придётся.

Это на уровне групп все делается.

По разным логическим группам прокатываются разные роли, к ним применяются разные переменные В одном хосте совмещается несколько логических групп Как элегантно отразить это в инвентори без занесения хоста в разные группы?

ну, а я о чем? зачем мне два инвентаря))) реально, перечитай весь тред!

Вы не понимаете, что вам пишут

"Есть многое на свете, друг Горацио, что не подвластно нашим мудрецам" это и ответ на ссылку на доки)))

Ты не хочешь чесать ЧСВ об участников этого чата. Вернее, тебя наверняка огорчит результат.

У вас для каждого нового хоста меняется количество групп, к которым он принаждежит? Или таки есть жесткая схема?

и 100% не использую два инвентаря. питон в руки!

Ответьте на вопрос

Я пишу плагины на питоне для Ansible там, где это действительно требуется. Мои деплои на прод и стейдж отличаются только значением параметра -i. Впрочем, разломаете свой прод - пишите.

ой. я деликатно замну тему. а то мы еще с вами где-то пересечемся и вам станет стыдно за это бряцанье. и не надо думать, что истина одна и всегда ваша) не обидел? надеюсь!

Если схема для каждого нового хоста не меняется, то все просто. Заносите в основную группу. Все остальное делается через вложенные группы.

Надо добавить, что окружений у меня не 2, а 100500: production, feature/*, нувыпоняли

Спасибо Ну, это в рамках "разные инвентори для разных окружений"? К сожалению, оно сюда не подходит Вот у меня несколько инвентори: пара динамических, один статический, ансибл ходит за ними в директорию, типа: -i inventories/ Динамические инвентори подвозят *срезы* по лейблам/тегам, проставленным на стороне провайдера То есть у меня инвентори это не дерево, а двумерная табличка: с одной стороны stage, с другой логическая группа Это удобно и вполне безопасно, если поставить защиту от человека на уровень, например, CI-системы: - в плейбуке прогоняем задачу по hosts: application - CI запускается всегда с --limit target_env В такой схеме всё хорошо, но статический инвентори писать очень стрёмно Надо отдельно добавить хост в правильное окружение и отдельно в правильную логическую группу Ход конём типа production > applciation > host1 тут не прокатывает т.к. группа application не дочерняя для production application/database/whatever это отдельный срез по функциональному признаку

У вас схема не самая удачная, судя по всему

В динамическом инвентаре элементарно на каждый хост при создании вешается нужный набор тегов

А при деплое просто группы инвентаря формируются динамически на основе этих самых тегов

@tgadiev , Вы упорно тянете меня в стан иерархичного инвентори) Всё, что сейчас сказали про динамику - так и работает, с этим никто и не спорит Просто у меня проблема не в том, как дерево правильно составить, а в том, что я вообще не хочу им оперировать Подход со стороны тегов/лейблов для меня в работе оказался гораздо более удобен Неудобно только когда внезапно отняли всю динамику и надо написать что-то статичное Ну, тут кря, буду страдать :) Спасибо за время!

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

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

Да, динамический работает долго, но там два уровня кеширования - локальный кеш и общий в etcd/consul/zookeeper Частичное обновление пока не подвезли, но так было бы вообще шоколадно, вы абсолютно правы

>тогда эдхук команды не идут Инвентори можно заинлайнить.

А, сори, выпал из вашей Санта-Барбары. :)

У меня другой вопрос созрел. Два варианта: 1. - hosts: all roles: - role: db-server when: role_db_server is defined И на нужных хостах определить нужную переменную. 2. - hosts: db-servers roles: - role: db-server И хосты в соответствующих группах. И так и так сработает. Не могу определиться, как оставить. Инвентори - статика, если что.

У меня другой вопрос созрел. Два варианта: 1. - hosts: all roles: - role: db-server when: role_db_server is defined И на нужных хостах определить нужную переменную. 2. - hosts: db-servers roles: - role: db-server И хосты в соответствующих группах. И так и так сработает. Не могу определиться, как оставить. Инвентори - статика, если что.

Я тут из двух вариантов выбрать не могу, а ты мне третий принес. Спасибо, блин. :)

У меня другой вопрос созрел. Два варианта: 1. - hosts: all roles: - role: db-server when: role_db_server is defined И на нужных хостах определить нужную переменную. 2. - hosts: db-servers roles: - role: db-server И хосты в соответствующих группах. И так и так сработает. Не могу определиться, как оставить. Инвентори - статика, если что.

Ну вообще такие штуки обычно в ansible_vault складываются - и всё.

Опять таки это один из примеров и получается дублирование, а если еще одна машина, то получается и её дублировать. На сколько дублирование является нормой на практике? А если IP-address изменится к примеру, то получается надо приучать себя пользоватся поиском, вместо заранее знать структуру инвентори

Ооо пока такая тема за inventory, а подскажите пожалуйста как быть если один хост должен быть в двух инвентори? (Ранее задавал вопрос, но малоли, еще интересные мысли услышу). К примеру есть лог хост на который происходит отправка логов. Есть два инвентори: production, staging. Лог сервер указан в production, но надо что бы staging виртуальные сервера отправляли логи в лог сервер. Как тут быть?

ip? а как он в инвентаре? он в ansible_host? или вот прямо так

делаешь variables с адресом твоего лог сервера и используешь ее в своем filebeat-е или что там у тебя

Та вроде все по правилам: log: hosts: mlog01: ansible_port: 22 ansible_host: "192.168.1.121"

да, но потом возникает вопрос "если поменяется ip") ответ: для независимости от ip используют или резолверы или динамически генерируемый инвентарь. т.е если где-то есть дублирование, то должен быть единый источник изменений. это или a-рекорд, или скрипт, порождающий инвентарь из единой базы

Хммм... по поводу А записи интересно, че то не додумался посмотреть в эту сторону, спасибо.

/etc/hosts - deploy on every hosts 😉 шучу

Я так делаю. Без шуток. hosts генерится из инвентори.