Victor Ricardo

Para nos situarmos, considero este um importante marco que anuncia a quase conquista do ANSIBLE (na prática, a metade da jornada) Esse meio será dividido em três partes consecutivas: como escrever playbooks, arquivos, variáveis … a) estaticamente, b) dinamicamente, c) e organizá-los em roles, para melhor uso/reuso da ferramenta e suas capacidades. Enquanto que o encerramento, posts dedicados e exclusivos sobre: Ansible GALAXY, Ansible VAULT, Ansible INVENTORIES, e MISC.

POR QUE RECICLAR CÓDIGO? (A BOA E VELHA PRÁTICA DE REUTILIZAR PARTES COMUNS) …

Até o presente momento, tenho certeza que já percebeu que sempre escrevemos tudo em um único playbook. Quero dizer, tarefas, variáveis, manipuladores, estão todos lá, em um arquivo nomeado com a extensão .YML Não por acaso, pois quando ainda em processo de aprendizagem, é muito mais fácil e menos complexo visualizar o que se está fazendo num só lugar. Porém, com o passar do tempo, as coisas deixam de ser tão triviais e se tornam um pouco mais “sofisticadas”, digamos assim. Talvez por isso que programadores costumam analisar um(a) problema/questão, dividindo-o(a) em etapas menores, e “atacando” (resolvendo) uma parte por vez.

Sim, não é estranho e soa familiar porque você provavelmente já leu/ouviu em algum lugar. Alguns podem citar a obra A Arte da Guerra, escrita no séc. IV a.C. pelo comandante militar chinês Sun Tzu. Outros remetem ao general cartaginês Aníbal Barca (247 a.C.-183 a.C.) Enfim, vários personagens da história contribuíram e aperfeiçoaram essa tática ao longo dos séculos.

Mas, voltando ao Ansible e a automação, faremos a mesma coisa que outras linguagens de programação já fazem. Por exemplo, um sistema operacional escrito em C possui diversas bibliotecas com funções auxiliares para: gerenciamento de memória, sistema de arquivos, processamento, etc. Uma aplicação Java apresenta uma classe SISTEMA, outra CLIENTE, e várias classes OBJETOS, com atributos (características) e métodos (acesso/modificação) E assim por diante …

Resumindo, um código não segmentado se torna extremamente difícil para:

ARTEFATOS? O QUE SÃO?

No sentido macro, um artefato pode ser desde um banco de dados inteiro até um imenso datacenter geográfico, com todos os seus componentes lógicos e físicos. Em contrapartida, no microuniverso ansible podemos encontrar quatro tipos. Sendo que, todos necessariamente são sempre arquivos ( ou files, em inglês), de natureza distribuída e reutilizáveis. São eles: variáveis, tarefas, playbooks, roles. Além disso, cada um conta com certas particularidades, vistas logo abaixo.

• Um arquivo de variáveis somente pode conter variáveis
• Um arquivo de tarefas apenas tarefas
• Um playbook deve apresentar no mínimo uma jogada (ou play, como é chamada), permitindo também algumas variáveis, tarefas, e outros tipos correlatos. Passível de reuso indiscriminado mas sempre estaticamente, nunca dinamicamente.
• A mesma coisa vale para uma role, com a adição de manipuladores (handlers), defaults (um subtipo de variável), módulos e plugins. Todos esses definidos e organizados em um estrutura de árvore de diretórios. Outro grande diferencial das roles em relação aos anteriores, é a possibilidade de compartilhá-las em repositório online, uma espécie de central, denominado Ansible GALAXY.

REUSANDO PLAYBOOKS – IMPORT_PLAYBOOK

Playbooks são capazes de incorporar uns aos outros. Em outras palavras, eles conseguem usufruir de tarefas e elementos presentes nos respectivos pares. Tudo isso, é claro, através de uma simples referência no código. Mas cuidado, e muita atenção aqui, pois você deve apenas usar o import para tal. Na prática, isso implica que playbooks usam outros playbooks de maneira estática e só, ponto final. Ou seja, o Ansible executará cada tarefa, cada play, do playbook(s) correspondente(s) e que foi(ram) importado(s), exatamente na ordem que elas aparecem noutrem. É como se, no fim das contas, essas tivessem sido declaradas diretamente no atual, sem prejuízo nenhum.

- import_playbook: webservers.yml
- import_playbook: databases.yml

Também é possível fazer essa seleção em tempo real, quando se está prestes a rodar o playbook. Como Victor? Basta que você defina o nome do playbook alvo numa variável, graças ao parâmetro –extra-vars ou palavra-chave vars.

- import_playbook: "/path/to/{{ import_from_extra_var }}"
- import_playbook: "{{ import_from_vars }}"
  vars:
    import_from_vars: /path/to/one_playbook.yml

REUSANDO FILES, TASKS, ROLES – IMPORT_TASKS – IMPORT_ROLES

Para todo e qualquer conteúdo importado, especialmente files e roles, Ansible realiza o pré-processamento bem antes da execução de tarefas do playbook principal. Assim garantimos que esse conteúdo nunca será afetado por nenhuma outra tarefa de nível superior.

É possível passar variáveis durante a importação, sempre que quiser executar um arquivo mais de uma vez dentro do playbook. Por exemplo:

tasks:
- import_tasks: wordpress.yml
  vars:
    wp_user: timmy

- import_tasks: wordpress.yml
  vars:
    wp_user: alice

- import_tasks: wordpress.yml
  vars:
    wp_user: bob

Dúvidas sobre precedência, quem vem primeiro, e aonde colocar uma variável corretamente, saiba mais em https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#ansible-variable-precedence

REUSANDO TAREFAS COMO SE FOSSEM MANIPULADORES

# restarts.yml
- name: Restart apache
  ansible.builtin.service:
    name: apache
    state: restarted

- name: Restart mysql
  ansible.builtin.service:
    name: mysql
    state: restarted

As importações são processadas antes do início da reprodução, portanto, o nome da importação não existe mais durante a execução da reprodução, mas os nomes das tarefas importadas individuais sim. Para usar a tarefa Restart apache com reutilização estática, consulte o nome de cada tarefa ou tarefas no arquivo importado.

- name: Trigger an imported (static) handler
  hosts: localhost
  handlers:
    - name: Restart services
      import_tasks: restarts.yml
  tasks:
    - command: "true"
      notify: Restart apache
    - command: "true"
      notify: Restart mysql

>_ REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.html