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

Question

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 aplicação , que irão executar instâncias de uma aplicação Ruby on Rails e uma aplicação ASP.NET MVC mais antiga.
• Processando nós , que executarão os trabalhos solicitados pelos nós do aplicativo.

Todos os nós serão executados em 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, venho investigando possibilidades alternativas. Nós temos um número de pessoas que são usuários fantoches de longa data, e eles me encorajaram a dar uma olhada.

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

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

    

Answer 1

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

Você quer uma DSL? - As receitas do Chef são escritas em ruby, o fantoche tem uma DSL. Se uma DSL é boa ou uma má escolha é uma das maiores diferenças entre chef e fantoche. O link que você postou para comparação da bitfield consulting tem alguns bons comentários sobre isso, você deve ler se ainda não o fez. Eu também achei esta postagem no blog útil, lembre-se de ler os comentários também.

Você conhece Ruby? - Se você não conhece Ruby, começar com o chef pode ser mais difícil ou exigir um investimento maior de tempo, já que você precisa aprender um novo idioma. O Puppet tem o seu idioma próprio que é fácil de começar. Começando com o fantoche 2.6, os manifestos podem ser escritos em ruby também.

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

Opscode / Chef fala sobre a diferença entre ele e o boneco em seu FAQ como bem.

Eu acho que você não sabe as perguntas certas a serem feitas, pode ser que você não tenha muita experiência em trabalhar com qualquer um deles, uma vez que você começar a usá-los, começará a perceber as diferenças entre eles. Eu sugiro vir com alguns problemas da vida real que você vai resolver com o chef ou fantoche, em seguida, começar a tentar resolvê-los e ver o que você gosta / não gosta deles. Com o Opscode / Chef, eles oferecem uma solução hospedada que você pode configurar 5 nós gratuitamente para começar.

    

Answer 2

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

Como líder de equipe, escolhi o Puppet para o meu time. Se eu fosse uma equipe de apenas eu, eu teria escolhido o Chef em seu lugar. Aqui está o porquê:

Embora minha especialidade seja certamente em administração de sistemas, minha experiência está em programação. É o que frequentei na escola e não estou acostumado a escrever aplicativos completos (não apenas scripts). Enquanto eu não conhecia Ruby, eu quero, e o Chef seria uma ótima desculpa para aprender ambos.

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

Equipes cheias de desenvolvedores fazendo atividades de sysadmin tendem a preferir Chef. Como a DSL do Puppet é declarativa, a ordem (mesmo dentro de arquivos individuais) não importa, e isso frustra muitos dos usuários habituados a uma linguagem de programação mais típica.

Eu também ouvi dizer que muitas vezes o Chef é muito mais amigável com as nuvens do que o Puppet, mas o Puppet fez disso um foco com seu produto da Puppet Enterprise no ano passado. Eu não posso falar da experiência em habilidades de nuvem dos produtos.

Por causa das qualidades acima, o estereótipo (e muitas vezes é correto) é que você encontrará o Puppet mais difundido na empresa em máquinas físicas, onde Chef comanda as startups na nuvem. Há exceções, é claro, mas o que tenho visto certamente apóia o estereótipo.

Se for uma equipe de uma pessoa, avalie os dois e escolha qual deles você gosta. No entanto, se você, como eu, tiver uma equipe de pessoas, certifique-se de manter as necessidades da sua equipe com prioridade sobre quaisquer preferências pessoais, pois isso economizará você mais tarde quando tentar obter um buy-in.

    

Answer 3

Divulgação completa, não usamos nenhum deles, embora os tenhamos avaliado internamente ao tentar decidir sobre um sistema de gerenciamento de configuração. Então não me considere um especialista sobre o que, afinal de contas, é um desses.

• Como é fácil obter uma configuração de instância?
• Qual configuração é exigida no cliente para que ele se comunique com o servidor?

E assim por diante. Mas você mesmo pode responder a essas perguntas com facilidade: configure-as! Colocar uma amostra em funcionamento é algumas horas do seu tempo para cada produto, e considerando que tudo o que você usa para isso provavelmente será usado por um longo tempo, o tempo vale a pena. Não só você pode ter uma ideia de como eles lidam com as coisas específicas da plataforma (ou seja, baseados e apt baseados no Debian, baseados no RPM e no yum), mas certamente ajudarão você a ter uma idéia dos aplicativos.

Lembre-se também de que todos os recursos do mundo não compensarão uma interface difícil, além de 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 esperado?

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

    

Answer 4

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á tenham experiência com o Puppet, use o Puppet.

    

Answer 5

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

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

Esses são bons indicadores do sucesso geral do projeto e podem, de certa forma, prever o tempo de vida.

    

Answer 6

Tente encontrar pessoas que usem Chef ou Marionete há mais de um par de meses e pergunte sobre suas experiências.

    

Answer 7

Para mim, está intimamente relacionado com a tradição da comunidade específica. Historicamente, o Chef estava mais perto dos caras do RubyOnRails. Também grande parte da popularidade do Chef na comunidade ROR porque a Engineyard construiu sua infraestrutura no topo do Chef.