Inventário, as páginas amarelas do Ansible

Inventario, as páginas amarelas do Ansible

Por: Adelmo da Silva – consultor de sistemas

Antes da Internet, antes das pesquisas com o Google ou Bing, mesmo antes das A.I., como ChatGPT, sempre procurávamos informações de lugares, ou pessoas, nas chamadas Páginas Amarelas. Este imenso catálogo, ou livro, que era fornecido mediante uma assinatura, continha folhas amarelas que eram o repositório físico com informações de todos os que possuíam contas telefónicas, tais como nome completo, número de telefone e endereço da residência. Um motorista profissional, tal como Taxista, Chofer, Caminhoneiro, etc., por mais experiente que seja, não conhecem todos os caminhos para os desitnos novos, ou já conhecidos. Com o Ansible não é diferente. O Ansible possui uma gama poderosa de módulos e recursos. Mas, se não souber aonde ir, de nada adianta. É necessário saber exactamente aonde ir, de forma ordenada e organizada.

O Inventário

O arquivo de inventário do Ansible fica localizado, por padrão, em /etc/ansible/hosts, mas pode ser criado em qualquer outro local. Mas falaremos disso daqui a pouco.

new_cognito

Dentro deste arquivo listamos todos os endereços IP’s dos hosts que irão gerenciados pelo nosso amigo. Também podemos utilizar o famoso FQDN (em inglês, Fully Qualified Domain Name, ou em Português, Nome de Domínio Completamente Qualificado), ou hostnames. Mas para que isso funcione, o DNS precisa estar funcionando ou o arquivo 0 precisa estar configurado perfeitamente. Se pegarmos uma lista de todos os IPs / FQDN’s do nosso parque e colocarmos neste arquivo de inventário, o Ansible funcionará, mas o administrador não saberá quem é quem lá dentro desta lista, pois estes IP’s não estão separados de forma a saber a que grupo ou ambiente pertencem. Para que o administrador utilize de forma eficiente e efectiva, o inventário possui uma estrutura própria, onde os IP’s / FQDN’s são organizados por grupos para que o Ansible execute as suas tarefas em grupos, ou hosts, específicos, conforme a necessidade da demanda exigir. A estrutura é dividida em:

[ db-servers ] → GRUPO DE HOSTS

192.168.10.21 → IP do host 01

192.168.10.22 → IP do host 02

new_cognito

 

[ webservers ] → GRUPO DE HOSTS

srv-web01.empresa.lan → FQDN do host 03

srv-web02.empresa.lan → FQDN do host 04

new_cognito

Nesta estrutura temos dois grupos: db-servers e webservers. Nesta organização, o administrador do sistema saberá, exatamente, onde aplicar as tarefas criadas nos playbooks. Em um grupo foram “cadastrados” os IP’s e em outro, o FQDN dos servidores. Esta estrutura auxilia tanto no uso de playbooks ou nos comandos AD-HOC do Ansible. Por exemplo, o administrador recebe uma demanda onde é necessário a instalação do Apache nos servidores, que são todos Ubuntu Server. No comando AD-HOC, ficaria:

ansible webservers -m apt -a “name=apache2 enabled=yes state=present”

Já no playbook, ficaria assim:

—-

new_cognito

  hosts: webservers

  become: yes

  tasks:

    – name: Instalando o Apache2 no grupo webservers

new_cognito

      apt: name=apache2 enabled=yes state=latest

Veja que, no AD-HOC, depois do comando, ansible vem o nome do grupo, especificando que o Apache será instalado no grupo webservers. Já no playbook, na linha “hosts” foi especificado o grupo webservers. Em ambos os casos, nada será feito no grupo db-servers. Se fosse um inventário só com uma lista de IP’s, todos os servidores receberiam esta instalação. O que ocasionaria um caos nos serviços.

Outra vantagem de se organizar bem o inventário é o uso de variáveis do próprio Ansible neste arquivo. Por exemplo, os dois servidores de Data Base possuem usuário diferentes: O IP 192.168.10.21 t e o 192.168.10.22 possuem o usuário “oracleadm”, que é diferente do usuário que foi utilizado para fazer a primeira conexão. No inventário do Ansible, podemos especificar usuário e senha dos hosts . Neste caso, vamos usar as variáveis para definir usuario e senha: ansible_username e ansible_password:

[ db-servers ]

new_cognito

192.168.10.21 ansible_ssh_user=oracleadm ansible_ssh_pass=78910

192.168.10.22 ansible_ssh_user=oracleadm ansible_ssh_pass=78910

 

[ webservers ]

new_cognito

srv-web01.empresa.lan → FQDN do host 03

srv-web02.empresa.lan → FQDN do host 04

Desta forma, no acto da conexão do Ansible com os hosts do grupo db-servers, será utilizado um usuário diferente para os hosts.

Mas, somos profissionais, certo? Precisamos deixar este inventário mais elegante e funcional. Imagine um grupo db-servers com mais de 30 servidores. Teríamos 30 linhas repetindo em casa as variáveis “ansible_username” e “ansible_password”. Em um belo dia, as senhas são trocadas. Neste ponto, teremos que trocar um por um. Seria um trabalho muito chato: copia e cola. Vamos lá! No inventário podemos utilizar uma instância do grupo, um subgrupo, com a adição da opção “VARS”. Vamos configurar nosso inventário para que os hosts do grupo db-servers utilizem um único usuário:

new_cognito

[ db-servers ]

192.168.10.21

192.168.10.22

[ db-servers:vars ]

new_cognito

ansible_ssh_user=oracleadm

ansible_ssh_pass=78910


[ webservers ]

srv-web01.empresa.lan → FQDN do host 03

new_cognito

srv-web02.empresa.lan → FQDN do host 04

Veja que retiramos as variáveis do grupo db-servers e criamos um grupo, tecnicamente chamado do subgrupo, com a opção ”vars” na frente do nome. Isto indica ao Ansible que deve ler esta instância, pois ela possui informações adicionais. Portanto, se tivermos uma troca de senha de hosts, basta alterarmos o subgrupo e todas elas funcionarão a 100%. Um inventário elegante, profissional e funcional.

Múltiplos Inventários

Contudo, em um parque com dezenas, ou até centenas de hosts, existem inúmeros ambientes: Desenvolvimento, Homologação, Produção, etc. Neste caso, centralizar tudo em um único inventário pode se tornar um pouco bagunçado e danoso. Numa situação destas, podemos criar três inventários, um para cada ambiente. Mas como utilizar isso se o padrão do Ansible está no /etc/ansible/hosts? Digamos que temos um inventário para cada ambiente:

  • Produção
  • Homologação
  • Desenvolvimento

Assim, teremos a seguinte estrutura:

new_cognito

inventarios/
── inventario-dev
── inventario-homolog
└── inventario-prod

Mas, se rodarmos um comando AD-HOC, ou no Playbook, o Ansible irá, por padrão, buscar os hosts em /etc/ansible/hosts. Para que isso não ocorra, basta utilizarmos a flag “i”, de inventário, para indicarmos o arquivo que o Ansible deve usar. Para uma instalação, por exemplo, no ambiente DEV, no comando AD-HOC, ficaria assim:

ansible -i inventarios/inventario-dev webservers -m apt -a “name=apache2 enabled=yes state=present”

E o comando para rodar o playbook, ficaria assim:

new_cognito

ansible-playbook -i inventarios/inventario-dev instalacao-apache.yaml

Em ambos os casos utilizamos “-i inventarios/inventario-dev” indicando que o Ansible deve utilizar o arquivo “inventario-dev” dentro do directório “inventario”. Pronto, uma segunda solução profissional e elegante, o que nos dá tempo de saborear um delicioso cafézinho!

Até a próxima, pessoal.

 

new_cognito

Partilhar artigo:

Versao3 - Cópia

Somos um portal de notícias, voltado às tecnologias de informação e inovação tecnológica. Informamos com Rigor, Objectividade e Imparcialidade. Primamos pela qualidade, oferecendo aos nossos leitores, a inclusão tecnológica e a literacia digital

+(244) 930747817

info@pti.ao | redaccao@pti.ao

Mais Lidas

Últimos Artigos

Desenvolvido Por SP Media