Назад | Перейти на главную страницу

Переменная Ansible не определена, если не задана по умолчанию

Я пытаюсь добавить новую переменную в существующий репозиторий git, полный файлов Ansible, которые интенсивно используют роли. Так что где бы foo упоминается ниже

vars_files:
   - vars/aws.yml
   - vars/aws-credentials.yml

Я добавил новую строку

   - vars/rpm-repo.yml

и я создал vars/rpm-repo.yml с содержанием:

---
yum_rpm_dir: https://example.com/repo/noarch

который является допустимым YAML в соответствии с командой, указанной в этот ответ для проверки, является ли файл допустимым YAML.

И в roles/foo/tasks/main.yml Я сменил yum задача установить это:

name: "{{ yum_rpm_dir }}/rest-api-{{ rest_api_version }}-1.noarch.rpm"

(Цель этого явного URL-адреса - исправить ошибку в нашем репозитории RPM.)

Но я получаю:

fatal: [1.2.3.4]: FAILED! => {"failed": true, "msg": "'yum_rpm_dir' is undefined"}

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

Итак, я скопировал файл выше в roles/foo/defaults/main.yml также.

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

tl; dr: Как правильно установить переменную в Ansible, чтобы ее могла подобрать роль?

Вы не указываете, какая версия ansible это тот, который вы используете, и есть важные изменения с 1.x на 2.x.

Из он-лайн документации, ответ на

Как правильно установить переменную в Ansible, чтобы ее могла подобрать роль?

было бы:

В 1.x приоритет выглядит следующим образом (последние перечисленные переменные имеют приоритет):

  • «Значения по умолчанию для ролей», которые теряют приоритет по всему и их легче всего изменить
  • переменные, определенные в инвентаре
  • факты, обнаруженные о системе
  • «Почти все остальное» (параметры командной строки, используемые переменные, включенные переменные, переменные роли и т. Д.)
  • переменные подключения (ansible_user и т. д.)
  • дополнительные вары (-e в командной строке) всегда выигрывают

В 2.x порядок приоритета более конкретен (последние перечисленные переменные имеют приоритет):

  • значения по умолчанию для роли (Задачи в каждой роли будут видеть значения по умолчанию для своих ролей. Задачи, определенные вне роли, будут видеть значения по умолчанию для последней роли)
  • Переменные инвентаризации (переменные, определенные в файле инвентаризации или предоставленные динамической инвентаризацией)
  • инвентарь group_vars
  • инвентарь host_vars
  • playbook group_vars
  • playbook host_vars
  • факты о хозяине
  • играть в вары
  • играть vars_prompt
  • играть в vars_files
  • зарегистрированные вары
  • set_facts
  • роль и включить вары
  • блочные вары (только для задач в блоке)
  • переменные задачи (только для задачи)
  • дополнительные вары (всегда имеют приоритет)

Ответ на ваш конкретный вариант использования требует, чтобы вы указали местоположение var файлы (поскольку это не может быть выведено из предоставленных данных) в структуре каталогов. В зависимости от того, где размещены эти файлы, они имеют разный приоритет.

Я лично предпочитаю группировать данные в group_vars (проверить лучшие практики документ для предпочтительного макета), поэтому я могу назначать данные группам узлов, в основном потому, что это чаще всего отображается непосредственно на роли.

Проблема заключалась просто в том, что я пропустил один файл, в котором foo роль использовалась.

Ссылка на foo не выглядело так:

 roles:
    - foo

а вот так:

 roles:
     - { role: foo, rest_api_version: "{{ blah_version }}" }

поэтому я упустил это из виду. Как только я добавил ту же ссылку на файл vars перед этим «вызовом» роли foo, она работала без файла по умолчанию.