cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
773
Apresentações
10
Útil
1
Comentários
image

 

 

Comecei a estudar a ferramenta de provisionamento, gerenciamento de configuração e deploy de aplicações do momento, o ansible e nesse artigo vou compartilhar as minhas anotações dos  conceitos fundamentais dessa poderosa ferramenta.

 

Pegue o seu café, abra o seu terminal e let's do it!

Devemos pensar em ansible como automação, ele vem para otimizar por exemplo, o tempo gasto com a manutenção ou implantação de servidores (se você é um administrador de sistemas) ou seu  tempo com os seus routers, switches etc. (se você é um engenheiro de redes).
Automatizar é o seu objetivo.

💡 Ansible = Automation

 

I, Robot - 20th Century Fox (2004)

 

I, Robot - 20th Century Fox (2004)

 

 

O ansible é da RedHat, muito simples de operar e você não precisa saber programar para usá-lo (pode te ajudar se souber, mas não é um pré requisito).

Abaixo seguem alguns conceitos de ansible, que precisamos entendê-los antes de operar o Ansible para a automação de rede/infraestrutura.

 

CONCEITOS FUNDAMENTAIS

  • Control node
    É de onde a mágica acontece, é apenas no control node que o ansible precisa ser instalado, pois como veremos mais adiante, o ansible é agentless, ou seja, ele opera sem a premissa de ter um client/agent instalado nos hosts que você quer atingir.

  • Managed nodes
    Aqui ficam os dispositivos de rede ou servidores que gerenciamos com o ansible no control node. Também chamados de hosts, não precisam ter o ansible instalados neles.

  • Inventory
    Onde listamos os nosso managed nodes que iremos gerenciar com o ansible, também conhecido como "hostfile" Toda a organização dos managed nodes é feita no inventory, que fica em /etc/ansible/hosts

  • Modules
    Um módulo normalmente abstrai uma tarefa do sistema, como lidar com pacotes ou criar e alterar arquivos. O Ansible possui diversos módulos integrados, com um utilitário chamado
    ansible-doc
     é possível consultar todos os módulos disponíveis numa instalação padrão do Ansible, mas você também pode criar módulos personalizados:

$ ansible-doc -l
  • Tasks
    São tarefas para executar nos hosts. Podemos executá-las com comandos ad-hoc diretamente na linha de comando sem o uso de Playbooks, mas os comandos Ad-Hoc executam apenas um
    módulo por vez. E se quisermos criar uma sequência de tarefas com os módulos disponíveis? Aí que entram as playbooks.
  • Playbooks
    Listas ordenadas de tarefas, a playbook basicamente é composto por ‘play’ e ‘tasks’. Uma ‘play’ é análoga a uma jogada ensaiada de basquete. Define-se quais jogadores participarão (Hosts
    alvo) e quais passos (tasks) serão executados. As playbook são escritas em YAML.

 

POR QUE USAR ANSIBLE?

Como vimos anteriormente, não há mais espaço para tarefas repetitivas hoje em dia, precisamos automatizar essas tarefas e otimizar o nosso tempo e produtividade, vamos a um exemplo simples:

Um administrador provisiona 100 servidores por dia e deve executar uma série de comandos em cada um deles antes de entregá-los aos usuários, "meio" trabalhoso, né?!

Com ansible esses comandos podem ser colocados em uma playbook e executados nos 100 servidores, em uma tacada só.

Não foi fornecido texto alternativo para esta imagem

É isso mesmo, não é necessário acessar todas as 100 máquinas (managed nodes) para rodar os comandos, você só precisa fazer a gerência dessa configuração no seu ansible (control node) e uma executar uma vez e irá atingir os 100 servidores. Que tal?

Stress I Need A Drink GIF - Find & Share on GIPHY

 


ANSIBLE É AGENTLESS (SEM AGENTE)

O fato de o ansible ser agentless é uma das coisas mais legais, porque não precisamos instalar um client/agent no host que queremos gerenciar e muitas vezes isso não é possivel, especialmente
para engenheiros de redes porque por exemplo, temos routers e switches Cisco rodando cisco IOS, não é possível instalar coisas neles. Portanto todas as instruções são executadas em uma máquina
de controle que se comunica com clientes remotos por SSH.

Não foi fornecido texto alternativo para esta imagem

 

Idempotência e ansible

Eu confesso que nem conhecia o significado dessa palavra, mas vi que ela é bastante recorrente quando o assunto é automação de TI, parafraseando o glossário do ansible "uma operação é
idempotente se o resultado da sua execução é sempre o mesmo sem que haja qualquer intervenção." O que isso quer dizer? Quer dizer que você pode executar seus playbooks várias
vezes e o resultado final deveria ser o mesmo: os managed nodes estarão no "estado desejado". Se o playbook falhar, é possível solucionar o problema e executar o playbook novamente. Como o
playbook é idempotente, os managed nodes precisam estar no "estado desejado" e nenhuma outra mudança ocorrerá.

No link abaixo temos o glossário do ansible:
https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html

 

 

Lab de ansible + vagrant

Agora vamos brincar um pouco de ansible.

Requisitos:

  • Instalação do Ansible em um control node.
  • Acesso SSH para se comunicar com os managed nodes.
  • E python, o ansible pode ser executado com o Python 2 (versão 2.7) ou Python 3 (versões 3.5 e
    superior) instalado.

 

Infraestrutura do lab

Para podermos executar um pouco dessa teoria, vamos criar um simples laboratório composto por três "maquinetas":

  • Uma VM será o Control Node
  • Duas VMs para Managed Nodes


Não foi fornecido texto alternativo para esta imagem

O provisionamento dessas máquinas será feito com o Vangrant, escrevi um artigo sobre isso aqui.

 

Instalando o ansible no control node (Ubuntu):

[vagrant@ansible-control:~] $ sudo apt update
[vagrant@ansible-control:~] $ sudo apt install software-properties-common
[vagrant@ansible-control:~] $ sudo apt-add-repository ppa:ansible/ansible
[vagrant@ansible-control:~] $ sudo apt install ansible -y

 

Lembrando que como o ansible é agentless, essa instalação é feita apenas no control node.

Instalação do ansible:
https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html


Hosts (Inventory)

Agora vamos listar os managed nodes que queremos atingir nesse laboratório.

Acessando /etc/ansible/ e se listarmos o conteúdo desse diretório:

Não foi fornecido texto alternativo para esta imagem

Podemos ver o arquivo ansible.cfg que é o arquivo de configuração do ansible e o arquivo hosts que é onde vamos fazer o inventário dos managed nodes.

Lembrando que o arquivo hosts é um ponto chave no funcionamento do ansible, ele é o inventário e todos os managed nodes que queremos controlar devem estar aqui.

Vamos usar um editor de texto vim para editar esse arquivo e inserir os dois servidores do lab:

[vagrant@ansible-control:~/etc/ansible] $ sudo vim hosts


No final do arquivo vou inserir os servidores, como boa prática recomenda-se inserir por grupos e até mesmo por questão de elegância visual no arquivo, portanto no final do arquivo:

[webservers]
192.168.0.102
192.168.0.103

O [webservers] é o grupo e abaixo inseri os endereços IP dos servidores. E assim apontamos os managed nodes no nosso querido inventário.

Agora para podermos autenticar nos managed nodes, vamos utilizar o método de par de chaves SSH.
Para maiores informações, sobre o assuntoo acesse: https://www.ssh.com/ssh/key/


Acesso SSH

Primeiro vou gerar o par de chaves no control node.

[vagrant@ansible-control:~/.ssh] $ ssh-keygen 

Esse comando gera um par de chaves, conhecidas como chave pública e chave privada, esse não é o foco desse artigo, mas usando uma analogia:

  • Chave pública (public key) fica no host que quero acessar = cadeado. 🔒
  • Chave privada (private key) fica no host que estou usando para acessar = chave. 🔑


As chaves são geradas num diretório oculto da home do usuário (.ssh). No exemplo do laboratório:

/home/vagrant/.ssh/


Agora vamos copiar essas chaves para os managed nodes usando o utilitário ssh-copy-id.

[vagrant@ansible-control:~/.ssh] $ ssh-copy-id vagrant@192.168.0.102
[vagrant@ansible-control:~/.ssh] $ ssh-copy-id vagrant@192.168.0.103

O que esse comando faz é copiar a chave pública para o host de destino em /home/vagrant/.ssh/authorized_keys que é o arquivo que lista as conexões SSH autorizadas para o
host.

Feito isso temos conexão com os managed hosts por par de chaves SSH.

Comandos ad-hoc

Havendo conexão SSH entre o control node e os managed nodes, vamos começar a brincar de ansible, primeiro com comandos ad-hoc que como vimos anteriormente são comando executados
direto na linha de comando.

Vamos testar a comunicação com o comando abaixo:

[vagrant@ansible-control] $ ansible all -m ping


E conforme a saída do comando, tudo ocorreu bem e estamos com comunicação entre o control node e os managed nodes.

Não foi fornecido texto alternativo para esta imagem

Uma outra forma de fazer isso é em vez de declarar "all" significando todos os managed nodes do inventário, posso passar apenas o nome do grupo, o que é muito útil, aqui é um lab, mas numa 
infraestrutura real você poderá ter grupos de servidores, grupos de routers, switches etc. e você pode querer aplicar determinada ação a apenas um grupo específico e não em todos (all).

 

Então em vez disso, declaramos o nome do grupo [webservers].

[vagrant@ansible-control] $ ansible webservers -m ping


Não foi fornecido texto alternativo para esta imagem

 


Outro exemplo simples de comando ad-hoc para localizar o nome e a versão do sistema operacional dos dois managed nodes:

[vagrant@ansible-control] $ ansible webservers -a "cat /etc/os-release"


Não foi fornecido texto alternativo para esta imagem

 

Ou podemos executar um comando do módulo de shell direto nos servidores, criando um arquivo vazio em /tmp/ com nome "novo":

[vagrant@ansible-control] $ ansible webservers -m shell -a "touch/tmp/novo"


Não foi fornecido texto alternativo para esta imagem

Agora que entendemos os elementos básicos da execução do Ansible, podemos ir para a automação de tarefas repetitivas usando Playbooks.

 

Playbooks

O jeito mais poderoso de usar ansible é por meio de playbooks, como vimos anteriormente, uma playbook basicamente é composto por ‘play’ e ‘tasks’ e é um arquivo YAML (.yml).

É recomendado começar com playbooks simples, para que a medida que o entendimento com relação a estrutura das playbooks for crescendo, você vá expandindo as possibilidades..

Vamos criar um playbook muito simples apenas para teste nesse lab.

[vagrant@ansible-control] sudo vim check-nano.yml
--- #Sempre inicia com esses três traços
  - name: check-nano #Play
    remote_user: root 
    hosts: webservers #Grupo ou All
    tasks: #Task
      - name: garantir que o nano esteja lá
        apt: #Module
          name: nano
          state: latest #estado

Portanto ao executar esse playbook, eu quero checar se o editor de texto nano está instalado e na versão mais recente nesses servidores pertencentes ao grupo webservers e se não estiver instalado,
passei o módulo apt para instalação do mesmo.

Não foi fornecido texto alternativo para esta imagem



Executar playbook

Para executar o playbook, rode o comando abaixo:

[vagrant@ansible-control] $ ansible-playbook -check-nano.yml

Não foi necessário especificar o grupo, pois fizemos isso dentro do playbook.

Saída do comando:

Não foi fornecido texto alternativo para esta imagem


Antes de executar esse playbook, eu me certifiquei de que o nano não estava presente nos servidores de destino, justamente para podermos observar as saídas do comando.


Agora que foi instalado com sucesso o nano, vamos executar mais uma vez o playbook:

[vagrant@ansible-control] $ ansible-playbook -check-nano.yml


Não foi fornecido texto alternativo para esta imagem

Lembra da tal Idempotência? Que podemos executar um playbook várias vezes e o resultado final será o mesmo: desde que os managed nodes estejam no "estado desejado"? Pois é, nesse ponto  os meus servidores estão com o estado desejado (com o nano instalado em cada um deles), sendo assim não ocorre nenhuma alteração (changed=0) quando executei o playbook novamente. 

Sensacional!

Não foi fornecido texto alternativo para esta imagem


Enfim pessoal, usamos apenas exemplos simples nesse lab, mas é possível fazer coisas muito maiores com essa ferramenta espetacular, estude ansible!

Você pode encontrar mais informações na documentação oficial do ansible:
https://docs.ansible.com


Abraços!


Max
📧 contato@maxaddress.com.br
ℹ️ linkedin.com/in/maxwlima
🌐 www.maxaddress.com.br

1 Comentário
Primeiros Passos

Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.

Estamos felizes por você estar aqui! Participe da conversa, encontre respostas, faça perguntas e conecte-se com sua comunidade.