Ansible na prática – instalação e configuração #1

Por: Adelmo da Silva – consultor de sistemas

Bom, eu já mostrei para você o que é o Ansible e a sua importância na área de T.I, as inúmeras vantagens e a sua base, o Inventário e alguns exemplos do que ele pode fazer. Acredito que já tenha tido uma ideia do que o Ansible é e o que pode fazer. Confira os artigos anteriores nos links abaixo:

1. Automação é o caminho e o Ansible, seu guia;
2. Ansible: o fim das configurações manuais em servidores remotos;
3. Ansible, o poliglota;
4. Inventário, as páginas amarelas do Ansible.

Depois de mostrar a você tudo isso, agora vamos avançar. Vamos colocar a mão na massa. Este é o primeiro artigo/tutorial sobre Ansible na Prática. Será uma série de artigos onde irei replicar a vida no dia-a-dia de um profissional da área de T.I., como actualizações, colecta de informações, explicação de comandos, entre outros recursos e configurações de nosso amando Ansible. É importante lembrar: todos os artigos que irei publicar neste série “Ansible na Prática” será baseado no Ansible instalado em um servidor Linux, seja CentOS, Oracle Linux, Ubuntu, etc.

Então, chega de blá blá blá e vamos para a parte mais legal… a Prática. Pois o quanto mais você dominar o Ansible, mais tempo para aquele cafezinho você vai ter… hummm coisa boa!

Instalando no Oracle Linux e Ubuntu

Bora lá!

Para esse, e os futuros artigos, vou utilizar máquinas virtuais (VM’s) com as seguintes configurações:

• Sistema Operacional: Oracle Linux 7.9
• CPU: 6
• RAM: 4GB

Estou utilizando o Vagrant para criar estas VM’s. Mas você pode utilizar a que desejar: VirtualBox, Docker, VMWare, Boxes, etc. Neste artigo, em específico, usarei apenas o Oracle Linux. Nos próximos vamos utilizar outros sistemas. Mas na instalação irei contemplar o Ubuntu também.

Sempre é bom deixar o sistema atualizado antes de se instalar qualquer aplicação ou serviço. Neste caso, vamos atualizar nossos sistemas:

Oracle Linux 7.9:

yum update -y && yum upgrade -y

 Ubuntu:

apt update -y && apt upgrade -y

Agora, precisamos instalar um repositório chamado EPEL (Extra Packages for Enterprise Linux) para obter o pacote Ansible:

Oracle Linux 7.9:

yum install epel-release -y

 Ubuntu:

O repositório EPEL é específico para distribuições baseadas no Red Hat, como o Oracle Linux. No Ubuntu, não é necessário instalar o EPEL. No Ubuntu, o Ansible pode ser instalado directamente dos repositórios oficiais.

Agora é possível instalar nosso amado Ansible.

Oracle Linux 7.9:

yum install ansible

ansible –version

Ubuntu:

apt install ansible

ansible –version

Versão do Ansible usado para este artigo:

[vagrant@orc-ansible ~]$ ansible –version

ansible 2.9.27

  config file = /etc/ansible/ansible.cfg

  configured module search path = [u’/home/vagrant/.ansible/plugins/modules’, u’/usr/share/ansible/plugins/modules’]

  ansible python module location = /usr/lib/python2.7/site-packages/ansible

  executable location = /usr/bin/ansible

  python version = 2.7.5 (default, Jul  1 2022, 08:35:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)]

Além dos meios tradicionais através dos gerenciadores ‘apt’ e ‘yum’, é possível instalar o Ansible através  do ‘pip’ (gerenciador de pacotes do Python), tanto no Oracle Linux quanto no Ubuntu. Para isso basta instalar o pacote

Oracle Linux 7.9:

yum install epel-release -y

yum install python3-pip -y

pip3 install ansible

Caso o yum não localize o pacote epel-release, utilize os comandos abaixo:

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

yum install -y epel-release-latest-7.noarch.rpm

Ubuntu:

apt install python3-pip

pip3 install ansible

Feito! Já temos nosso querido Ansible instalado e pronto para ser usado. Mas antes disso, vamos verificar as configurações principais desse rapaz.

Verificando as configurações padrão

O Ansible possui vários arquivos de configuração que podem ser utilizados para personalizar o comportamento do Ansible. O directório padrão do Ansible fica em ‘/etc/ansible’ e é monde estão os dois principais arquivos de configuração:

• cfg: Este é o arquivo principal de configuração do Ansible. Ele pode ser usado para definir configurações globais que afectam todos os playbooks e comandos do Ansible. O arquivo ansible.cfg pode ser colocado no diretório de trabalho actual, no diretório home do usuário (~/.ansible.cfg) ou em /etc/ansible/ansible.cfg para configurações globais de sistema. Mas, neste artigo, vamos manter o local padrão.

• inventory: O arquivo de inventário, por padrão chamado de hosts, define os hosts em que o Ansible vai executar os playbooks e comandos. O arquivo de inventário permite agrupar hosts em grupos, definir variáveis específicas para hosts ou grupos, e muito mais. Por padrão, o arquivo de inventário pode ser encontrado em /etc/ansible/hosts.

• roles: são uma maneira de organizar e reutilizar código. Elas permitem que você agrupe tarefas, variáveis, handlers e outros elementos relacionados em uma estrutura modular. Uma role pode ser usada para definir a configuração e a funcionalidade de um componente específico do sistema, como um serviço, um aplicativo ou um conjunto de tarefas relacionadas. Dentro do diretório roles, você pode criar subdirectórios para cada role que você deseja criar. Por exemplo, você pode ter um diretório chamado webserver para uma role que configura um servidor web, e dentro desse diretório, você teria a estrutura de arquivos da role em si. Mas veremos isso em artigos futuros.

Preparando os hosts para controlo do Ansible

Você já tem o poderoso Ansible instalado. Já sabe onde ficam as configurações base dele. Agora, vamos preparar os hosts, ou seja, os servidores que serão controlados pelo Ansible.

O Ansible se conecta via ssh aos hosts para que seja executados os comandos, seja Ad-Hoc ou Playbooks:

Fluxo de Conexão do Ansible. Fonte: Packet Warrior – Créditos: D.R

Para estabelecer uma relação de confiança entre o Ansible e um host, você deve utilizar a autenticação por chave SSH. Isso permite que o Ansible se conecte ao host de forma segura e execute comandos remotamente. É essencial que o usuário que está no servidor Ansible seja o mesmo em todos os hosts da rede Para isso, vamos seguir os passos abaixo

I – Gerando chaves SSH com o ssh-keygen:

[vagrant@orc-ansible ~]$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/vagrant/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/vagrant/.ssh/id_rsa.

Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:4l/8CEnX4vmF9IniX/BLl+VmNzNRDH3qEBV4aboDxJ0 vagrant@orc-ansible.test

The key’s randomart image is:

+—[RSA 2048]—-+

|         . . +++ |

|          o E +oo|

|         .   = .+|

|          ..o . .|

|      . S o.++ ..|

|     . o = +o*.o+|

|      . o * o.B=*|

|       . + = + ==|

|        . o.+ .  |

+—-[SHA256]—–+

II – Copie a chave pública para o host remoto usando o ssh-copy-id:

[vagrant@orc-ansible ~]$ ssh-copy-id vagrant@192.168.100.4

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/home/vagrant/.ssh/id_rsa.pub”

The authenticity of host ‘192.168.100.4 (192.168.100.4)’ can’t be established.

ECDSA key fingerprint is SHA256:2dOBSIUd6MBkLoqN/hrBfGCwsjZqSjMgB0neup/ali4.

ECDSA key fingerprint is MD5:f8:e1:93:fa:b9:b0:b7:e3:2f:2b:fd:9c:10:f5:72:d1.

Are you sure you want to continue connecting (yes/no)? yes

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys

vagrant@192.168.100.4’s password:

Number of key(s) added: 1

Now try logging into the machine, with:   “ssh ‘vagrant@192.168.100.4′”

and check to make sure that only the key(s) you wanted were added.

Veja que temos quatro estágios, destacados em negrito:

• ssh-copy-id vagrant@192.168.100.4: Inicia a conexão e a cópia da chave ssh para o hosts.
• Are you sure you want to continue connecting (yes/no)? Yes: ele pergunta se deseja continuar com a conexão
• vagrant@192.168.100.4’s password: é solicitado a senha do user, neste caso o user vagrant para validar a conexão.
• Number of key(s) added: 1: Confirmação de hosts adicionados á lista de confiança.

III – Teste a conexão SSH: para testar a conexão de confiança entre o ansible e o host, entre com o comando:

[vagrant@orc-ansible ~]$ ssh 192.168.100.4 à início da conexão

[vagrant@orc-app1 ~]$ à acesso confirmado. Veja que o hostname, depois do @, está com o do host orc-app1.

Isso deverá ser feito para todos os hosts da rede.

Testes Iniciais

Agora vamos aos testes que dão gosto depois desses passos iniciais. Vamos aos testes de conexão. Mas, antes, precisamos preparar nosso inventário, lembra? Lembra do meu artigo sobre o Inventário: Inventário, as páginas amarelas do Ansible?

Então, vamos entrar no arquivo padrão de inventário do ansible em ‘/etc/ansible/hosts’ e vamos definir os grupos e ip’s:

[server-apps]

192.168.100.4

192.168.100.5

[server-db]

192.168.100.6

Este é o meu inventário. Você deverá colocar aqui os ip’s dos seus servidores.

Agora que nosso inventário está configurado, vamos testar as respostas dos servidores por meio do módulo PING. Neste primeiro teste vou dar ping para todos os hosts do inventário:

[vagrant@orc-ansible ~]$ ansible all -m ping

192.168.100.6 | SUCCESS => {

    “ansible_facts”: {

        “discovered_interpreter_python”: “/usr/bin/python”

    },

    “changed”: false,

    “ping”: “pong”

}

192.168.10.5 | SUCCESS => {

    “ansible_facts”: {

        “discovered_interpreter_python”: “/usr/bin/python”

    },

    “changed”: false,

    “ping”: “pong”

}

192.168.100.4 | SUCCESS => {

    “ansible_facts”: {

        “discovered_interpreter_python”: “/usr/bin/python”

    },

    “changed”: false,

    “ping”: “pong”

}

Todos responderam ao ping. Isso pode ser comprovado pela reposta “ping”: “pong” ao final de cada host.

Para testar apenas um grupo, trocamos o “all” pelo nome do grupo, como por exemplo:

[vagrant@orc-ansible ~]$ ansible server-apps  -m ping

Os hosts 192.168.100.4 e 192.168.100.5 irão responder ao ping.

Pronto! O Ansible já está no controle dos seus hosts.

Vamos rodar mais dois comandos simples para que você veja o Ansible em ação. Vamos atualizar apenas o server DB utilizando o módulo SHELL:

[vagrant@orc-ansible ~]$ ansible server-db -m shell -a “sudo yum update -y”

…

Updated:

  cronie.x86_64 0:1.4.11-25.el7_9

  cronie-anacron.x86_64 0:1.4.11-25.el7_9

  iwl100-firmware.noarch 999:39.31.5.1-999.18.el7

  iwl1000-firmware.noarch 999:39.31.5.1-999.18.el7

  iwl105-firmware.noarch 999:18.168.6.1-999.18.el7

  iwl135-firmware.noarch 999:18.168.6.1-999.18.el7

  iwl2000-firmware.noarch 999:18.168.6.1-999.18.el7

  iwl2030-firmware.noarch 999:18.168.6.1-999.18.el7

  iwl3160-firmware.noarch 999:22.0.7.0-999.18.el7

  iwl3945-firmware.noarch 999:15.32.2.9-999.18.el7

  iwl4965-firmware.noarch 999:228.61.2.24-999.18.el7

  iwl5000-firmware.noarch 999:8.83.5.1_1-999.18.el7

  iwl5150-firmware.noarch 999:8.24.2.2-999.18.el7

  iwl6000-firmware.noarch 999:9.221.4.1-999.18.el7

  iwl6000g2a-firmware.noarch 999:17.168.5.3-999.18.el7

  iwl6000g2b-firmware.noarch 999:17.168.5.2-999.18.el7

  iwl6050-firmware.noarch 999:41.28.5.1-999.18.el7

  iwl7260-firmware.noarch 999:22.0.7.0-999.18.el7

  iwlax2xx-firmware.noarch 999:20230315-999.18.el7

  kernel-abi-whitelists.noarch 0:3.10.0-1160.90.1.0.1.el7

  kernel-headers.x86_64 0:3.10.0-1160.90.1.0.1.el7

  kernel-tools.x86_64 0:3.10.0-1160.90.1.0.1.el7

  kernel-tools-libs.x86_64 0:3.10.0-1160.90.1.0.1.el7

  kexec-tools.x86_64 0:2.0.15-51.0.5.el7_9.3

  linux-firmware.noarch 999:20230315-999.18.gitc761dbe8.el7

  python-perf.x86_64 0:3.10.0-1160.90.1.0.1.el7

  rhn-check.x86_64 0:2.0.2-24.0.9.el7

  rhn-client-tools.x86_64 0:2.0.2-24.0.9.el7

  rhn-setup.x86_64 0:2.0.2-24.0.9.el7

  rhnlib.noarch 0:2.5.65-8.0.5.el7

  rsyslog.x86_64 0:8.24.0-57.0.3.el7_9.3

  tzdata.noarch 0:2023c-1.el7

Complete!

[vagrant@orc-ansible ~]$

Pronto. Já temos um servidor actualizado. Agora basta fazer nos outros ao meso tempo e poder tomar aquele cafezinho.

Lembrando que este é o primeiro artigo da série Ansible na Prática. Até o próximo.