Условный os_server возвращает критически важную информацию (uuid инстанса, который он только что запустил). Предложение никогда не смотреть на значения, которые возвращает модуль - утопия и шапкозакидательство.

Условный os_server возвращает критически важную информацию (uuid инстанса, который он только что запустил). Предложение никогда не смотреть на значения, которые возвращает модуль - утопия и шапкозакидательство.

Ну-ну. Теги же для слабаков, правда?

И dynamic inventory - тоже.

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

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

А setup ты техниченько обошёл. нет такого модуля, да?

А setup ты техниченько обошёл. нет такого модуля, да?

А ты исходники погляди :-))))))) Это фейк, обёртка.

Ты юлишь. setup это action plugin, но для нашего разговора "никогда не используй вовзращаемые значения модуля" это никакой разницы не играет. Есть масса _info модулей (официальная рекомендация в dev guide переименовать из с _facts на `_info`) - и ансибл полон таких модулей. Часть их них даже в base осталась.

Ты юлишь. setup это action plugin, но для нашего разговора "никогда не используй вовзращаемые значения модуля" это никакой разницы не играет. Есть масса _info модулей (официальная рекомендация в dev guide переименовать из с _facts на `_info`) - и ансибл полон таких модулей. Часть их них даже в base осталась.

Вот не надо "ля-ля". Почитай уже исходники. setup - модуль, ибо живёт в ansible/modules/system/setup.py, и выглядит как module = AnsibleModule( argument_spec=dict( gather_subset=dict(default=["all"], required=False, type='list'), gather_timeout=dict(default=10, required=False, type='int'), filter=dict(default="*", required=False), fact_path=dict(default='/etc/ansible/facts.d', required=False, type='path'), ), supports_check_mode=True, )

Если это плагин..... нутыпонел.

ты уходишь от вопроса про "не-использование возвращаемых значений". Кто их возвращает - модуль или плагин никакой роли не играет. register или не regsiter.

Вот не надо "ля-ля". Почитай уже исходники. setup - модуль, ибо живёт в ansible/modules/system/setup.py, и выглядит как module = AnsibleModule( argument_spec=dict( gather_subset=dict(default=["all"], required=False, type='list'), gather_timeout=dict(default=10, required=False, type='int'), filter=dict(default="*", required=False), fact_path=dict(default='/etc/ansible/facts.d', required=False, type='path'), ), supports_check_mode=True, )

хм. а что должно быть в /etc/ansible/facts.d ? yaml с фактами ?

хм. а что должно быть в /etc/ansible/facts.d ? yaml с фактами ?

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

хм. а что должно быть в /etc/ansible/facts.d ? yaml с фактами ?

Либо скрипт, либо yaml

Скрипт - исполняемый

ты уходишь от вопроса про "не-использование возвращаемых значений". Кто их возвращает - модуль или плагин никакой роли не играет. register или не regsiter.

Не ухожу - просто не использую, ибо нарушает идемпотентность.

https://medium.com/opsops/custom-facts-for-ansible-ade5f78d6d94

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

а как выключить не нашёл

Не ухожу - просто не использую, ибо нарушает идемпотентность.

Идемпотентность они не нарушают. Если у тебя что-то info возвращает только info и changed: false, то всё хорошо. Вот что они ломают - это нормальный check_mode, потому что ты уже не уверен что будет дальше без реального действия.

https://medium.com/opsops/custom-facts-for-ansible-ade5f78d6d94

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

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

Хороший вопрос. Ща посмотрю...

Только если ты эти значения в модуль передавать будешь. наверное, если туды lookup засунуть, то он исполнится. Но надо проверять.

Т.е по факту setup'а ничего плохого не будет. а вот если ты file path={{ansible_local.fact_name}} - то, наверное, может. Хотя 90% там !!unsafe.

Ладно, за параметры роли спасибо, по остальному не согласен. Но уже пора спать. /offline

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

Навскидку - тупо json грузится. С другой стороны, тот же вызов, например, consul-template туда сложить вполне можно.

Навскидку - тупо json грузится. С другой стороны, тот же вызов, например, consul-template туда сложить вполне можно.

впрочем там отдельный неймспейс. нужна сильно кастомная роль

впрочем там отдельный неймспейс. нужна сильно кастомная роль

Обычный. ansible_facts вроде

Вон Георгий пишет что оно будет в ansible_local: {}

Значит, я ошибся. Ткнул в исходники - точно, ansible_local.

Навскидку - тупо json грузится. С другой стороны, тот же вызов, например, consul-template туда сложить вполне можно.

Я ещё не заснул. Чтобы кастомный факт выполнился на хосте при его сборке надо chmod +x на него. А дальше любой код (хоть питон хоть бинарь на си) и json в stdout.

нее. я соображаю над атакой

очень очевидный вектор атаки. наверняка прикрыт

Только если его использовать. Джинжа ленивая. И может быть помечена unsafe, тогда не выполнится.

Google: !!unsafe ansible

ну факты они как бы нужны что бы их использовать

а на плейбуки типа кубспрей вполне можно целится

Кубспрей использует кастомные факты?

я вооще не знаю ни кого кто их использовал бы

Идемпотентность они не нарушают. Если у тебя что-то info возвращает только info и changed: false, то всё хорошо. Вот что они ломают - это нормальный check_mode, потому что ты уже не уверен что будет дальше без реального действия.

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

я вооще не знаю ни кого кто их использовал бы

На локале как минимум грузится json, причём loads

Вон Георгий пишет что оно будет в ansible_local: {}

Кстати, чтобы это стало обычными переменными, без неймспейса: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars

я вооще не знаю ни кого кто их использовал бы

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

^^^ 👍

я почему то не верю ноде.

Кстати, чтобы это стало обычными переменными, без неймспейса: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars

Кастомных это не касается.

и это не часть bizantine problem

я считаю что ноду могли поднять с бекапа.

и там может быть что угодно в фактах

или из снапшота

Кастомных это не касается.

Ну да, ну да..... # push facts to main namespace if C.INJECT_FACTS_AS_VARS: all_vars = combine_vars(all_vars, wrap_var(clean_facts(facts))) else: # always 'promote' ansible_local all_vars = combine_vars(all_vars, wrap_var({'ansible_local': facts.get('ansible_local', {})}))

Не, это решение другой проблемы. При сетапе надо ребуты и т.д. не глядя, а потом надо осторожно. Вот факт что продакшн мы ставим после начального сетапа. Получается очень кратко и надёжно.

так пацаны, я не понял. а почему все делают флаги для запуска сервисов и зачем они все их доблестно перечисляют в ExecStart= почему это по нормальному не делать через EnviromnetFile= в который положить ARGS= "--help" и написать ExecStart=/bin/myproga $ARGS

коллеги а я буду гореть в аду за when: item.when | bool ?

Bool это не то, что ты думаешь.

Bool это не то, что ты думаешь.

чой то ? и вообще ты спишь :)

коллеги а я буду гореть в аду за when: item.when | bool ?

Смотря какой страны у тебя паспорт

The following example sets values for two role variables of role2. role1 is used in the same way as the previous example. Any defaults and vars variables are overridden when role2 is used. --- - hosts: remote.example.com roles: - role: role1 - role: role2 var1: val1 var2: val2 Another equivalent YAML syntax which you might see in this case is: --- - hosts: remote.example.com roles: - role: role1 - { role: role2, var1: val1, var2: val2 } There are situations in which this can be harder to read, even though it is more compact. IMPORTANT Role variables set inline (role parameters), as in the preceding examples, have very high precedence. They will override most other variables. Be very careful not to reuse the names of any role variables that you set inline anywhere else in your play, since the values of the role variables will override inventory variables and any play vars.

Variable precedence can be confusing when working with role variables in a play. • Almost any other variable will override a role's default variables: inventory variables, play vars, inline role parameters, and so on. • Fewer variables can override variables defined in a role's vars directory. Facts, variables loaded with include_vars, registered variables, and role parameters are some of the variables that can do that. Inventory variables and play vars cannot. This is important because it helps keep your play from accidentally messing up the internal functioning of the role. • However, variables declared inline as role parameters, like the last of the preceding examples, have very high precedence. They can override variables defined in a role's vars directory. If a role parameter has the same name as a variable set in play vars, a role's vars, or an inventory or playbook variable, the role parameter overrides the other variable.

Они даже так пишут: You can pass different parameters in each role definition as: --- - hosts: webservers roles: - { role: foo, vars: { message: "first" } } - { role: foo, vars: { message: "second" } }(говорят 'parameters', пишут 'vars').

Это вроде как и есть параметры роли просто в yaml синтаксисе

- name: "Load environment variables!" shell: cmd: "source /etc/profile.d/maven.sh" почему после этого выдается ошибка в убунте? если тоже самое вставляешь в сам терминал то все ок

и на centos тоже все отрабатывает

ошибка такая fatal: [192.168.60.5]: FAILED! => {"changed": true, "cmd": "source /etc/profile.d/maven.sh", "delta": "0:00:00.002493", "end": "2020-11-06 23:05:38.537560", "msg": "non-zero return code", "rc": 127, "start": "2020-11-06 23:05:38.535067", "stderr": "/bin/sh: 1: source: not found", "stderr_lines": ["/bin/sh: 1: source: not found"], "stdout": "", "stdout_lines": []}

ошибка такая fatal: [192.168.60.5]: FAILED! => {"changed": true, "cmd": "source /etc/profile.d/maven.sh", "delta": "0:00:00.002493", "end": "2020-11-06 23:05:38.537560", "msg": "non-zero return code", "rc": 127, "start": "2020-11-06 23:05:38.535067", "stderr": "/bin/sh: 1: source: not found", "stderr_lines": ["/bin/sh: 1: source: not found"], "stdout": "", "stdout_lines": []}

Потому что в убунте /bin/sh - это симлинк к dash, у которого нет команды source И да, ансиболь здесь не при чем

Потому что в убунте /bin/sh - это симлинк к dash, у которого нет команды source И да, ансиболь здесь не при чем

что за /bin/sh ? откуда он взялася

я думал модуль shell просто вводит в терминал удаленной машины то что в кавычках, нет?

Ты не знаешь, что такое shell?

ansible.builtin.shell – Execute shell commands on targets - из справки ансибла

вот я и хочу чтоб он сделал ексекуте команд

У тебя нет базовых знаний

У тебя нет базовых знаний

каких именно

я думал модуль shell просто вводит в терминал удаленной машины то что в кавычках, нет?

Так, продолжай

каких именно

Загугли командный интерпретатор

Ему проще про оболочки загуглить

Загугли командный интерпретатор

ну bash там или zsh

Ему проще про оболочки загуглить

Оно следом пойдет

ну оболочка это типа программа которая обеспечивает cli

О, погуглил

но разница то в чем? ансибл же должен войти в систему и ввести команду

О, погуглил

я это знал

О, погуглил

Провал)