Скажите когда на salt придет пора переходить ;)

Пятница? Давайте, я вам ещё про reusable roles вброшу. https://medium.com/opsops/non-reusable-roles-9f55230bd60f

А чо толку то? Переписать его на расте не кому

Скажите когда на salt придет пора переходить ;)

Он тоже не оч

В принципе, за 6 лет изучения мне не хватает только одной точки интеграции - я хотел бы загружать свои функции в Jinja. Половина вычурной срани из шаблонов просто исчезла бы, и стала нормальными dict/list comprehensions в питонячьем коде.

В принципе, за 6 лет изучения мне не хватает только одной точки интеграции - я хотел бы загружать свои функции в Jinja. Половина вычурной срани из шаблонов просто исчезла бы, и стала нормальными dict/list comprehensions в питонячьем коде.

>хотел бы загружать свои функции в Jinja Вообще можно

В принципе, за 6 лет изучения мне не хватает только одной точки интеграции - я хотел бы загружать свои функции в Jinja. Половина вычурной срани из шаблонов просто исчезла бы, и стала нормальными dict/list comprehensions в питонячьем коде.

Это можно же

Это можно же

Ну не фильтры, а прям чонть отбитое.

>хотел бы загружать свои функции в Jinja Вообще можно

Кроме фильтров - как?

Пока нет изоляции, нельзя получить нормальный dry.

Ну не фильтры, а прям чонть отбитое.

У меня в ноке был тег {{python}}

Пока нет изоляции, нельзя получить нормальный dry.

Она нинужна, иначе - ад.

Правда в джанго темплейтах но не думаю что сильно сложнее

Пока нет изоляции, нельзя получить нормальный dry.

Как мог бы выглядеть дизайн такой канители?

У меня в ноке был тег {{python}}

Сама по себе это не проблема - вгрузить функцию в глобальный контекст Jinja. Проблема в другом - куда её положить, чтобы автозагрузчик нашёл, и чтобы джинджа-контекст был доступен.

Она нинужна, иначе - ад.

С изоляцией ад, без изоляции ада нет. Не пояснишь?

Кто-то работал с инвентори плагином для Ажура? Как сделать так, что бы если в tag к виртуалке велью разедлен, например, запятой, в инвентори создавались две группы вместо одной?

Если бы я дизайнил роли, то у меня были были бы vars/global.yaml и vars/local.yaml, и локальные переменные за пределами роли были бы недоступны. То же самое касалсь бы register_local и т.д.

С изоляцией ад, без изоляции ада нет. Не пояснишь?

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

Ты просто не понял о какой изоляции речь. Не хоста от хоста, а роли от роли.

Всем привет, ребят может у когось есть мануал как Ансиблом установить docker и на него поставить Apache

...

Я учусь если что )

Ты просто не понял о какой изоляции речь. Не хоста от хоста, а роли от роли.

Зачем? Чтобы поощрять плохой выбор переменных и отсутствие явной передачи параметров в роль?

Всем привет, ребят может у когось есть мануал как Ансиблом установить docker и на него поставить Apache

взять готовую роль взять готовый образ наслаждаться

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

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

block: vars: ip: 0.0.0.0 Валидно

Ну можешь динамически его каждый раз составлять

- name: "find files" find: paths: "archives/" recurse: true patterns: "*zip" register: "files"

Ну сорт оф, а там в files['files'] будут файлы, у каждого есть path

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

Тебе, скорее всего, требуется кастомная реализация VariableManager.

block: vars: ip: 0.0.0.0 Валидно

До тех пор, пока кто-то set_fact/register с таким же именем в соседней роли не сделал

До тех пор, пока кто-то set_fact/register с таким же именем в соседней роли не сделал

Это костыль, просто не надо этим пользоваться. Тогда и про отсутствие идемпотентности плакаться не придётся.

Это костыль, просто не надо этим пользоваться. Тогда и про отсутствие идемпотентности плакаться не придётся.

+

Не используйте переменные. Особенно в register, да?

Register не только для when используется, кстати.

Не используйте переменные. Особенно в register, да?

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

Если рядом с вызовом роли явным образом записаны её параметры - нувыпонели. Хоть заперекрывайся.

Ты о чем вообще? Если у нас две независимые роли, а у одной переменная ip в vars, а у другой в defaults, что нас ждёт на выходе?

@amarao про https://amarao-san.livejournal.com/3471918.html я для нока притащил тестирование плейбуов не смотря на сопротивление автора

Ты о чем вообще? Если у нас две независимые роли, а у одной переменная ip в vars, а у другой в defaults, что нас ждёт на выходе?

в vars

это предсказуемо

Ты о чем вообще? Если у нас две независимые роли, а у одной переменная ip в vars, а у другой в defaults, что нас ждёт на выходе?

Нету у ролей выхода, кроме состояния целевой системы. Ансибл - не язык программирования. Внутри роли будет её значение.

Если одна роль сделает set_fact или register, это перекроет переменную другой роли. Даже если эта переменная не планировалась для exposure и была использована в переменных таски.

@amarao про https://amarao-san.livejournal.com/3471918.html я для нока притащил тестирование плейбуов не смотря на сопротивление автора

чо я не успел сделать так это что бы исходником для плейбука был исходный sql дамп. но это в целом пофиг

Если одна роль сделает set_fact или register, это перекроет переменную другой роли. Даже если эта переменная не планировалась для exposure и была использована в переменных таски.

только корректный нейминг и ничего более

Я знаю как с этим жить. Но это не отменяет того, что если бы переменные можно сделать локальными, то жить было бы легче

это значительно повысит требования к разработчику плейбука

особенно тяжело будет сетевикам (с)

Если одна роль сделает set_fact или register, это перекроет переменную другой роли. Даже если эта переменная не планировалась для exposure и была использована в переменных таски.

Не может перекрыть vars/

Может.

https://docs.ansible.com/ansible/2.5/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

set_fact имеет выше приоритет, чем vars роли, здрасьте

Именно там и написано. RTFM, как говорили в моей молодости.

Да, не туда посмотрел (cached set_facts).

Я только что проверил ещё более ужасную вещь. Если у одной роли foo в vars, а у второй в defaults, то обе наслаждаются значением из vars. Даже если обе роли не планировали expose значений.

Только вот незадача насчёт параметров роли, о необходимости использования которых я писал: они перекрывают всякие register, set_facts и прочие неидемпотентные поделия.

cat ./role1/defaults/main.yaml --- foo: 1 cat ./role1/tasks/main.yaml --- - debug: var=foo cat ./role2/vars/main.yaml --- foo: 2 cat ./role2/tasks/main.yaml - debug: var=foo cat ./play.yaml --- - hosts: localhost gather_facts: false roles: - role1 - role2Вывод - 2,2

И?.....

И если две роли случайно не зная про друг друга назвали переменную одинаково (и не планировали её к использованию за пределами роли), то случится ... казус.

Сюрприз, set_fact побеждает параметры роли.

Сюрприз, set_fact побеждает параметры роли.

issue в студию

cat ./role1/tasks/main.yaml --- - set_fact: bar: role cat ./role2/tasks/main.yaml --- - debug: var=bar cat ./play.yaml --- - hosts: localhost gather_facts: false roles: - role: role1 - role: role2 vars: bar: params

Никакого issue, по ссылке же сказано, что facts и register побеждают всё, кроме -e

issue нет, wtf'а полные штаны.

Хотя нет, ты прав. Они утверждают, что role params побеждают. Но это не так, и я всегда считал, что facts побеждают всех (как оно и есть)

Я сейчас поигрался, только include_role/vars имеет больший приоритет, чем факты. (Что добавляет ЕЩЁ один слой WTF'а). И я понял за что я ещё больше не люблю include'ы.

(перепроверил - в 2.10 так же). Enjoy your Ansible. It's better than Covid.

Хотя нет, ты прав. Они утверждают, что role params побеждают. Но это не так, и я всегда считал, что facts побеждают всех (как оно и есть)

Не мути воду, записывай role params правильно :-)

--- - hosts: localhost gather_facts: false roles: - role: role1 - role: role2 wtf: true - hosts: localhost gather_facts: false

Без ключевого слова 'vars'

Так можно? Я такой формы никогда не видел. Проверю как освобожусь.

Можно. Именно это и есть role params.

Ну и вот это вот: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-private-role-vars

Enjoy your Ansible responsibly :-)

https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#passing-different-parameters а это тогда как понимать?

https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#passing-different-parameters а это тогда как понимать?

С трудом :-))))) Я тоже ведь не сразу нашёл, о чём именно речь.

хах, а в старых доках именно такой, как ты указал формат https://docs.ansible.com/ansible/2.5/user_guide/playbooks_reuse_roles.html#using-roles

Но вообще начал вот с этого: https://github.com/ansible/ansible/issues/69388. Один-в-один issue. Я прост знаю, что ансибл писали и пишут достаточно умные люди (bcoca, в частности).

хах, а в старых доках именно такой, как ты указал формат https://docs.ansible.com/ansible/2.5/user_guide/playbooks_reuse_roles.html#using-roles

Ну да, доку чот испортили.

22:47 пятницы. самое время написать что нить на ансибле