Menu Início

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 victor@10.10.0.111
$ ssh-copy-id victor@10.10.0.112
$ ssh-copy-id victor@10.10.0.113
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 victor@10.10.0.111
    $ ssh victor@10.10.0.112
    $ ssh victor@10.10.0.113

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
Figura 01. Propositalmente, demonstra a saída do Ansible quando alcança uma máquina com sucesso (verde), e outra não (vermelho)
# ansible -m ping [grupo]
Figura 02. Ansible alcançando máquinas de um grupo chamado ‘web’. Por enquanto, somente a VM #02 (node-01) consta nessa lista
# ansible -m ping [host]
Figura 03. Ansible alcançando a única máquina do nosso LAB chamada ‘node-01′

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'
Figura 04. Ansible mostrando informações de cada partição de cada máquina listada no arquivo inventário. Mais uma vez, de propósito, a VM node-02 está inacessível. O intuito é mostrar a paleta de cores do ansible-cli (command line interface)

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 …

Figura 05. Ansible executando o playbook conforme o esperado, sem nenhum erro. Cor amarela implica que algo (conf., serviço, arquivo, pasta…) foi modificado no host (node) de maneira bem sucedida
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!

Categorias:Ansible

Marcado como:

vicrlda

🐧Linux SysAdmin & OTRS, Zabbix, Ansible
🎴 Paraíba - Brazil
💀 Rock: Garagem, Surf, Punk, 60's, Indie, Folk
😍 @mayararaissa.t
👶 Miguel's Dad

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 )

Foto do Google

Você está comentando utilizando sua conta Google. 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 )

Conectando a %s

%d blogueiros gostam disto: