Puppet vs Chef, pró e contra dos usuários e casos de uso [fechado]

Eu já pesquisei no Google e li o artigo "Fantoche ou chef de cozinha" .

Estou interessado em casos de uso, implementações do mundo real nas quais as pessoas escolheram uma ou outra com base em problemas reais.

Estou particularmente interessado na integração com questões de sapateiro (sei que o fantoche é uma abordagem padrão nessa direção); como alguém qualquer experiência em integração sapateiro-chef ?

desde já, obrigado

Para ser sincero, acho que isso se resume a um ponto de vista simples: o chef parece ser uma solução imperativa e programática, o uso de ruby ​​como a linguagem instantaneamente me faz esperar que alguém a tenha transportado para python, como é o caminho do mundo com todos os ideias do Ruby.

Não é isso que você deseja para esse tipo de coisa. Você quer falar com o vazio onde o sistema estará e declarar:

"Na porta 80, convoque do norte o daemon chamado nginx. Sua tarefa é servir."

"Um usuário deve existir, seu nome deve ser chiggsy e ele deve ser um dos poderosos no grupo da roda"

"Levante uma parede de fogo, fina nos lugares 80.443.8080"

E assim por diante, embora talvez em linguagem menos florida.

Puppet suporta esse paradigma melhor IMO. Eu teria usado qualquer um deles, não tinha preferência, mas quando se tratava disso, o declarativo era mais adequado para mim.

Fantoche.

Escrevi uma comparação detalhada de Chef vs Puppet aqui: Puppet vs Chef: 10 razões pelas quais Puppet vence . Embora não inclua casos de uso, espero que forneça alguns pontos de partida úteis para as pessoas se perguntarem qual ferramenta escolher para sua automação de infraestrutura.

Desculpe pela verbosidade. Use a ferramenta que facilita o trabalho. Esse é o ponto da automação, certo?

História: Eu usei fantoches em shows anteriores e no mês passado passei cerca de uma semana tentando me acostumar com o chef para ver se eu faria a troca no meu novo show.

Eu não pulei.

Jargão: Um problema infeliz com esses dois sistemas é a sobrecarga de jargão. (receitas, modelos, nós, funções, atributos, provedores) Ele continua e continua. Encontrei Chef deu um passo adiante. (Faca, Shef, etc.)

Maturidade do código: Basta dizer que eu achei o Chef um pouco cru demais. Parece muito com o que as marionetes sentiram no período de 0,21 / 0,22, há 3-4 anos. Há muito fluxo acontecendo.

Para não dizer que também não aconteceu em fantoches. (Eu descobri muitos recursos excelentes em bonecos que só apareceram nos últimos anos. - correspondência de expressões regulares!)

Ruby: Eu não gostei de toda a sobrecarga de rubi no Chef. (você precisa de gem e rake antes mesmo de começar) Você pode usar o ruby ​​para resolver problemas complexos no puppet a'la facter, mas você não precisa se não quiser.

Complexidade: não gostei do foco da GUI no chef. Sei que é bonito e o boneco tem uma interface da Web em andamento como um complemento, mas acho que isso deve ser mais dissociado.

Chef tem uma arquitetura muito mais complexa. Pode escalar melhor, mas existem muitos pontos potenciais de falha.
http://wiki.opscode.com/display/chef/Architecture

O Chef precisa de couchdb, rabbitmq e solr, além do servidor da API e da interface da web.

Eu só quero uma interface cliente / servidor simples que não precise de uma estrutura MVC e um armazenamento de dados complexo por trás dela.

O Puppet é muito mais simples nesse departamento. (para não dizer que não há muitos complementos para torná-lo mais confuso)

Concluindo o trabalho: no final, fui com o que sabia. Depois de passar uma semana trabalhando lado a lado e mal conseguindo fazer o básico com o Chef, pude voltar ao fantoche e esgotar minhas necessidades básicas em poucas horas. (gerenciamento de pacotes, gerenciamento de usuários, modelos de arquivo de configuração)

Advertência sobre os módulos: O Puppet mudou recentemente para o uso de "módulos", que são contribuídos por terceiros. Eu não acabei usando isso e encontrei uma ampla variedade de qualidade. Não deixe de espiar embaixo das cobertas e ver o que e como elas estão funcionando antes de se aprofundar nelas.

Aqui está uma opinião: tentamos todos eles em nossa empresa e preferimos marionetes. Simplesmente porque é fácil de usar.

Eu mesmo já vi casos em que gerenciar 1000 hosts com diferentes configurações é muito mais fácil com o fantoche. Empresas de fato como o google usam fantoches para sua implantação.

A principal arquitetura de design do fantoche é tal que, ele funciona muito melhor do que outros se você o configurar da maneira correta. Por exemplo, adicionando fatos personalizados para suas configurações personalizadas etc. os links abaixo podem fornecer algumas informações http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent

http://slashroot.in/puppet-tutorial-how-does-puppet-work

Isso pode ter mudado desde a última vez que o experimentei, mas quando estava tentando chef no RHEL, não havia uma maneira clara de instalá-lo. Alguém criou um yum repo com todos os pacotes necessários, mas acabou instalando 200 pacotes ímpares. O fantoche, por outro lado, tem uma única rpm (e algumas dependências).