Chef vs Marionete

Puppet e Chef evoluíram significativamente - basta dizer que estamos muito atrasados em revisitar esses dois pesos pesados. Neste artigo, daremos uma nova olhada em seus principais componentes, juntamente com novas ferramentas e integrações de ecossistema que continuam a posicioná-los como plataformas líderes de automação de TI corporativa.

Alguns diferenciais anteriores - como a respectiva abordagem declarativa/processual de cada plataforma e a linguagem de programação subjacente - foram discutidos ad nauseum. E como ambas as soluções continuam a se tornar mais poderosas e complexas, essas diferenças são de fato menos relevantes. Para os fins desta comparação, vamos nos concentrar em quão bem eles resolvem os desafios de TI e entrega contínua enfrentados pelas empresas de hoje.

Chefe

Simplesmente rotular uma ferramenta como uma solução de DevOps não a torna assim. Ele deve abordar os desafios contemporâneos de TI na construção/gerenciamento de organizações de alta velocidade, facilitando a melhoria constante e a colaboração entre grupos. As ferramentas, como agentes críticos de mudança, são fundamentais tanto para gerenciar a tecnologia quanto para moldar a cultura:

"As ferramentas que usamos reforçam o comportamento; O comportamento reforça a ferramenta. Assim, se você quiser mudar seu comportamento, mude suas ferramentas. ”

- Adam Jacob, diretor de tecnologia, chef

O Chef estende ainda mais essa noção usando as artes marciais como uma metáfora para o DevOps, especificamente - Kung-fu. Abaixo está um detalhamento da escola particular de DevOps Kung-fu do Chef:

De fato, muitos dos princípios destacados acima (por exemplo, coletar métricas, integrar e entregar continuamente, colocar aplicativos e infraestrutura no mesmo fluxo de trabalho) são manifestos no Chef 15.

Recursos e destaques do chef

No nível básico, o Chef é uma ferramenta para automação, provisionamento e gerenciamento de configuração. A plataforma é composta pelos seguintes componentes:

• Chef Server: o hub principal onde o Chef propaga e armazena informações e políticas de configuração do sistema (ou seja, receitas e livros de receitas). O console de gerenciamento do Chef é a interface do usuário da Web para o Chef Server.
• Chef Client: instalado em cada nó que está sendo gerenciado, o Chef Client executa tarefas de configuração na máquina local.
• Chef Workstation: permite que estações de trabalho designadas criem/testem/mantenham livros de receitas e carreguem-nos no Chef Server. As estações de trabalho também são usadas ao utilizar o pacote do kit de desenvolvimento do Chef.
• Chef Analytics: uma plataforma que fornece ações e histórico de execuções, relatórios em tempo real e notificações sobre as atividades de automação do Chef.
• Chef Supermarket: um diretório de código aberto de livros de receitas contribuídos pela comunidade

Entrega contínua com o Chef Automate

As comparações tradicionais entre Puppet e Chef geralmente descrevem o último como sendo mais amigável ao desenvolvedor, com favoritos como Chef's Knife Plugin Architecture e o Chef Developer Kit (Chef DK) relegados principalmente ao uso do desenvolvedor. No evento ChefConf 2015, um novo produto de fluxo de trabalho DevOps foi apresentado: Chef Delivery, um conjunto de ferramentas que adicionou recursos ainda mais amigáveis ao desenvolvedor, como históricos abrangentes de alteração de base de código, métricas e gerenciamento de permissões para a plataforma. Desde então, o Chef incorporou essa automação e entrega contínua ao Chef Automate, uma plataforma que reúne todas as ferramentas de automação de infraestrutura do Chef.

As ferramentas de teste automatizado e integração/entrega contínua do Chef Automate incluem recursos como um pipeline de fluxo de trabalho compartilhado, recursos de colaboração e análises aprimoradas, bem como integrações de ecossistema com AWS, Azure e Docker, para citar alguns. Embora esses aprimoramentos sejam, sem dúvida, uma bênção para a comunidade de desenvolvedores do Chef, as aspirações do Chef têm pouco a ver com se tornar uma ferramenta de automação centrada no desenvolvedor e mais com a construção de uma plataforma abrangente para gerenciamento de pipeline de DevOps.

Segurança aprimorada com o Chef Vault

As personalizações de clientes e/ou comunidades muitas vezes se tornam tão difundidas e integrais que encontram seu caminho em lançamentos de produtos genuínos. Este é certamente o caso do Chef Vault, um projeto iniciado pela Nordstrom para melhorar os mecanismos de segurança inerentes à plataforma. O Chef pode armazenar nativamente dados confidenciais (por exemplo, chaves de certificado SSL, senhas de banco de dados) em "recipientes de dados" criptografados - repositórios de pares de chave/valor - para acesso seguro e fácil. O gerenciamento desses pacotes de dados, no entanto, é um processo tedioso e propenso a erros. O Chef Vault fornece uma camada adicional de segurança que permite um gerenciamento mais fácil desses recipientes de dados criptografados.

Vulnerabilidades do Chef

De acordo com o banco de dados Common Vulnerabilities and Exposures (CVE), o Chef tem um total de 3 vulnerabilidades relatadas de gravidade média:

• CVE-2011-5098
• CVE-2011-5097
• CVE-2010-5142

O Chef também mantém uma lista contínua de notas de segurança que fornecem aos clientes diretrizes de correção adequadas para lidar com as deficiências de segurança da plataforma.

Perfil de risco de segurança cibernética do Chef

Demos uma olhada no site do Chef para ver se poderíamos descobrir algum risco potencial de segurança cibernética que pudesse resultar em vazamentos ou violações de dados.

Não surpreendentemente, a Chef, uma empresa de tecnologia relativamente sofisticada, obtém uma respeitável classificação de segurança B (770/950).

Entre seus riscos mais significativos estão uma versão SSL/TLS insegura, deixando-a aberta a ataques man-in-the-middle. Falta de DMARC e DNSSEC.

Saiba mais sobre os fatores de risco para o site chef.io ou obtenha sua própria classificação de segurança gratuitamente.

Marionete

Como mencionado anteriormente, o Puppet é considerado uma solução mais orientada para operações e administradores de sistemas quando comparado ao Chef, embora, novamente, essas distinções baseadas em funções estejam se tornando menos relevantes a cada versão. Os profissionais de DevOps, tanto os desenvolvedores quanto a equipe de operações, se esforçam para alcançar as condições ideais para integração/entrega contínua. As ferramentas são, portanto, cada vez mais avaliadas com base em sua capacidade de atingir esses fins de forma eficaz e eficiente no contexto das necessidades exclusivas de uma empresa. Não obstante, o Puppet desfrutou de vantagens significativas de pioneirismo ao longo dos anos e, embora o Chef e o Puppet tenham sido líderes de mercado desde os primeiros dias da automação de TI, o último possui um histórico comercial mais longo e uma base de instalação maior.

Atualmente na versão 6.11, o Puppet é comumente implantado em uma configuração cliente/servidor com nós gerenciados sincronizando periodicamente suas configurações com o servidor. Relatórios (por exemplo, resultados de execuções de automação, erros/exceções) e outras informações são enviados pelos clientes de volta ao servidor para análise e processamento agregados. O gráfico a seguir é uma representação básica do fluxo de dados do Puppet:

Recursos e destaques da marionete

A automação do Puppet funciona impondo o estado desejado de um ambiente, conforme definido nos manifestos do Puppet, arquivos que contêm informações predefinidas (ou seja, recursos) que descrevem o estado de um sistema. Os principais componentes que compõem o Puppet são os seguintes:

• Puppet Server - o servidor central que gerencia os nós do Puppet (agentes)
• Puppet Agent - software cliente instalado em nós gerenciados que permite a comunicação e a sincronização com o Puppetmaster
• Puppet Enterprise Console - uma GUI da Web para analisar relatórios e controlar recursos de infraestrutura
• PuppetDB - serviço de armazenamento de dados para Puppet os dados produzidos pelo Puppet

Outros componentes importantes que valem a pena mencionar em relação a outros incluem o MCollective, uma estrutura para oferecer suporte à orquestração de servidores ou à execução de tarefas paralelas, e o Hiera, um utilitário de pesquisa hierárquica de chave/valor para fornecer dados de configuração específicos do nó ao Puppet (para manter os dados específicos do site fora dos manifestos). A Puppet integrou o MCollective, o Hiera e uma infinidade de outros projetos de código aberto em sua plataforma para fornecer automação e gerenciamento abrangentes de infraestruturas corporativas de missão crítica. Muitos complementos contribuídos pela comunidade também estão disponíveis no Puppet Forge, uma biblioteca expansiva de módulos de código aberto para estender os recursos e capacidades da plataforma.

Atualizações no Puppet Node Manager

O Gerenciador de nós do Puppet permite a criação de regras em torno dos atributos do nó, o que permite um gerenciamento de nós mais fácil e eficiente. Com o Node Manager, os nós podem ser gerenciados com base em seu trabalho e não no nome, eliminando a necessidade de classificar manualmente cada nó. As novas atualizações incluem recursos avançados de provisionamento para contêineres do Docker, infraestrutura da AWS e máquinas bare-metal.

Introdução ao Puppet Code Manager

O Puppet tem sido um dos pilares do movimento DevOps desde o seu início e continua a atender aos requisitos de integração/entrega contínua da empresa. O conceito de "infraestrutura como código" envolve o uso de práticas recomendadas de desenvolvimento de software para gerenciar configurações de infraestrutura e detalhes de provisionamento, incluindo revisão de código, controle de versão e desenvolvimento colaborativo, entre outros. E, como o Chef, a plataforma da Puppet evoluiu em resposta às crescentes necessidades de um mecanismo abrangente para gerenciar o pipeline de entrega contínua.

Disponível desde o Puppet Enterprise 3.8, o Puppet Code Manager fornece uma maneira consistente e automatizada de alterar, revisar, testar e promover o código do Puppet em uma estrutura de entrega contínua. Com base no R10K, um conjunto de ferramentas de uso geral para implantar ambientes e módulos do Puppet fazendo interface com um sistema de controle de versão, o Puppet Code Manager acelera a implantação da infraestrutura, tornando-a um processo testável e programático. E ao permitir fácil integração com o Git para controle de versão, esta última adição à plataforma Puppet confunde ainda mais a linha entre software e infraestrutura.

Rede definida por software (SDN)

A SDN é um novo paradigma de rede que desacopla o controle e o encaminhamento de rede da infraestrutura física, permitindo o gerenciamento ágil de recursos de rede em ambientes em rápida mudança. Assim como a computação em nuvem permite que a TI ative rapidamente instâncias de computação e armazenamento sob demanda, a SDN substitui operações de rede rígidas (e às vezes manuais) por serviços e recursos de rede provisionados dinamicamente.

Este novo modelo de rede está alinhado com a defesa da Puppet de "infraestrutura como código". " Como tal, a empresa fez iniciativas estratégicas e parcerias significativas em apoio à SDN. Por exemplo, a Puppet Labs anunciou recentemente uma parceria com a Arista Networks, desenvolvedora líder de switches SDN, para fornecer suporte de automação à linha de equipamentos SDN do fornecedor. Esta e outras parcerias semelhantes (por exemplo, Cumulus Networks, Dell, Cisco) posicionarão o Puppet favoravelmente em relação aos fornecedores concorrentes, uma vez que as tecnologias SDN ganhem ampla adoção.

Segurança e vulnerabilidades do Puppet

Nenhum software está isento de vulnerabilidades, e o Puppet certamente tem a sua própria. A empresa mantém ativamente um repositório de divulgações de segurança do Puppet, com uma lista completa de vulnerabilidades relatadas disponíveis por meio do banco de dados CVE. No momento em que este artigo foi escrito, 79 vulnerabilidades foram documentadas em todo o ecossistema do Puppet, com um nível médio de gravidade médio, e a maioria delas se aplicando ao Puppet e ao Puppet Enterprise de código aberto. O Chef não mantém um banco de dados CVE para todos os seus produtos. O único produto para o qual eles emitiram CVEs, o Chef, contém 3 CVEs de 2012.

Perfil de risco de segurança cibernética do Puppet

A pontuação geral de risco do Puppet, medida pelo Upguard Cybersecurity Rating, tem uma pontuação A (903/950), muito mais alta do que a classificação B do Chef.

No entanto, o diabo está nos detalhes quando se trata de configuração incorreta, e o Puppet está se abrindo e seus clientes para falsificação de e-mail em campanhas de phishing e spear phishing com sua filtragem SPF branda.

Como o Chef, ele também não utiliza DNSSEC.

Saiba mais sobre os fatores de risco para o site puppet.com ou obtenha sua própria classificação de segurança gratuitamente.

Chef vs Puppet: diferenças de DSL e facilidade de uso

Enquanto o Chef e o Puppet estão muito mais próximos em design do que ferramentas de gerenciamento de configuração radicalmente diferentes, como o Ansible. A primeira grande diferença é que ferramentas como o Ansible dependem de uma arquitetura sem agente, enquanto o Chef e o Puppet usam uma arquitetura baseada em agente mestre ou escravo de marionete. Para o Ansible, as alterações de gerenciamento de configuração são propagadas de qualquer máquina de trabalho via SSH, em vez de clientes nos nós. A segunda grande diferença dessas outras ferramentas é o uso da linguagem de programação Ruby sobre a qual o Chef e o Puppet são construídos. No uso diário, no entanto, você notará diferenças sutis entre o Chef e o Puppet, graças em grande parte ao uso de cada plataforma de uma linguagem específica de domínio exclusiva para automatizar o gerenciamento de configuração.

Em primeiro lugar, o Chef DSL se parece sintaticamente com Ruby, na verdade, é um Ruby DSL padrão com funções especiais e palavras-chave adicionadas para lidar com a configuração de infraestrutura e aplicativos em plataformas de sistema operacional que incluem Linux, Windows e muito mais. Como a DSL do Chef permite que você escreva código Ruby normal junto com a chamada de funções específicas do Chef e o uso de palavras-chave específicas do Chef, ela vem com uma curva de aprendizado mais baixa para as equipes de DevOps que usam Ruby regularmente para seu trabalho. Por exemplo, colocar um desenvolvedor Ruby em funcionamento com o Chef provavelmente levará menos de uma única tarde e algumas pesquisas rápidas no Google. Esse não é o caso do Puppet, que usa uma DSL que, embora declarativa, se afasta muito da sintaxe padrão do Ruby.

Para ver esses dois em funcionamento, considere o exemplo de código a seguir que instala o servidor Web Apache.

Chef:

pacote "apache2" do

ação: instalar

fim

Marionete:

classe apache {

pacote { 'apache':

nome => $apachename,

garantir => presente,

}

}

As diferenças de DSL são superficiais quando você olha para casos de uso simples, mas levam a diferentes efeitos embutidos. O Chef, por exemplo, tende a ser muito flexível, pois você pode realizar o que quiser usando auxiliares e funções padrão do Ruby. Todo o poder expressivo do Ruby está disponível para você. Isso tem vantagens e desvantagens, principalmente que você introduz complexidade desnecessária que pode ser difícil para os mantenedores de suas receitas do Chef desembaraçarem.

A DSL do Puppet tem a força de manter a maioria das tarefas simples e geralmente há uma maneira segura de fazer as coisas. A desvantagem é que, se sua equipe tiver configurações complexas para lidar, você se verá lutando contra as restrições impostas pela DSL. Foi observado que a DSL do Chef é amigável para desenvolvedores Ruby, enquanto a DSL do Puppet é mais amigável e mais próxima dos administradores de sistema que podem preferir uma linguagem de configuração não muito longe do XML ou de outros arquivos de configuração declarativos. Essa visão permanece verdadeira, embora, como observado, ambas as plataformas realizem essencialmente as mesmas tarefas na maior parte.

Chef vs Puppet: Microsserviços e Suporte à Conteinerização

A popularidade da conteinerização e de ferramentas como Docker e Kubernetes impactaram a maneira como os aplicativos são implantados. À medida que os aplicativos evoluíram de uma arquitetura monolítica para microsserviços granulares, o papel das ferramentas tradicionais de gerenciamento de configuração foi questionado. Afinal, plataformas de conteinerização como Google Kubernetes Engine e Amazon ECS vêm com ferramentas para configurar contêineres na nuvem.

O Chef adotou a conteinerização e criou ferramentas para dar suporte à criação e implantação de aplicativos em contêineres. Sua ferramenta de código aberto Chef Habitat, disponível no Github, oferece uma ferramenta completa de gerenciamento do ciclo de vida do aplicativo que funciona bem com Docker, Kubernetes e outras ferramentas de conteinerização. A versatilidade do Habitat permite que ele crie e implante aplicativos tradicionais, como aplicativos Java ou Python legados, com a mesma facilidade que microsserviços granulares, por meio do uso de um arquivo plan.sh que fornece todos os detalhes necessários para criar seu aplicativo. O Habitat se integra bem com ferramentas tradicionais de DevOps, como Jenkins, e é implantado em um grande número de plataformas, incluindo Red Hat Linux, outras distribuições Linux, Mac, Windows e Unix. Os formatos de exportação de pacotes disponíveis no Habitat estão definidos para expandir no futuro, mas o Docker já está incluído. A lista completa apresenta:

• Estivador
• ACI
• Mesos
• Alcatrão
• fundição de nuvens

O Puppet também integrou mecanismos para facilitar o gerenciamento e a implantação de aplicativos em contêineres pelos administradores de sistema. O Puppet tem vários módulos compatíveis para instalar e gerenciar o Docker, incluindo download e configuração de imagens do Docker. A versão mais recente do módulo Docker do Puppet disponível no Puppet Forge permite a execução e o gerenciamento de contêineres do Docker usando o código do Puppet. O módulo Docker do Puppet é compatível com os seguintes sistemas operacionais:

• RedHatLinux
• Janelas
• Ubuntu
• Debian
• CentOS

Automação de teste para código do Chef e do Puppet

As boas práticas de código incluem testar seu código com antecedência e frequência, com desenvolvimento orientado a testes praticado popularmente em todas as seções do setor de tecnologia. A mudança da configuração da infraestrutura para a infraestrutura como código (IaC) facilitada por ferramentas de devops, como Chef e Puppet, significa que há um escopo maior para executar testes leves para verificar quaisquer alterações que serão implementadas em sua infraestrutura.

O kit de desenvolvimento do Puppet, o PDK, fornece ferramentas para testes de unidade, bem como para validar a sintaxe dos arquivos de código do Puppet, incluindo o arquivo metadata.json que rastreia todos os metadados do módulo no formato JSON. O Puppet depende de ferramentas padrão, incluindo RSpec e Cucumber, para testar o código do Puppet.

O Chef, por outro lado, oferece suporte a todos os itens acima e também inclui ferramentas poderosas para testar a exatidão e a conformidade do código da sua infraestrutura. A primeira dessas ferramentas é o ChefSpec, uma estrutura que estende os recursos do RSpec para permitir testar suas receitas como parte de uma execução simulada do Chef Infra Client. Uma infinidade de exemplos está disponível no repositório ChefSpec Github para ajudá-lo a começar.

Outra ferramenta de teste abrangente para receitas do Chef é o Kitchen, que permite o teste de integração de seus livros de receitas e código de infraestrutura do Chef, com uma arquitetura de plug-in de driver que testa seu código em ferramentas de virtualização e conteinerização, como Vagrant e Docker, bem como plataformas de nuvem.

O Kitchen ainda inclui suporte para código de gerenciamento de configuração de teste de integração executado por outras ferramentas de gerenciamento de configuração, como Ansible e Saltstack. Para esses casos de uso, são necessários provisionadores específicos, que estão disponíveis como bibliotecas de código aberto no Github. O ecossistema de testes de integração e teste de conformidade do Chef é muito mais cheio de recursos do que o oferecido pelo Puppet. O ecossistema do Chef também inclui o Chef Automate, uma ferramenta de nível empresarial para automatizar a conformidade de segurança e gerenciar a automação de sua infraestrutura a partir de um único painel.

Quando escolher o chef em vez do fantoche

Agora que vimos como essas duas plataformas funcionam nos bastidores e como elas realizam muitas das mesmas coisas, uma palavra sobre como escolher a plataforma certa para os requisitos de sua equipe. Uma ferramenta será mais adequada para um ambiente e conjunto de requisitos do que para outro, e isso é algo que você deve ponderar seriamente antes de fazer a seleção para sua equipe.

Para começar, você pode escolher o Chef em ambientes em que deseja considerar cenários complexos de gerenciamento de configuração, como implantação em vários destinos na nuvem e em plataformas de virtualização. O design do Chef funciona bem em cenários em que você precisa de todo o poder da linguagem de programação Ruby para codificar suas receitas, com poucas restrições para fazer as coisas de uma determinada maneira.

O ecossistema do Chef, em particular o Chef Habitat, oferece cobertura quando se trata de criar seus aplicativos para serem executados em praticamente qualquer sistema que você tenha em mente, e isso ajudará a simplificar seus fluxos de trabalho de conteinerização com o Docker ou o Kubernetes. O Chef tem excelente suporte para a comunidade de código aberto e outras ferramentas que sua empresa pode usar, como Kubernetes, Nagios, Docker e muito mais. As integrações estão disponíveis para plataformas de nuvem como a Rackspace, com o Amazon EC2 dando um passo adiante ao integrar servidores do Chef por meio do serviço AWS OpsWorks for Chef Automate. Em um sinal de seu compromisso com o código aberto, em abril de 2019, o CEO da Chef anunciou em uma postagem no blog que a Chef tornaria todos os seus produtos de código aberto. Depois que sua equipe dominar o Chef uma vez, você continuará colhendo os dividendos usando a experiência do Chef em seu amplo ecossistema de código aberto.

Quando escolher fantoche em vez de chef

O Puppet, com seu estilo declarativo, atrai organizações que desejam uma ferramenta confiável e fácil de usar para gerenciamento de configuração. Essa diferença filosófica se destaca fortemente de uma ferramenta como o Chef, que, embora igualmente poderosa, exige muito mais esforço programático, envolvendo o uso de Ruby puro e o Chef DSL. A decisão de usar o Chef impõe uma curva de aprendizado mais acentuada para desenvolvedores que não são Ruby. O estilo declarativo de gerenciamento de configuração vem com vários pontos fortes, incluindo facilidade de manutenção e manutenção da implementação de configuração consistente em toda a equipe.

O Puppet tem essas vantagens em comum com outras ferramentas de CM declarativas, como o Ansible, que usa o formato YAML para compor playbooks de configuração em um estilo declarativo. Se sua equipe de DevOps consistir em um grande número de administradores de sistema que provavelmente estão mais familiarizados com arquivos de configuração declarativos, o uso do Puppet será mais adequado para sua equipe. O Puppet é uma ferramenta de gerenciamento de configuração muito mais opinativa do que o Chef e deve, sem dúvida, funcionar melhor em equipes muito grandes, onde o Puppet, por design, coloca restrições embutidas no estilo do código.

Resumo

O Chef e o Puppet continuam a expandir suas plataformas de automação em resposta às necessidades da empresa habilitada para DevOps, com novos recursos, como o Chef Delivery e o Puppet Code Manager, ajudando a simplificar o pipeline de integração/entrega contínua. Ambos os fornecedores estão forjando parcerias que podem definir - como diria o Chef - a que escola de DevOps uma determinada organização pertence. No passado, os dois fizeram parceria com a Microsoft para integrar suas plataformas ao Azure, e o Puppet, acostumado a ser o primeiro, foi o primeiro a fazer alianças importantes com os principais fornecedores de SDN para posicioná-lo favoravelmente à medida que a tecnologia se consolida. Portanto, se sua organização planeja adotar SDN, o Puppet pode ser um candidato mais forte a esse respeito.

A segurança é uma preocupação de toda a empresa nos dias de hoje e deve ser levada em consideração ao avaliar as tecnologias. O Chef fez avanços significativos na melhoria da segurança de sua plataforma com o Chef Vault, embora suas 3 vulnerabilidades CVE publicadas certamente sejam insignificantes em comparação com as 79 do Puppet. É interessante que o Puppet Labs retransmita CVEs para software de fornecedores, como ruby, enquanto o Chef não, apesar de ambos os produtos incluírem Ruby como componente principal. Também é difícil acreditar que o Chef não encontrou uma vulnerabilidade em nenhum de seus softwares desde 2012.

Em suma, ambas as plataformas de automação de TI amadureceram muito como soluções corporativas. Destacamos alguns dos principais atributos e benefícios do Chef e do Puppet: selecionar a opção certa se resume a identificar as principais competências de cada plataforma e determinar quais delas estão alinhadas com as necessidades e requisitos exclusivos da sua organização. Independentemente da plataforma de automação escolhida, o UpGuard pode complementar qualquer uma das soluções para completar a cadeia de ferramentas de DevOps com avaliação e monitoramento avançados de vulnerabilidades, garantindo que a segurança - em função da qualidade - seja incorporada em todas as etapas do processo de entrega contínua.

Uma boa regra é que o Puppet é como escrever arquivos de configuração, enquanto o Chef é como programar o controle de seus nós. Se você ou sua equipe têm mais experiência com administração de sistemas, você pode preferir o Puppet e, se você for principalmente desenvolvedores, o Chef pode ser a melhor opção.

Isenção de responsabilidade

Os perfis de risco de segurança cibernética foram atualizados pela última vez em 12 de dezembro de 2019.

Embora estejamos comprometidos em representar o perfil de risco de cada empresa com precisão, este blog não é o lugar para monitoramento de risco em tempo real, e as informações acima devem ser tomadas como instantâneos pontuais.

Infográfico de fantoche vs chef