Ansible / Puppet – Conclusão

Agora que vimos exemplos e considerações sobre similaridades e diferenças entre as duas ferramentas, vamos analisar e chegar à uma conclusão sobre qual delas usar de acordo com o cenário e o objetivo.

O cagaço

Conclusão: quem usa Ansible tem medo de executar todos os playbooks. Quem usa Puppet tem medo de comitar alterações.

Você pode fazer a alteração que for nas suas regras Ansible que isso não causará impacto algum até que seja executado. E como não é de costume executar repedidas vezes as mesmas regras, é provável que o que já foi configurado permaneça como está e você só execute a versão nova das regras em máquinas novas. Além disso, no Ansible é muito fácil controlar o grupo de hosts nos quais a regra será aplicada e você pode aplicar aos poucos. O medo vem justamente por que, como o Ansible não roda constantemente, você não tem como fazer idéia de quão diferente do que deveria, seu servidor está.

No Puppet é comitar e torcer que, independentemente do número de maquinas, todas elas terão aplicado as regras em até 30 minutos (padrão). Ou seja, você precisa MUITO ter um fluxo controlado do que vai para produção ou não.

Consultoria local

O Ansible é ótimo para consultorias presenciais.

Imagine que você contrate uma consultoria para implementar um OpenStack na sua empresa. O consultor pode vir com os playbooks e roles prontos e executar o Ansible do próprio notebook e subir todos os nós pra você simples assim. Se fosse Puppet, você precisaria subir um servidor Puppet antes, copiar as classes pra lá, instalar os agentes nos servidores e aplicar as regras.

No entanto, se feito com Ansible, quando o consultor for embora o “conhecimento” vai junto com ele. Você pode quebrar o ambiente e vai ter que chamá-lo novamente. Com Puppet, o Puppet consertaria pra você.

Consultoria remota

Agora pense pelo lado do freelancer remoto.

Com Ansible, o cliente terá que lhe fornecer uma VPN pra que você alcança os hosts na rede dele. Se você tiver vários clientes, e com redes conflitantes, vai ter que ficar gerenciando as VPNs.

Com Puppet, você pode simplesmente criar um Puppet na AWS com todo seu portfólio de serviços e os clientes se conectarão à ele sem problemas. Nada de VPN. E quando você fizer uma melhoria em alguma regra, ela será deplorada em todos os clientes automaticamente.

Cenário ideal

Com tudo isso, eu acredito que o cenário ideal pro Ansible é quando você tem equipes diferentes administrando servidores diferentes ou em comum. Como no exemplo do pessoal de infra executar os runnings iniciais depois os devs entrarem com os playbooks da aplicação (se bem que, nesse modelo, os devs podem desfazer os runnings do pessoal de infra).

Já o Puppet parece mais adequado quando os servidores todos são administrados por uma única equipe organizada.

Conclusão

Então, se você tem os dois cenários, use as duas ferramentas. Ninguém disse que você só pode usar uma delas. Quanto mais ferramentas diferentes você souber usar, melhor vai atacar cada problema (dilema do alicate: o alicate martela, aparafusa, desencapa etc, mas em si ele não é a ferramenta certa pra nada).

Eu ainda acrescentaria outras duas ao jogo:

Foreman e MCollective (post em breve).

O Foreman é uma ferramenta de gerenciamento completo do ciclo de vida de servidores físicos e virtuais. Ele se integra à Puppet, Ansible, Chef, Salt, ele provisional hosts físicos, virtuais e na nuvem, faz o papel de IPAM integrado ao DNS, conformidade de segurança com OpenSCAP e mais. Conheça o Foreman (oficial).

 

 

 

Um comentário em “Ansible / Puppet – Conclusão

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s