Chef vs. Puppet: Differences, Similarities, and How to Choose
Hoje colocamos duas ferramentas populares para o gerenciamento da configuração uma contra a outra; Chef vs Puppet. Estes tipos de ferramentas ajudam os engenheiros a manter uma configuração consistente em todos os servidores. Por exemplo, todos os servidores podem precisar ter IIS com uma ligação à porta 443 para acesso HTTPS e a respectiva regra de firewall para o tráfego de entrada. Mais importante, se alguém remover a regra do firewall, estes tipos de ferramentas vão manter a consistência, criando a regra do firewall novamente.
E sobre as cadeias de conexão de banco de dados onde você tem um diferente para dev, test, e prod?
Yes, Puppet ou Chef pode lidar com estes também.
Today’s post é sobre a comparação do Chef com o Puppet. Estas são ferramentas muito semelhantes que atingem o mesmo objetivo: manter um estado consistente. Mas, eles também diferem em como eles ajudam os usuários a manter a consistência e repetibilidade ao longo de todo o pipeline de entrega. Finalmente, vou falar sobre como escolher uma ferramenta em vez da outra, dependendo das suas necessidades e das necessidades da sua equipa.
Então vamos a isso.
>
>
>
>
Similitudes
Chef e Puppet têm semelhanças na forma como gerem as configurações nos servidores. Embora ambas as ferramentas funcionem de maneiras diferentes internamente, o resultado é o mesmo. Com ambas as ferramentas, você pode definir o estado desejado através do código. Ambas as ferramentas funcionam com uma arquitetura de nó mestre onde o mestre é responsável por armazenar todos os dados, e os nós são responsáveis por garantir que os servidores sempre tenham a configuração de estado desejada no lugar.
Por exemplo, um dos principais objetivos de usar o Chef ou o Puppet para o gerenciamento de configurações é que você possa definir como código qual deve ser o estado desejado de um grupo de servidores. Não deve importar se você quiser aplicar a mesma configuração aos servidores, o Chef e o Puppet se certificarão de implementar qualquer mudança de forma independente. Da mesma forma, todos nós acertamos Ctrl + S várias vezes para ter certeza de que estamos salvando as mudanças. Mas onde estes tipos de ferramentas brilham é que se alguém entra no servidor manualmente, e muda o estado desejado do servidor, estas ferramentas irão atualizar os servidores reconfigurando-os.
De uma perspectiva de arquitetura, Chef e Puppet parecem bem parecidos já que ambos usam uma arquitetura master-agent. Um nó mestre é onde todas as configurações do servidor ficam armazenadas. Masters para ambas as ferramentas estão altamente disponíveis (HA), mas com ligeiras diferenças – mais tarde. Então, para cada servidor que você quer gerenciar, há um agente instalado que está puxando a configuração em períodos automaticamente. Os agentes estão sempre verificando se o estado desejado está em conformidade, e não o contrário. Ambas as ferramentas podem gerenciar servidores Linux e Windows.
Por último, ambas ferramentas têm uma versão open-source e uma versão paga com mais recursos como uma melhor configuração do HA.
Diferenças
Eu disse antes que a arquitetura do Chef e do Puppet são similares, mas eles diferem ligeiramente na forma como eles lidam com o HA. No Puppet, o mestre replica seus dados para outro servidor, e eles funcionam de uma forma ativa/passiva. Para o Chef, o HA é tratado com três servidores em modo ativo/ativo com um front end de API que pode escalar horizontalmente.
Uma diferença significativa entre Chef e Puppet está em como eles definem a configuração de estado desejada para os servidores. Cada ferramenta tem sua própria linguagem específica de domínio (DSL). O Chef usa Ruby para DSL. Você tem mais liberdade para criar configurações complexas porque você está usando uma linguagem de programação. O Chef chama essas configurações de estado desejadas que você escreve receitas. Qualquer coisa que possa fazer com Ruby, pode fazer no Chef para criar receitas como se-condições ou chamar outras bibliotecas. O benefício disto é que os programadores podem sentir-se mais confortáveis a escrever receitas do Chef. Além disso, os desenvolvedores não se sentirão restritos apenas a uma DSL, adicionando ao definir uma configuração.
Por outro lado, o Puppet tem sua própria DSL, “que foi projetada para ser acessível para sysadmins”. E se você tem experiência em trabalhar com arquivos de configuração Nagios, escrever manifestos (sua versão de receitas do Chef) não será um problema. Você não tem muita liberdade aqui, mas isso também é bom do ponto de vista de ter uma linguagem universal. Portanto, você não precisa ter um background de desenvolvedor para usar e aprender o Puppet.
Por último, estas ferramentas diferem na forma como você desenvolve e testa receitas ou manifestos. O Chef tem uma estação de trabalho incluindo o Chef SDK que você pode instalar no seu computador local como um ambiente de encenação. Você pode testar as receitas localmente e depois carregá-las para o nó mestre. O Puppet não tem uma estação de trabalho, mas tem um SDK onde você pode testar os manifestos enquanto os desenvolve. Além disso, você pode aplicar os manifestos localmente com o comando apply puppet.
Exemplos
Vamos dar uma olhada em um exemplo de código de como ter certeza de que o agente Stackify está instalado.
Uma receita no Chef ficará assim (Ruby puro):
# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end
Para o Puppet, há um módulo para instalar o agente Stackify, e o manifesto ficará assim:
class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }
Como você pode ver, os exemplos de código acima confirmam o que eu disse antes. No Chef, você tem mais liberdade. Mas no Puppet, o código pode parecer mais simples quando há um módulo que você pode usar.
Premium Features
Vamos fazer a comparação, incluindo os recursos premium, que incluem outras coisas além do gerenciamento da configuração.
Para o Puppet, eles têm o Puppet Enterprise que inclui os seguintes recursos:
- Relatórios que ajudam com políticas de conformidade
- Orquestração de implementações de aplicativos e infraestrutura
- Provisionamento automatizado de infraestrutura com infraestrutura como código
- Gestão de código para promover mudanças de infraestrutura automaticamente
- Gestão de nó para controle granular de servidores
- Role-políticas de controle de acesso para usuários
- Suporte via e-mail ou telefone
Têm também o Puppet Remediate, que é uma ferramenta para a gestão de vulnerabilidades dos seus servidores. Você pode obter melhores insights sobre quais vulnerabilidades existem em seus servidores, e aplicar patches em escala a todos os servidores.
No Chef, além do gerenciamento da configuração, a versão paga inclui os seguintes recursos:
- Conformidade e gerenciamento de segurança
- Criar pipelines CI/CD e gerenciar versões para todos os aplicativos
- Visibilidade com dashboards em toda a sua pilha de infraestrutura
Você obtém mais detalhes em cada site do fornecedor, eles têm recursos muito bons para ajudá-lo a começar rapidamente.
Como escolher
Como escolher entre Chef e Puppet é uma pergunta difícil, e a resposta, como sempre, é … “depende”
Seja qual for a ferramenta que escolher, deve ser uma decisão de equipa, especialmente daqueles que acabarão por trabalhar com a ferramenta. Uma boa abordagem poderia ser considerar o histórico da equipe. As pessoas com um histórico de administrador de sistema podem achar mais adequado o uso do Puppet. Mesmo que tenham que aprender a DSL, nunca será como aprender uma linguagem de programação. Embora, se eles tiverem um background em desenvolvimento, as pessoas podem gostar mais do Chef (mesmo que não conheçam Ruby).
Mas você também deve considerar as funcionalidades premium de cada ferramenta. Qual dessas funcionalidades irá ajudar a sua organização a reduzir silos e desperdícios? Mais uma vez, tudo depende das suas necessidades. Eu vi que ambos os fornecedores sempre tentarão nivelar um com o outro com as funcionalidades. Por exemplo, no Puppet, você pode criar funções personalizadas com Ruby.
E, claro, outro aspecto essencial é o preço. Eu não quero incluir preços aqui porque os preços variam muito, e variam dependendo das necessidades de cada cliente. Outra razão é que no caso do Puppet, a sua página de preços não tem um número público mas sim um botão “Contacte-nos”. O Chef, por outro lado, a sua página de preços tem números, mas ainda precisa de os contactar. Aconselho-o a contactá-los directamente e a procurar uma boa oferta. Dependendo do número de servidores que você precisa para gerenciar, eles poderiam lhe oferecer um preço melhor.
Não há Silver Bullet
Como um lembrete amigável, não há Silver Bullet para uma ferramenta de gerenciamento de configuração. Tanto o Chef quanto o Puppet estão muito maduros hoje em dia, e estão constantemente melhorando seu produto, fazendo investimentos em pesquisa, criando melhores maneiras para as pessoas aprenderem sua ferramenta, etc. Espero que esta comparação tenha ajudado você a entender melhor como ambas as ferramentas funcionam. Talvez você esteja se preparando para uma entrevista de emprego, ou esteja curioso sobre as principais diferenças e semelhanças.
Mas se você está decidindo qual ferramenta usar para sua empresa, certifique-se de ter uma idéia clara dos problemas que está tendo e como esse tipo de ferramenta pode ajudá-lo a aliviar a carga. Haverá sempre uma curva de aprendizagem, e dependerá do background da equipe e qual ferramenta é mais adequada para eles. Além disso, observe os recursos e serviços premium além do gerenciamento da configuração, pois sua empresa pode precisar de mais ajuda com as políticas de conformidade.
- Sobre o Autor
- Últimos Posts
Sobre Christian Meléndez
Christian Meléndez é um tecnólogo que começou como desenvolvedor de software e mais recentemente se tornou um arquiteto de nuvens focado na implementação de dutos de entrega contínua com aplicações em vários sabores, incluindo .NET, Node.js e Java, frequentemente usando containers Docker.
- AWS Elastic Beanstalk .NET Core Getting Started – 17 de janeiro de 2020
- AWS Batch: Um Guia Detalhado para Começar Seu Primeiro Trabalho – 26 de dezembro de 2019
- Azure Container Service (AKS) – Uma Introdução Detalhada – 18 de dezembro de 2019
- Envio de Métricas Personalizadas CloudWatch da Lambda com Exemplos de Código – 14 de novembro de 2019
- Chef vs Puppet: Diferenças, semelhanças e como escolher – 24 de setembro de 2019