Quais são as limitações do Puppet em comparação com o Ansible?

16

Gostaria de entender as diferenças entre o Puppet e o Ansible, especialmente o tipo de limitações do Puppet em comparação com o Ansible.

Existem coisas que você não pode fazer no Puppet, mas no Ansible? Em outras palavras, por que algumas pessoas se mudam de Puppet para Ansible?

ansible comparison puppet

— kenorb
fonte

Eu mantive minha resposta bem separada disso, uma das razões pode ser todo o dinheiro que está investindo nela.

— ᴳᵁᴵᴰᴼ

19

É claro que existem vários prós e contras para cada Puppet, Ansible, Chef e adicione sua ferramenta favorita aqui também. Então, tentarei ficar longe da opinião e compartilhar o que é ótimo no Ansible, na verdade.

O principal recurso que coloca o Ansible acima dos outros não é ter que confiar em algum agente customizado / adicional em execução nos nós de destino, sendo baseado apenas em conexões ssh. Sim, ele ainda requer um servidor ssh, Python e várias bibliotecas Python nos nós, e se sua distribuição preferida (ou, boa sorte, existem alguns nós do Windows) não for fornecida com eles, será um pouco doloroso para iniciar. Mas isso é improvável e pode até fazer você pensar novamente sobre sua distribuição.

Isso simplificará o monitoramento, não consumirá recursos adicionais, não forçará o sistema a executar um daemon como root o tempo todo e, em geral, se sente melhor dentro da filosofia do UNIX. O Chef chef-solosabe que o Puppet pode ser executado sem mestre, mas ambos trabalham "na outra direção", clonando e usando ganchos, respectivamente. Enquanto com o Ansible, uma mesclagem no repositório de origem pode desencadear a implantação de uma maneira com a qual todos nos sentimos confortáveis, seja no Jenkins, no git master ou em alguma outra ferramenta como Rundeck, por exemplo.

— ᴳᵁᴵᴰᴼ
fonte

É importante notar que, se você alterou sua configuração ssh com o ansible, está bloqueado para fora da sua máquina, essa é a desvantagem do modelo push. Puppet ou chef pode trabalhar em um emprego crontab para que eles não terão impacto mais o sistema de código Python ansible em tudo

— Tensibai

1

Uma observação sobre os agentes: fui aprovado para integrar o Ansible em um HSE (ambiente de alta segurança) por uma equipe de segurança que recusou Chef e Puppet, mesmo na configuração sem mestre. Sem agente é um fator vencedor em alguns casos.

— Woodland Hunter

2

Se você interromper a configuração do SSH, você terá problemas além do Ansible. É uma boa prática do DevOps testar coisas como alterações de SSH em vários ambientes antes que elas cheguem à produção, e também é possível validar se a configuração do SSH está correta como parte da gravação - o templatemódulo Ansible facilita bastante isso.

— RichVel 7/08

Ouvi dizer que as pessoas argumentaram que a arquitetura sem agente da Ansible a torna mais adequada para gerenciar, por exemplo, roteadores, nos quais você não pode instalar um agente Puppet, por exemplo. Mas esses dispositivos vêm com intérpretes Python? Talvez não, o Python é realmente um requisito forte para todos os componentes gerenciados pelo Ansible?

— Drux

9

Não, as pessoas que se mudam de Puppet para Ansible (ou vice-versa) não têm nada a ver com o que pode ou não pode ser realizado com qualquer uma das ferramentas. Fantoche / Chef / Ansible - é principalmente uma questão de gosto.

Por exemplo, o Ansible é baseado em Python, e os desenvolvedores de Python geralmente se sentem mais à vontade com ele (não há necessidade de aprender um DSL) ou Ruby (para Chef). Mais fácil para os desenvolvedores de Python estenderem o Ansible também.

Mas, em essência, são todos muito semelhantes em termos do que você pode alcançar. Alguns têm pontos fortes em algumas áreas, e pontos fracos em outras, mas geralmente a escolha entre eles é feita pelo estilo / cultura / preferência da equipe.

— Assaf Lavie
fonte

7

Até o Puppet 4.0, não havia uma maneira fácil de orquestrar aplicativos espalhados por vários servidores ou serviços, pois era difícil ordenar ações especificamente no Puppet, que era uma opção de design . O Ansible era melhor em orquestrar e ordenar as etapas, especialmente em vários servidores. Isso foi especialmente significativo em aplicativos em que a ordem incorreta das etapas pode levar a erros irrecuperáveis através da repetição dessas etapas até que uma consistência eventual possa ser alcançada.

Isso não é mais um problema e, portanto, as distinções são amplamente baseadas em preferências.

— Jiri Klouda
fonte

2

A escolha do design do boneco foi um dos motivos pelos quais o Chef iniciou, e o principal foi o fato de eu ter mudado para o Chef por nossa infraestrutura e sistema de CD há alguns anos.

— Tensibai 6/03/2017

2

A orquestração de marionetes é apenas um recurso da empresa de marionetes (comercial), enquanto a orquestração no Ansible está na versão de código aberto. Geralmente, o Ansible é muito mais fácil de instalar e aprender do que o Puppet - tendo feito alguma avaliação de ambos, agora uso o Ansible. Também existem outras diferenças, por isso não é apenas uma questão de preferência pessoal.

— RichVel 7/08

1

Estou usando o Ansible no meu trabalho anterior e no atual, mas ele tem seus próprios problemas. Quanto mais uso o Ansible, mais me interessa aprender outra alternativa. Eu preferiria essa alternativa a não usar o Python para o desenvolvimento de módulos e a ter uma comunidade ativa de código aberto vital. Os pedidos de extração de Ansible levam quase um ano para serem revisados. Nesse ritmo, poderia ser também proprietário.

— Jiri Klouda

1

Muitas pessoas reclamam do agente fantoche, mas quando você está na nuvem e no grupo de dimensionamento automático e não deseja reconstruir a imagem da sua vm, é bom que a vm se conecte ao mestre das marionetes, não vejo nenhum problema em tem um pequeno agente.

— C4f4t0r 07/12/19