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

По умолчанию 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