Puppet vs. Ansible

Fonte: Wikiversidade
Saltar para a navegação Saltar para a pesquisa

Introdução[editar | editar código-fonte]

Aqui serão apresentadas as ferramentas Puppet e Ansible, bem como suas diferenças, semelhanças, finalidades e arquiteturas, com o objetivo de esclarecer possíveis concorrências entre as ferramentas durante o processo de gerência de configuração de software.

Ansible[editar | editar código-fonte]

O Ansible foi desenvolvido em Pyhton e PowerShell por Michael DeHaan, sua primeira release se deu em 20 de fevereiro de 2012 e em 2015 a Red Hat Inc. comprou seus direitos. Assim como a maioria de softwares de GCS, o Ansible possui dois tipos de servidores, as máquinas controladoras e os nós. A orquestração se inicia na primeira máquina de controle, que descreve a localização de cada máquina nó através de seu inventário, e então os nós são gerenciados por ela através do uso de SSH.

Objetivos de Design[editar | editar código-fonte]

Os objetivos de design do Ansible são:

  • Natureza minimalista: não adiciona dependências adicionais ao ambiente de trabalho;
  • Consistente;
  • Seguro: não requer agentes nas máquinas nós, apenas requer OpenSSH;
  • Confiável: as playbooks do Ansible quando bem escritas podem realizar tarefas repetitivas sem alterar o estado atual do sistema, prevenindo efeitos colaterais inesperados;
  • Aprendizado fácil: os playbooks fazem uso de uma linguagem descritiva baseada em templates YAML e Jinja.

Módulos[editar | editar código-fonte]

Módulos são as unidades de trabalho utilizadas pelo Ansible, e, em sua maioria, são autônomos e podem ser escritos em linguagens de script comuns, como Python, Perl, Ruby e Bash. Uma das propriedades principais dos módulos é idempotência, o que significa que mesmo se uma operação é repetida várias vezes (por exemplo, após a recuperação de uma interrupção), ele sempre colocará o sistema no mesmo estado.

Configuração de Inventários[editar | editar código-fonte]

O inventário é uma descrição dos nós que podem ser acessados pelo Ansible e, por padrão, o Inventário é descrito por um arquivo de configuração em formato INI, cuja localização padrão se encontra em /etc/ansible/hosts. O arquivo de configuração lista o endereço IP ou o nome do host de cada nó acessível pelo Ansible, os quais também podem ser atribuídos a grupos.

Exemplo:

192.168.6.1

[webservers]
foo.example.com
bar.example.com


Esse arquivo de configuração especifica três nós, o primeiro por endereço de IP e os dois últimos por hostnames. Além disso, os últimos também estão agrupados sobre um grupo de webservers.

Playbooks[editar | editar código-fonte]

Os playbooks expressam as configurações, implantação e orquestração no Ansible. Eles são formatados em YAML e cada um dele mapeia um grupo de hosts para uma sequência de papéis (roles). Cada papel é representado por chamadas para as tarefas do Ansible.

Ansible Tower[editar | editar código-fonte]

Ansible Tower é uma API, web service, e um console web-based desenvolvido para disponibilizar o Ansible para equipes de TI através de um hub para automatização de tarefas. A Tower é um produto comercial, portanto é pago, mas uma alternativa para ele é o Ansible Semaphore (que foi desenvolvido em Go).

Plataformas Suportadas[editar | editar código-fonte]

As máquinas controladoras devem ser um host baseado em Linux/Unix, como por exemplo Debian, CentOS, OS X e Ubuntu, e devem possuir Python 2.6 ou 2.7 instalados. Para as máquinas nós, caso elas sejam baseadas em Unix, precisam possuir Python 2.4 ou posterior. Para as que possuírem Python 2.5 ou anterior, o pacote python-simplejson também será necessário. A partir da versão 1.7 do Ansible ele passou a gerenciar nós do SO Windows e neste caso, é utilizado o recurso remoto de PowerShell nativo no lugar de SSH.

Integração em Nuvem[editar | editar código-fonte]

Além dos hosts físicos, o ansible pode implantar e gerenciar ambientes de virtualização em nuvem, incluindo o Amazon Web Services, CloudStack, DigitalOcean, Eucalyptus Cloud, Google Cloud Platform, KVM, Microsoft Azure, OpenStack e VMware.

Instalação[editar | editar código-fonte]

Para instalação em sistemas como Ubuntu e Debian, os seguintes comandos devem ser executados:

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

Pacotes do Debian/Ubuntu podem também ser montados a partir do código-fonte. Para isso execute:

$ make deb

Puppet[editar | editar código-fonte]

O Puppet é uma ferramenta de gerência de configurações e estados que vem da escola de GCONF do Mark Burgess, da universidade de OSLO, criador do CFEngine e destes princípios que vem sendo contruídos desde os anos 90.O puppet foi desenhado dentro dos conceitos fundamentais da “gerência de configurações”.

Linguagem e Sistemas[editar | editar código-fonte]

O Puppet usa uma linguagem declarativa para configurar sistemas operacionais e tem suporte a Linux, *BSDs, Solaris, Windows e outros, além de ser distribuído sob a Licença Apache 2.0.

Funcionamento[editar | editar código-fonte]

O Puppet é utilizado como cliente/servidor, seu ciclo de funciomaneto consiste em:

  • Facts: O node envia seus facts para o Puppet master. Esses facts são dados coletados pelo próprio agent (cliente) e que são enviados, em formato YAML, ao master (servidor).
  • Catalog: Após receber os facts, o Puppet master vai compilar um catalog com base nos facts recebidos, e então vai enviar esse catalog para o agent. O agent receberá o catalog e então executará o que está descrito nele.
  • Report: Após o agent aplicar as mudanças do catalog compilado no passo anterior, ele envia um relatório com as mudanças realizadas para o Puppet master.
  • Enforcement : O agente realiza as alterações necessárias para que o nó esteja em conformidade com o catalogo.
  • Report : Cada agente envia um relatório para o puppet master, indicando todas as alterações que foram efetivadas para a deixar o no em conformidade com seu catálogo;
  • Report Sharing: API aberta do puppet pode enviar dados para outras ferramentas, permitindo a você poder compartilhar informações de infraestrutura com outras equipes.

Instalação[editar | editar código-fonte]

Instalação no servidor:

apt-get install puppetmaster

Instalação no cliente:

apt-get install puppet

Comparação[editar | editar código-fonte]

Tanto Ansible como Puppet possuem a capacidade de realizar gerência de configuração de software, mas cada um possui uma finalidade de serviço diferente. Enquanto o Ansible é uma ferramenta para orquestração e automatização de tarefas de TI, implantação de aplicativos e gerência de configuração de sistemas, o Puppet funciona como uma ferramenta de configuração e estados. Ambos utilizam o sistema de cliente e servidor, que no Ansible são chamados de Máquinas Controladoras e Nós, sendo a conversação no Puppet feita através de SSL e no Ansible por meio de SSH. Ansible por ser um sistema agentless, ele não requer que um agente seja instalado na máquina nó, diferentemente do Puppet que requer a aplicação de um agente na máquina cliente.

Principais Vantagens[editar | editar código-fonte]

Ansible:

  • Não adiciona dependências adicionais ao ambiente de trabalho;
  • Consistente;
  • Não requer agentes nas máquinas nós, apenas requer OpenSSH;
  • As playbooks do Ansible quando bem escritas podem ser idempotentes;
  • Os playbooks fazem uso de uma linguagem descritiva baseada em templates YAML e Jinja.


Puppet:

  • Redução de custos de manutenção de computadores;
  • Diminuição do downtime de seu ambiente;
  • Maior facilidade e flexibilidade para implantar novas soluções com menor trauma e consequentemente menor custo;
  • Maior facilidade e flexibilidade para distribuir configurações para todo o parque de forma controlada.

Diferenças Técnicas[editar | editar código-fonte]

Ansible Puppet
Linguagem Python Ruby
Autenticação Mútua SSH SSL
Encriptação Secure Shell SSL, TLS
Agente Não Sim
GUI Sim (Pago) Sim


Referências[editar | editar código-fonte]

Ansible

Ansible Docs

Matera

Cooperati