Управление поведением Ansible: правила приоритета

Параметры конфигурации

Параметры конфигурации включают значения из файла ansible.cfg и переменные среды. В этой категории значения, заданные в файлах конфигурации, имеют более низкий приоритет. Ansible использует первый найденный файл ansible.cfg и игнорирует все остальные. Ansible ищет ansible.cfg в следующих местах в указанном порядке:

• ANSIBLE_CONFIG (переменная среды, если она задана)
• ansible.cfg (в текущем каталоге)
• ~/.ansible.cfg (в домашнем каталоге)
• /etc/ansible/ansible.cfg

Переменные среды имеют более высокий приоритет, чем записи в ansible.cfg. Если на управляющем узле заданы переменные среды, они переопределяют параметры в том файле ansible.cfg, который загружает Ansible. Значение любой переменной среды подчиняется обычным правилам приоритета оболочки: последнее заданное значение заменяет предыдущие.

Параметры командной строки

Любой параметр командной строки переопределяет любой параметр конфигурации.

Вводя что-либо непосредственно в командной строке, вы можете полагать, что заданные вручную значения должны переопределять все остальные, но Ansible работает иначе. Параметры командной строки имеют низкий приоритет — они переопределяют только конфигурацию. Они не переопределяют ключевые слова плейбука, переменные из инвентаря или переменные из плейбуков.

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

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

ansible -u mike -m ping myhost -u carol

Некоторые параметры допускают несколько значений. В этом случае Ansible добавит все значения из узлов, перечисленных в файлах инвентаря inventory1 и inventory2:

ansible -i /path/inventory1 -i /path/inventory2 -m ping all

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

Ключевые слова плейбука

Любое ключевое слово плейбука переопределяет любой параметр командной строки и любой параметр конфигурации.

Приоритет ключевых слов плейбука зависит от его структуры: более конкретное значение имеет приоритет над более общим:

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

Простой пример:

- hosts: all
  connection: ssh
  tasks:
    - name: This task uses ssh.
      ping:

    - name: This task uses paramiko.
      connection: paramiko
      ping:

В этом примере ключевому слову connection на уровне плей задано значение ssh. Первая задача наследует это значение и подключается с помощью ssh. Вторая задача наследует это значение, переопределяет его и подключается с помощью paramiko. Та же логика применима к блокам и ролям. Все задачи, блоки и роли внутри плей наследуют ключевые слова уровня плей; любая задача, блок или роль может переопределить любое ключевое слово, задав для него другое значение в этой задаче, блоке или роли.

Помните, что это КЛЮЧЕВЫЕ СЛОВА, а не переменные. И плейбуки, и файлы переменных определяются в YAML, но имеют разное назначение. Плейбуки — это структура команд или «описание состояния» для Ansible, а переменные — данные, помогающие сделать плейбуки более динамичными.

Переменные

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

Переменные, которым соответствуют ключевые слова плейбука, параметры командной строки и параметры конфигурации, называются переменными подключения. Изначально предназначенная для параметров подключения, эта категория расширилась и теперь включает другие основные переменные, например временный каталог и интерпретатор Python.

Переменные подключения, как и все переменные, можно задавать несколькими способами и в разных местах. Вы можете определять переменные для узлов и групп в инвентаре. Вы можете определять переменные для задач и плейов в блоках vars: в плейбуках. Однако это всё равно переменные — данные, а не ключевые слова или параметры конфигурации. Переменные, переопределяющие ключевые слова плейбука, параметры командной строки и параметры конфигурации, подчиняются тем же правилам приоритета переменных, что и любые другие переменные.

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

- hosts: cloud
  gather_facts: false
  become: true
  vars:
    ansible_become_user: admin
  tasks:
    - name: This task uses admin as the become user.
      dnf:
        name: some-service
        state: latest
    - block:
        - name: This task uses service-admin as the become user.
          # a task to configure the new service
        - name: This task also uses service-admin as the become user, defined in the block.
          # second task to configure the service
      vars:
        ansible_become_user: service-admin
    - name: This task (outside of the block) uses admin as the become user again.
      service:
        name: some-service
        state: restarted

ansible -u carol -e 'ansible_user=brian' -a whoami all

Прямое назначение

Эта категория применима только к объектам, принимающим прямые параметры, как правило, к модулям и некоторым типам плагинов. У большинства модулей и плагинов действий нет других способов задавать параметры, поэтому в этом контексте вопрос приоритета возникает редко. Однако для некоторых из них это всё же возможно, и такая возможность должна быть отражена в документации.

- debug: msg='this is a direct assignment option to an action plugin'

- ping:
    data: also a direct assignment

Помимо действий задач, наиболее очевидные примеры «прямого назначения» встречаются у плагинов поиска, фильтров и тестов:

lookup('plugin', direct1='value', direct2='value2')

'value_directly_assigned'|filter('another directly assigned')

'direct value' is testplugin

Хотя большинство этих плагинов нельзя настраивать другими способами, особенно тесты, плагины и фильтры могут использовать данные из других источников конфигурации, если это указано в их документации.

С плагинами инвентаря всё немного сложнее: они используют «источники инвентаря», которые иногда могут выглядеть как файл конфигурации и передаются в виде параметра командной строки, но всё равно считаются «прямым назначением». Это понятнее при использовании встроенного источника -i host1, host2, host3, чем при использовании источника-файла -i /path/to/inventory_source, однако приоритет у них одинаковый.