Configurando computadores com ansible e ansible-playbook

Gerenciar múltiplos computadores simultaneamente pode se tornar uma tarefa cansativa. Imagine ter que atualizar pacotes, copiar arquivos, instalar programas, alterar configurações em quatro computadores diferentes? Nem sempre trabalhar com imagens prontas é uma opção, especialmente se você está em um ambiente heterogêneo, com computadores em que até a arquitetura do processador [e diferente. Para o nosso pequeno nodepool a reposta é ansible e ansible-playbook.

Mas não iríamos configurar os agentes agora?

Você está falando isso porque está acompanhando a série de artigos sobre instalação de um cluster pessoal. Mas vai por mim, você vai agradecer por essa pausa. A minha primeira tentativa foi fazendo tudo manualmente mesmo. Mas cara, isso cansa e pode te desmotivar. Para que você não fique com a motivação lá embaixo, vou te passar o pouquinho do que eu sei e estou utilizando de ansible.

Mas não precisa se preocupar.  Eu sempre vou passar os comandos sem o ansible, pra você saiba o que estamos fazendo.

Mas o que é o ansible?

Ansible é um utilitário de linha de comando (CLI) em que você pode configurar tarefas a serem executadas em um ou vários computadores simultaneamente. Ele faz tudo isso através de conexão SSH (esse é um detalhe muito importante!) com os computadores alvo.

Nesse momento você deve estar criando paralelos com o Terra Form. E no que diz respeito a usar uma linguagem declarativa para alterar o estado de um ambiente, você até tem razão. Mas a principal diferença entre os dois é que, enquanto o Terra Form cria o ambiente, o ansible pode te ajudar a configurá-lo.

E como a conexão é via ssh, você pode utilizar ansible para configurar qualquer computador acessível através da sua rede. Ou seja, os computadores da sua casa e a VM que você mantém em alguma nuvem podem ser gerenciadas com os playbooks do ansible.

Instalando o ansible.

Se a essa altura do campeonato você ainda está preso ao Windows, instale logo o WSL e comece a se divertir de verdade. Não sabe como fazer? Nesse vídeo eu te mostro como configurar o WSL para desenvolvimento. Quer continuar no Windows e sem WSL. Nesse caso, acho que você vai ter que fazer na mão mesmo.

Uma vez no seu terminal lindão (estou usando Ubuntu 24), digite os comandos:

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible

Pronto! O ansible já estará disponível na sua linha de comando. Duvida? Digite:

ansible --version

Configurando SSH para usar com Ansible

Você vai precisar muito de ssh daqui para frente. E não só você, o ansible também! Logo, a primeira coisa a fazer é tornar o seu ambiente mais “próximo” dos computadores que você vai gerenciar. Ser obrigado a digitar senha em todas as iterações seria extremamente maçante.

Como isso é feito? Você vai gerar um conjunto de chaves e copiá-la para cada um dos computadores.

Também recomendo que, pelo menos uma vez, você entre em cada máquina. Nessa primeira vez o SSH pergunta se você deseja lembrar daquele host. Passo importante para que o ansible não fique travado.

Vamos gerar a chave:

ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@IP_MAQUINA_DESTINO

Repita o comando ssh-copy-id para cada computador que você tive disponível. No lugar o IP_MAQUINA_DESTINO, você tem duas opções: A primeira é configurar no arquivo hosts da sua máquina, adicionando os IPs e Hosts (no ubuntu esse arquivo fica em /etc/hosts e você pode editar utilizando o VIM). A segunda é utilizar o PiHole e configurar nele o nome das máquinas e IP.

Como eu disse antes, é bom que você faça uma primeira conexão manualmente ao host (o próprio terminal também te sugere isso).

ssh seu_usuario@controller

E se o nome do usuário do seu computador for o mesmo usuário que você configurou nas demais máquinas, pode até pular a parte no username.

ssh morgul

Se fizer o login e não pedir senha, deu tudo certo. Se você já acessou esse mesmo host via ssh antes, pode ser que o ssh reclame de alguma coisa. Geralmente o próprio terminal te indica o que fazer, qual comando rodar. Mas se não for esse o caso, você pode excluir as linhas que mencionam o ip ou hostname do arquivo ~/.ssh/known_hosts. Ou até mesmo apagar o arquivo.

Informando ao ansible quais são os seus computadores

O ansible trabalha com o conceito de inventário em arquivo. Neste arquivo você pode agrupar os computadores que vai gerenciar, além de configurar variáveis que serão úteis durante a execução das tarefas. Esse arquivo pode seguir a mesma estrutura dos bons e velhos .ini. Mas eu gosto mesmo é do formato yaml.

Vamos entender esse inventário, olhando para o meu:

all:
  vars:
    K3S_TOKEN: '{{ lookup("env", "K3S_TOKEN") }}'
    cluster_token: ""
controller:
  hosts:
    morgul:
      ansible_host: morgul
      ansible_connection: ssh
      ansible_user: sauron
      ansible_password: '{{ lookup("env", "ANSIBLE_MORGUL") }}'
      ansible_become_password: '{{ lookup("env", "ANSIBLE_MORGUL") }}'
      var_disk: sda
      var_uuid: e9c01c2b-8330-46bc-aeed-a8fa5f696e2c
workers:
  hosts:
    controller_rasp:
      ansible_connection: ssh
      ansible_host: controller
      ansible_user: ftathiago
      ansible_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'
      ansible_become_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'
    worker1:
      ansible_connection: ssh
      ansible_host: worker1
      ansible_user: ftathiago
      ansible_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'
      ansible_become_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'
    worker2:
      ansible_connection: ssh
      ansible_host: worker2
      ansible_user: ftathiago
      ansible_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'
      ansible_become_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'

A primeira seção do arquivo, all, é uma espécie de seção global. Tudo o que você colocar ali estará visível para todos os hosts e tasks. Você pode ver que ali eu especifiquei duas variáveis. E uma delas está lendo dados do próprio environment.

K3S_TOKEN: '{{ lookup("env", "K3S_TOKEN") }}'

Essa é umas das formas de você tratar segredos. Afinal, se você gravar esses valores no arquivo, eles serão versionados no seu git. Tudo bem que os segredos do seu homelab podem não ser tão importantes assim. Mas é sempre bom ter cuidado, não é?

Depois eu tenho dois grupos: controller e Workers. O nome e o propósito de cada um é autoexplicativo. Vamos entender cada uma das propriedades que estou utilizando:

• ansible_host: Aqui você pode informar o ip ou o hostname do computador que vai ser gerenciado.
• ansible_connection: É a forma de comunicação que o ansible estabelecerá com o computador. Especifique ssh.
• ansible_user: Nome do usuário na máquina. Em um cenário mais seguro, você teria um usuário especifico para execução do ansible, com permissões bem especificadas. Mas para a nossa homelab, você pode utilizar o mesmo usuário com que faz login na máquina, ou o famoso `root`.
• ansible_password: a senha para acessar o computador. Desnecessário se você copiou o certificado local.
• ansible_become_password: senha do usuário que você especificou em `ansible_user`.
• var_disk: Apenas um exemplo de variável que vamos utilizar futuramente.

Para validar se está tudo certo, no terminal digite:

ansible all -I ./inventory -m ping

O resultado esperado é que, para cada host, você obtenha a palavra “pong”.

./inventory é o nome do diretório que contém o arquivo de inventário.

O comando que executamos rodou em todos os computadores. Agora digamos que você quer reiniciar os Workers:

ansible workers -m reboot -b -i ./inventory

Ou quem sabe fazer um update no controller:

ansible controller -m shell -a "apt update" -i ./inventory -b

Criando um playbook

Executar comandos um a um é legal. Mas pode ser que você tenha vários comandos para serem executados de uma vez. Nesse caso é legal você montar um playbook. No exemplo à seguir, para cada computador que vamos instalar o cluster, precisamos instalar alguns pacotes que vamos utilizar ou que facilitarão a gestão futuramente.

• Vim: para configurações em geral;
• Curl: para acessar sites e validar conexão;
• Nmap: para mapear IPs, encontrar máquinas;
• Net-tools: Pacote com utilitários de rede;
• Nfs-common, open-iscsi: para configurar discos;
• Linux-utils: pacotes de CLIs úteis;

Como ficaria nosso playbook?

- name: Install packages
  hosts: all
  become: yes
  tasks:
    - name: Install vim
      ansible.builtin.apt:
        pkg:
          - vim
    - name: Install curl
      ansible.builtin.apt:
        pkg:
          - curl
    - name: Install nmap
      ansible.builtin.apt:
        pkg:
          - nmap
    - name: Add disk nfs-common
      ansible.builtin.apt:
        name: nfs-common
        state: present
    - name: Add disk open-iscsi
      ansible.builtin.apt:
        name: open-iscsi
        state: present
    - name: Add disk linux-utils
      ansible.builtin.apt:
        name: util-linux
        state: present
    - name: Add disk net-tools
      ansible.builtin.apt:
        name: net-tools
        state: present

Você deve ter notado que cada task tem um ansible.builtin.apt. Esses são módulos do ansible (mais uma similaridade com o terra form). Para cada ação que você deseja executar, pode existir um módulo específico para aquilo. Para o que não possuir um módulo, você pode se resolver com o shell.

Uma dica importante

Agora você pode estar pensando que: “Acho que pode ser inteligente, então, fazer um único playbook para configurar o cluster e instalar todos os sistemas que quero”. Certo?

Bom, você pode fazer isso. Contudo, eu não recomendo. Gosto de manter escopos de execução pequenos. Isso me ajuda a lidar com a ansiedade de tudo acabar logo. Mas também me ajuda a ter feedbacks de erro mais rápido, além de me permitir execuções parciais.

No próximo post vamos utilizar o ansible para nos ajudar a instalar o k3s nos nosso workers.