Utilizando o Ansible – parte 4

ansible-4_abertura

Na (agora distante) terceira parte foi introduzido o conceito do playbook. Com eles é possível agrupar diversas tarefas — um módulo e seus parâmetros — em um único arquivo YAML para serem todos executados em um ou mais nós.

Agora é a vez de usar um tipo especial de tarefa, os handlers, para adicionar uma certa inteligência ao playbooks e assim evitar a execução de certas ações de forma desnecessária ou repetida.

Antes de começar

Apenas para para não perder o hábito.

$ cd ~/Vagrant/ansible
$ git pull
$ git checkout parte-4
$ vagrant up
...
$ vagrant ssh
$ source ~/ansible_env/bin/activate
(ansible_env) $

Para atualizar o repositório, ir para um ramo específico deste (“parte-4”), iniciar a máquina virtual, acessá-la e, claro, configurar o ambiente para a ferramenta.

Handlers

Os handlers são um tipo de tarefa que só podem ser chamadas através de outras. Diferente das tarefas normais, executadas na sequência em que se encontram dentro do arquivo, eles são invocados uma única vez  após a execução de todas as demais tarefas do playbook — e lembrando que o handler só será executado uma única vez, mesmo que invocado por diversas tarefas¹.

Por exemplo, um playbook² encarregado de instalar/atualizar em conjunto Apache, MemcachedPHP e WordPress³. No caso da atualização de um destes componentes será necessário reiniciar o servidor HTTP e para evitar que isto seja feito repetidas vezes — entre 1 a 4 vezes — basta que cada tarefa invoque o handler específico para que esta ação seja feita uma única vez no playbook.

Dentro do playbook os handlers são definidos logo após as tarefas e possuem a mesma sintaxe delas (veja no exemplo abaixo). E dentro das tarefa é utilizado o comando “notify” para listar os handlers que deverão ser invocados caso a execução do módulo resulte em uma modificação do status anterior — o valor da chave “changed” retornar True.

(¹) Por exemplo, um serviço só será parado se ele estiver em execução (ou só será posto em execução se estiver parado), um arquivo só será copiado se houver diferença de conteúdo entre origem e destino, um pacote só será instalado se ele ainda não estiver presente etc.

(²) Aliás, quase optei em utilizá-lo nos exemplos mas ele acabaria ficando bem mais longo e complexo do que os do Nginx.

(³) Assumindo aqui que o banco de dados SQL — MariaDB ou MySQL por conta de ser o WordPress — ficaria em outro host.

Adaptando o playbook do Nginx

O playbook utilizado na parte 3 sempre reiniciará o servidor HTTP e isto independente de ter havido ou não de haver alterações. Assim ele pode ser reescrito para usar um handler e reiniciá-lo somente quando for necessário.

Propositalmente fiz com que todas as tarefas notifiquem o handler “Reinicia o Nginx”, quando seria somente necessário fazê-lo em “Instala Nginx”.

Executando o playbook com handler

Se nada foi alterado na configuração da máquina virtual, o resultado da execução deste playbook será algo assim:

$ ansible-playbook -i hosts /vagrant/configure_http_handlers.yaml

PLAY [localhost] ****************************************************

TASK [Gathering Facts] **********************************************
ok: [127.0.0.1]

TASK [Instala o Nginx] **********************************************
ok: [127.0.0.1]

TASK [Monta a página principal] *************************************
ok: [127.0.0.1]

TASK [Copia a imagem] ***********************************************
ok: [127.0.0.1]

PLAY RECAP **********************************************************
127.0.0.1 : ok=4 changed=0 unreachable=0 failed=0

Ou seja, nada foi alterado e então o handler não precisou ser executado.

Mas basta alterar alguma coisa nesta configuração para que o handler seja invocado.

$ sudo rm /var/www/html/rackserver.png
$ ansible-playbook -i hosts /vagrant/configure_http_handler.yaml

PLAY [localhost] ****************************************************
...
TASK [Copia a imagem] ***********************************************
changed: [127.0.0.1]

RUNNING HANDLER [Reinicia o Nginx] **********************************
changed: [127.0.0.1]

PLAY RECAP **********************************************************
127.0.0.1 : ok=5 changed=2 unreachable=0 failed=0

Experimente também alterar o template do “index.html” (ou  o conteúdo do arquivo em /var/www/html”) ou mesmo desinstalar manualmente o pacote do Nginx para verificar que o comportamento também se repetirá.

Fim desta parte

Para remover as chamadas extras ao handler “Reinicia Nginx” basta apagar as linhas de “notify” das tarefas — para evitar surpresas use um validador de YAML. Aliás, a proposta original seria de incluir a execução condicional ainda nesta parte mas ficou longo. Daí preferi dividir e deixá-lo para a próxima parte.

Até!

Anúncios

Um comentário sobre “Utilizando o Ansible – parte 4

  1. Pingback: Utilizando o Ansible – parte 5 | giovannireisnunes

Os comentários estão desativados.