😉

... И они перезатрут переменные из инвентори.

Если одноимённые - то да.

> Глупый вопрос: а переменные, определённые в roles/role1/vars/main.yaml видны в role2? (role1 и role2 назначены на один хост) не видны, собственно этого и хочется добиться, чтобы были видны

... Это не путь на тёмную сторону, это гигантская грабля, которую я час отлавливал, причём в режиме "variable is undefined", потому что соседняя роль в эту переменную писала имя несуществующей переменной.

касательно перезатирания, если вызывать роль внутри роли и передавать переменные непосредственно через vars, то все будет ок, перезатирания не будет.

Не, я про простой roles: [role1, role2].

Мой эксперимент показывает, что перезатирает. Дикий wtf.

> Глупый вопрос: а переменные, определённые в roles/role1/vars/main.yaml видны в role2? (role1 и role2 назначены на один хост) не видны, собственно этого и хочется добиться, чтобы были видны

После вызова роли переменные, которые эта роль загружала, так и остаются в словаре hostvars, если что. Никто ничего не удаляет. Соответственно, если такое же имя у переменной - упс.....

поэтому ввели конвенцию что роли имеют независимые переменные изначально)

Обожаю глобальные переменные и goto. Мне кажется, в ansible надо добавить поддержку goto на произвольную таску. /сарказм.

не хотелось бы плодить сущностей. Например две роли используют одни и теже пути

> Глупый вопрос: а переменные, определённые в roles/role1/vars/main.yaml видны в role2? (role1 и role2 назначены на один хост) не видны, собственно этого и хочется добиться, чтобы были видны

https://docs.ansible.com/ansible/latest/modules/include_role_module.html попробуйте директиву vars_from

которые объявлены в переменной

Обожаю глобальные переменные и goto. Мне кажется, в ansible надо добавить поддержку goto на произвольную таску. /сарказм.

tasks_from + теги животворящие чудеса творят 😉

пихать в all не хотелось бы

которые объявлены в переменной

Это переменная уровня inventory, не нужно выдумывать ничего.

Всё уже выдумано.

tasks_from + теги животворящие чудеса творят 😉

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

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

Безусловно имеешь право на своё мнение, это вот прям точно. Другое дело - помогает ли это мнение в работе или нет, но это вопрос риторический.

Безусловно имеешь право на своё мнение, это вот прям точно. Другое дело - помогает ли это мнение в работе или нет, но это вопрос риторический.

Интересно, а чем ансибл отличается от любых других тьюринг-полных систем? Традиционно считается, что глобальные переменные - зло.

Интересно, а чем ансибл отличается от любых других тьюринг-полных систем? Традиционно считается, что глобальные переменные - зло.

Отсутствием переменных, вот чем. Есть словарь hostvars, который притворяется "переменными" (это если прям технически точно выражаться).

Если бы у нас был "просто словарь", то я мог бы сделать a: '{{ a + 1}}'. А я не могу, ибо бесконечная рекурсия. А ещё сверху накручиваются приоритеты разных источников перменных, которые доставляют особое развлечение при include'ах.

Если бы у нас был "просто словарь", то я мог бы сделать a: '{{ a + 1}}'. А я не могу, ибо бесконечная рекурсия. А ещё сверху накручиваются приоритеты разных источников перменных, которые доставляют особое развлечение при include'ах.

Потому и не можешь (потому что словарь). Приоритеты описаны в доке. И там даже написано, что не стоит делать #странное, чтобы потом не задаваться вопросом "откуда же у меня загружается переменная x?" https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

... А потом роль с galaxy случайно объявляет твою переменную у себя в vars и....

... А потом роль с galaxy случайно объявляет твою переменную у себя в vars и....

Стянул роль из Galaxy, и сразу в production?

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

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

@Sergey Pechenko, а ты как решаешь эту проблему?

@Sergey Pechenko, а ты как решаешь эту проблему?

Опять не меня триггернул 😃

А по делу - знаю свой софт, переиспользую роли, роли с Galaxy использую как справочник, 5D игнорю.

Не пишу универсальные комбайны, которые на 17 ОС и 5 версий софта.

везет

а иногда приходится

... Уточни, пожалуйста, насчёт "знаю свой софт". У меня без "комбайна" в проекте примерно 100 разных приложений, 150 ролей. Мне аж интересно стало как это всё можно наизусть помнить.

А на счёт "не используй 100 приложений в одной плейбуке" - получается, что чем дальше в крупный софт, тем тяжелее проекты на ansible сопровождать. Особенно, когда над проектом работает несколько человек.

вот мы сейчас пишем проверку инсталяторов для Artifactory и там как минимум надо поддерживать Debian 8/9, Centos 6/7, RHEL 6/7/8, Ubuntu 14/16/18, а еще windows :)

... Уточни, пожалуйста, насчёт "знаю свой софт". У меня без "комбайна" в проекте примерно 100 разных приложений, 150 ролей. Мне аж интересно стало как это всё можно наизусть помнить.

У меня вот сейчас 14 ролей в проекте, в предыдущем было порядка 70 (там вдвоём писали). Все роли написаны максимально похоже, поддерживают 6 обязательных тегов, свои дефолты носят в role/defaults, и принимают параметры только тогда, когда это действительно нужно.

... А как вы достигаете отсутствия коллизий по именам переменных? role_name_{{uuid}}_{{var_name}} в имени каждой переменной? Никаких там 'local_address' или 'query_result'?

Что такое query_result? Это CURLом схожено куда-то в башсибле? 😉

Избегаю башсибла, опять же.

А на счёт "не используй 100 приложений в одной плейбуке" - получается, что чем дальше в крупный софт, тем тяжелее проекты на ansible сопровождать. Особенно, когда над проектом работает несколько человек.

мои апплодисменты

это гениально

ибо действительно сложность системы растет нелинейно

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

ибо действительно сложность системы растет нелинейно

Это да. Ну так для этого же и придумали отдельные окружения, и (хотя ты и не согласишься) идемпотентность.

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

Смотря как добавляешь? 😉

вот мы сейчас пишем проверку инсталяторов для Artifactory и там как минимум надо поддерживать Debian 8/9, Centos 6/7, RHEL 6/7/8, Ubuntu 14/16/18, а еще windows :)

а вы - JFROG? или просто некий аутсорсер или крупный айти?

Я весь внимание о том, как сделать два куска ансибла так, чтобы они могли работать вместе и не ломать друг другу ничего.

не использовать куски ансибла, а писать их все самому

но это сразу ад для мейтейнера

((((

Я весь внимание о том, как сделать два куска ансибла так, чтобы они могли работать вместе и не ломать друг другу ничего.

Я выше написал всё, что, на мой взгляд, поможет.

Не тянуть разное с Galaxy.

... А как вы достигаете отсутствия коллизий по именам переменных? role_name_{{uuid}}_{{var_name}} в имени каждой переменной? Никаких там 'local_address' или 'query_result'?

ты думаешь, что это только ансибловая проблема? )))))

Не тянуть разное с Galaxy.

только он тогда, извините, нахрен не нужен

ты думаешь, что это только ансибловая проблема? )))))

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

только он тогда, извините, нахрен не нужен

там же нет процедуры модерации, проверки годноты ролей и т.д.

ну, да, проблемы глобального состояния. Но ансибл - это не язык программирования (С)

там же нет процедуры модерации, проверки годноты ролей и т.д.

и что? а надо чтоб было

и что? а надо чтоб было

это опенсорс, PR в студию

😉

Я весь внимание о том, как сделать два куска ансибла так, чтобы они могли работать вместе и не ломать друг другу ничего.

149 roles 582 defaults 259 facts 3305 files 763009 lines

вырезка из ansigenome

очень, очень сложно сделать чтобы ничего не ломалось

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

assert + врапперы

немного помогает

но хотелось бы конечно больше

помогает еще бить по рукам за set_fact, прекоммиты, кодревью, именование переменных с префиксом по имени роли

your mileage may vary

помогает еще бить по рукам за set_fact, прекоммиты, кодревью, именование переменных с префиксом по имени роли

А чем плохо именование переменных с префиксом по имени роли? 🤔

наоборот хорошо

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

Ну если использовать как язык программирования - да, всё плохо. Но если не пытаться - то всё ок. Язык - Python, именно на нём надо писать плагины и модули, а не пытаться обойти ограничения существующих конструкций. Тут периодически LDAP делают на Ansible, было дело - и Git пытались. Но это же не повод всем так делать, и не значит, что это правильно.

Всё это описывается двумя словами: defensive programming.

А мантра "не язык программирования" странно контрастирует с всё новыми и новыми фичами языка программирования, которые появляются в ansible. block с секцией always, include_role, include_vars...

вот блок это для врапперов

149 roles 582 defaults 259 facts 3305 files 763009 lines

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

👍

Там, небось, большая часть - комменты в шаблонах.