Utilizando o Ansible – parte 5

ansible-5_abertura

Na quarta parte os playbooks receberam alguma inteligência com a utilização dos handlers para executar determinadas tarefas apenas em caso de necessidade. Agora é a vez de aumentar um pouco mais esta inteligência dos playbooks com a execução condicionada de tarefas!

Reconfigurando o ambiente de testes

Antes de seguir adiante, uma pequena mudança na configuração do ambiente de testes:

$ vagrant halt
$ git checkout parte-5
$ vagrant up
Bringing machine 'ubuntu' up with 'virtualbox' provider...
Bringing machine 'centos' up with 'virtualbox' provider...
...

O processo demorará um pouco e serão criadas duas novas máquinas virtuais, uma com a versão 16.04 LTS do Ubuntu (“ubuntu”) e outra com o CentOS 7 (“centos”). Em ambos os casos as distribuições serão atualizadas porém o Ansible será instalado apenas na primeira — visto que não há necessidade de instalar em ambas.

Para acessá-la faça:

$ vagrant ssh ubuntu

Também será necessário ativar o ambiente:

$ source ./ansible_env/bin/activate
(ansible_env) $

Até aqui nada mudou e a principal diferença aqui está no arquivo de inventário.

$ cat ~/hosts
[localhost]
127.0.0.1 ansible_connection=local

[servers]
172.20.20.10 ansible_connection=ssh ansible_user=ubuntu
172.20.20.11 ansible_connection=ssh ansible_user=vagrant

Que agora contém tantos os novos nós — 172.20.20.10 e 172.20.20.11 — e algumas informações importantes para que o Ansible saiba como fazer para acessá-los. Em “ansible_connection” estou definindo a forma de acesso a este nó — local para acesso local, ssh para acesso remoto e winrm para acesso remoto em Windows — e “ansible_user” com a identificação do usuário no qual o Ansible será executado.

Ativando (e testando) o acesso via SSH

O acesso via SSH aos nós não requer senha porém é preciso fazer “aquele” primeiro acesso para poder armazenar as chaves em “~/.ssh/known_hosts”, o que que é uma boa oportunidade para também verificar se está tudo certo na máquina com Ubuntu:

$ ansible 172.20.20.10 -c local -i ~/hosts -m ping
The authenticity of host '172.20.20.10 (172.20.20.10)' can't be
established.
...
Are you sure you want to continue connecting (yes/no)? yes
172.20.20.10 | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}

Como também na com CentOS:

$ ansible 172.20.20.11 -c local -i ~/hosts -m ping
The authenticity of host '172.20.20.11 (172.20.20.11)' can't be
established.
...
Are you sure you want to continue connecting (yes/no)? yes
172.20.20.11 | SUCCESS => {
 "changed": false, 
 "ping": "pong"
}

E apenas lembrando que o Ansible não foi instalado nela! 🙂

Execução condicional

É possível condicionar a execução de uma determinada tarefa dentro do playbook através do parâmetro “when”. O Ansible validará a expressão e a executará se o resultado for verdadeiro, ou a pulará se falso. Você pode fazer comparações usando variáveis do próprio playbook ou mesmo com algum fato sobre o host remoto — do original fact, que consiste naquele conjunto de informações recuperadas do nó na primeira etapa da execução do playbook, a Gathering Facts.

Adicionando condições ao playbook

Por conta das diferenças na localização de alguns arquivos e na forma como as duas distribuições instalam os programas este playbook precisou contemplar ambos os casos e acabou ficando um pouco maior que os anteriores:

 

Os fatos ansible_distribution e ansible_os_family são utilizados para fazer a distinção entre as distribuições. Como o Nginx não está empacotado no CentOS é necessário adicionar o repositório do pacote ao YUM antes de instalá-lo.

Executando o playbook com condições

Terminadas as explicações, hora de de executar o playbook:

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

PLAY [servers] ******************************************************
...
PLAY RECAP **********************************************************
172.20.20.10 : ok=5 changed=4 unreachable=0 failed=0 
172.20.20.11 : ok=6 changed=6 unreachable=0 failed=0

E pronto! O Nginx foi instalado nos dois nós e a partir deste momento é possível replicar o mesmo em quantos outros hosts executando Ubuntu (ou Debian) ou CentOS¹. Basta que eles estejam listados no arquivo de inventário.

Acessando o servidor HTTP do CentOS

ansible-4_html

Apenas para matar a curiosidade, o servidor HTTP do CentOS está disponível em http://127.0.0.1:8001 enquanto que o Ubuntu permanece acessível em http://127.0.0.1:8000 — e ambas as portas serão redirecionadas para dentro das respectivas máquinas virtuais.

(¹) No caso CentOS 7 para usar em outras versões seria necessário editar a variável “repo_add” usando os fatos sobre o nó remoto para saber qual versão do CentOS ele está executando.

E a outra máquina virtual?

Aquela outra máquina virtual rodando Ubuntu não foi destruída e nem seus dados foram perdidos. Para acessá-la desligue as máquinas virtuais e retorne ao outro ramo do repositório:

$ vagrant halt
==> centos: Attempting graceful shutdown of VM...
==> ubuntu: Attempting graceful shutdown of VM...
$ vagrant status
Current machine states:

ubuntu poweroff (virtualbox)
centos poweroff (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
$ git checkout parte-4
Switched to branch 'parte-4'
Your branch is up-to-date with 'origin/parte-4'
$ vagrant status
Current machine states:

default                   poweroff (virtualbox)

The VM is powered off. To restart the VM, simply run `vagrant up

É a “mágica do Git”! 🙂

E ao selecionar o ramo “parte-5” você retorna para a configuração de duas máquinas virtuais. A única recomendação aqui é desligá-las antes de fazer o respectivo git checkout para evitar que o Vagrant se perca.

E para terminar

Este é o fim desta introdução sobre o Ansible, englobando alguns dos módulos básicos, os playbooks com o uso de handlers e de condicionantes para a execução de tarefas. Sei que o exemplo do Nginx é básico mas contém quase tudo que é necessário ser feito (instalação, customização e cópia de arquivos etc).

Um exercício interessante seria acrescentar mais nós a esta configuração, seja rodando Ubuntu (ou Debian) , CentOS ou mesmo acrescentar outras distribuições ou sistemas operacionais — lembrando que no caso do Windows (nativo) os módulos e a forma de acesso são diferentes.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s