O Ansible parece ter uma clara vantagem sobre a concorrência, como chef e fantoche, porque é sem agente e economiza um certo grau de sobrecarga.
Eu li várias comparações das várias ferramentas de configuração e, embora cada ferramenta tenha suas próprias forças e fraquezas, percebo que muito disso se deve a preferências pessoais.
O benefício de ser menos agente é um acéfalo, mas existem vantagens da arquitetura mestre / agente em relação às ferramentas de gerenciamento de configuração?
Respostas:
Encontrei uma discussão interessante sobre a topologia pull vs push do gerenciamento de configuração de tópico
Um colaborador escreve que os sistemas pull (mestre / agente) oferecem mais flexibilidade e são mais fáceis de escalar.
IMHO, a única vantagem de uma arquitetura pull de mestre / agente é que ela pode ser usada em uma rede com firewall (quando a configuração real está localizada fora dessa rede) sem abrir brechas no firewall, enquanto a arquitetura push não pode.
Em termos de flexibilidade, acho que a questão mais importante é a configuração mínima necessária em um nó para se tornar remotamente gerenciável. Uma vez cumprido esse requisito, as duas arquiteturas podem lidar com atualizações. Uma arquitetura de mestre / agente precisa do agente instalado, configurado e em execução. Por um lado, Puppet e Chef ainda não estão instalados por padrão na maioria dos sistemas, enquanto o sshd (necessário pelo Ansible) está. Por outro lado, até o Ansible precisa de execução de sshd e credenciais configuradas no nó para serem acessíveis, então eu diria que não há muita diferença nessa perspectiva - especialmente se a configuração mínima for alcançada por meio de imagens de sistema personalizadas.
Em termos de escalabilidade, consideraria a arquitetura principal / agente menos escalável (mas apenas um pouco):
se o mestre tentar manter ativamente um estado ativo do sistema (ou seja, o mapa de todos os agentes e seus estados) que consumiria algum tempo / recursos. Sem um mestre, o Ansible não é suscetível a esse problema de escalabilidade. É verdade que até as arquiteturas mestre / agente podem oferecer uma abordagem escalável para fornecer um estado geral do sistema semelhante ao da Ansible (e provavelmente todos eles fazem hoje em dia).
antigamente, quando o mestre realizava as tarefas de configuração do agente (como mencionado na postagem mencionada em sua resposta), a escalabilidade dessa arquitetura poderia sofrer muito. Mas isso não é mais um problema, pois para todas as ferramentas mencionadas na sua pergunta, a configuração é transferida apenas para o nó local, que então executa as tarefas.
quando se trata de transferir as configurações para os nós locais, uma arquitetura pull é limitada apenas pela capacidade de atender a essas configurações (comum a ambas as arquiteturas), mas um mestre / agente precisa também executar as transferências de condução lógica e realmente fazer o transferências, se aplicável (é possível instruir apenas os agentes a obter suas próprias configurações), o que limita a rapidez com que o mestre pode propagar as configurações para um grande número de agentes.
IMHO, a idéia de ter um agente, mestre ou ambos se resume a isso:
Um mecanismo para gerenciar continuamente os estados dos nós.
Se tal ferramenta permitir isso, a capacidade de "auto-recuperação" é os benefícios óbvios.
No caso de Ansible, no que me diz respeito, não há mecanismos internos para fornecer os recursos de autocura (porque nenhum daemons está funcionando continuamente para buscar os estados e reagir a eles).
Dito isso, a autocorreção não parece o problema que uma ferramenta de gerenciamento de configuração deve resolver, então talvez não seja algo que se possa considerar "vantagem" de outras ferramentas contra o Ansible.