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

По умолчанию Ansible собирает информацию о фактах и выполняет все задачи на машинах, соответствующих строке hosts вашего плейбука. Эта страница показывает, как делегировать задачи другой машине или группе, делегировать информацию о фактах на определённые машины или группы или выполнить весь плейбук локально. Используя эти подходы, вы можете точно и эффективно управлять взаимосвязанными средами. Например, при обновлении веб-серверов, вам может потребоваться временно исключить их из сбалансированного пула. Вы не можете выполнить эту задачу на самих веб-серверах. Делегировав задачу на localhost, вы сохраняете все задачи в рамках одного плейбука.

• Задачи, которые нельзя делегировать
• Делегирование задач
• Делегирование фактов
• Локальные плейбуки

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

Некоторые задачи всегда выполняются на контроллере. Эти задачи, включая include, add_host, и debug, нельзя делегировать.

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

Если вы хотите выполнить задачу на одном узле со ссылкой на другие узлы, используйте ключевое слово 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

Переменная ansible_host отражает узел, на который делегирована задача.

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

Делегирование задач 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