Ansible descomplicado

Vamos instalar as ferramentas necessárias para o treinamento como Git, Virtualbox e Vagrant.

Neste vídeo, dedicaremos a criação das máquinas virtuais utilizando Vagrant. Teremos um laboratório completo em pouco tempo, em compliante e automatizado.

Vamos aprender as formas de acesso das máquinas virtuais para dar continuidade ao treinamento e ambientar o Ansible Master e sistemas operacionais gerenciados.

Vamos instalar o Ansible em poucos minutos.

Inventário: Arquivo que descreve as máquinas a serem acessadas pelo Ansible e suas particularidades.

Anteriormente precisamos mencionar o IP do servidor, em uma infraestrutura, geralmente damos nomes ao servidores para comunicar-se com eles. Neste vídeo iremos fazer isto.

Vamos criar relação de confiabilidade, uma chave ssh no *Master*, transferir para a máquina remota e em seguida validar que estamos conectando sem senha quando informamos a chave.

Para concluir o módulo, vamos enviar nosso Inventário para o arquivo padrão, assim não precisamos repetir a sintaxe -i hosts.

Ad hoc significa “para esta finalidade", “para isso” ou "para este efeito". É uma expressão latina, geralmente usada para informar que determinado acontecimento tem caráter temporário e que se destina para aquele fim específico.

Um exame ad hoc, um método ad hoc, um cargo ou uma função ad hoc, são exemplos que definem a criação de algo provisório, que vai atender apenas determinado propósito.

ADHOC no Ansible, São comandos executados diretamente na linha de comando com a instrução que deseja, vamos supor que você precise dar um start/stop/restart em um serviço em uma série de servidores, ou você precise saber quais servidores estão com a configuração X, ou ver espaço em disco, memória, ou talvez você queira instalar um pacote, enfim são N possibilidades, mais você só quer fazer isso em um dado momento e não necessariamente guardar essa configuração em playbook.

Módulos são pequenos programas que efetuam alguma ação no nó alvo, por exemplo ping, shell, powershell e outros.

Conheceremos o módulo Shell.

No exemplo, criaremos o arquivo teste e enviaremos ao servidor ubuntu.

Com o módulo *apt* instalamos um pacote na base Debian.

Com o módilo *yum* instalamos um pacote na base Red Hat.

Com o módilo *package* instalamos um pacote na base Red Hat ou Debian.

Fatos é um termo usado para informações do sistema dos nós gerenciados pelo Ansible. As informações do sistema podem ser sobre distribuição do SO, versão, processador, endereço IP, etc. A tarefa de coletar essas informações do sistema remoto é chamada de  "Gathering facts" em tradução "Coleta de fatos" e os dados coletados ou informações coletadas são chamados de factos ou variáveis. Usamos setup o módulo **setup** para coletar fatos dos nós gerenciados.

Neste vídeo, aprenderemos como utilizar o módulo git e seus recursos utilizáveis.

O Módulo uri apresenta uma boa alternativa para testar a URL de um site. A seguir, utilizaremos o parâmetro *status_code* para testar se está ou não ativo.

Vamos criar um sistema de arquivos. facilmente com o modulo filesystem.

Com o módulo *mount*, controlamos os pontos de montagem ativos e configurados.

Vamos montar o sistemas de arquivos criado anteriormente.

O módulo *at* Agenda a execução de um comando ou arquivo de script.

Com o módulo *cron* podemos gerenciar entradas cron.d e crontab, com um processo mais robusto que o at.

Com o módulo *service* Controlamos serviços. Os sistemas init suportados incluem SysV, systemd, upstart e outros.

Este módulo *timezone* configura a configuração do fuso horário, tanto do relógio do sistema quanto do relógio do hardware.

Para escrevermos um Playbook, precisamos saber o básico de YAML, a linguagem utilizada para dar vida aos Playbooks.

Vamos produzir o seguinte resultado neste módulo:

- Instalar o Nginx garantindo que está ativo e iniciando com o sistema;

- Garantir que o arquivo de configurações do Nginx esteja integro e fazer o deploy de uma página.

- Aprender a criar template baseado em variáveis dos facts, retornados pelo módulo *setup*

- Fazer o deploy do template.

Ansible não é uma linguagem de programação completa, mas possui vários recursos de linguagem de programação, e um dos mais importantes é a substituição de variáveis. Existem diferentes tipos de variáveis ​​disponíveis no Ansible.

Variáveis ​​definidas passando *-e* ou *--extra-vars* com *var=value* têm a precedência mais alta, o que significa que você pode usar isso para substituir variáveis ​​que já estão definidas.

Variáveis ​​definidas passando *-e* ou *--extra-vars* têm a precedência mais alta, o que significa que você pode usar isso para substituir variáveis ​​que já estão definidas.

Se você estiver usando o playbook ansible em algum projeto, não é recomendável modificar o arquivo de inventário. Temos uma solução mais limpa disponível para definir variáveis ​​de host e grupo no Project.

Para definir a variável do host podemos criar um subdiretório host_vars e da mesma forma para definir a variável do grupo podemos criar um subdiretório group_vars dentro do diretório principal do projeto.

Sabemos que, por padrão, todas as tarefas em um playbook são executadas, mas para algum propósito, se você deseja desabilitar uma tarefa, podemos fazer isso usando tags. Você pode simplesmente atribuir a respectiva tag *never* na tarefa e essa tarefa não será executada por padrão, a menos que você chame especificamente o nome da tag dessa tarefa.

As tags Ansible são outro ótimo recurso que pode ajudá-lo a executar as respectivas tarefas. Por padrão, todas as tarefas do playbook são executadas, mas com tags podemos controlar esse comportamento e executar apenas as tarefas com as tags correspondentes.

Sabemos que, por padrão, todas as tarefas em um playbook são executadas, mas para algum propósito, se você deseja desabilitar uma tarefa, podemos fazer isso usando tags. Você pode simplesmente atribuir a respectiva tag *never* na tarefa e essa tarefa não será executada por padrão, a menos que você chame especificamente o nome da tag dessa tarefa.

Neste capítulo, será apresentado uma visão geral da estrutura de diretórios de roles do Ansible.   

Ao trabalhar com o Ansible, é recomendável usar diretórios de projetos para que o conteúdo possa ser organizado de maneira consistente. Cada diretório de projeto pode ter seu próprio inventário e ansible.cfg, bem como playbooks, arquivos, modelos, etc.

- **Roles**, em tradução livre para o português **Funções**.

- Os playbooks Ansible podem ser muito semelhantes: o código usado em um playbook pode ser útil em outros playbooks também

- Uma role do Ansible é composta por várias pastas, cada uma contendo vários arquivos YAML.

- Por padrão, eles têm um arquivo main.yml, mas podem ter mais de um quando necessário.

- Cada função do Ansible deve conter pelo menos um dos seguintes diretórios que veremos, dependendo do Playbook, vários ou todos eles.