0

[DevOps] Gerenciamento de configuração com o Ansible

0 Flares 0 Flares ×

Neste artigo irei falar sobre uma ferramenta que ao longo dos ultimos anos vem ganhando força por sua agilidade e rápida implantação, estou falando do Ansible. O ansible é um utilitario de gerenciamento e orquestração de código aberto e pode automatizar e padronizar a configuração de hosts remotos e máquinas virtuais. Sua funcionalidade de orquestração permite certificar-se que um serviço esta rodando ou para adicionar atualizações e reinicializações, isso para tarefas simples.

Devido a isso, Ansible pode executar atualizações de massivas em vários sistemas de uma maneira que resulta em zero downtime. Em vez de escrever scripts personalizados, individualizados, os administradores de sistema criam plays de alto nível no Ansible. Sua arquitetura é sem agentes implementáveis na comunicações entre master/client. Em vez disso, todas as funções são executadas em SSH.

Originalmente escrito por Michael DeHaan, o criador do Cobbler provisionamento. Ansible foi adotado, porque é simples de usar para o sysadmins. Sua facilidade ou vantagem e porque ele foi desenvolvido em Python, usado hoje em dia na maioria das implantações Linux/Unix e suportado por ferramentas DevOps, como Vagrant e Jenkins.

Pode ser executado sem uso de arquivos de configurações para tarefas simples, como: certificar-se de que um serviço esta rodando ou para adicionar atualizações e reinicializações. Para tarefas complexas, a configuração do Ansible é manipulada através da sintaxe YAML em arquivos de configurações chamados de playbooks. Os comandos Ansible podem ser escritos em quase qualquer linguagem de programação que é distribuídos como módulos JSON universais, o que é claramente um benefício em vez de ter que escolher uma única linguagem. Os módulos são os programas que realizam o trabalho real das tarefas de um play. Ansible é imediatamente útil porque vem com centenas de módulos principais que executam o trabalho administrativo útil do sistema.

Há muitas coisas que Ansible não pode fazer. Ele não pode auditar as alterações feitas localmente por outros usuários em um sistema. Por exemplo, quem fez uma alteração em um arquivo?

A lista a seguir fornece alguns outros exemplos do que o Ansible não pode executar.

  • O Ansible pode adicionar pacotes a uma instalação, mas não executa a instalação mínima inicial do sistema. Cada sistema pode começar com uma instalação mínima, seja através do Kickstart ou uma imagem de base da base da nuvem, depois use o Ansible para configuração adicional.
  • Embora Ansible possa corrigir o drift de configuração, ele não monitora o mesmo.
  • O Ansible não rastreia quais alterações são feitas nos arquivos no sistema, nem rastreia o que o usuário ou processo fez essas alterações. Esses tipos de alterações são melhor rastreados com um sistema de controle de versão ou o Linux Auditing System.

Quando os administradores pensam em Ansible, uma coisa que vem à mente é o gerenciamento de configuração. O Ansible pode implantar e manipular os arquivos de configuração de um host remoto. Os arquivos podem ser estáticos ou templates. Pode ser usado como uma ferramenta de implantação de vários nós. Os Playbooks podem definir os aplicativos instalados e configurados em máquinas remotas. Além disso, os aplicativos multi-nó podem ser orquestrados pelas regras do Ansible.

A execução remota da tarefa simples pode ser executada pelo Ansible. Isso pode ser demonstrado especificando comandos ad hoc na linha de comando, fazendo com que o execute em hosts remotos.

Playbooks são uma maneira completamente diferente de usar ansible do que no modo de execução de tarefa ad hoc, e são particularmente poderosos. Simplificando, playbooks são a base para um gerenciamento de configuração realmente simples e implantação de hosts, é muito bem adequado para a implantação de aplicativos complexos.

Playbooks pode declarar configurações, eles também podem orquestrar etapas de qualquer processo manual ordenado, mesmo que diferentes etapas devem saltar para frente e para trás entre conjuntos de máquinas em ordens específicas. Eles podem iniciar tarefas de forma síncrona ou assíncrona. Enquanto você pode executar o programa para tarefas ad-hoc, playbooks são mais propensos a ser mantido em controle de origem e usado para empurrar a sua configuração ou assegurar as configurações de seus sistemas remotos estão em spec.

Exemplos de configurações Playbooks

Playbooks são escritos no formato YAML, que intencionalmente não tenta ser uma linguagem de programação ou script, mas em vez disso um modelo de uma configuração ou um processo. Cada playbook é composto de um ou mais ‘plays’ em uma lista.

O objetivo de um play é mapear um grupo de hosts para algumas funções bem definidas, representadas por tarefas. Em um nível básico, uma tasks nada mais é que uma chamada para um módulo ansible. Ao compor um playbook de múltiplos ‘plays’, é possível orquestrar implementações de várias máquinas, executando determinadas etapas em todas as máquinas no grupo de servidores web, em seguida, determinadas etapas no grupo de servidores de banco de dados e, em seguida, mais comandos de volta no grupo de servidores da Web etc.

Para entendimento, aqui está um playbook que contém apenas um play:

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest

  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache

  - name: ensure apache is running (and enable it at boot)
    service: name=httpd state=started enabled=yes
  handlers:
  - name: restart apache
    service: name=httpd state=restarted

Host Inventory

Um host inventory define quais hosts o Ansible poderá gerenciar. Os hosts podem pertencer a grupos que normalmente são usados para identificar a função dos hosts no datacenter. Um host pode ser membro de mais de um grupo. Há duas maneiras pelas quais os host inventory podem ser definidos. Um host inventory estático pode ser definido por um arquivo de texto ou um host inventory dinâmico pode ser gerado por provedores externos.

Static Host Iventory

Um static host inventory é definido em um arquivo de texto semelhante a INI, no qual cada seção define um grupo de hosts. Cada seção começa com um nome de grupo de hosts entre colchetes [ ]. Em seguida, as entradas para cada host gerenciado em um grupo, cada uma em uma única linha. Eles consistem em nomes de host ou endereços IP dos hosts gerenciados que são membros do grupo. No exemplo a seguir, o host inventory define dois grupos de servidores web e servidores de banco.

[webservers]
web2.example.com ansible_user_ssh=webuser ansible_user_pass=webuserpass ansible_ssh_host=192.168.7.2

[db-servers]
web1.example.com
db1.example.com

[myservers:children]
webservers
db-servers

Em caso de dúvida, teste a presença da máquina no inventário com o comando ansible:

@scrpnx [~] $ ansible web1.example.com --list-hosts
  hosts (1):
    web1.example.com

Dinamic host inventory

As informações do host inventory também podem ser geradas dinamicamente. Informações de dinamic inventory incluem fornecedores de nuvem publica/privida, informações sistemas Cobbler, banco de dados LDAP ou um banco de dados de um CMDB. O Ansible inclui scripts que manipulam informações dinâmicas de host, grupo e variáveis dos provedores mais comuns, como o Amazon EC2, Cobbler, Rackspace Cloud e OpenStack. Para provedores de nuvem, as informações de autenticação e acesso devem ser definidas em arquivos aos quais os scripts podem acessar.

O exemplo anterior mostrei como um único nome de host é usado para fazer referência a um host contido em um arquivo de inventário e como a opção –list-hosts pode ser usada para identificar os hosts contido no host inventory. É possível também lista por: grupo, wildcards “*”, IP address e all (para todos os itens no host inventory).

No site GitHub da Ansible em https://github.com/ansible/ansible/tree/devel/contrib/inventory, está disponibilizado scripts que suportam a geração dinâmica de um inventário baseado em informações do host disponíveis para um grande número de plataformas

Arquivo de configuração Ansible

O arquivo de configuração Ansible consiste em várias sessões com cada sessão contendo configurações definidas como key/valor. Os títulos das seções estão entre colchetes. As configurações são agrupadas nas seis sessões a seguir no arquivo de configuração default do ansible.

@scrpnx [~] $ egrep "^\[" /etc/ansible/ansible.cfg
[defaults]
[privilege_escalation]
[paramiko_connection]
[ssh_connection]
[accelerate]
[selinux]

A maioria das configurações no arquivo de configuração estão agrupadas na sessão [default]. A sessão [privilege_escalation] contém configurações para definir os acessos que exigem privilégios escalados. As seções [paramiko_connection][ssh_connection] e [accelerate] contêm configurações para otimizar as conexões aos hosts gerenciados.

As configurações são personalizadas, alterando seus valores no arquivo de configuração ativo e entrando em vigor assim que o arquivo é salvo. Algumas configurações são predefinidas dentro Ansible com valores padrão e esses valores são válidos mesmo se suas respectivas configurações são comentadas. Para identificar o valor padrão dessas configurações predefinidas, consulte os comentários no arquivo de configuração global /etc/ansible/ansible.cfg fornecido pelo pacote ansible. A página man do ansible também fornece informações sobre os valores padrão dessas configurações predefinidas.

@scrpnx [~] $ ansible --version
ansible 2.2.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Se existir um arquivo ansible.cfg no diretório no qual o comando ansible é executado, ele é usado em vez do arquivo global. Isso permite que os administradores criem uma estrutura de diretórios onde diferentes ambientes ou projetos estão alojados em diretórios separados, com cada diretório contendo um arquivo de configuração personalizado com um conjunto exclusivo de configurações.

@scrpnx [Learn] $ ansible --version
ansible 2.2.1.0
  config file = /dados/Project/ansible/Local/Learn/ansible.cfg
  configured module search path = Default w/o overrides

Outra maneira de exibir o arquivo de configuração ativo é usar a opção -v ao executar comandos no prompt. Mostrara alem do arquivo de configuração ativo como também listará os host configurados no host inventory.

@scrpnx [Learn] $ ansible all --list-hosts -v
Using /dados/Project/ansible/Local/Learn/ansible.cfg as config file
  hosts (2):
     rhel-7
     rhel-6

Ansible Módulos

Os módulos (também conhecidos como “plugins de tarefas” ou “plugins de bibliotecas”) são aqueles que fazem o trabalho real, eles são o que é executado em cada tarefa de um playbook. Mas você também pode executar um único modulo usando o comando ansible via command line.

Vamos analisar como executamos dois módulos diferentes a partir da linha de comando:

ansible rhel-6 -m service -a "name=httpd state=started"
ansible rhel-6 -m command -a "/sbin/reboot -t now"

Em playbooks, os módulos Ansible são executados de uma maneira muito semelhante:

- name: reboot the servers
  command: /sbin/reboot -t now

Aqui, como argumentações;

- name: restart webserver
  service:
    name: httpd
    state: restarted

Ansible disponibilizar mais de 400 módulos disponíveis para o uso, a partir de sua implementação. Esses módulos podem ser usados para executar uma ampla gama de tarefas, como gerenciamento de nuvem, usuários, pacotes e serviços.

Para uma melhor organização e gerenciamento, os módulos são agrupados nas seguintes categorias funcionais.

  • Cloud
  • Clustering
  • Commands
  • Database
  • Files
  • Inventory
  • Messaging
  • Monitoring
  • Network
  • Notification
  • Packaging
  • Source Control
  • System
  • Utilities
  • Web Infrastructure
  • Windows

Fonte: http://docs.ansible.com/ansible/modules_by_category.html

A documentação do módulo também está disponível localmente no control node e disponível usando o comando ansible-doc. Para ver uma lista dos módulos disponíveis em um control node, execute o comando ansible-doc -l. Isso exibe uma lista de nomes de módulos e uma sinopse de sua função.

@scrpnx [Learn] $ ansible-doc -l
a10_server                         Manage A10 Networks AX/SoftAX/Thunder/vThunder devices
a10_service_group                  Manage A10 Networks devices' service groups
a10_virtual_server                 Manage A10 Networks devices' virtual servers
acl                                Sets and retrieves file ACL information.
add_host                           add a host (and alternatively a group) to the ansible-playbook in-memory inventory
airbrake_deployment                Notify airbrake about app deployments
alternatives                       Manages alternative programs for common commands
apache2_mod_proxy                  Set and/or get members' attributes of an Apache httpd 2.4 mod_proxy balancer pool
apache2_module                     enables/disables a module of the Apache2 webserver
apk                                Manages apk packages
apt                                Manages apt-packages
apt_key                            Add or remove an apt key
apt_repository                     Add and remove APT repositories
... Omitindo saida ...

Uma documentação mais detalhada sobre um modulo especifico, você poderá mostrar passando o nome do modulo para o comando ansible-doc.

@scrpnx [Learn] $ ansible-doc apt
> APT
  Manages `apt' packages (such as for Debian/Ubuntu).

Options (= is mandatory):

- allow_unauthenticated
        Ignore if packages cannot be authenticated. This is useful for bootstrapping environments that manage their own apt-key setup.
        (Choices: yes, no)[Default: no]
- autoremove
        If `yes', remove unused dependency packages for all module states except `build-dep'.
        (Choices: yes, no)[Default: False]

- cache_valid_time
         Update the apt cache if its older than the `cache_valid_time'. This option is set in seconds.
         [Default: 0]
- deb
          Path to a .deb package on the remote machine.
          If :// in the path, ansible will attempt to download deb before installing. (Version added 2.1)
          [Default: (null)]
... Omitindo saida ...
EXAMPLES:
# Update repositories cache and install "foo" package
- apt: name=foo update_cache=yes

# Remove "foo" package
- apt: name=foo state=absent

# Install the package "foo"
- apt: name=foo state=present
... Omitindo saida ...

 Invocando Módulos

Existem várias maneiras de trabalhar com módulos, dependendo do contexto e das necessidades do administrador.

Os módulos podem ser chamados como parte de um comando ad hoc, usando o comando ansible. A opção -m permite especificar o nome do módulo a ser usado. O comando a seguir usa o módulo ping para testar a conectividade com todos os hosts gerenciados. Este módulo conecta e autentica ao host remoto e verificar se os requisitos do python são atendidos.

@scrpnx [Learn] $ ansible rhel-7 -m ping
rhel-7 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Módulos pode ser chamado em playbooks, como parte de uma tarefa (tasks). O trecho a seguir mostra como o módulo yum pode ser invocado com o nome de um pacote e o seu estado desejado como argumentos.

tasks:
- name: Installs a package
  yum:
    name: postfix
    state: latest

Instalando um Control Node

Ao contrário de outros utilitários de gerenciamento de configuração, como Puppet e Chef, o Ansible usa uma arquitetura sem agente. Basicamente só precisamos instalar no host do qual ele será executado. Os hosts que serão gerenciados pelo Ansible não precisam ter o Ansible instalado.

Esta instalação envolve relativamente poucos passos e tem requisitos mínimos. Você também precisará do Python 2.4 ou posterior. Em sistemas inferior a Python 2.5, você precisará do python-simplejson, alem do python2.

Dica:

Se você precisar rodar em sistemas com o Python 2.X, podemos usar o módulo ‘raw’. Este modulo é capaz de executar remotamente em sistemas que o mesmo tenha uma versão do python inferior a 2.5. Por exemplo, iria instalar Python 2.X e o módulo simplejson necessário para executar módulos ansible.

ansible rhel-5 --sudo -m raw -a "yum install -y python2 python-simplejson

 

Nota:

Ansible não suporte versão do Rhel 2.x, 3.x e 4.x.

 

Instalando Via YUM:

RPMs estão disponíveis a partir yum para EPEL 6, 7, e atualmente apoiado distribuições Fedora.

http://fedoraproject.org/wiki/EPEL

O próprio Ansible pode gerenciar sistemas operacionais anteriores que contenham Python 2.4 ou superior (assim também EL5).

$ sudo yum install ansible

Instalando Via APT

Para configurar o PPA na sua máquina e instalar o ansible execute estes comandos:

Os builds necessários estão disponíveis em https://launchpad.net/~ansible/+archive/ubuntu/ansible.

$ sudo apt-get install software-propriedades-comuns
$ sudo apt-add-repository ppa: ansible / ansible
$ sudo apt-get update
$ sudo apt-get install ansible

O exemplo a seguir mostra como configurar um host e grupos em um arquivo de inventário e como a opção –list-hosts pode ser usada para identificar esses host e grupos.

@scrpnx [Learn] $ cat inventory

[prod]
rhel-7 ansible_ssh_host=192.168.60.134 ansible_ssh_user=root ansible_ssh_pass='toor'
rhel-6 ansible_ssh_host=192.168.60.131 ansible_ssh_user=root ansible_ssh_pass='toor'

[dev]
sles12 ansible_ssh_host=192.168.60.142 ansible_ssh_user=root ansible_ssh_pass="toor"

[dbs]
rhel-6 ansible_ssh_host=192.168.60.131 ansible_ssh_user=root ansible_ssh_pass='toor'

[datacenter:children]
dev
prod
dbs

 

Listando um host:

@scrpnx [Learn] $  ansible rhel-6 -i inventory --list-hosts
  hosts (1):
    rhel-6

Listando um grupo:

@scrpnx [Learn] $ ansible datacenter -i inventory --list-hosts
  hosts (3):
    sles12
    rhel-7
    rhel-6

Verificando comunicação entre o control node e o hosts gerenciado.

@scrpnx [Learn] $ ansible rhel-6 -i inventory -m ping
rhel-6 | SUCCESS => {
"changed": false,
"ping": "pong"
}

A saída SUCESS indica que o host esta respondendo atendendo todos os requisitos, versão do python.

O modulo setup mostrará toda informações do hosts remoto. Este modulo é muito útil para um inventario de maquinas, por exemplo.

@scrpnx [Learn] $ ansible rhel-6 -i inventory -m setup
rhel-6 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.60.131"
],
"ansible_all_ipv6_addresses": [
"fe80::20c:29ff:fe9e:b27f"
],
"ansible_architecture": "x86_64",
"ansible_bios_date": "07/02/2015",
"ansible_bios_version": "6.00",
"ansible_cmdline": {
"KEYTABLE": "br-abnt2",
"LANG": "en_US.UTF-8",
"SYSFONT": "latarcyrheb-sun16",
"crashkernel": "129M@0M",
"quiet": true,
"rd_LVM_LV": "vg_rhel6/lv_root",
"rd_NO_LUKS": true,
"rhgb": true,
"ro": true,
"root": "/dev/mapper/vg_rhel6-lv_root"
},
"ansible_date_time": {
"date": "2017-02-09",
"day": "09",
"epoch": "1486634895",
"hour": "08",
... Omitindo saida ...

Neste exemplo iremos editar o arquivo /etc/motd, incluído uma mensagem simples. Imaginem isso em um edição massiva de servidores.

@scrpnx [Learn] $ ansible rhel-6 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd'
rhel-6 | SUCCESS => {
"changed": true,
"checksum": "4458b979ede3c332f8f2128385df4ba305e58c27",
"dest": "/etc/motd",
"gid": 0,
"group": "root",
"md5sum": "65a4290ee5559756ad04e558b0e0c4e3",
"mode": "0644",
"owner": "root",
"size": 19,
"src": "/tmp/root/ansible/ansible-tmp-1486640030.33-71582033397171/source",
"state": "file",
"uid": 0
}

Testando a modificação:

@scrpnx [Learn] $ ssh -l root 192.168.60.131
root@192.168.60.131's password:
Last login: Thu Feb  9 09:33:50 2017 from 192.168.60.1
Managed by Ansible
[root@rhel-6 ~]#

Então pessoal, esta é uma pequena introdução ao ansible. O que ja nos dar uma noção de seu poder e infinita possibilidade. Resumindo esta ferramenta em uma unica palavra eu diria, simplicidade em todos os aspectos.

Espero que curtem, até a proxima !!!

 

Referencia: 

http://docs.ansible.com/

http://docs.ansible.com/ansible/intro_installation.html

https://www.ansible.com/red-hat

Jonatas Lopes

Sempre aprendendo coisas novas e passando o conhecimento adiante !!!

Dúvidas? Deixe seu comentário ou entre em contato.