Victor Ricardo

Temos somente mais esta postagem para concluir nossa intro e antes de irmos à pratica. Trarei no decorrer do texto os principais conceitos e termos que orbitam por este universo chamado ansible. Não pretendo me alongar demais aqui por quatro bons motivos: (1) a maior parte da teoria e discussão ficou bem pontuada anteriormente; (2) existe uma infinidade de material online disponível (sites, blogs, vídeos, livros, trabalhos acadêmicos) que tratam com primor e maior detalhamento tal ferramenta; (3) minha intenção é ter um viés hands-on (aprendizado prático em tradução livre) enquanto abordo o ansible; (4) elementos e palavras novas que ocasionalmente irão surgindo explanarei ao longo da série (com definições e exemplos).

Boa leitura e bons estudos machiners!!! 🧐

O QUE É ANSIBLE?

O Ansible é uma ferramenta de código aberto que pode ser usada para: (a) gerenciamento de configuração ou (b) automação de fluxos de trabalho.

De maneira sucinta, gerenciamento de configuração é trazer para o mundo real o conceito de “infraestrutura como código”. Em outras palavras, é colocar tarefas e comandos que são recorrentes do dia-a-dia dentro de um script automatizado, que será escrito uma vez (passível de futura revisão), e executado em várias máquinas ao mesmo tempo.

Já automação de fluxos de trabalho refere-se a qualquer processo ou procedimento da computação cuja complexidade foi reduzida à simplicidade de um script automático bem elaborado. Isso pode ser desde o provisionamento de uma infraestrutura em nuvem até a implantação de um software específico, por exemplo.

O Ansible foi escrito na linguagem de programação Python e utiliza o protocolo SSH para comunicação entre as partes envolvidas. Seu funcionamento será explicado mais adiante.

POR QUE AUTOMATIZAR?

(a) Mitigar o erro humano!

Pessoas digitam errado, interpretam mal, esquecem, colocam na ordem errada, etc. Isso é algo natural do ser humano. Sendo assim, é melhor deixar para as máquinas a execução de tarefas repititivas. Ou seja, o Ansible.

(b) Diminuir o tempo gasto!

Leva muito tempo fazer login em consoles, pesquisar configurações, conectar-se a servidores, escrever comandos. Então mais uma vez, deixe o computador fazer isso. Com o tempo que sobrar você pode focar em escrever novos códigos para automatizar outras coisas.

(c) Auto-documentação!

Você não precisa manter uma biblioteca virtual de blocos de nota (.TXT) com instruções/comandos e listas de verificação. Isso porque esses arquivos podem não ser atualizados, sendo negligenciados e consequentemente tornando-se ultrapassados, o que acaba não refletindo a realidade atual. Na “infraestrutura como código” a automação pode existir em um software de controle de versão, como o Git. Assim ela passa por processos de revisão por pares. E você sempre saberá quais foram as etapas seguidas bem como as decisões tomadas.

(d) Reprodutibilidade!

Reproduzível (nesse contexto específico) significa que a transição de DESENVOLVIMENTO para HOMOLOGAÇÃO para PRODUÇÃO é algo fácil de alcançar, ou seja, a infraestrutura imutável é simples de atingir, além de evitar que componentes falhos apareçam em suas pilhas e ambientes.

CARACTERÍSTICAS DO ANSIBLE

1) Gratuito:

Devido a sua natureza open-source, qualquer pessoa da comunidade pode baixá-lo, usá-lo e até contribuir com o desenvolvimento do seu código-fonte.

2) Simples instalação e uso:

A curva de aprendizagem é muito rápida, fora que também não é necessário altas habilidades em programação para utilizá-lo.

3) Poderoso:

Consegue lidar com modelos de infra/redes desde os pequenos até os mais complexos.

4) Flexível:

O analista responsável é capaz de orquestrar ambientes inteiros e separá-los em vários e por nome (ex: DESENVOLVIMENTO, HOMOLOGAÇÃO, PRODUÇÃO). Tudo isso graças ao recurso de inventários do ansible.

5) Sem agente:

Não é preciso instalar nenhum cliente/programa/daemon para desempenhar o papel de agente nos sistemas alvos (máquinas destino). A diferença é a ausência do pré-requisito de uma estrutura de gerenciamento separada para controle.

6) Idempotente:

Possui inteligência o suficiente para, caso um script seja executado várias vezes numa máquina em particular e a mesma não tenha sofrido nenhuma alteração desde então, o Ansible simplesmente ignora, pulando para a próxima sem refazer nenhuma instrução na vigente.

DO QUE O ANSIBLE É CAPAZ?

• Gerenciamento de configurações;
• Implantação de aplicações;
• Orquestração: Análogo ao maestro musical — Traz diferentes notas (tasks) produzidas por diferentes instrumentos (nodes) dentro de um trabalho artístico coeso (script);
• Segurança e conformidade;
• Provisionamento em nuvem

TERMINOLOGIA

• Tasks: uma tarefa é a menor unidade de trabalho. Pode ser qualquer ação como “criar um banco de dados” ou “remover regra de firewall”.
• Plays: uma play trata-se de um composto de tarefas. Exemplo, a seguinte play — “Preparar DB para um Nginx” é composto das tarefas:
  • Instalar o pacote de banco de dados;
  • Definir uma senha para o administrador do banco de dados;
  • Criar um banco de dados;
  • Definir o acesso ao banco de dados.
• Playbooks: um playbook é composto por um conjunto de plays. Um playbook poderia ser: “Preparar meu site com um backend de banco de dados”, e as plays seriam: 1) Configurar o servidor de banco de dados; e 2) Configurar o servidor web.
• Roles: As funções são usadas para salvar e organizar scripts, além de permitir compartilhar e reutilizar playbooks.
• Inventory: Por padrão o ansible só vem com um único arquivo de inventário, ele é o /etc/ansible/hosts. Mas é possível criar outros para separar os ambientes e hosts. Nesses arquivos você deve informar todos os parâmetros relacionados a cada máquina, como nome, ip, usuário, senha, etc.
• Ansible Galaxy: O Ansible Galaxy é um repositório online onde as funções são carregadas para que possam ser compartilhadas com outras pessoas. Está integrado com o GitHub.

ARQUITETURA E FUNCIONAMENTO

O Ansible opera conectando-se e enviando pequenos códigos de programação aos seus nós. Isso é denominado de “módulos”. O Ansible então executa esses miniprogramas (por padrão via SSH) e os remove uma vez concluídos. Essa biblioteca de módulos pode residir em qualquer máquina e não há servidores, daemons ou bancos de dados necessários, caracterizando assim uma arquitetura totalmente descentralizada.

O nó de gerenciamento é o nó de controle (ou máquina de controle) e este controla toda a execução do playbook. É o nó a partir do qual você está “disparando” a instalação. O arquivo de inventário fornece a lista de hosts onde os módulos do Ansible precisam ser executados. O nó de gerenciamento faz uma conexão SSH, executa tais módulos nos hosts, e o resultado é a instalação do produto/software (especificado no playbook) em todas as máquinas destino.

Como dito anteriormente, a beleza do Ansible reside em remover esses pequenos programas, logo após se conectar à máquina host, executar as instruções e, se for instalado com sucesso, o código copiado para o destino é apagado.

BREVE COMPARATIVO COM OUTRAS SOLUÇÕES

Ansible | Chef | Puppet

Chef e Puppet são outras duas ferramentas de automação bem populares. Todos os três podem ser usados para resolver problemas semelhantes e ter conjuntos de recursos semelhantes. Entretanto, existem duas diferenças principais entre Ansible e Chef / Puppet. Tanto o Chef quanto o Puppet são baseados principalmente em agentes. As máquinas gerenciadas pelo Chef / Puppet executam um agente. O agente volta à máquina de controle para ver quais mudanças precisam acontecer. Isso não requer SSH, mas requer infraestrutura para executar o servidor puppet / chef. O modelo sem agente da Ansible significa que é fácil começar e funciona com inventários menores. O Ansible também depende do SSH para se conectar às máquinas, portanto, a distribuição de chaves é outro aspecto a ser considerado.

Outra diferença é que o Chef e o Puppet usam uma linguagem específica de domínio (DSL) customizada para descrever o que fazer. O Chef na verdade usa código Ruby puro. A Puppet criou uma DSL totalmente nova. Contudo, existe um porém, se o indivíduo já conhece YAML, ele está apto para começar a escrever playbooks do Ansible. O que o torna dentre os três o mais amigável para se começar automação.

Em resumo, temos:

• * Ansible usa YML para descrever o trabalho;
• * Chef usa código Ruby para descrever o trabalho;
• * Puppet usa uma DSL personalizada para descrever o trabalho;
• * Chef / Puppet são baseados em agentes;
• * Ansible é baseado em SSH e push.