Управление поведением Ansible: правила приоритета
Для максимальной гибкости управления вашими средами Ansible предлагает множество способов управления поведением Ansible: как он подключается к управляемым узлам и как работает после подключения. Если вы используете Ansible для управления большим количеством серверов, сетевых устройств и ресурсов облака, вы можете определить поведение Ansible в нескольких местах и передать эту информацию Ansible несколькими способами. Эта гибкость удобна, но может привести к проблемам, если вы не понимаете правила приоритета.
Эти правила приоритета применяются к любому параметру, который можно определить несколькими способами (настройки конфигурации, параметры командной строки, ключевые слова playbook, переменные).
- Настройки конфигурации
- Параметры командной строки
- Ключевые слова playbook
- Использование дополнительных переменных в командной строке
Категории приоритета
Ansible предлагает четыре источника для управления своим поведением. В порядке приоритета от низшего (легче всего перезаписывается) к высшему (перезаписывает все остальные), категории:
- Настройки конфигурации
- Параметры командной строки
- Ключевые слова playbook
- Переменные
Каждая категория перезаписывает любую информацию из категорий с более низким приоритетом. Например, ключевое слово playbook перезапишет любую настройку конфигурации.
Внутри каждой категории приоритета применяются конкретные правила. Однако, как правило, вступает в силу последняя определённая величина, перезаписывая все предыдущие определения.
Настройки конфигурации
Настройки конфигурации включают значения из файла ansible.cfg и переменные окружения. В этой категории значения, установленные в файлах конфигурации, имеют более низкий приоритет. Ansible использует первый файл ansible.cfg, игнорируя все остальные. Ansible ищет ansible.cfg в этих расположениях в указанном порядке:
-
ANSIBLE_CONFIG(переменная окружения, если задана) -
ansible.cfg(в текущей директории) -
~/.ansible.cfg(в домашней директории) /etc/ansible/ansible.cfg
Переменные окружения имеют более высокий приоритет, чем записи в файле ansible.cfg. Если на вашем контрольном узле установлены переменные окружения, они перезаписывают настройки в загружаемом Ansible файле ansible.cfg. Значение любой заданной переменной окружения подчиняется стандартному приоритету оболочки: последнее определенное значение перезаписывает предыдущие значения.
Параметры командной строки
Любой параметр командной строки перезапишет любую настройку конфигурации.
Когда вы вводите что-то непосредственно в командной строке, вы можете считать, что ваши значения должны перезаписывать все остальные, но Ansible работает иначе. Параметры командной строки имеют низкий приоритет — они перезаписывают только настройки конфигурации. Они не перезаписывают ключевые слова playbook, переменные из инвентаризации или переменные из playbooks.
Вы можете перезаписать все остальные настройки из всех других источников во всех категориях приоритета в командной строке, используя Использование дополнительных переменных -e в командной строке, но это не параметр командной строки, это способ передачи переменной.
В командной строке, если вы передаете несколько значений для параметра, принимающего только одно значение, вступает в силу последнее определенное значение. Например, эта задача ad hoc подключится как carol, а не как mike.
Некоторые параметры допускают несколько значений. В этом случае Ansible добавит все значения из узлов, перечисленных в файлах инвентаризации inventory1 и inventory2.
ansible -i /path/inventory1 -i /path/inventory2 -m ping all
Справка по каждому инструменту командной строки содержит доступные параметры для этого инструмента.
Ключевые слова playbook
Любое ключевое слово playbook перезапишет любой параметр командной строки и любую настройку конфигурации.
Внутри ключевых слов playbook приоритет определяется самим playbook; более конкретное значение побеждает над более общим:
- play (самое общее)
- блоки/включения/импорты/роли (необязательные и могут содержать задачи и друг друга)
- задачи (наиболее конкретные)
Простой пример:
- hosts: all
connection: ssh
tasks:
- name: This task uses ssh.
ping:
- name: This task uses paramiko.
connection: paramiko
ping:
В этом примере ключевое слово connection установлено в значение ssh на уровне play. Первая задача наследует это значение и подключается используя ssh. Вторая задача наследует это значение, перезаписывает его и подключается используя paramiko. Та же логика применяется к блокам и ролям. Все задачи, блоки и роли в рамках play наследуют ключевые слова на уровне play; любая задача, блок или роль могут перезаписать любое ключевое слово, определив другое значение для этого ключевого слова внутри задачи, блока или роли.
Помните, что это КЛЮЧЕВЫЕ СЛОВА, а не переменные. Как playbooks, так и файлы переменных определяются в формате YAML, но имеют разное значение. Playbooks — это структура команд или «описание состояния» для Ansible, переменные — это данные, которые мы используем, чтобы сделать playbooks более динамичными.
Переменные
Любая переменная перезапишет любое ключевое слово playbook, любой параметр командной строки и любую настройку конфигурации.
Переменные, которые имеют эквивалентные ключевые слова playbook, параметры командной строки и настройки конфигурации, известны как переменные подключения. Первоначально разработанные для параметров подключения, эта категория расширилась, включив в себя и другие ключевые переменные, такие как временная директория и интерпретатор Python.
Переменные подключения, как и все переменные, могут быть установлены несколькими способами и в нескольких местах. Вы можете определить переменные для узлов и групп в инвентаризации. Вы можете определить переменные для задач и play в блоках vars: в playbooks. Однако они по-прежнему являются переменными — это данные, а не ключевые слова или настройки конфигурации. Переменные, которые перезаписывают ключевые слова playbook, параметры командной строки и настройки конфигурации, подчиняются тем же правилам приоритета переменных, что и любые другие переменные.
При установке в playbook переменные следуют тем же правилам наследования, что и ключевые слова playbook. Вы можете установить значение для play, а затем перезаписать его в задаче, блоке или роли:
- hosts: cloud
gather_facts: false
become: yes
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
Область действия переменной: как долго значение доступно?
Значения переменных, установленные в playbook, существуют только внутри объекта playbook, который их определяет. Эти переменные «с областью действия объекта playbook» недоступны последующим объектам, включая другие playbooks.
Значения переменных, непосредственно связанные с узлом или группой, включая переменные, определенные в инвентаризации, через плагины vars или с помощью модулей, таких как set_fact и include_vars, доступны для всех playbooks. Эти переменные «с областью действия узла» также доступны через словарь hostvars[].
Использование дополнительных переменных в командной строке
Для перезаписи всех остальных настроек во всех других категориях можно использовать дополнительные переменные: --extra-vars или -e в командной строке. Значения, переданные с -e, являются переменными, а не параметрами командной строки, и они перезаписывают настройки конфигурации, параметры командной строки и ключевые слова playbook, а также переменные, заданные в другом месте. Например, эта задача подключится как brian, а не как carol:
ansible -u carol -e 'ansible_user=brian' -a whoami all
Вы должны указать как имя переменной, так и ее значение с --extra-vars.
© 2012–2018 Michael DeHaan
© 2018–2021 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.11/reference_appendices/general_precedence.html