как собралось:)

угу если поменяешь порядок объявления групп то все может измениться

Ну да. И это фигово. Поэтому если хост один в двух группах, то лучше иметь разные переменные для него(названия)

ну вот гипотетитечкая ситуация. две группы, фронтенд и бекенд. есть роль деплой, которая деплоит в зависимости от значения переменной. хочу в одной группе target=frontend, в другой target=backend

а в плейбуке как-то так - hosts: frondend_group roles: - deploy

а оно может взять переменную из другой группы

я что-то делаю не так?

Да, переменная не может одновременно иметь два значения

Тогда тебе надо передавать в роль непосредственно эту переменную. roles: - { role: deploy, target: frontend }

мда, печально

если переменных много, это будет не очень удобно

разве что как-то так: [group1] host1 ansible_host=hostname [group1:vars] var=1 [group2] host2 ansible_host=hostname [group2:vars] var=2

но это как-то совсем костыль

Если переменных много и все сильно меняется, то стоит разделить один плейбук на два

Так как они выполняют разные задачи

программирование на конфигах. любимые грабли же.

Если переменных много и все сильно меняется, то стоит разделить один плейбук на два

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

программирование на конфигах. любимые грабли же.

ну это не совсем программирование. логики же нет в конфигах. так, параметризация..

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

Правильнее переменные для групп скидывать в group_vars/groupname.yml

ну так то же самое будет?

если один хост в двух группах окажется, то непонятно, какую переменную возьмёт?

Но конкретно твой кейс - применение переменной target кривое на мой взгляд

сделай 2 переменные is_frontend и is_backend

И тогда коллизий не будет

роль deploy сможет производить действия в зависимости от того, в какую группу входит хост и даже если входит в обе

ок, а если переменная например path

Тогда какова должна быть логика если хост входит одновременно в 2 группы?

во фронтенде path=/var/www, в бекенде - /opt

ну вот я решил на один хост и фронтенд и бекенд задеплоить, почему нет?

а на некоторые хосты только бекенд

Тогда тебе надо передавать в роль непосредственно эту переменную. roles: - { role: deploy, target: frontend }

ок, а если переменная например path

тогда frontend_path, backend_path и т.д.

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

что за упорное игнорирование неймспейсов (хотя бы и костыльных) и эти вечные попытки выстрелить себе в ногу?

тогда frontend_path, backend_path и т.д.

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

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

+1

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

тебе не кажется это как-то криво? у меня есть несколько групп и параметр, который отличается в зависимости от того, в какой группе хост. в us-west-dc днс один, в us-east-dc днс второй. логично положить его в переменную nameserver, которая в зависимости от группы хостов будет принимать разное значение

что за упорное игнорирование неймспейсов (хотя бы и костыльных) и эти вечные попытки выстрелить себе в ногу?

а что ты подразумеваешь под костыльными неймспейсами? я нихочу игнорировать их :)

> отличается в зависимости от того, в какой группе хост. в us-west-dc днс один, в us-east-dc днс второй. да но в данном случае отображение не взаимно однозначное. Если хост в двух группах, то у тебя этот параметр уже не определен однозначно. Таким образом, переменная это неподходящий способ передавать параметр

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

ну логично..

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

в общем для моего случая наверно как-то так надо, спасибо

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

Ты можешь даже эту роль дважды подключать в плейбуке. 1 раз если хост фронтенд, и второй раз если хост бэкенд

Будет 2 раза деплоиться у тебя

ну вот так и придётся делать

а если кроме плейбука деплой есть ещё и плейбук бекап, а ещё и плейбук мониторинг, то в КАЖДОМ плейбуке я должен буду определить переменную path. а так бы только в group_vars её вписал и всё ^^

но я понял, ок )

> а так бы только в group_vars её вписал и всё так бы - это как бы? Какого поведения ты хочешь добиться?

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

> а так бы только в group_vars её вписал и всё так бы - это как бы? Какого поведения ты хочешь добиться?

хочу чтобы в зависимости от группы, значение параметра различалось

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

да я вроде сформулировал..

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

хочу чтобы в зависимости от группы, значение параметра различалось

Это не формулировка. Какая зависимость конкретно? Что делать в случае если входит в 2 группы? У меня понимания не возникло.

Получается что да, в каждую роль надо вписывать чтобы убрать неоднозначность

завтра напишу ещё, если ты здесь будешь :)

буду

Чуваки, я туплю или нет? Есть таск docker_service, в дескрипшоне docker-compose, который собирает образ. Я поставил build: yes в надежде на то, что эта шняга будет пересобирать образ даже если он уже есть в системе.

а она не пересобирает

сука такая

и?

ты сказал ему recreate: always|never|smart?

гм, нет, не сказал

ща попробую

ну а если не сказал, то там NO по дефолту, почему сразу сука то )

там smart по-дефолту

если чо

ну ща проверю

сработало

ну а если не сказал, то там NO по дефолту, почему сразу сука то )

ты ж солнышко, спасибо тебе

А ансиблил кто фрисвичи? )

хочешь поймать рак мозга?

С чем?

с вышеуказанным)

С ансиблом? )

с фрисвичами)

Есть неудачный опыт?

У нас пока 2 года более-менее удачного

на мой взгляд эта софтина из разряда работает не трогай

Это астер

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

Всем привет. Пытаюсь заставить работать кейс с динамическими именами групп в хостах, и что-то не работает. Пример: - name: ... hosts: localhost connection: local tasks: - set_fact: timestamp="{{ lookup('pipe', 'date +%Y%m%d%H%M%S') }}" register: timestamp - name: ... hosts: "foobar-{{ timestamp }}" become: true gather_facts: true vars: ansible_ssh_key: "/tmp/id_rsa_{{ timestamp }}" tasks: - ...

Т.е. в первой части я работаю "локально" и поднимаю инстанс AWS, назначаю ему уникальную группу. Добавляю в инвентори в рантайме. Затем мне надо поработать с ним. Т.е. эту группу надо как то теперь указать в hosts

И вот переменная чет не шарится

Инвентори файла нету, точнее я его не использую т.к. писать туда особо нечего. Плейбук расчитан на один запуск - создание и уничтожение инстанса

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

Или я что-то не так делаю и это можно упростить?

надо динамик инвентори заюзать вроде как

и вроде как он из коробки есть для авс