Это действительно как то связано с тем, что корневой тег ссылается на один и тот же хост?

переменные на хост же апплаются

Дак проблема в том что я плейбук вызываю не для общей группы а для сабгруппы

Посмотри выше

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

Ок, положим что тут я прострелил себе ногу. Как тогда лучше решить проблему?

Хочешь чтобы кто-то вникал в твою кухню?

И не надеюсь :) Но малоли есть совет с наскоку

это же надо курить твой контекст, сам понимаешь

Понимаю, проблема не на уровне "сходи в гугл"

И не надеюсь :) Но малоли есть совет с наскоку

с наскоку - переменные по группам раскладывай

с наскоку - переменные по группам раскладывай

Так они ж уже в группах! 😂 В этом вся и проблема

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

Затык в том что хост один и тот же

с наскоку - переменные по группам раскладывай

=)

назови хост по-разному?

Это EC2 инстанс

mysql_stage ansible_ssh_host=1.2.3.4 nginx_stage ansible_ssh_host=1.2.3.4

назови хост по-разному?

inventory_hostname

Получается надо лезть в ec2.py патчить 😰

нет

А как тогда. Я IP адреса динамически получаю

у тебя там в плейбуках хостнейм выставляется так как ты его в ansible написал?

а.

tag_Kind_app_B_backend — это и есть "группа"

Амазоновский тег

inventory_hostname для хоста поменяй во второй группе

Каким образом?

Не совсем понял

в inventory file

А это вообще законно?)

ты мапишь Inventory_hostname на хост в инвентарии 2 раза на хост, хосты останутся прежними, inventory_hostname будут отличаться

Щас попоробую, сек

но я бы в целом пересмотрел подход, но попрообуй

[app_A:vars] inventory_hostname=app-A [app_B:vars] inventory_hostname=app-B ... Вот так не помогло

не так

А как?

Или к амазоновскому тегу?

к тегу

[tag_Kind_app_A] [tag_Kind_app_A:vars] inventory_hostname=app-A [tag_Kind_app_B] [tag_Kind_app_B:vars] inventory_hostname=app-B Вот так тоже непашетЪ

А оно точно по inventory_hostname применяет в конченом счете?

не так, чо у тебя так все запутно?

переменные групп в конце раскидываются какпеременные хоста. Утебя же есть хост, который состоит в 2х группах?

Ну вот то что выше это виртуальная группа, которая генерится с помощью ec2.py

Ее имя генерится из значения тега Kind в EC2

Т.к. Kind может быть записан через запятую, а ec2.py сплитнуть, в итоге создается две виртуальных группы которые назначены на один и тот же хост

с твоей схемой, как я ее понял: нужно прийти к тому, чтобы хост, который попадет в 2+ группы получал разный inventory_hostname в каждой группе

Ну это прямая дорога править ec2.py. Но это не так уж и страшно

Щас гляну что там назначается.

а ты зачем то пишешь в переменные группы "inventory_hostname"

а ты зачем то пишешь в переменные группы "inventory_hostname"

?

правь, чо

?

А, все

?

не ты?

У нас давно был взят ec2.py стандартный

Он вычитывает теги и вот работает таким образом

Я правда потом его уже патчил, добавил поддержку тегов для RDS

Которой небыло в официальной версии, так что пропатчить еще раз уже не проблема

карочи inventory_hostname это "псевдоним" хоста, по которому ансибл оперирует им

Понял, теперь понятно где отправная точка для правок, спасибо большое!

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

*имея два одинаковых...

Блин, ec2.py высирает след структуру { "_meta": { "hostvars": { "172.30.1.10": { } } }И вот что то мне подсказывает, что этот IP адрес и является inventory_hostname в данном случае, а так же contact_point'ом к инстансу

Это я так, брифово, что все хуево 😂

ну сдклай так, чтобы он генерил для второй группы другой inventory_hostname для того же айпишника

иначе логику плейбука перестраивать

у меня ec2 не было, конкретнее ничего не могу предположить

ну сдклай так, чтобы он генерил для второй группы другой inventory_hostname для того же айпишника

Я еще не тестил, но похоже все так и есть. Но для консистентности придется заводить дополнительные сетевые интерфейсы на инстансе под каждое приложение, потому что hostvars это хэш, а ключ это contact_point для инстанса, т.е. он должен быть доступен для ssh/

Т.е. в итоге чтобы не городить костылей, проще подсунуть ансиблу в итоге правильный инвентори как ты и предложил.

А т.к. внешники в Амазоне бесплатные пока ты их используешь то это вообще не проблема для меня

@korotovskii получается?

Ну я щас компаюсь в скрипте ec2.py и постепенно приходит понимание что ты был прав, да и вообще это стыкуется с идеологией асибла и моей разбивкой по группам. Просто видишь как они решили ИМХО неудачно взять идентификатор уникальности

амазон неудачно?

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

Я пока не могу сказать где конкретно ансибл решает что для ssh ему надо брать значение ключа из хэша hostvars

Так что ИМХО тут проблема ансибла, а лезть во внутрь и менять там что-то чтобы в ключ hostvars можно было положить любую ебанину, а ssh contact point забрать из атрибутов, только потому что я хочу упаковать пачку приложений на один хост это бред

Так что в этом случае логично просто "расширить" список значений в hostvars копией инстанса с другим IP адресом и все должно пойти своим чередом

(ну я так надеюсь)

проверить то просто на статичном inventory с разными inventory_hostname одинаковыми ip хоста в двух группах, имеющих одноименные переменные с разными значениями

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