Quais são as perguntas certas a serem feitas ao decidir usar o Chef ou o Puppet?

Estou prestes a iniciar um novo projeto que, em parte, exigirá a implantação de muitos nós idênticos de aproximadamente três classes diferentes:

• Nós de dados , que executarão instâncias fragmentadas do MongoDB.
• Nós de aplicativo , que executarão instâncias de um aplicativo Ruby on Rails e de um aplicativo ASP.NET MVC mais antigo.
• Nós de processamento , que executarão os trabalhos solicitados pelos nós do aplicativo.

Todos os nós serão executados nas instâncias do Ubuntu 10.04, embora tenham pacotes diferentes instalados.

Tenho alguma familiaridade com o Chef de projetos anteriores, embora não me considere um especialista. Em um esforço para fazer a devida diligência, tenho investigado possibilidades alternativas. Temos um número interno de pessoas que são usuários de marionetes de longa data e eles me incentivaram a dar uma olhada.

Estou tendo problemas para avaliar as duas opções, no entanto. Chef e Puppet compartilham muitas das mesmas terminologias de domínio - pacotes , recursos , atributos etc. - e eles têm um histórico comum que decorre da adoção de abordagens diferentes para o mesmo problema. Então, em certo sentido, eles são muito semelhantes. Mas muitas das informações de comparação que encontrei, como este artigo , estão um pouco desatualizadas.

Se você estivesse iniciando este projeto hoje, que perguntas você faria para decidir se deveria usar o Chef ou o Puppet para o gerenciamento de configurações? (Nota: não quero responder à pergunta "Devo usar o Chef ou o Puppet?")

O Puppet e o Chef podem fazer o que você deseja. O seu melhor será começar a fazer o que você está tentando fazer e decidir qual ferramenta você mais gosta. Eu acho que as grandes perguntas que você precisa fazer é:

Você quer uma DSL? - As receitas do chef são escritas em rubi, o fantoche possui uma DSL. Se uma DSL é boa ou uma má escolha é uma das maiores diferenças entre chef e fantoche. O link que você postou na comparação da consultoria bitfield tem alguns bons comentários sobre isso, que você deve ler se ainda não o tiver. Eu também achei este post útil, certifique-se de ler os comentários também.

Você conhece Ruby? - Se você não conhece o ruby, iniciar o chef pode ser mais difícil ou exigir um investimento maior de tempo, pois você precisa aprender um novo idioma. Puppet tem sua própria linguagem que é fácil de começar a usar. Começando com o boneco 2.6, os manifestos também podem ser escritos em rubi .

Na Open Source Bridge, em 2009, eles tiveram um painel de autores e representantes de chef, puppet, bcfg2, cfengine e automateit, que você pode assistir no bliptv, que tem 1,75 horas de discussão sobre os utilitários de gerenciamento de configuração.

Opscode / Chef também fala sobre a diferença entre ele e o fantoche nas perguntas frequentes .

Acho que o fato de você não saber as perguntas certas pode resultar de você não ter muita experiência em trabalhar com nenhum deles. Depois que você começar a usá-los, começará a ver as diferenças entre eles. Eu sugiro que venha com alguns problemas da vida real que você resolverá com o chef ou fantoche, depois comece a tentar resolvê-los e veja o que você gosta / não gosta neles. Com o Opscode / Chef, eles oferecem uma solução hospedada que você pode configurar gratuitamente 5 nós para começar.

Deixe-me dizer primeiro - se você não estiver usando Puppet ou Chef; Não existe resposta errada. Ou será muito melhor do que o que você está fazendo agora.

Como líder de equipe, fiz a escolha de Puppet para minha equipe. Se eu fosse apenas uma equipe, teria escolhido o Chef. Aqui está o porquê:

Embora minha experiência seja certamente em administração de sistemas, minha formação é em programação. Foi para isso que eu fui à escola e não sou estranho em escrever aplicativos completos (não apenas scripts). Enquanto eu não conhecia Ruby, eu quero, e o Chef teria sido uma ótima desculpa para aprender as duas coisas.

No entanto, minha equipe está cheia de administradores de sistemas com pouca ou nenhuma experiência em programação, além do ocasional shell script. Para eles, escrever um módulo fantoche é como escrever um arquivo de configuração. É declarativo, não há iteradores e, no geral, é mais amigável ao administrador.

Equipes cheias de desenvolvedores que realizam atividades de administrador de sistemas tendem a preferir o Chef. Como o DSL do Puppet é declarativo, a ordem (mesmo em arquivos individuais) não importa, e isso frustra muitos usuários da linguagem de programação mais típica.

Também ouvi dizer muitas vezes que o Chef é muito mais amigável à nuvem do que o Puppet, mas o Puppet fez isso com o seu produto Puppet Enterprise no ano passado. Não posso falar por experiência própria sobre as habilidades na nuvem de nenhum dos produtos.

Por causa dessas qualidades acima, o estereótipo (e geralmente é correto) é que você verá que o Puppet é mais difundido na empresa em máquinas físicas, onde o Chef governa as startups na nuvem. É claro que há exceções, mas o que eu vi certamente apóia o estereótipo.

Se for uma equipe de uma pessoa, avalie as duas e escolha qual delas você gosta. No entanto, se, como eu, você tem uma equipe de pessoas, mantenha as necessidades da sua equipe priorizadas em relação a qualquer preferência pessoal, isso o poupará mais tarde quando você tentar obter o buy-in.

Divulgação completa, não usamos nenhum deles, embora os avaliemos internamente enquanto tentamos decidir sobre um sistema de gerenciamento de configuração. Portanto, não me considere um especialista em quais delas, afinal.

• Quão fácil é obter uma configuração de instância?
• Que configuração é necessária no cliente para que ele se comunique com o servidor?

E assim por diante. Mas você pode responder essas perguntas com muita facilidade: configure-as! Colocar uma amostra em funcionamento é algumas horas do seu tempo para cada produto e, considerando que o que você usar provavelmente será usado por muito tempo, vale a pena. Não apenas você pode ter uma idéia de como eles lidam com coisas específicas da plataforma (como o Debian e o apt, o RPM e o yum), mas definitivamente ajudará você a ter uma idéia dos aplicativos.

Lembre-se também de que todos os recursos do mundo não compensam uma interface difícil, além disso, pode expor problemas específicos da sua infraestrutura - ou seja, o que acontece se os arquivos de configuração forem atualizados em uma ordem diferente do que o esperado?

Então esse é o meu conselho; Chef e Puppet não são tão difíceis de configurar um servidor e um ou dois clientes e proporcionam uma experiência em primeira mão em ambos. Além disso, se você começar a configurá-lo e perceber que é uma dor enorme, já terá o conhecimento antes de se comprometer.

Se houver pessoas no seu projeto que já tenham experiência com o Puppet, sugiro que você use o Puppet.

Chef e Puppet são bastante semelhantes, e ambos os projetos são igualmente de alta qualidade. Se você tiver acesso a pessoas que já têm experiência com o Puppet, use o Puppet.

O exposto acima é definitivamente uma boa diretriz, também gosto de fazer essas perguntas gerais sempre que considerar uma nova dependência de terceiros.

• Qual a idade do projeto?
• Quão ativa é a comunidade (listas de discussão, bugs, irc etc.)?
• A documentação sólida é fornecida com práticas padrão?

Esses são bons indicadores do sucesso geral do projeto e podem prever um pouco a vida útil.

Tente encontrar pessoas que usem Chef ou Puppet por mais de um par de meses e pergunte a eles sobre suas experiências.

Para mim, está intimamente relacionado à tradição de uma comunidade específica. Historicamente, o Chef estava mais próximo dos caras do RubyOnRails. Também grande parte da popularidade do Chef na comunidade ROR porque o Engineyard construiu sua infraestrutura em cima do Chef.