Victor Ricardo

CONT. ☝

👈 ANTERIOR: LOOPS

Ao executar um playbook, o comportamento que se espera do Ansible é:

1. antes, reunir todos os fatos referentes aos nodes ( gather_facts )
2. depois, rodar as tarefas especificadas ( playbook ) somente nas máquinas-alvo que estão expressas ou de acordo com a linha “hosts” , presente no próprio main.yml, test.yml por exemplo.

Dito isso, quatro caminhos estão abertos ao admin responsável (você, eu). São eles:

• delegar tarefas a uma máquina em particular
• delegar tarefas a um grupo específico
• delegar fatos a uma série de hosts ou grupos
• executar um playbook inteiro localmente

03-a. Tasks que NÃO podem ser delegadas !!!

A execução de algumas pouquíssimas tarefas está restrita apenas ao controlador, e essas sempre serão rodadas única e exclusivamente nele, não importando o que você faça. include , add_hosts , e debug integram essa lista, não podendo de forma nenhuma serem delegadas a terceiros.

03-b. Delegando tasks . . .

Agora sim meus caros colegas 😉, tarefas que podem ser delegadas para nodes remotos. Trecho a seguir retirado da documentação oficial:

Se você deseja executar uma tarefa em um host com referência a outros hosts, use a palavra-chave delegate_to em uma tarefa. Isso é ideal para gerenciar nós em um pool com carga balanceada ou para controlar janelas de interrupção. Você pode usar a delegação com a palavra-chave serial para controlar o número de hosts em execução ao mesmo tempo

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-tasks

---
- 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 : significa que será rodado na máquina corrente, ou seja, localmente naquela que executa o Ansible!

03-c. Delegando fatos . . .

Delegar tarefas do Ansible é como delegar tarefas no mundo real – seus mantimentos pertencem a você, mesmo que outra pessoa os entregue em sua casa. Da mesma forma, quaisquer fatos reunidos por uma tarefa delegada são atribuídos por padrão ao inventory_hostname (o host atual), não ao host que produziu os fatos (o delegado ao host). Para atribuir fatos coletados ao host delegado em vez do host atual, defina delegate_facts como true.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts

---
- hosts: app_servers

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

Esta tarefa reúne fatos para as máquinas no grupo dbservers e atribui os fatos a essas máquinas, mesmo que a play seja direcionado ao grupo app_servers. Desta forma, você pode pesquisar hostvars [‘dbhost1’] [‘ansible_default_ipv4’] [‘endereço’], mesmo que dbservers não tenham feito parte da peça ou deixados de fora usando –limit.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts

03-d. Playbooks locais . . .

Pode ser útil usar um playbook localmente em um host remoto, ao invés de conectar por SSH. Isso pode ser usado para garantir a configuração de um sistema, colocando um playbook em um crontab.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#local-playbooks

ansible-playbook playbook.yml --connection=local

---
- hosts: 127.0.0.1
  connection: local

CONTINUA (…)

Próximo post >>> Conditionals

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#playbooks-delegation