Estou usando esta publicação como revisão do conhecimento adquirido e de forma introdutória, para quem quiser aprender a usar o Ansible. 😁👍

👉 Utilize a seção Índice para navegar diretamente ao ponto que desejas estudar.

👉 Ao revisar este curso, acredito que o nível técnico nessário para entendê-lo é para profissionais já iniciados em computação! Leigos não entenderão quando estiver escrito para declarar variáveis, por exemplo.

👉 A parte prática só funcionará se você ler e interpretar o que está escrito. Caso sinta dificuldade ou esteja em dúvida, me manda um comentário que deixarei mais claro nesta aula e te respondo também.

👉 Todos os arquivos usados (caso não queira digitar ou copiar) estarão disponíveis aqui .

👉 A documentação tem praticamente tudo que você precisa e tudo que não estará aqui, também.

🤷 Qual a vantagem de aprender aqui? 👉 Farei da maneira mais didática possível, seguindo uma ordem e em pt-BR. O que eu não colocar aqui, já deixarei um link apontando o que você deve estudar na documentação.

Ansible? 🤔

Segundo o próprio site da documentação (e em tradução livre):

• Ansible é um projeto comunitário de código aberto patrocinado pela Red Hat , e é o jeito mais simples de automatizar a TI.
• Ansible é a única linguagem de automação que é usada por toda a equipe de TI, do administrador de sistemas e redes aos desenvolvedores e gerentes.
• O Ansible teve sua primeira versão lançada em 2012, escrito por Michael DeHaan. Em 2015, a empresa por trás do Ansible, foi comprada pela Red Hat.

Automatizar a TI? 🤔🤔

Sim! O Ansible funciona de forma centralizada e automatiza as tarefas de administração!

São características do Ansible:

• Não utiliza agentes: veja os pré-requisitos mais a frente, e não… não é necessário instalar clientes ou agentes nos nós gerenciáveis;
• Idempotente: Pode ser executado a mesma rotina mais de uma vez sem que o resultado se altere.

Como a Red Hat pode ganhar dinheiro com Ansible? 💰

Com serviços e produtos. Alguns exemplos:

• Vendendo um framework chamado Red Hat Ansible Automation Platform (antigo Ansible Tower)
• Vendendo treinamentos, exames e certificações para Red Hat Certified Engineer
• Vendendo treinamentos, exames e certificações aqui e aqui

Posso usar sem pagar? 💸

O Ansible é de código aberto e sob a licença GPL3. Em outras palavras, é software livre… ou seja, você pode modificá-lo a vontade, não há coleta de seus dados para nenhum fim e nunca será pago (mesmo se você alterá-lo, não pode cobrar pela sua versão do ansible).

Você pode encontrar o código fonte e outros detalhes aqui .

Queria usar o Ansible Automation Platform… 😢

Se não possuir interesse em pagar pela licença pelo motivo que for, você pode utilizar o projeto AWX Operator 😀. Este utiliza a licença Apache, que é um pouco mais permissiva que a GPL3.

Outra alternativa é utilizar o Ansible Semaphore , que seria uma altenativa entre o AWX Operator e utilizar o Ansible via CLI.

Pré-requisitos ✅

Há dois pontos de pré-requisitos. No nó de controle (onde ficará instalado o Ansible) e nos nós gerenciáveis (dispositivos fins que queira automatizar).

Nó de controle 💻

Precisa de Python 3.8+ instalado. Isso vale para sistema operacional com kernel linux (CentOS, Debian, Red Hat, …), macOS, qualquer BSD e via WSL do Windows .

Neste curso, utilizaremos o pip por ser recomendado pela documentação (é onde tem a versão mais recente e com correções mais rápidas)

Nós gerenciáveis ☁️

É necessário ter Python 2.6+ ou 3.5+, SSH e SFTP ou SCP.

Instalação 💾

No momento, a última versão do ansible é 9.2 e o ansible-core é 2.16.3.

pip e Ansible

Se seu sistema não possui o pip para instalar (via apt, yum, brew, etc…), segundo a documentação oficial , pode-se instalar, com seu usuário sem privilégios (para que não faça instalação globalmente), da seguinte forma:

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py --user

Usando este método, ao invés de executar apenas pip (ou pip3), você deverá executar python -m pip. Seguirei explicando com o comando simplificado.

Primeiro atualize o seu pip3, com seu usuário sem privilégios, utilizando o comando (o -U é de upgrade):

pip3 install -U pip

Agora instale o Ansible com o comando:

pip3 install -U ansible

Caso você tenha um Ansible muito antigo instalado via pip e apresentou erro ao fazer a instalação, desinstale-o e instale a nova versão, visto que atualizações de pacotes muito antigos podem causar problemas:

pip3 uninstall ansible
pip3 install ansible

Libvirt

Não usaremos o virtualbox, instale os seguintes pacotes:

• libvirt-daemon
• virt-manager

Para que seu usuário possa manipular máquinas virtuais, será necessário incluir seu usuário no grupo do libvirt ou libvirtd, dependendo da distribuição usada.

Para checar se o grupo existe, execute o comando, para libvirt:

sudo getent group | grep libvirt

Verifique se é libvirt ou libvirtd e, a seguir, adapte o comando para sua necessidade:

sudo usermod -a -G libvirt $(whoami)

Agora você pode usar máquinas vagrant libvirt!

Vagrant

Acesse https://www.vagrantup.com/downloads , baixe e instale o Vagrant conforme seu sistema operacional.

Precisa-se instalar o plugin vagrant-libvirt. Para instalá-lo, utilize o seguinte comando:

vagrant plugin install vagrant-libvirt

Vamos precisar dele para montar nosso laboratório.

Levantando o laboratório ⤴️

Os arquivos desta seção estão na pasta 01_Levantando_o_laboratório

Configurando o acesso com chaves via ssh 🔑

Comece gerando sua chave pública, caso não possua, com o comando:

ssh-keygen -t rsa

Para simplificar/facilitar, não forneça uma senha nessa etapa (deixe para usar a senha nessa etapa quando for pra valer).

O arquivo ~/.ssh/id_rsa.pub será utilizado no Vagrantfile, caso tenha utilizado outro caminho ou nome de arquivo, favor fazer os devidos ajustes.

O Vagrantfile

O arquivo Vagrantfile tem o seguinte conteúdo:

#!/usr/bin/env ruby

maquinas = {
  "maquina01" => "192.168.56.10/24",
  "maquina02" => "192.168.56.20/24",
  "maquina03" => "192.168.56.30/24"
}


Vagrant.configure("2") do |config|
  maquinas.each do |nome, ip|
    config.vm.define nome do |maquina|
      maquina.vm.box = "debian/bookworm64"
      maquina.vm.hostname = "%s" % nome
      maquina.vm.network "private_network", ip: ip, libvirt__network_name: "lab_ansible"
      maquina.vm.provider "libvirt" do |lv|
        lv.memory = 384
        lv.default_prefix = "lab_ansible_"
      end
    end
    config.nfs.verify_installed = false
    config.vm.synced_folder '.', '/vagrant', disabled: true
    config.vm.provision "shell" do |s|
      ssh_pub_key = File.readlines(File.join(Dir.home, ".ssh/id_rsa.pub")).first.strip
      s.inline = <<-SHELL
      echo #{ssh_pub_key} >> /home/vagrant/.ssh/authorized_keys
      SHELL
    end
  end
end

Em outras palavras, levantará três VMs para ser o lab em seu libvirt-daemon.

Para levantar seu ambiente Vagrant, vá para a pasta onde está o Vagrantfile e execute vagrant up. Basta esperar e tudo será configurado e estará funcionando.

O usuário é: vagrant A senha é utilizando certificado, logo, não é necessária.

Você pode testar o acesso fazendo um ssh vagrant@192.168.56.10.

Alguns comandos para gerenciamento das VMs ⌨️

Seguem alguns comandos que podem auxiliar a verificar se está tudo ok ☑️ e para limpar 🗑 sua máquina das VMs do laboratório.

Listar todas as VMs

virsh list --all

Listar as redes virtuais disponíveis

virsh net-list

Listar os IPs que foram definidos na primeira interface (DHCP)

virsh net-dhcp-leases vagrant-libvirt

Verificar box instalado

vagrant box list

Desligar VMs (execute no mesmo diretório do Vagrantfile)

vagrant halt

Remover o box do Debian

vagrant box remove debian/bookworm64

Apagar VMs criadas (execute no mesmo diretório do Vagrantfile)

vagrant destroy

Arquivos INI e YAML 📄

Basicamente são os tipos de arquivo que você terá de lidar no ansible e que irei abordar aqui no curso.

INI

Usado no arquivo de hosts e configuração do Ansible.

Observe este exemplo para entender melhor.

# Esta linha está comentada e é possível com "#" apenas no início da linha
; Esta linha também está comentada e é possível com ";" no início e em linhas com algum conteúdo

arquivo=caminho/arquivo.txt             ; A variável arquivo recebe (com o sinal de igua "=") o valor "caminho/arquivo.txt"
outroarquivo=caminho/outroarquivo.txt   ; Só é possível comentar na mesma linha se usando o ";". Comentar com "#" não funciona

[novasecao]                             ; Usando [] é possível criar seções dentro do mesmo arquivo INI
porta=1080                              ; Foi definido que a variável porta tem o valor 1080 e está dentro da seção novasecao

[outrasecao]                            ; Aqui começa a outrasecao, sendo o fim da novasecao
protocolo=tcp                           ; Foi definido que a variável protocolo tem o valor tcp e está dentro da seção outrasecao

[grupodesecoes:childrens]               ; É assim que se agrupa seções, colocando o nome da seção maior seguido de ":childrens"
novasecao
outrasecao

Exemplo do arquivo hosts

Exemplo 1:

[debian]
maquina01

[centos]
maquina02
maquina03

Exemplo 2, agrupando seções:

[debian]
maquina01

[centos]
maquina02
maquina03

[linux:childrens]     ; Agrupando as seções debian e centos, podendo ser invocados ao usar "linux"
debian
centos

Caso você não tenha definido uma configuração de acesso em seu ~/.ssh/config, você pode fazer assim como no arquivo ini do Exemplo 4:

[debian]
maquina01 ansible_host=192.168.56.10 ansible_port=22

Há várias variáveis que podem ser usadas no arquivo de hosts, cabendo vários exemplos e, inclusive, pode ser usado yaml ao invés de ini. Mais detalhes na documentação oficial sobre inventário .

Exemplo do arquivo ansible.cfg

Como já explicado anteriormente, utiliza o padrão INI.

Quanto ao exemplo de arquivo de configuração, algo rápido, seria assim:

[defaults]
inventory = hosts                 ; onde se encontra o arquivo de inventário
host_key_checking = False         ; para não ter de aceitar o certificado do primeiro ssh
ask_pass = True                   ; para perguntar a senha do usuário do ssh
nocows = True                     ; não exibir vacas... é sério... não é brincadeira
log_path = ./logs/ansible.log     ; caminho para gravação do log de atividades do ansible

[privilege_escalation]
become = True                     ; se vai usar sudo
become_ask_pass = True            ; perguntar a senha de sudo

Para mais parâmetros de configuração, acesse aqui na documentação .

YAML

O arquivo yaml normalmente é utilizado na escrita dos playbooks. O arquivo segue o seguinte padrão (versão traduzida de Aprenda Yaml em Y minutos ):

---  # início do documento

# Comentários em YAML são como este.

###################
# TIPOS ESCALARES #
###################

# Nosso objeto raiz (que continua por todo o documento) será um mapa,
# o que equivale a um dicionário, hash ou objeto em outras linguagens.
chave: valor
outra_chave: Outro valor vai aqui.
u_valor_numerico: 100
notacao_cientifica: 1e+12
boleano: true
valor_nulo: null
chave com espaco: valor
# Observe que strings não precisam de aspas. Porém, elas podem ter.
porem: 'Uma string, entre aspas.'
'Chaves podem estar entre aspas tambem.': "É útil se você quiser colocar um ':' na sua chave."
aspas simples: 'possuem ''um'' padrão de escape'
aspas duplas: "possuem vários: \", \0, \t, \u263A, \x0d\x0a == \r\n, e mais."
# Caracteres UTF-8/16/32 precisam ser codificados
Superscript dois: \u00B2

# Seqüências de várias linhas podem ser escritas como um 'bloco literal' (utilizando |),
# ou em um 'bloco compacto' (utilizando '>').
bloco_literal: |
Todo esse bloco de texto será o valor da chave 'bloco_literal',
preservando a quebra de com linhas.

O literal continua até 'des-indentar', e a primeira identação é 
removida.

  Quaisquer linhas que são 'mais identadas' mantém o resto de suas identações - 
  estas linhas serão identadas com 4 espaços.
estilo_compacto: >
Todo esse bloco de texto será o valor de 'estilo_compacto', mas esta
vez, todas as novas linhas serão substituídas com espaço simples.

Linhas em branco, como acima, são convertidas em um carater de nova linha.

  Linhas 'mais-indentadas' mantém suas novas linhas também -
  este texto irá aparecer em duas linhas.

####################
# TIPOS DE COLEÇÃO #
####################

# Texto aninhado é conseguido através de identação.
um_mapa_aninhado:
chave: valor
outra_chave: Outro valor
outro_mapa_aninhado:
  ola: ola

# Mapas não tem que ter chaves com string.
0.25: uma chave com valor flutuante

# As chaves podem ser também objetos multi linhas, utilizando ? para indicar o começo de uma chave.
? |
Esta é uma chave
que tem várias linhas
: e este é o seu valor

# YAML também permite o mapeamento entre sequências com a sintaxe chave complexa
# Alguns analisadores de linguagem de programação podem reclamar
# Um exemplo
? - Manchester United
- Real Madrid
: [2001-01-01, 2002-02-02]

# Sequências (equivalente a listas ou arrays) semelhante a isso:
uma_sequencia:
- Item 1
- Item 2
- 0.5 # sequencias podem conter tipos diferentes.
- Item 4
- chave: valor
  outra_chave: outro_valor
-
  - Esta é uma sequencia
  - dentro de outra sequencia
- - - Indicadores de sequência aninhadas
    - podem ser recolhidas

# Como YAML é um super conjunto de JSON, você também pode escrever mapas JSON de estilo e
# sequências:
mapa_json: {"chave": "valor"}
json_seq: [3, 2, 1, "decolar"]
e aspas são opcionais: {chave: [3, 2, 1, decolar]}

###########################
# RECURSOS EXTRAS DO YAML #
###########################

# YAML também tem um recurso útil chamado "âncoras", que permitem que você facilmente duplique
# conteúdo em seu documento. Ambas estas chaves terão o mesmo valor:
conteudo_ancora: &nome_ancora Essa string irá aparecer como o valor de duas chaves.
outra_ancora: *nome_ancora

# Âncoras podem ser usadas para duplicar/herdar propriedades
base: &base
name: Todos possuem o mesmo nome

# O regexp << é chamado Mesclar o Tipo Chave Independente-de-Idioma. É usado para
# indicar que todas as chaves de um ou mais mapas específicos devam ser inseridos
# no mapa atual.

foo:
<<: *base
idade: 10

bar:
<<: *base
idade: 20

# foo e bar terão o mesmo nome: Todos possuem o mesmo nome

# YAML também tem tags, que você pode usar para declarar explicitamente os tipos.
string_explicita: !!str 0.5
# Alguns analisadores implementam tags específicas de linguagem, como este para Python de
# Tipo de número complexo.
numero_complexo_em_python: !!python/complex 1+2j

# Podemos utilizar chaves YAML complexas com tags específicas de linguagem
? !!python/tuple [5, 7]
: Fifty Seven
# Seria {(5, 7): 'Fifty Seven'} em Python

####################
# YAML TIPOS EXTRA #
####################

# Strings e números não são os únicos que escalares YAML pode entender.
# Data e 'data e hora' literais no formato ISO também são analisados.
datetime: 2001-12-15T02:59:43.1Z
datetime_com_espaços: 2001-12-14 21:59:43.10 -5
date: 2002-12-14

# A tag !!binary indica que a string é na verdade um base64-encoded (codificado)
# representação de um blob binário.
gif_file: !!binary |
R0lGODlhDAAMAIQAAP//9/X17unp5WZmZgAAAOfn515eXvPz7Y6OjuDg4J+fn5
OTk6enp56enmlpaWNjY6Ojo4SEhP/++f/++f/++f/++f/++f/++f/++f/++f/+
+f/++f/++f/++f/++f/++SH+Dk1hZGUgd2l0aCBHSU1QACwAAAAADAAMAAAFLC
AgjoEwnuNAFOhpEMTRiggcz4BNJHrv/zCFcLiwMWYNG84BwwEeECcgggoBADs=

# YAML também tem um tipo de conjunto, o que se parece com isso:
conjunto:
? item1
? item2
? item3
ou: {item1, item2, item3}

# Como Python, são apenas conjuntos de mapas com valores nulos; o acima é equivalente a:
conjunto2:
item1: null
item2: null
item3: null

...  # fim do documento

Exemplo de arquivos YAML

hosts: web

tasks:
- name: Garantindo que o apache2 está atualizado
  apt:
    name: apache2
    state: latest
- name: Escrevendo o arquivo de configuração do apache2
  template:
    src: ./templates/apache.j2
    dest: /etc/apache/apache.conf

Aprendendo a configurar o Ansible 🔧

Há considerações de segurança relacionada ao ansible.cfg.

Não deixá-lo numa pasta com permissão de escrita para qualquer um. (um usuário poderia substituir o arquivo e rodar código malicioso localmente e remotamente)

Se o arquivo estiver dentro de um Vagrant ou WSL, montar a partição com as configurações do Ansible limitadas a certos usuários e grupos.

As configurações no Ansible segue uma sequência de prioridades na busca das informações de configuração. A ordem de prioridade da maior para a menor é a seguinte:

• ANSIBLE_CONFIG (variável de ambiente se definida)
• ansible.cfg (no diretório atual, precisa de permissão de escrita apenas para o usuário, chmod 644 ansible.cfg)
• ~/.ansible.cfg (na pasta do usuário, precisa de permissão de escrita apenas para o usuário, chmod 644 ~/.ansible.cfg)
• /etc/ansible/ansible.cfg

Arquivo ansible.cfg para usarmos no laboratório

Os arquivos desta seção estão na pasta 02_Arquivos_de_configuracoes_para_usarmos_no_laboratorio

Já apresentei um arquivo de configuração do Ansible, anteriormente, mas agora será apresentado o que utilizaremos no nosso laboratório.

Na pasta em que você reservou para o Ansible, utilize o seguinte arquivo ansible.cfg:

[defaults]
inventory = hosts                     ; arquivo padrão de hosts
host_key_checking = False             ; para não dar problema nos hosts que não foram feitos os primeiros acessos ssh, que pede para aceitar o certificado
nocows = True                         ; não gosto das vacas aparecendo
deprecation_warnings = False          ; podem aparecer alguns avisos de deprecation
forks = 10                            ; paralelizando a coisa quando houver vários hosts
log_path = ./logs/ansible.log         ; gravar um log em arquivo

[privilege_escalation]
become = True                         ; tornar-se root

Mais opções de configuração para o ansible.cfg

Se deseja saber TODAS as opções possíveis, acesse o link da documentação .

Arquivo de hosts usados no laboratório

Os arquivos desta seção estão na pasta 02_Arquivos_de_configuracoes_para_usarmos_no_laboratorio

No laboratório, utilizaremos as seguintes configurações (conforme o arquivo do Vagrant):

maquina01 ansible_host=192.168.56.10 ansible_user=vagrant
maquina02 ansible_host=192.168.56.20 ansible_user=vagrant
maquina03 ansible_host=192.168.56.30 ansible_user=vagrant

Perceba que foram passados os parâmetros junto aos hosts. Poderíamos preencher, também, separando em arquivos. Porém, ao separar, só é possível usar YAML, ao invés do INI (conforme documentação ).

Fica a seu critério escolher como configurará seus hosts, seja separando ou junto com suas respectivas variáveis.

Os arquivos ALTERNATIVOS desta seção estão na pasta 02.01_Arquivos_de_configuracoes_para_usarmos_no_laboratorio_hosts_alt

Arquivo de hosts:

[laboratorio]
maquina01
maquina02
maquina03

No arquivo ./group_vars/laboratorio para definir o que é comum ao grupo de nome laboratorio:

---
ansible_user: vagrant

No arquivo ./host_vars/maquina01 para definir o que é exclusivo ao host de nome maquina01:

---
ansible_host:192.168.56.10

No arquivo ./host_vars/maquina02 para definir o que é exclusivo ao host de nome maquina02:

---
ansible_host: 192.168.56.20

No arquivo ./host_vars/maquina03 para definir o que é exclusivo ao host de nome maquina03:

---
ansible_host: 192.168.56.30

Usando o modo ad hoc

É possível utilizar o ansible sem playbook. Conheça, então, um modo de uso do ansible que é o ad hoc.

Vamos fazer um ping em todas as máquinas com o comando:

ansible all -m ansible.builtin.ping

Veja agora as versões do linux com o comando:

ansible all -m ansible.builtin.shell -a "lsb_release -a"

Apenas para explicar:

• -m - O módulo a ser utilizado
• -a - O parâmetro para ser usado no módulo

Saiba quais são todos os facts da maquina01 com o comando:

ansible maquina01 -m ansible.builtin.setup

Com esse módulo, é possível filtrar os facts para coletar informações úteis, como todos os IPv4 disponíveis na maquina01:

ansible maquina01 -m ansible.builtin.setup -a "filter=ansible_all_ipv4_addresses"

Para mais detalhes, acesse a documentação

Primeiro playbook 🏁

Os arquivos desta seção estão na pasta 03_Primeiro_playbook

Vamos instalar o servidor web/proxy nginx na maquina01.

Crie o arquivo nginx.yml com o seguinte conteúdo:

---
- hosts: maquina01
tasks:
  - name: Instalar o nginx
    apt:
      pkg: nginx
      state: present
      update_cache: true
...

Com o arquivo ansible.cfg e hosts criados como orientado anteriormente, execute no terminal:

ansible-playbook nginx.yml

Pronto! Será instalado o nginx na maquina01.

Observações 👀

Há os tipos de eventos em cada execução de tarefa ou de handlers:

• Ocorrerão eventos como OK e CHANGED, mas há outros como o UNREACHABLE, FAILED e SKIPPED também;
• OK - Foi executado com sucesso;
• CHANGED - Foi executado com sucesso mas houve modificações;
• UNREACHABLE - Não foi possível se comunicar com o destino (está desligado, endereço errado, rede inalcançável, etc);
• SKIPPED - Não foi necessário executar (por causa de uso do when, por exemplo);
• FAILED - Algo de errado não está certo, falhou, deu ruim. Será necessário ler a mensagem de erro para proceder com a solução;

O playbook deu sucesso, mostrando a mensagem CHANGED. O que acontece se rodar novamente o playbook?

• Se você executar o playbook novamente, perceberá que não existirá mais nenhuma tarefa como CHANGED, mas como OK se der tudo certo.

Pretendo abordar o máximo possível do que está neste link de dicas e truques para playbooks do ansible . Caso não consiga, deixarei-o acessível aqui. 🙂

Segundo playbook ✌

É basicamente o primeiro playbook, porém ampliado e expandido. 🤣

Os arquivos desta seção estão na pasta 04_Segundo_playbook. Foi usado a segunda forma de organizar o arquivo de hosts, separando em diretórios.

No NGINX, será removido a configuração default do sites-enabled e criaremos a configuração do site_legal.

Arquivos necessários ☑

Localizações e arquivos:

• files/site_legal/index.html

<!DOCTYPE html>
<html lang="pt-BR">
<head>
<meta http-equiv="Content-Type"
      content="text/html; charset=utf-8">

<html>
    <head>
        <title>Olá mundo!</title>
    </head>
    <body>
        <h1>Olá mundo!!</h1>
        <p>Estou funcionando perfeitamente.</p>
        <hr>
        <p>Funcionou de primeira.</p>
    </body>
</html>

• templates/site_legal.conf.j2

server {
listen 80;

root {{ pasta_raiz_nginx }}/{{ pasta_site }};
index index.html index.htm;

server_name {{ nome_servidor }};

location / {
 default_type "text/html";
 try_files $uri.html $uri $uri/ =404;
}
}

O playbook 📖

Como deve ficar o playbook em si (vou encher de comentários para ampliar as explicações)

No playbook site_legal_nginx.yml contém:

---
- hosts: maquinawx-01
  vars:
    nome_servidor: "{{ ansible_default_ipv4.address }}"
    pasta_raiz_nginx: /var/www
    nome_site: site_legal
    pasta_site_local: "files/{{ nome_site }}"
    usuario_nginx: "www-data"

  tasks:
    - name: Instala o nginx
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Copia o arquivo html do site_legal
      copy:
        src: "{{ pasta_site_local }}"
        dest: "{{ pasta_raiz_nginx }}"
        owner: "{{ usuario_nginx }}"
        group: "{{ usuario_nginx }}"
        mode: preserve

    - name: Remove site default
      file:
        path: /etc/nginx/sites-enabled/default
        state: absent
      notify: Reiniciar NGINX

    - name: Cria site site_legal
      template:
        src: templates/site_legal.conf.j2
        dest: "/etc/nginx/sites-available/{{ nome_site }}.conf"
        mode: 0644
      notify: Reiniciar NGINX

    - name: Habilitar novo site
      file:
        src: "/etc/nginx/sites-available/{{ nome_site }}.conf"
        dest: "/etc/nginx/sites-enabled/{{ nome_site }}.conf"
        state: link
      notify: Reiniciar NGINX

  handlers:
    - name: Reiniciar NGINX
      service:
        name: nginx
        state: restarted
...

“Bacana… Entendi! vars é a declaração de variáveis que são chamadas depois, mas e esses tasks, handlers, apt, copy, file, template e service?”

Nada disso foi inventado por mim ou tirado do nada! Tudo tem um motivo e, nessas horas, a documentação será seu melhor e maior aliado! ☺

Explicando

vars: Declarar variáveis que podem ser chamadas para preencher outras variáveis dentro do playbook, link da documentação ;

tasks: Tarefas que serão executadas nos playbooks, link da documentação ;

handlers: Parece com tasks MAS só é executado, uma única vez, caso seja invocado usando o notify ou pode ser executado mais de uma vez se utilizado o flush handlers durante a execução das tasks, link da documentação ;

apt: Módulo para instalação de pacotes em sistemas linux tipo debian, link da documentação ;

copy: Módulo para copiar arquivos da máquina local (ou remoto) destinado à máquina remota, link da documentação ;

file: Módulo para definir atributos (ou apagar) em arquivos, links simbólicos ou diretórios, link da documentação ;

template: Preenche variáveis nos modelos de arquivos (j2), baseado em jinja2, e envia-os para o sistema remoto, link da documentação ;

service: Controla os serviços nos sistemas remotos, link da documentação ;

facts: O ansible_default_ipv4.address refere-se ao fact de endereçamento IPv4 do sistema remoto. 🙂 Facts são informações relacionadas aos sistemas remotos. Como IP, sistemas operacionais, sistemas de arquivos, etc, link da documentação .

Executando o playbook 🏃

Basta executar, dentro da pasta 04_Segundo_playbook, o seguinte comando:

ansible-playbook site_legal_nginx.yml

Repare que, se você não limpou o lab por conta da atividade passada, ele não marcará como CHANGED, mas como OK, a etapa de instalação do NGINX!

Checando problemas e voltando com condicionais

TO DO TO DO 🌱🌱🌱🌱🌱🌱

Organizando tudo com roles

TO DO 🌱🌱🌱🌱🌱🌱

Levantando dois webservers com balanceamento de carga

🌱🌱🌱🌱🌱🌱

Templates com jinja2

🌱🌱🌱🌱🌱🌱

Levantando um wordpress com proxy reverso

🌱🌱🌱🌱🌱🌱

Ansible vault

O que fazer quando é necessário por uma senha em um dos arquivos YAML e não pode ser uma senha gerada apenas na execução do playbook? 👀

Criptografar deve ser a primeira coisa que vem em sua mente, mas como pode ser feito isso? É… você viu o título desta seção e já sabe que é usando o Ansible Vault! 🔐

Boas práticas de configuração em seu editor preferido

Pra não ficar a senha em texto plano em arquivos ou buffers.

vim

Edite seu arquivo .vimrc e acrescente (se já não possuir):

" Desativar os arquivos swap que funcionam em caso de problema ou interrupção do vim.
set noswapfile

" Desativar a criação de arquivo de backup.
set nobackup
set nowritebackup

" Desativer o arquivo viminfo de copiar dados de sua seção atual.
set viminfo=

" Desativar a possibilidade de copiar para o clipboard do sistema.
set clipboard=

emacs

🌱🌱🌱🌱

Processo criptográfico em arquivo YAML

Criptografar arquivo em texto plano

ansible-vault encrypt arquivo.yaml

Decriptar arquivo para texto plano

ansible-vault decrypt arquivo.yaml

Criar arquivo criptografado vazio

O arquivo não pode existir

ansible-vault create arquivo.yaml

Editar arquivo criptografado

O arquivo precisa existir

ansible-vault edit arquivo.yaml

Criptografar uma variável

Caso deseje manter seu arquivo YAML descriptografado e queira criptografar apenas a informação de uma variável utilize o seguinte comando:

ansible-vault encrypt_string

Escrevendo a variável criptografada no vim

Com o arquivo desejado aberto, execute o comando: :r! ansible-vault encrypt_string.

Será solicitado:

• A senha para encriptar o conteúdo da string;
• A confirmação da senha;
• O conteúdo a ser encriptado, devendo ser finalizado com Ctrl+d.

TO DO 🌱🌱🌱🌱🌱🌱

Utilizando o ansible-lint

TO DO 🌱🌱🌱🌱🌱🌱

Hashicorp vault

TO DO 🌱🌱🌱🌱🌱🌱

Instalar e configurar o AWX Operator

Aqui você terá os procedimentos para instalar o AWX Operator

Instalar o Minikube

Vá no site do procedimento de instalação do Minikube e siga o procedimento. Quando terminar, volte aqui. ☺

Depois de fazer o procedimento, execute e crie o seguinte alias em seu .bashrc:

alias kubectl="minikube kubectl --"

…

Imagino que você já fez o procedimento e, em algum momento, desligou o seu computador. Comandos úteis:

Iniciar o Minikube

minikube start

Checar os nós criados

kubectl get nodes

Instalar o Kustomize

Para instalar o AWX Operator, utilizaremos o Kustomize, seguindo as orientações do procedimento de instalação.

Mais uma vez, siga o que é orientado no procedimento de instalação do Kustomize e depois volte aqui, indo na próxima seção.

Instalação básica

Com o Minikube devidamente instalado e o Kustomize, vá na pasta 16_Instalar_e_configurar_o_AWX_Operator e veja o conteúdo do arquivo kustomization.yaml e do arquivo awx-local.yaml.

Após colocar a tag na versão desejada, execute (ainda dentro da pasta):

kustomize build . | kubectl apply -f -

Uns segundos depois, verifique se o awx-operator já está rodando com o comando:

kubectl get pods -n awx

Para não ter de ficar escrevendo -n awx toda vez, defina-o namespace atual com o comando:

kubectl config set-context --current --namespace=awx

Para verificar os logs do AWX Operator, execute o seguinte comando:

kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager

Agora basta acessar a aplicação, para ver qual o endereço de acesso execute o comando:

minikube service awx-local-service --url

Em seu navegador, deve aparecer a seguinte tela:

E “SE NÃO RETORNAR NADA”?! Não vos preocupeis. Comigo não funcionou o comando que é usado na documentação, que foi o que expus logo acima.

Para acessar o AWX Operator, descubra o IP usando o comando:

minikube ip

Para saber qual a porta, execute o comando:

kubectl get service awx-local-service --output='jsonpath="{.spec.ports[0].nodePort}"'

Por padrão o usuário é admin e a senha está em awx-local-admin-password. Para pegar a senha, execute o comando:

kubectl get secret awx-local-admin-password -o jsonpath="{.data.password}" | base64 --decode

Ao colocar o login e senha, deve aparecer a seguinte interface:

Parabéns! Você fez a instalação mais básica do AWX e que utilizaremos neste curso! Para mais opções de configuração e instalação, cheque o github do AWX Operator