Ansible — Grosso modo
Basicamente é usado pelo fato de não ter o agente, muito usado para fazer o provisionamento em situações em que você precisa ir até uma máquina e não necessariamente voltar até ela, ou seja, ele não faz o compliance (não mantém a configuração) e é muito bom porque usa o protocolo SSH. É muito usado em ambientes de cloud e para fazer deploys.
A arquitetura é Master to nodes, ou seja, não usa agente, e sim um nó de gerenciamento que faz acesso utilizando o SSH.
A linguagem usada é o YAML. Básica, intuitiva, a ‘tampa da panela’ para o Ansible rs. Para todas as informações, consulte:
www.yamllint.com
yaml-online-parser.appspot.com
No meu laboratório:
- Criei chaves:

Logo após salvar o caminho das chaves é possível ainda adicionar mais uma camada de segurança:

Mas a intenção aqui é tornar este acesso o mais automatizado possível, ou seja, na hora que rodarmos um script (playbook) do Ansible queremos que a função seja executada sem nenhuma camada fazendo uma pergunta de segurança. Portanto apenas ignore, e aperte ENTER (rs).
Conceito básico das chaves:
pública = cadeado
privada = chave
Ou seja, o nó de gerenciamento deve ter a chave privada (chave) e as máquinas gerenciadas, o cadeado (pública). Assim a chave abre o cadeado.
Logo após, copiei a chave pública (cadeado) para minhas máquinas:

(Perceba que na primeira vez, ainda é preciso digitar a senha para autenticar).
(Usei o nome da máquina “docker” pois meu IP está sendo resolvido através do meu “resolv.conf”).
Agora sim, vamos lá!
2. Instalando o Ansible:

Existem dois arquivos de configuração:

Basicamente, em ansible.cfg podemos setar valores e interagir com as configurações, e em Hosts fica o inventário, aonde setamos uma lista de máquinas que irão receber tudo o que o Ansible enviar.
Apenas para exemplificar (e não me prolongar muito), em ansible.cfg posso setar (descomentar > #) qual o caminho da chave (aquela mesmo que criei anteriormente) que o Ansible irá usar para se conectar nas máquinas:

Já no arquivo Hosts, existem diversas formas de declarar as máquinas no arquivo (todas as instruções estão no próprio arquivo). Funciona mais ou menos como um “resolv.conf” rs.
3. Cliente do Ansible
Com as chaves OK e o Ansible instalado (e devidamente configurado conforme as características do ambinte), podemos fazer um teste usando o ‘cliente’ do Ansible, sem uso de playbook:

Aqui foi feito um “ls no /” em uma das máquinas gerenciadas pelo nó. Não é incrível? rsrs.
O cliente é muito útil mas a mágica real acontece dentro dos PLAYBOOKS, que são arquivos no formato .yml (YAML), que através do protocolo SSH ditam o que será feito na gerência.
4. Primeiro PLAYBOOK
Como exemplo, no primeiro teste padronizei o arquivo “resolv.conf” nas máquinas usando um PLAYBOOK:

(Daqui em diante é muito importante estar familiarizado com a linguagem YAML).

Dentro deste Playbook usamos módulos (ou plugins) do Ansible. Que são Scripts prontos em Python com a finalidade de executar alguma tarefa, exemplificando, no capítulo 3 através do cliente do Ansible usei o COMMAND, que executa um programa após “ “ < no nosso exemplo, o comando “ls /”.
Neste primeiro playbook, usei os seguintes módulos:
NAME (O que estou fazendo no playbook)
HOSTS (Quais são os hosts nos quais executo a tarefa)
TASKS (Quais são as tarefas que devem ser executadas — funciona como um “echo” na tela)
COPY (copia um arquivo de um lugar para outro, apresentando no playbook a origem “src=” e o destino de tal arquivo “dest=”.
Logo após, basta executar o PLAYBOOK:

E então para verificar, executo um CAT através do cliente Ansible:

De forma muito interessante posso também através do mesmo PLAYBOOK solicitar ao Ansible que faça coisas diferentes em hosts diferentes, bastando apenas ‘setar’ isso de forma muito intuitiva:

No exemplo uso o módulo APT para a instalação de um pacote sl, setando em HOSTS apenas o hostname das máquinas ao qual quero a instalação.
5. Criando variáveis
Posso reaproveitar o código que está dentro um PLAYBOOK para executar a mesma coisa alterando apenas os valores. Na prática criei um PLAYBOOK para criação de usuários:


VARS é o módulo para criar variável, e no caso, dentro de USERNAME posso criar diversos usuários apenas substituindo o valor “sysadmin” por “devops” por exemplo rs.
Ainda em TASKS, seto que o nome do usuário criado será de acordo com o valor de USERNAME e posso até definir qual será o interpretador do USER criado, no caso : “/bin/bash”.
Logo após é só executar o PLAYBOOK:

E claro, é possível interagir com a variável na linha de comando, agora instalando o usuário “developer”:

6. Loops no Ansible
Com o módulo WITH_ITEMS podemos criar uma lista de pacotes a serem instalados, e para que o módulo APT entenda isso podemos adicionar a variável {{ item }} dentro de NAME após TASKS, e o Ansible já irá entender que deve instalar a lista:

Apenas alterei o primeiro PLAYBOOK adicionando o módulo para percorrer a lista o no módulo APT setei que temos que interagir com os items > {{ item }} para a instalação de todos eles.
7. TASKS condicionais (módulo WHEN)

No exemplo testei se um arquivo existe ou não. Usando o módulo REGISTER para registrar a saída do comando.
Caso o Ansible não encontre o arquivo ele vai dar erro, para ignorar esse erro usei o módulo IGNORE_ERRORS: yes
Ou seja, se existir ou não existir o arquivo ele armazena e continua a tarefa.

Para fazer o ‘echo’ da bash do Linux usei o módulo SHELL.
Se o rc (result code) for igual a 0 ele não mostra a mensagem de que o arquivo esta indo pra lá, pois ele já está lá rsrs.
8. ROLES

A ROLE permite uma melhor organização. No laboratório usei as roles para instalar: Docker, Gitlab, Jenkins, Puppet e Rundeck.. o código foi montado em TASKS (tarefas) dentro da ROLE de cada um. No exemplo, Docker:

Existem dependencias para a instalação, assim como uma key (módulo APT_KEY). Sempre necessário consultar a documentação >
https://docs.docker.com/install/linux/docker-ce/ubuntu/
E o que achei mais interessante: uma ferramenta nativa do Ansible para resolver um problema de distribuição (versão):

O Ansible possui um Setup aonde é possível cosultar todas as informações da máquina, e isso ajudou muito, pois descobri que é possível usar todas as variáveis que estão no Setup dentro dos playbooks. Então ao dar um ‘grep’ descobri que existe uma variável que identifica a versão da distribuição, e adicionando a variável ao módulo do repositório torno meu PLAYBOOK genérico.
