ANSIBLE Series: Lab … Modo CLI e Hello.YML (1st Playbook)
Dezembro chegou, e as festas de final de ano já batem a porta. Para celebrar vamos iniciar o lado prático do Ansible. Graças a enorme extensão (falo num bom sentido) dos pontos a serem cobertos, o aprendizado será dividido em várias partes, que quando somadas formarão o conjunto de um todo, fazendo total sentido. Dito isso, essa primeira sessão, podemos chamá-la assim, abordará o contexto não-gráfico do Ansible, ou seja, a sua CLI (Command Line Interface) – modo texto/bash/prompt. Como instalar, como configurar, como testar, como validar, entre outros, foram transformados (convertidos) em tópicos logo adiante. PORÉM, TODAVIA, CONTUDO, bem antes de qualquer passo ou etapa, iremos necessitar de dois sujeitos. São eles: (I) o bom, velho e gratuito VirtualBox; e (II) o poderoso, robusto e estável CentOS. Ambos podem ser baixados respectivamente em https://www.virtualbox.org/ e https://www.centos.org/. Se você é novato, perguntas tais como: O que são? Por que usar? Como utilizar? … Já se encontram respondidas em cada um desses endereços. Embora muito provavelmente por serem figurinhas carimbadas no mundo da TI, eles dispensam maiores apresentações para veteranos e pessoal técnico.
Uma vez instalado o VirtualBox e baixado a ISO do CentOS, é chegada a hora de criar as máquinas virtuais. Pois é. Isso mesmo que acabou de ler… No plural. Tendo em vista que vamos precisar de mais de uma para criar nosso cenário/laboratório de testes, segue abaixo as informações de cada uma.
VM #01
Nome: control-A Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 55 GB Rede: Bridge
VM #02
Nome: node-01 Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 11 GB Rede: Bridge
VM #03
Nome: node-02 Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 11 GB Rede: Bridge
- Quando formos instalar determinado serviço/ferramenta, utilizaremos a máquina#01 como hospedeira, desempenhando o papel de servidor/controladora. EX: um zabbix-server será a VM control-A; um zabbix-proxy a VM control-B; um zabbix-agent a VM node-01; e assim por diante.
- Máquinas servidoras/controladoras sempre terão mais espaço em disco do que as máquinas chamadas de nodes (nós). Isso porque elas acumularão sistemas distintos em uma só instância. EX: a VM control-A será o OTRS Server, Zabbix Server, e Ansible Controller.
- VMs identificadas como node (nó) possuirão a função de host/remoto/cliente/agente para o respectivo serviço/ferramenta em questão. Além de um HD menor pois as considero como “descartáveis”. Por exemplo, se uma máquina ou grupo de X máquinas cair, é possível provisionar novas instâncias rapidamente com qualquer software de automação, criando assim uma espécie de coleção de templates para cada serviço ofertado.
- Todos os adaptadores de rede estarão em modo bridge para que solicitem a mesma faixa de IPs ao servidor DHCP Local, ao mesmo tempo que são capazes de se comunicar externamente, com a internet. Enxergando uns aos outros e, portanto, na mesma rede, sem barreiras.
Muito bem meus caros… Anotaram tudo? Instalaram? Compreenderam a lógica? Então vamos ao que interessa. Que comece a nossa jornada! 🙃
INSTALAÇÃO E CONFIGURAÇÃO
No sistema operacional CentOS 7, primeiro instale o pacote EPEL “Extra Packages for Enterprise Linux”:
# yum install epel-release
Depois atualize o S.O:
# yum update
Instale o pacote do ansible:
# yum install ansible
Verifque se o ansible foi instalado e qual a versão corrente:
# ansible --version
Configure o arquivo de inventário padrão:
# vi /etc/ansible/hosts
FORMATO [nome_grupo_de_maquinas] fqdn_do_primeiro_host ansible_ssh_host=ip_da_maquina1 fqdn_do_segundo_host ansible_ssh_host=ip_da_maquina2 fqdn_do_terceiro_host ansible_ssh_host=ip_da_maquina3 (... e assim por diante)
EXEMPLO [pool_prod] srv01.machiner.com.br ansible_ssh_host=10.10.0.111 srv02.machiner.com.br ansible_ssh_host=10.10.0.112 srv03.machiner.com.br ansible_ssh_host=10.10.0.113
CHAVES SSH
O Ansible faz uso do protocolo SSH para comunicação. Entretanto, existem duas formas de operá-lo.
A primeira delas é, além de colocar no arquivo de inventário o FQDN e IP das máquinas, também é possível colocar o usuário local e senha local dos hosts remotos que irão executar os playbooks. Isso graças aos parâmetros “ansible_user” e “ansible_password”. Todavia, armazenar senhas em texto plano dentro de um arquivo não é nada seguro, tornando-se um ponto de vulnerabilidade.
A segunda, que é a mais recomendada, acontece da seguinte maneira:
- Gerar um par de chaves com o seu usuário corrente na máquina ansible.
$ ssh-keygen -t rsa -b 4096
Quando solicitado "digitar uma senha para a chave SSH", deixar a senha em branco, ou seja, simplesmente apertar "ENTER". Caso contrário, será preciso digitar a senha toda vez que uma máquina é alcançada pelo ansible durante a execução do playbook. Exemplo, imagine digitar a senha 50 vezes para 50 servidores diferentes... Muito trabalho né? :(
- Distribuir as chaves com os hosts remotos.
$ ssh-copy-id [usuario_remoto]@[ip_ou_hostname_do_alvo]
Na prática você copiará umas das chaves para cada alvo (máquina remota).
EX:
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
O usuário remoto deve existir localmente na máquina alvo. Se não a execução do ansible irá falhar!
Esteja preparado para digitar "YES" (aceitando a solicitação) para cada troca de chaves para cada host remoto.
TESTAR O SSH
EX: $ ssh [email protected]
$ ssh [email protected]
$ ssh [email protected]
COMO VALIDAR? COMO TESTAR? … PING, MÓDULOS, COMANDOS AD-HOC, OUTPUTS
A resposta é simples: basta “pingar” usando um dos inúmeros módulos ansible, neste caso o PING. Com ele é possível dar o comando para: (a) todas as máquinas, (b) um grupo específico, (c) ou ainda um único host. Lembrando que os hosts, grupos e filhos estão presentes ou foram definidos no inventário padrão (/etc/ansible/hosts). Há também a opção de criar seus próprios arquivos e separá-los por ambiente, mas aí você precisa explicitar com o parâmetro -i e argumento nome_inventário. Execute e aguarde a resposta de cada um dos alvos.
# ansible -m ping all

# ansible -m ping [grupo]

# ansible -m ping [host]

Dando seguimento aos nossos testes, vamos agora pegar emprestado outros módulos disponíveis no Ansible. Lista completa aqui https://docs.ansible.com/ansible/2.8/modules/modules_by_category.html Bônus¹ – Como trabalhar com módulos – https://docs.ansible.com/ansible/latest/user_guide/modules.html Bônus² – Criando seus próprios módulos – https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#developing-modules-general
Mesmo procedimento, executar e aguardar a saída (output).
# ansible all -m shell -a 'date'
Buscar a data e hora de todas as máquinas usando o módulo ansible 'shell'
# ansible all -m shell -a 'free -m'
Exibir a quantidade de memória de todas as máquinas usando o módulo 'shell'
# ansible all -m shell -a 'df -h'
Mostrar o espaço em disco e todas as partições de todas as máquinas usando o módulo 'shell'

Bem legal né? 😎 Concorda?
YAML E O SEU BÁSICO
Breve História e Definição
- Ano: 2001
- Criado por: Clark Evans
- O que é: Um formato de serialização (codificação) de dados legíveis por humanos inspirado em linguagens como XML, C, Python e Perl
- Sigla: YAML é um acrônimo recursivo que significa “YAML Ain’t Markup Language” (em português, “YAML não é linguagem de marcação”)
- História: No início do seu desenvolvimento YAML significava “Yet Another Markup Language” (“Mais outra linguagem de marcação”) para distinguir seu propósito centrado em dados no lugar de documentos marcados. Como é usado frequentemente XML para serialização de dados e XML é uma autêntica linguagem de marcação de documentos, é razoável considerar o YAML como uma linguagem de marcação rápida
Por que YAML?
- Playbooks são escritos e expressos utilizando a sintaxe YAML, que é a linguagem de gerenciamento de configuração do Ansible.
- É usado YAML porque é mais fácil para humanos lerem e escreverem do que outros formatos de dados comuns, como XML ou JSON. Além disso, existem bibliotecas disponíveis na maioria das linguagens de programação para trabalhar com YAML.
Sintaxe e Visão Geral
- Para o Ansible, quase todo arquivo YAML começa com uma lista. Cada item da lista é uma lista de pares de chave / valor, comumente chamada de “hash” ou “dicionário”. Portanto, precisamos saber como escrever listas e dicionários em YAML.
- Há outra pequena peculiaridade no YAML. Todos os arquivos YAML (independentemente de sua associação com Ansible ou não) podem, opcionalmente, começar com — e terminar com … Isso faz parte do formato YAML e indica o início e o fim de um documento.
- Todos os membros de uma lista são linhas que começam no mesmo nível de recuo começando com um “-” (um travessão e um espaço):
---
# A list of tasty fruits
- Apple
- Orange
- Strawberry
- Mango
...
- Um dicionário é representado em uma forma simples de chave: valor (os dois pontos devem ser seguidos por um espaço):
---
# An employee record
martin:
name: Martin D'vloper
job: Developer
skill: Elite
...
- Estruturas de dados mais complicadas são possíveis, como listas de dicionários, dicionários cujos valores são listas ou uma mistura de ambos:
---
# Employee records
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
...
- Dicionários e listas também podem ser representados de forma abreviada caso prefira:
---
martin: {name: Martin D'vloper, job: Developer, skill: Elite}
['Apple', 'Orange', 'Strawberry', 'Mango']
...
- Elas são chamadas de “coleções de fluxo” (flow collections).
Links Úteis (+ YAML !!!)
¹ https://yaml.org/
² https://en.wikipedia.org/wiki/YAML
³ https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
HELLO.YML, O PRIMEIRO PLAYBOOK … ESCREVENDO E EXECUTANDO
Na verdade, sendo bem sincero, o nome do nosso playbook não será exatamente Hello.YML … E sim, httpd.yml … A razão vocês irão entender logo mais, prometo! O que eu quis foi dar um título que chamasse atenção, e que também remete-se ao mundo da programação. Aquele que nunca nomeou o seu primeiro código-fonte de uma determinada linguagem como hello.c, hello.cpp, hello.sh, hello.py, hello.php, e afins … Que atire a primeira pedra 🤣🤣🤣
Brincadeiras à parte, passemos para nossa real proposta aqui, expressa logo abaixo.
OBJETIVO: Instalar o servidor apache em um grupo de máquinas e configurar uma tela de boas-vindas em HTML.
PS: Elementos que porventura aparecem neste playbook (como template, notify e handlers) serão explicados mais adiante, nos próximos posts.
# cd /etc/ansible/
# mkdir playbooks
# cd playbooks/
# touch httpd.yml
# vi httpd.yml
---
- hosts: webservers
remote_user: victor
become: yes
become_method: su
tasks:
- name: Installing Latest Version of Apache
yum: name=httpd state=latest
- name: Copying the demo page
template: src=/etc/ansible/demo/index.html dest=/var/www/html owner=apache group=apache mode=0644
- name: (Enable it on System Boot)
service: name=httpd enabled=yes
notify:
- start apache
handlers:
- name: start apache
service: name=httpd state=started
...
# cd ..
# mkdir demo
# cd demo/
# touch index.html
# vi index.html
<html>
<head>
<title>Apache is installed by Ansible</title>
</head>
<body>
<h1>Apache is installed by Ansible</h1>
<p>Now, Apache is managed through Ansible</p>
</body>
</html>
# ansible-playbook httpd.yml
(Quando já se tem a chave SSH no alvo, não precisa de senha!!!)
# ansible-playbook httpd.yml --ask-become-pass
(Caso contrário, é preciso digitar a senha do usuário local ao alvo!!!)
STOP ! ATTENTION! PLAYBOOK RUNNING !!! PLEASE WAIT …

Pronto! Feito!
Meus Parabéns 🙂
Me despeço aqui pessoal. Por hoje é tudo. Espero de coração que tenham gostado. Mas calma, nossa caminhada no mundo ansible apenas começou, temos muito chão para cobrir ainda. Forte abraço a todos! Até breve!
[…] https://machinesbecomeservices.com/2020/12/01/ansible-series-hands-on-01-modo-cli-e-hello-yml-1st-pl… […]