Ansible / Puppet – Considerações

Pelo que vimos dos exemplos no post anterior, as ferramentas parecem similares. Porém, por funcionarem de formas completamente diferentes, você deve estar ciente das consequências das diferenças de arquitetura delas para saber qual se adequa melhor ao seu cenário.

Push vs Pull

O Ansible trabalha no modo push, ou seja, ele vai até os servidores. O Puppet trabalha com pull, no qual agentes em cada servidor se conectam à um servidor Puppet.

Mark Burgess escreveu a teoria da promessa (resumo aqui) na qual compara dois modelos: o da obrigação e o da promessa. Para o modelo de promessa é necessário que as máquinas tenham um agente rodando localmente, modelo que Puppet, Salt, Chef e CFEngine seguem. O Ansible funciona no modelo de obrigação.

Uma vantagem do modelo push é não precisar de agente mas, uma desvantagem decorrente disso, é que hosts atrás de NAT tornam a vida um pouco mais difícil e hosts com o mesmo IP atrás de firewalls diferentes tornam a vida impossível.

Em um ambiente pequeno isso pode não ser problema, mas em grandes e complexos ambientes é muito mais simples garantir que todo mundo chegue num determinado IP do que garantir que um determinado IP chegue em todo mundo.

Outra coisa é que o modelo push não escala. A partir do momento que o Ansible precisa ir em cada servidor, é óbvio que demorará mais tempo pra fazer algo em 1000 máquinas do que fazer em 100. No modelo com agente isso não faz diferença.

 

Descentralizado vs centralizado

Para quem leu A Catedral e o Bazar (Eric Raymond), eu comparo o Ansible ao Bazar e o Puppet à Catedral.

O Ansible permite um modelo descentralizado de trabalho, onde cada equipe pode até ter sua própria máquina Ansible, ou até mesmo executar o Ansible de suas próprias estações. Mais de um Ansible pode executar coisas em um mesmo servidor. exemplo: pessoal de infra tem seus playbooks ansible pra subir a configuração e tunning inicial dos servidores e, logo depois, o pessoal de dev executa os playbooks para subir suas aplicações. Outra característica é que não há um report centralizado, o report é o STDOUT da execução do comando ansible na máquina que ele foi executado.

O Puppet é um modelo centralizado onde cada máquina está ligada à um único servidor Puppet que precisa saber tudo sobre ela. Por ser centralizado, você tem todos os reports das execuções num ponto único.

Ou seja, o Ansible tem a mesma flexibilidade e agilidade dos bons e velhos scripts via ssh que sempre usamos. O Puppet é um pouco mais “engessado” nesse ponto.

 

Executar vs assegurar

Por padrão o Ansible executa. Por padrão o Puppet assegura. É a natureza das ferramentas.

Ok, você pode usar o Ansible pelo cron, rundeck e Ansible Tower/AWX.

Ok, você pode usar o Puppet localmente sem ter que ter um servidor Puppet.

Mas não se trata do quanto você pode martelar pregos. Não force a barra.

 

Facts

Lembra dos facts ?

O seu Puppet também é um sistema de inventário do seu parque porque ele coleta diversas informações das máquinas sempre que o agente executa (padrão a cada 30m). No Ansible não há um local onde você possa consultá-los e, mesmo que houvesse, os dados podem ficar defasados à menos que você rode o ansible frequentemente.

Num caso de uso normal do Puppet você pode criar regras que “reagem” à mudanças. Por exemplo: se você tem diferentes servidores DNS em diferentes redes e sua regra analisa a rede que a máquina está para decidir qual DNS apontar, se você depois mudar a máquina de rede automaticamente o DNS será reconfigurado.

Isso é bem útil pelo lado de segurança também. Você pode criar um fact que teste/explore uma vulnerabilidade e, caso esse fact tenha “sucesso”, pode aplicar alguma medida como baixar serviços, subir regras de firewall ou aplicar um patch.

 

Ordem de execução

O Ansible executa sequencialmente as tarefas na ordem que estão descritas.

O Puppet não e não faria sentido. O Puppet compila um catálogo com o estado final desejado com base em todas as regras que devem ser aplicadas ao host, e essas regras podem vir de diversos arquivos separados. Ele tem sim alguma inteligência para criar um grupo antes de criar o usuário que depende daquele grupo, mas pra coisas não tão óbvias, você precisa especificar o que depende do que.

Idempotência

Idempotência é uma proprieade que o sistema tem de chegar sempre ao mesmo resultado independentemente do estado anterior e do número de vezes que você executar. Outro conceito importante é o da convergência, que consiste basicamente em executar apenas o necessário para chegar ao estado desejado.

Tema polêmico. Tão polêmico que fiz um post só pra isso e por isso não vou detalhar aqui.

Mas o resumo é: o Ansible não só não é idempotente como não precisa ser.

Idempotência e convergência são conceitos aplicados à ferramentas que trabalham com estado final desejado, que não é o caso do Ansible. No Ansible, você descreve uma lista de tarefas (essa é a hora que tomo as pedradas).

Meu ponto é bem simples: o Ansible do fulano pode configurar o servidor A pra um estado X. Já o Ansible do ciclano pode configurar o mesmo servidor pra um estado Y diferente de X e não haverá um conflito. Essa é a beleza do Ansible ! Não há um ponto centralizado que analise esse tipo de conflito.

Na verdade, nem precisa ser esse o caso. Numa mesma playbook você consegue declarar coisas conflitantes, como por exemplo: “O serviçco X deve estar parado. O serviçco X deve estar rodando.”. Além do Ansible não reclamar, ele irá parar e subir o serviço em toda execução. Aí, meu amigo, convergência… idempotência… foi tudo pro calalio.

Percebem ? Não é idempotente porque não define um estado final, mas sim uma lista de tarefas a serem executadas de forma inquestionável. Essa é a beleza da orquestração.

Módulos e roles da comunidade

Ambas as ferramentas possuem repositório oficial para compartilhamento de regras. Ansible Galaxy pro Ansible e Forge pro Puppet.

Só para fazer um comparativo, segue número de downloads de regras equivalentes dos respositórios de cada um:

HAproxy: Ansible=1.4k, Puppet=2.3M

Keepalived: Ansible=6.7k, Puppet=5.1M

Consul: Ansible=784, Puppet=3.7M

Cassandra: Ansible=63, Puppet=584k

Não sei se é só porque o Puppet existe há mais tempo que o Ansible ou se de fato o pessoal do Ansible costuma fazer suas próprias regras antes mesmo de procurarem se já existe (visto que é simples de fazer, talvez).

Módulos para Windows

O Ansible tem módulos separados para gerenciar as mesmas coisas em windows e Linux.

Enquanto o Puppet usa os recursos como file, service, package e user para ambos os sistemas, o Ansible tem win_file, win_copy, win_service, win_package, win_user etc específicos para Windows.

Essa diferença faz sentido porque quem interpreta as diferenças entre as plataformas é o agente do Puppet, e como o Ansible não tem agente e é o próprio código do recurso que teria que interpretar as diferenças, faz mais sentido fazer recursos diferentes mesmo.

Fazem a mesma coisa ?

Repetindo a pergunta: fazem a mesma coisa ?

Até podem fazer, mas de formas completamente diferentes, certo ?

Com isso já deu pra ter uma idéia que, dependendo do cenário e do objetivo, uma ferramenta pode atender melhor que a outra.

No próximo e último artigo da série eu explico minha conclusão sobre qual, como e onde utilizar cada ferramenta.

 

 

 

3 comentários em “Ansible / Puppet – Considerações

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