Guia rápido de introdução ao Ansible para administradores de sistemas

12 de março de 2018Curtis Rempel

Red Hat Ansible Automation Platform: Guia Prático

A automação ajuda empresas a operar com mais eficiência e rapidez desde os tempos da Revolução Industrial. Dê início ou prosseguimento à jornada de automação com este guia prático da Red Hat.

Leia o ebook

Você tem a rotina típica de um administrador de sistema, com muito trabalho e pouco tempo? Você fica nervoso só de pensar em fazer uma mudança simples em um servidor DNS ou ajustar os parâmetros do kernel em todo seu farm de servidores? Ou pior, realizar mudanças baseadas em características variáveis do sistema, como memória instalada ou versão lançada? Os desenvolvedores da sua organização parecem estar falando outra língua com essa coisa toda de DevOps?

O Red Hat Ansible Automation é uma ferramenta de automação legível sem agentes que usa SSH para orquestrar o gerenciamento de configurações, a implantação de aplicações e o provisionamento em um ambiente com uma ou várias camadas. Ele é baseado no Ansible, uma das tecnologias open source de automação de TI mais famosas do mundo.

Este post vai ajudar você a entender os princípios básicos do Ansible e como usá-lo na sua função de administrador de sistemas para melhorar a eficiência de gerenciamento dos sistemas.

Antes de começar, precisamo definir alguns termos:

Nó de controle: o host em que usamos o Ansible para executar tarefas nos nós gerenciados

Nó gerenciado: um host configurado pelo nó de controle

Inventário do host: uma lista de nós gerenciados

Comando ad-hoc: uma tarefa simples e pontual

Playbook: um conjunto de tarefas repetitivas em configurações mais complexas

Módulo: código que executa uma tarefa comum específica, como adicionar um usuário, instalar um pacote etc.

Idempotência: uma operação é idempotente se o resultado é o mesmo em uma ou várias execuções, sem necessidade de intervenção

Ambiente

O ambiente neste post é composto por um nó de controle (vm1) e quatro nós gerenciados (vm2, vm3, vm4, vm5), todos executados em um ambiente virtual com instalação mínima do Red Hat Enterprise Linux 7.4. Para simplificar o processo, o nó de controle tem as seguintes entradas no arquivo /etc/hosts:

192.168.102.211 vm1 vm1.redhat.lab
192.168.102.212 vm2 vm2.redhat.lab
192.168.102.213 vm3 vm3.redhat.lab
192.168.102.214 vm4 vm4.redhat.lab
192.168.102.215 vm5 vm5.redhat.lab

Para facilitar o uso nesta demonstração, o usuário do sistema receberá um sudo sem senha. Sua política de segurança pode variar, e o Ansible consegue gerenciar vários casos de uso de escalação de privilégios. Esta conta de usuário foi configurada com escalação de privilégios pela seguinte entrada no arquivo /etc/sudoers:

%wheel ALL=(ALL) NOPASSWD: ALL

Esse é apenas um exemplo, você pode usar sua própria variante de configuração do sudo.

Por fim, a autenticação por chave pública do SSH foi configurada e testada para esta conta de usuário, do nó de controle a cada nó gerenciado.

Instalação

O Ansible para Red Hat Enterprise Linux 7 está localizado no canal "Extras". Se você está usando o Red Hat Enterprise Linux 6, habilite o repositório EPEL. Para pacotes extras do Enterprise Linux (EPEL), esta solução no portal do cliente pode ser útil. Em sistemas Fedora, o Ansible está no repositório de base.

Quando o repositório adequado estiver configurado, a instalação será fácil e rápida:

[curtis@vm1 ~]$ sudo yum install -y ansible

Vamos conferir a versão:

[curtis@vm1 ~]$ ansible --version
ansible 2.4.1.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/home/curtis/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/site-packages/ansible
 executable location = /bin/ansible
 python version = 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Observe o arquivo de configuração padrão. Esse Python é obrigatório e está na instalação mínima do Red Hat Enterprise Linux 7.4.

Configuração

Como já configuramos os nós gerenciados com conta de usuário, a escalação de privilégios e a autenticação por chave pública SSH, configuraremos agora o nó de controle.

A configuração do nó de controle consiste em um arquivo de configuração do Ansible e um arquivo de inventário do host.

Arquivo de configuração

Como acabamos de descobrir, o arquivo de configuração padrão é /etc/ansible/ansible.cfg

Você pode alterar esse arquivo de configuração global ou fazer uma cópia especialmente para um diretório específico. A ordem de localização de um arquivo de configuração é a seguinte:

```
ANSIBLE_CONFIG (environment variable)
```
```
ansible.cfg (per directory)
```
```
~/.ansible.cfg (home directory)
```
```
/etc/ansible/ansible.cfg (global)
```

Neste post, usemos um arquivo de configuração mínimo no diretório home da conta de usuário já adicionada:

[curtis@vm1 ~]$ cat ansible.cfg [defaults] inventory = $HOME/hosts

Inventário do host

O arquivo padrão do inventário do host é /etc/ansible/hosts, mas ele pode ser alterado no arquivo de configuração (como mostrado acima) ou usando a opção -i no comando ansible. Usaremos um arquivo de inventário estático simples. Também podemos usar inventários dinâmicos, mas eles fogem do escopo deste post.

O nosso arquivo de inventário do host é o seguinte:

[webservers]
vm2
vm3
[dbservers]
vm4
[logservers]
vm5
[lamp:children]
webservers
dbservers

Definimos quatro grupos: webservers em vm2 e vm3, dbservers em vm4, logservers em vm5 e lamp, que consiste nos grupos webservers e dbservers.

Vamos verificar se todos os hosts podem ser localizados usando este arquivo de configuração:

[curtis@vm1 ~]$ ansible all --list-hosts
 hosts (4):
   vm5
   vm2
   vm3
   vm4

Faremos o mesmo com os grupos individuais, como o webservers:

[curtis@vm1 ~]$ ansible webservers --list-hosts
 hosts (2):
   vm2
   vm3

Agora que já validamos o inventário do host, vamos conferir rapidamente se todos os hosts estão funcionando. Para isso, vamos usar um comando ad-hoc que utiliza o módulo ping:

[curtis@vm1 ~]$ ansible all -m ping
vm4 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm5 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm3 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm2 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}

Na saída acima, percebemos que todos os sistemas retornaram um resultado bem-sucedido, nada foi alterado e todos os "pings" retornaram "pong".

Para obter uma lista dos módulos disponíveis, utilize:

[curtis@vm1 ~]$ ansible-doc -l

O número de módulos integrados cresce a cada versão do Ansible:

[curtis@vm1 ~]$ ansible-doc -l | wc -l 
1378

Veja a documentação de cada módulo em http://docs.ansible.com/ansible/latest/modules_by_category.html

A tarefa final neste ambiente é configurar o vm1 com o Apache e um repositório yum do Red Hat Enterprise Linux 7 para que os nós gerenciados instalem pacotes adicionais:

[root@vm1 ~]# yum install -y httpd
[root@vm1 ~]# systemctl enable httpd
[root@vm1 ~]# systemctl start httpd
[root@vm1 ~]# mkdir /media/iso
[root@vm1 ~]# mount -o loop /root/rhel-server-7.4-x86_64-dvd.iso /media/iso
[root@vm1 ~]# ln -s /media/iso /var/www/html/rhel7

Preparar, apontar, Ansible!

Agora que o ambiente está configurado e pronto, vamos colocar a mão na massa com o Ansible.

Como precisamos ter alguns pacotes adicionais instalados nos nós gerenciados, nossa primeira tarefa é configurar o repositório yum em cada host usando este arquivo de configuração:

[curtis@vm1 ~]$ cat dvd.repo
[RHEL7]
name = RHEL 7
baseurl = http://vm1/rhel7/
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
gpgcheck = 1

Podemos copiar esse arquivo para os nós gerenciados usando um comando ad-hoc com a opção -m do módulo de cópia ou especificar os argumentos necessários usando a opção -a da seguinte maneira:

[curtis@vm1 ~]$ ansible all -m copy -a 'src=dvd.repo dest=/etc/yum.repos.d owner=root group=root mode=0644' -b
vm5 | SUCCESS => {
   "changed": true, 
   "checksum": "c15fdb5c1183f360ce29a1274c5f69e4e43060f5", 
   "dest": "/etc/yum.repos.d/dvd.repo", 
   "failed": false, 
   "gid": 0, 
   "group": "root", 
   "md5sum": "db5a5da08d1c4be953cd0ae6625d8358", 
   "mode": "0644", 
   "owner": "root", 
   "secontext": "system_u:object_r:system_conf_t:s0", 
   "size": 135, 
   "src": "/home/curtis/.ansible/tmp/ansible-tmp-1516898124.58-210025572567032/source", 
   "state": "file", 
   "uid": 0
}
[...]

Para agilizar o processo, excluímos outras saídas dos hosts restantes.

Precisamos chamar a atenção para alguns pontos:

Todos os nós retornam SUCCESS e “changed” : true, o que significa que a execução do módulo foi bem-sucedida e o arquivo foi criado/alterado. Se executarmos o comando novamente, a saída vai incluir “changed” : false, o que significa que o arquivo já está presente e configurado como exigido. Ou seja, o Ansible só realizará as alterações solicitadas se elas já não existirem. É isso que chamamos de "idempotência".
A opção -b (veja http://docs.ansible.com/ansible/latest/become.html) faz com que a tarefa remota use a escalação de privilégios (ou seja, o sudo), obrigatório para copiar arquivos para o diretório /etc/yum.repos.d
Para descobrir os argumentos exigidos pelo módulo de cópia, utilize:

[curtis@vm1 ~]$ ansible-doc copy

Playbooks

Os comandos ad-hoc são úteis para testes e tarefas simples e pontuais, mas os playbooks podem ser usados para capturar um conjunto de tarefas repetitivas a serem executadas futuramente. Um playbook contém uma ou mais reproduções que definem um conjunto de hosts a serem configurados e uma lista de tarefas a serem executadas.

Nesse contexto, precisamos configurar os servidores web, os servidores de bancos de dados e um servidor de geração de logs centralizado. Os requisitos específicos são:

O pacote httpd foi instalado, habilitado e iniciado nos servidores web
Todos os servidores web têm uma página padrão com o texto “Bem-vindo ao <hostname> no <ip address>”
Todos os servidores web têm uma conta de usuário com acesso adequado para gerenciamento de conteúdo
O pacote MariaDB foi instalado, habilitado e iniciado nos servidores de bancos de dados
O host do servidor do log está configurado para aceitar mensagens remotas de geração de logs
Os hosts nos grupos webservers e dbservers enviam uma cópia das mensagens de log para o host do servidor do log

Este playbook (myplaybook.yml) configurará tudo que for necessário.

Ao analisar o playbook, observe o seguinte:

O módulo do usuário exige um hash de senha com texto simples (para mais detalhes, veja “usuário ansible-doc”). Para fazer isso, faça o seguinte:

[curtis@vm1 ~]$ python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())" Password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.

O conteúdo da web page padrão é criado usando "fatos" coletados do host. Para descobrir os fatos do host, use o módulo de configuração:

[curtis@vm1 ~]$ ansible vm2 -m setup
---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest
   - name: enable and start Apache server
     service:
       name: httpd
       enabled: yes
       state: started
   - name: open firewall port
     firewalld:
       service: http
       immediate: true
       permanent: true
       state: enabled
   - name: create web admin group
     group:
       name: web
       state: present
   - name: create web admin user
     user:
       name: webadm
       comment: "Web Admin"
       password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
       groups: web
       append: yes
   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s
   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r
- hosts: dbservers
 become: yes
 tasks:
   - name: install MariaDB server
     yum:
       name: mariadb-server
       state: latest
   - name: enable and start MariaDB server
     service:
       name: mariadb
       enabled: yes
       state: started
- hosts: logservers
 become: yes
 tasks:
   - name: configure rsyslog remote log reception over udp
     lineinfile:
       path: /etc/rsyslog.conf
       line: "{{ item }}"
       state: present
     with_items:
       - '$ModLoad imudp'
       - '$UDPServerRun 514'
     notify:
       - restart rsyslogd
   - name: open firewall port
     firewalld:
       port: 514/udp
       immediate: true
       permanent: true
       state: enabled
 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted
- hosts: lamp
 become: yes
 tasks:
   - name: configure rsyslog
     lineinfile:
       path: /etc/rsyslog.conf
       line: '*.* @192.168.102.215:514'
       state: present
     notify:
       - restart rsyslogd
 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

Como executar o playbook

Nosso playbook pode ser executado da seguinte forma:

[curtis@vm1 ~]$ ansible-playbook myplaybook.yml

Na saída abaixo, podemos ver que a configuração do servidor web ocorre apenas em vm2 e vm3 (primeira reprodução). Por outro lado, o banco de dados está instalado em vm4 (segunda reprodução) e o logserver (vm5) está configurado na terceira reprodução. Por fim, a quarta reprodução configura os hosts dos webservers e dbservers pelo grupo "lamp" para geração de logs remota.

PLAY [webservers] *********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm2]
ok: [vm3]
TASK [install Apache server] **********************************************************
changed: [vm3]
changed: [vm2]
TASK [enable and start Apache server] *************************************************
changed: [vm2]
changed: [vm3]
TASK [open firewall port] *************************************************************
changed: [vm2]
changed: [vm3]
TASK [create web admin group] *********************************************************
changed: [vm3]
changed: [vm2]
TASK [create web admin user] **********************************************************
changed: [vm3]
changed: [vm2]
TASK [set content directory group/permissions] ****************************************
changed: [vm3]
changed: [vm2]
TASK [create default page content] ****************************************************
changed: [vm3]
changed: [vm2]
PLAY [dbservers] **********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm4]
TASK [install MariaDB server] *********************************************************
changed: [vm4]
TASK [enable and start MariaDB server] ************************************************
changed: [vm4]
PLAY [logservers] *********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm5]
TASK [configure rsyslog remote log reception over udp] ********************************
changed: [vm5] => (item=$ModLoad imudp)
changed: [vm5] => (item=$UDPServerRun 514)
TASK [open firewall port] *************************************************************
changed: [vm5]
RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm5]
PLAY [lamp] ***************************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm3]
ok: [vm2]
ok: [vm4]
TASK [configure rsyslog] **************************************************************
changed: [vm2]
changed: [vm3]
changed: [vm4]
RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm3]
changed: [vm2]
changed: [vm4]
PLAY RECAP ****************************************************************************
vm2                        : ok=11 changed=9 unreachable=0    failed=0 
vm3                        : ok=11 changed=9 unreachable=0    failed=0 
vm4                        : ok=6 changed=4 unreachable=0    failed=0 
vm5                        : ok=4 changed=3 unreachable=0    failed=0

Pronto!

Para verificar os hosts do webserver, utilize:

[curtis@vm1 ~]$ curl http://vm2
Welcome to vm2 on 192.168.102.212
[curtis@vm1 ~]$ curl http://vm3
Welcome to vm3 on 192.168.102.213

e a geração de logs remota usando o comando logger nos hosts dos webservers e dbservers:

[curtis@vm1 ~]$ ansible lamp -m command -a 'logger hurray it works'
vm3 | SUCCESS | rc=0 >>
vm4 | SUCCESS | rc=0 >>
vm2 | SUCCESS | rc=0 >>

Confirmação do servidor de geração de logs central:

[curtis@vm1 ~]$ ansible logservers -m command -a "grep 'hurray it works$' /var/log/messages" -b
vm5 | SUCCESS | rc=0 >>
Jan 30 13:28:29 vm3 curtis: hurray it works
Jan 30 13:28:29 vm2 curtis: hurray it works
Jan 30 13:28:29 vm4 curtis: hurray it works

Dicas

Se você não está familiarizado com o YAML, a sintaxe pode ser um pouco difícil a princípio, especialmente com espaçamentos (sem guias).

Antes de executar um playbook, verifique a sintaxe usando:

$ ansible-playbook --syntax-check myplaybook.yml

É bom usar o vim com destaque de sintaxe para aprender yaml e descobrir problemas de sintaxe. Uma maneira rápida de habilitar o vim para sintaxe yaml é adicionar a seguinte linha ao arquivo ~/.vimrc:

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

Se você quiser mais funcionalidades, incluindo cor, clique aqui para acessar o plugin.
Se preferir usar o emacs em vez do vim, habilite o repositório EPELe instale o pacote emacs-yaml-mode.

É possível testar um playbook sem realizar alterações nos hosts de destino:

$ ansible-playbook --check myplaybook.yml

Também pode ser útil passar por um playbook:

$ ansible-playbook --step myplaybook.yml

Assim como um script de shell, você pode tornar o Ansible playbook executável e adicionar a esta linha no topo do arquivo:

#!/bin/ansible-playbook

Para executar comandos de shell ad-hoc arbitrários, use o módulo de comando (o módulo padrão se -m não estiver especificado). No entanto, se precisar usar coisas como redireção, pipelines etc., utilize o módulo de shell.

Para agilizar a gravação de playbooks, marque a seção “EXAMPLES:” na documentação de um módulo específico.

Coloque sequências de caracteres entre aspas nos playbooks para evitar problemas com caracteres especiais.

A geração de logs é desabilitada por padrão. Para habilitá-la, use o parâmetro log_path no arquivo de configuração do Ansible.

Espero que este post tenha sido útil para esclarecer como o Ansible funciona e poupar seu tempo e esforço ao usar playbooks para documentar e reproduzir tarefas rotineiras e repetitivas de maneira simples e precisa. Continue sua aprendizagem em http://docs.ansible.com e https://www.redhat.com/en/technologies/management/ansible.

Boa automação!

imagem Curtis Rempel, RHCA, é um Technical Account Manager (TAM) de plataformas sênior e líder de equipe no Canadá, além de já ter atuado como Red Hat Certified Instructor and Examiner (RHCI/RHCX). A jornada dele com Linux começou em 1994, com o Red Hat Linux 2.1 CD de Jon “maddog” Hall. Como um TAM, ele deu suporte a clientes empresariais nos setores de finanças, telecomunicações e aviação com know-how em automação, kernel e armazenamento. Conheça melhor o Curtis.

Um Technical Account Manager (TAM) da Red Hat é um especialista em soluções que trabalha junto às organizações de TI para planejar implantações estratégicas bem-sucedidas e ajudá-las a maximizar o desempenho e crescimento. O TAM faz parte da organização Customer Experience and Engagement de nível mundial da Red Hat e oferece recomendações e orientações proativas para ajudar você a identificar e resolver possíveis problemas antes que ele ocorram. Em caso de problemas, o TAM reconhece o problema e emprega os melhores recursos para que a resolução aconteça o quanto antes e sua empresa não precise parar.

Entre em contato com os TAMs em um evento Red Hat Convergence perto de você! O Red Hat Convergence é um evento gratuito exclusivo para usuários técnicos convidados. Nele, eles têm a oportunidade de aprofundar conhecimentos sobre as soluções Red Hat e descobrir novas maneiras de aplicar a tecnologia open source para atingir as metas de negócios. Esses eventos itinerantes percorrem o mundo para que você tenha um dia na sua cidade a experiência de aprender e se conectar com especialistas da Red Hat e colegas do setor.

A tecnologia open source é curiosidade colaborativa. Participe do Red Hat Summit, de 8 a 10 de maio, em São Francisco e se conecte pessoalmente com TAMs e outros especialistas da Red Hat. Inscreva-se agora por apenas US$ 1.100 com o código CEE18.

O Red Hat Cloud Success foi feito para simplificar sua transformação de TI e acelerar a adoção das tecnologias de nuvem com muito suporte, orientação e know-how das soluções. Das provas de conceitos à produção, um especialista técnico em nuvem altamente qualificado será seu parceiro contínuo e ajudará você na implementação bem-sucedida da solução de nuvem. Com essa pequena participação, o Red Hat Cloud Success pode ajudar você a planejar e implantar soluções de nuvem com eficiência e se preparar para o futuro estrategicamente.