blog-post

Aprendendo Ansible

author image
Índice

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:

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: Login do AWX Operator

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: Interface do AWX Operator

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

Publicações Recentes

blog-post

Ativar WSL do Windows

Este how-to é baseado na documentação oficial. Sobre a foto de capa: Foto de Umberto na Unsplash Pré-requisitos Tenha …

blog-post

O navegador Vieb

O que é o Vieb? Vieb é um navegador, software livre, baseado em Electron com interface gráfica minimalista, onde sua …

Quer saber mais sobre mim?

Para conversar comigo ou saber outros detalhes profissionais
me encontre no…

Linkedin
*