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 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

3 comentários sobre “Utilizando o Ansible – parte 5

  1. Olá!

    Estou começando com o Ansible e gostei bastante dos exemplos, porem estou recebendo um erro de Vagrant aqui:

    $ vagrant up
    Bringing machine ‘ubuntu’ up with ‘virtualbox’ provider…
    Bringing machine ‘centos’ up with ‘virtualbox’ provider…
    ==> ubuntu: Checking if box ‘ubuntu/xenial64’ is up to date…
    ==> ubuntu: There was a problem while downloading the metadata for your box
    ==> ubuntu: to check for updates. This is not an error, since it is usually due
    ==> ubuntu: to temporary network problems. This is just a warning. The problem
    ==> ubuntu: encountered was:
    ==> ubuntu:
    ==> ubuntu: The requested URL returned error: 404 Not Found
    ==> ubuntu:
    ==> ubuntu: If you want to check for box updates, verify your network connection
    ==> ubuntu: is valid and try again.
    ==> ubuntu: Machine already provisioned. Run `vagrant provision` or use the `–provision`
    ==> ubuntu: flag to force provisioning. Provisioners marked to run always will still run.
    ==> centos: Box ‘centos/7’ could not be found. Attempting to find and install…
    centos: Box Provider: virtualbox
    centos: Box Version: >= 0
    The box ‘centos/7’ could not be found or
    could not be accessed in the remote catalog. If this is a private
    box on HashiCorp’s Atlas, please verify you’re logged in via
    `vagrant login`. Also, please double-check the name. The expanded
    URL and error message are shown below:

    URL: [“https://atlas.hashicorp.com/centos/7”]
    Error: The requested URL returned error: 404 Not Found

    Sabe como contornar?

    Curtir

    • O que deu para perceber é que ele não conseguiu se conectar ao Atlas — atlas.hashicorp.com — para verificar atualizações da máquina virtual do Ubuntu (que ele deixou passar pois já tinha cópia local) e baixar e a do CentOS (que ele não tinha localmente e daí o erro). Verifique a conexão do computador que você estava usando e tente novamente com “vagrant up –provision” ou então “vagrant box update” (este apenas baixará/atualizará as máquinas virtuais para o cache local do Vagrant).

      Curtir

Os comentários estão desativados.