Так как я в настоящее время плотно погружаюсь в «чудесный» мир Ansible, то много читаю (и официальную документацию, да) статей по теме.
Недавно наткнулся на хороший цикл из трех статей от @amarao на Habr:
- Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон
- Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2
- Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 3
Они безусловно стоят того чтобы их прочесть внимательно (а также прочесть комментарии — там тоже изложены ценные мысли). Я выписал себе отдельно из них несколько тезисов которые планирую держать перед глазами при написании своих плейбуков и ролей.
Плейбуки и роли
- Не используй tasks и roles одновременно в play. Если play с ролями — для тасков лучше использовать pre_tasks или post_tasks.
- Роль — не функция! В нее нельзя передать параметры (не путать с переменными) и получить на выходе результат.
- Если у переменных роли должны быть дефолтные значениея — определяй их в defaults роли
- Избегай when — ansible task должен быть декларативным (и следовательно не опираться на предыдущие register)
- Если можно что-то красиво (без выкрутас) написать без хэндлеров лучше делать без них. Если красиво не получается — лучше с ними.
- Чем меньше if‘ов (явных или декларативных — в форме when или форме include_vars по набору переменных), тем лучше роль.
- Хотите строгой логики (программирования) — выносите ее в плагины, модули, библиотеки
Инвентори
- При работе с SSH, всегда (кроме спецслучаев) использовать ansible_host внутри которого IP-адрес. (Самый спорный тезис, имхо)
- Перменные в инвентори. Основной вопрос, который надо себе задавать: «почему эта переменная должна быть в инвентори»? Другими словами, инвентори — это специальное место для перменных, и вам нужны специальные причины записывать их туда.
Переменные
- Переменные разименовываются в момент интерполяции их в Jinja
- Не интерполируются ключи словарей на любом уровне вложенности yaml. Нельзя использовать шаблоны в именах модулей, ключах словарей в переменных, именах переменных (которые по сути те же ключи).
- Никогда не создавай перекрытие по именам между групповыми переменными (инвентори и плейбук), никогда не создавай перекрытия между hostvars , между инвентори и плейбукой.
Ну и, на последок, из того же источкника
Разумная таблица приоритетов переменных
- role/defaults — всегда проигрывает. Идеальное место для размещения переменных, которые надо переопределять. Дефолты ролей видны в соответствующих pre/post tasks.
- group_vars/all — переменные группы all наименее приоритетные
- group_vars/other_groups
- host_vars
- результат выполнения gather_facts: true (host_facts)
- Переменные уровня play
- Переменные уровня block
- Переменные уровня task
- set_fact/register. set_fact ещё и живёт дольше, чем плей (т.е. может передавать данные между разными play).
- -e побеждает всех и всегда.
Ну и хорошее напутствие — «Пишите просто, пишите красиво. Сложно и некрасиво не пишите» 🙂
