Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 3

Ох, сколько боли за этой! Я могу сказать, что "Variable precedence" делает практически невозможным разработку больших объемов Ansible кода. Вместо этого механизма, я бы предпочел жесткую инкапсуляцию переменных, т.е. полную невозможность для ролей или модулей использовать переменные, кроме тех, что переданы непосредственно.

Можно делать квазиинкапсуляцию, банально запуская ansible-playbook бинарник внутри других плейбуков, но это на столько грязно и беспомощно, что аж материться не хочется, а только лечь, обнять колени и плакать.

разрешите вопрос как эксперту?
Хотя возможно он относится не к переменным, а к инвентори (предыдущей статье), впрочем до этой статьи я их не особо различал

Есть у меня две таски два play:

1. запускает питон скрипт, который лезет в NMS, ищет неиспользуемые порты на всех коммутаторах и под каждый коммутатор создает host_vars со списком таких портов
2. заходит на каждый коммутатор и гасит все порты из списка

Так вот если объединить эти два плея в один плейбук, то он не работает:
1-й play наполняет инвентори как пложено, но 2-й play этот свежий инвентори не видит и ничего не делает.
Если запускать в разных плейбуках, то все работает как полагается
Похоже inventory вычитывается в самом начале плейбука и больше не перечитывается

Так вот вопросы:
Есть возможность как то сказать ансиблу чтоб он перечитал Inventory?
Допустимо ли создавать такие плейбуки или это bad-design без вариантов?

p.s. в итоге я на ansible забил и ушел на питон целиком

Нельзя использовать шаблоны в именах модулей, ключах словарей в переменных, именах переменных (которые по сути те же ключи).

Позвольте с этим не согласиться. Вот так работает. Но не уверен что стоит использовать.

- set_fact:
    var_{{ item.index }}: "{{ item.value }}"
  loop:
    - index: x1
      value: 'aaa'
    - index: x2
      value: 'bbb'
- debug: var=var_x1
- debug: var=var_x2

Может быть потому что факты — это переменные другого порядка :)

role/vars/ же используем для OS-dependent и для перевода человекочитаемых переменных в ansible-читаемые. типа предварительной фильтрации единого списка на два в зависимости от атрибута enabled/disabled

А вот зачем использовать vars: для отдельных тасков — это для меня совсем непонятно.

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

• play ансибловый — это русская плюха. Нарисовал такой плюху, и, хрясь ей по серваку/группе/всем узлам! Без тестирования. :) :D
• playbook, соответственно — набор плюх. А для граммарнаци и адептов английских терминов — плюхбук. :)

В момент, когда строковое значение передаётся как параметр 'msg' в модуль 'debug' (это не модуль, а action plugin, но для наших целей это не важно), строка {{ message }} прогоняется через шаблонизатор. Тот видит усы ({{ и }}) и заменяет их содержимым переменной message. Получается значение This is {{foobar }}. Дальше это значение прогоняется через шаблонизатор ещё раз получается This is {{ foo + "bar" }}. После ещё одного раунда тест становится This is foobar. После ещё одного раудна интерполяции текст не поменялся, т.е. интерполяция закончена. Получившаяся строка уходит в параметр msg модулю debug.

Что-то здесь не так. Я попробовал написать такое:

- debug:
     msg: '{{ message }}'
  vars:
    three_plus: 3 +
    message: '{% raw %}{{ {% endraw %}{{ three_plus }} 2 }}'

Согласно описанной в посте логике, значение message должно прогнаться через шаблонизатор ещё раз и в итоге выдать 5, но на практике получаем "msg": "{{ 3 + 2 }}" и никто ни на какие усы внимания не обращает.

Слишком доигрались с упрощёнными объяснениями?)

Или даже можно упростить пример:

- debug:
     msg: '{{ message }}'
  vars:
    message: '{% raw %}{{ 3 + 2 }}{% endraw %}'

Второго прогона шаблонизатора не случается и пятёрки тоже не случается.

Как раз начал ковырять ansible, статьи сделали все немного понятнее, спасибо. Однако, после знакомства с "переменными" у меня только один вопрос: что надо было курить чтобы родить подобное? Отдельно, кстати, порадовался поведению private_role_vars = true.

Вооружённые этим знанием мы уже можем попытаться догадываться, что за фигня происходит в этом коде:

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

- name: This is loop
  loop: '{{ groups.all }} as item'
      tasks:
        - name: Do not do this
          file: path=hello.txt state=touch
          vars:
            ansible_host: '{{ hostvars[item].ansible_host }}'

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

Жаль они не знают про major версии где смело можно забить на всё что есть и сделать нормально.

include_role

Я пока пришел к мнению что если воспринимать их как вызовы функций со своими параметрами (которые в данном случае стоит класть в vars/, а не в defaults/ чтобы исключить влияние внешних переменных (но не всех, да) и для которых кстати вроде есть PR который позволит явно указать список параметров), то всё вроде вполне неплохо и ожидаемо (и всяко сильно лучше чем, например, private_role_vars = true и dependencies у ролей...), но надо помнить что оно по сути создает новую изолированную область и, например, все "dependencies" будут вызваны еще раз, что далеко не всегда желательно.

ЗЫ: Удивляет как настолько кривая система стала популярной.