Управление выполнением задач: делегирование и локальные действия

Задачи, которые нельзя делегировать

Некоторые задачи всегда выполняются на контрольном узле. Эти задачи, включая include, add_host, и debug, нельзя делегировать. Вы можете определить, можно ли делегировать действие из документации атрибута connection. Если атрибут connection указывает, что support является False или None, то действие не использует подключение и не может быть делегировано.

Делегирование задач

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

---
- hosts: webservers
  serial: 5

  tasks:
    - name: Take out of load balancer pool
      ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

    - name: Actual steps would go here
      ansible.builtin.yum:
        name: acme-web-stack
        state: latest

    - name: Add back to load balancer pool
      ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

Первая и третья задачи в этом плейбуке выполняются на 127.0.0.1, что является машиной, на которой работает Ansible. Также есть сокращённый синтаксис, который вы можете использовать для каждой задачи: local_action. Вот тот же плейбук, что и выше, но с использованием сокращённого синтаксиса для делегирования 127.0.0.1:

---
# ...

  tasks:
    - name: Take out of load balancer pool
      local_action: ansible.builtin.command /usr/bin/take_out_of_pool {{ inventory_hostname }}

# ...

    - name: Add back to load balancer pool
      local_action: ansible.builtin.command /usr/bin/add_back_to_pool {{ inventory_hostname }}

Вы можете использовать локальное действие для вызова ‘rsync’ для рекурсивного копирования файлов на управляемые серверы:

---
# ...

  tasks:
    - name: Recursively copy files from management server to target
      local_action: ansible.builtin.command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/

Обратите внимание, что для этого должны быть настроены ключи SSH без паролей или ssh-agent, в противном случае rsync запросит пароль.

Для указания дополнительных аргументов используйте следующий синтаксис:

---
# ...

  tasks:
    - name: Send summary mail
      local_action:
        module: community.general.mail
        subject: "Summary Mail"
        to: "{{ mail_recipient }}"
        body: "{{ mail_body }}"
      run_once: True

Шаблонизация в контексте делегирования

Обратите внимание, что в режиме делегирования интерпретатор выполнения (обычно Python), connection, become, и shell параметры плагина теперь будут шаблонизированы с использованием значений с хоста, к которому делегирована задача. Все переменные, кроме inventory_hostname, будут теперь получены с этого хоста, а не с исходного хоста задачи. Если вам нужны переменные с исходного хоста задачи для этих параметров, вы должны использовать hostvars[inventory_hostname]['varname'], даже если inventory_hostname_short относится к хосту, которому делегирована задача.

Делегирование и параллельное выполнение

По умолчанию задачи Ansible выполняются параллельно. Делегирование задачи не изменяет этого и не обрабатывает проблемы с параллельностью (несколько вилок, записывающих в один и тот же файл). Чаще всего пользователи сталкиваются с этим при обновлении одного файла на одном делегированном хосте для всех хостов (например, с использованием модулей copy, template, или lineinfile). Они всё ещё будут работать в параллельных вилках (по умолчанию 5) и перезаписывать друг друга.

Это можно решить несколькими способами:

- name: "handle concurrency with a loop on the hosts with `run_once: true`"
  lineinfile: "<options here>"
  run_once: true
  loop: '{{ ansible_play_hosts_all }}'

Используя промежуточный плейбук с serial: 1 или используя throttle: 1 на уровне задачи, для более подробной информации см. Управление выполнением плейбука: стратегии и многое другое

Делегирование фактов

Делегирование задач Ansible подобно делегированию задач в реальной жизни – ваши продукты относятся к вам, даже если кто-то другой их доставит к вам домой. Аналогично, все собранные фактами делегированной задачи по умолчанию назначаются на inventory_hostname (текущий хост), а не на хост, который сгенерировал эти факты (хост, которому делегирована задача). Чтобы вместо текущего хоста назначить собранные факты на хост, которому делегирована задача, установите delegate_facts в true.

---
- hosts: app_servers

  tasks:
    - name: Gather facts from db servers
      ansible.builtin.setup:
      delegate_to: "{{ item }}"
      delegate_facts: true
      loop: "{{ groups['dbservers'] }}"

Эта задача собирает факты для машин в группе dbservers и назначает факты этим машинам, даже если плейбук ориентирован на группу app_servers. Таким образом, вы можете использовать hostvars[‘dbhost1’][‘ansible_default_ipv4’][‘address’], даже если dbservers не были частью плейбука или исключены с помощью --limit.

Локальные плейбуки

Иногда может быть полезно использовать плейбук локально на удалённом хосте, а не подключаясь через SSH. Это может быть полезно для обеспечения конфигурации системы, поместив плейбук в crontab. Это также можно использовать для запуска плейбука внутри установщика ОС, например, Anaconda kickstart.

Чтобы запустить весь плейбук локально, просто установите строку hosts: в hosts: 127.0.0.1 и затем запустите плейбук следующим образом:

ansible-playbook playbook.yml --connection=local

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

---
- hosts: 127.0.0.1
  connection: local