Ansible vs Puppet

Ansible e Puppet são os sistemas de gerenciamento de configuração (SCM) necessários para construir infraestruturas repetitivas.

O Ansible é fácil de usar, possui uma arquitetura sem agente (não requer a instalação de um agente / cliente no sistema de destino) e um DSL do tipo YAML, escrito em Python e facilmente expandido por módulos. Geralmente gerencia configurações do Linux.

O Puppet possui uma arquitetura cliente-servidor (consulta periodicamente o servidor para fazer alterações na configuração feita pelo administrador da rede), é escrito em Ruby e possui uma DSL semelhante a Ruby. Este aplicativo permite gerenciar centralmente a configuração do software instalado em vários computadores.

O artigo compara as vantagens e desvantagens desses SCMs.



Em comparação com os anos 90, atualmente os administradores e desenvolvedores de sistemas precisam gerenciar um número significativamente maior de servidores que hospedam muito mais aplicativos. A razão para isso é o crescimento exponencial da computação para organizações e empresas associadas ao advento de novas tecnologias, como virtualização e computação em nuvem.

Assim, ferramentas como Puppet e Ansible tornam-se rapidamente componentes necessários para gerenciar um grande número de servidores, por exemplo, em data centers. Eles são chamados de Configuration Management Tools (CM) e Remote Execution (RE) e geralmente são usados ​​com ferramentas de atualização de software. Esses aplicativos úteis permitem, por exemplo, que um administrador de rede execute ações em vários servidores ao mesmo tempo, implante vários aplicativos com um clique, o que simplifica bastante a configuração e manutenção de dezenas, centenas ou até milhares de servidores.

Ansible vs. Puppet: Uma Breve Revisão


Puppet é uma das marcas mais famosas do mercado CM. Existe desde 2005, que para as ferramentas de CM é equivalente a existir desde o início da humanidade. Muitos grandes nomes como Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs e Stanford University gerenciam seus data centers com o Puppet. Ter esses clientes a bordo sempre dá ao produto um certo nível de confiança. O Puppet também possui a interface mais madura e trabalha em todos os principais sistemas operacionais - Linux, Windows, Unix e até Mac OS X. Seguindo o modelo criado por várias versões do Linux, este aplicativo de código aberto é desenvolvido em Ruby. No entanto, existe uma empresa de apoio e patrocínio sólida e bem estabelecida do PuppetLabs,oferecendo suporte profissional e uma versão corporativa comercial do software.

O Puppet também oferece um procedimento simples de instalação e várias ferramentas para tarefas como implantação rápida em servidores clientes. Além da GUI, há uma CLI baseada em Ruby. De fato, para as tarefas mais avançadas, é provável que você dependa da CLI e a GUI é a interface para visualização, gerenciamento e monitoramento. Isso significa que, além de trabalhar como administrador do sistema, você precisa aprender Ruby.



Você pode pensar: “Tudo parece ótimo! Existe alguma desvantagem, ou vale a pena comprar o Puppet agora? ”.. O debate sobre o uso desse SCM em fóruns especializados de CM é que o Puppet, como muitos outros gigantes de software, foi vítima de seu próprio sucesso e tamanho. “Ágil” e “ágil” não são palavras que podem ser usadas para descrever o trabalho de Puppet. Os usuários relatam bugs que demoram muito para corrigir e ignorar novas solicitações. Também há alguma insatisfação com o fato de o PuppetLabs persistentemente pressionar seus clientes a aceitar a versão comercial. Por fim, embora o Puppet suporte Ruby puro e seu DSL configurado na CLI, o suporte somente para Ruby está obsoleto. Isso é uma má notícia para quem estudou Ruby, não para DSL.

O Ansible ignorou o Puppet, capturando a maior participação de mercado no setor de gerenciamento de configurações - 26,5%. É seguido pelo Microsoft System Center CM (21,8%) e Puppet (12%).



Também é um produto de código aberto lançado em 2012 e desde então tem sido suportado pela AnsibleWorks. Foi desenvolvido em Python, e não em Ruby, o que o torna espiritualmente mais próximo do Salt (outra nova ferramenta de CM) do que do Puppet. Outra vantagem do Python é que ele é incorporado à maioria dos aplicativos Unix e Linux; portanto, o SCM escrito nessa linguagem é instalado e funciona mais rapidamente.

A estratégia de marketing exclusiva da Ansible reside em sua implantação fácil e rápida. De fato, esse sistema nem usa agentes implementados para se comunicar com o cliente mestre; em vez disso, todas as funções são executadas através do SSH. Para aquelas configurações que não suportam SSH raiz, o Ansible pode executar "sudo" como raiz. O Ansible pode ser iniciado a partir da CLI sem usar arquivos de configuração para tarefas simples, como verificar a operação do serviço ou iniciar atualizações e reinicializações. Para tarefas mais complexas, a configuração Ansible é manipulada usando a sintaxe YAML nos arquivos de configuração chamados "playbooks". Os comandos possíveis podem ser escritos em quase qualquer linguagem de programação e distribuídos como módulos JSON universais, o que é claramente uma vantagem sobre a escolha de uma linguagem específica.

O Ansible se tornou mais popular com uma nova abordagem para tarefas de configuração tradicionais, e muitas empresas o utilizam para implantar grandes datacenters.

A comunidade Ansible de entusiastas está trabalhando duro para obter sucesso, aumentando o número de dispositivos suportados, integrando melhor suporte ao Windows, melhorando o ecossistema e assim por diante.

Ansible vs. Puppet: Diferença de instalação


As diferenças entre Ansible ou Puppet se tornam aparentes a partir do momento em que os sistemas são instalados. Como eles seguem diferentes paradigmas arquitetônicos, seu cenário é significativamente diferente. Portanto, o Ansible tem o objetivo explícito de tornar o processo de instalação o mais simples possível, o que se reflete na experiência do usuário.



Para configurar o Ansible, primeiro você precisa designar um nó como o nó de controle. De fato, qualquer um dos seus nós pode ser um nó de gerenciamento. É possível instalar o Ansible nesse nó usando o pacote Ansible mais recente nos repositórios de pacotes da sua distribuição, sem a necessidade de configurar o software cliente em outros nós. Basta criar um par de chaves SSH no nó de gerenciamento e copiá-los para os outros nós. Em seguida, crie um arquivo de inventário para nós Ansible - geralmente em sistemas operacionais Linux como Red Hat Linux, Ubuntu e Debian, isso acontece em / etc / ansible / hosts. Agora você está pronto para usar o Ansible para iniciar o PlayBook no host e no restante da infraestrutura de rede.O Ansible usará conexões SSH com seu nó de controle para acionar o gerenciamento de configurações com base no PlayBook.

A instalação do Puppet parece um pouco mais complicada, mas há muita documentação na Internet que ajudará em um caso difícil. Primeiro, você precisará configurar os nós mestre e do agente para que eles tenham o mesmo fuso horário e fuso horário. Então você precisa acessar o servidor principal com privilégios de root e instalar o software do servidor Puppet. Em seguida, você precisa configurar o arquivo do assistente Puppet / etc / hosts para conectar todos os clientes gerenciados, iniciar o serviço PuppetServer e colocá-lo no modo "ativar" para receber conexões do cliente na porta 8140. Como o Puppet depende do software cliente, será necessário instalar os agentes do software Puppet em cada um deles.

Além disso, você precisará adicionar o endereço IP do servidor mestre em / etc / hosts para que o cliente possa se conectar a ele. Para fazer isso, você deve iniciar e ativar o serviço do agente Puppet em cada cliente e, em seguida, gerar certificados SSL, pois esse sistema CM usa HTTPS para comunicação com o cliente principal.

Nos dois casos, será necessário reforçar a segurança do servidor para excluir a possibilidade de conexões não autorizadas.

Ansible vs. Puppet: mecanismo de transporte de escalabilidade e configuração


Os dois SCMs são bem dimensionados, mas usam mecanismos de transporte de configuração diferentes para conseguir isso. De fato, independentemente de você precisar gerenciar várias centenas ou dezenas de milhares de nós, existem truques e estratégias que você pode usar em cada plataforma para escalar convenientemente para o nível desejado.



O Ansible usa o mecanismo de transporte inteligente por padrão, que é baseado em certificados SSH confiáveis. O Ansible analisará primeiro os PlayBooks e identificará os elementos de infraestrutura afetados. Ela abrirá uma conexão SSH e criará um diretório temporário. Depois de fechar esta conexão, o Ansible abre uma segunda conexão para copiar o código do módulo Ansible e o código do modelo Ansible. O Ansible fechará essa conexão antes de abrir a terceira conexão final para executar o código. Essa configuração servirá à maioria dos propósitos, mas pode ser alterada conforme a infraestrutura é escalada.

A primeira função que o Ansible pode usar é chamada ControlPersist e depende de soquetes persistentes e persistentes para reduzir o tempo necessário para trocar apertos de mão necessários para várias conexões. O Ansible também suporta pipelining, uma configuração que reduz o número de conexões necessárias de três para um. Por fim, o Ansible pode ser configurado para lidar com mais nós de inventário ao mesmo tempo, configurando a variável de garfos na configuração deste sistema. Por padrão, esse valor é 5, mas você pode definir um valor mais alto para acelerar o processamento.



O mecanismo de transporte Puppet é HTTPS, que é gerenciado usando certificados SSL. Um servidor Puppet processa solicitações de configuração para uma lista inteira de clientes Puppet. Cada cliente envia fatos do Puppet ao servidor mestre, juntamente com uma solicitação ao diretório Puppet, após o qual o servidor mestre envia esse diretório em resposta. O cliente processa o diretório, verificando cada recurso de software com o estado de configuração necessário especificado no diretório. Se o recurso não estiver no estado desejado, o cliente Puppet atualizará o recurso neste computador e, após a conclusão da atualização, enviará um relatório sobre a alteração de configuração concluída ao servidor Puppet.



Notavelmente, o modelo de processamento Puppet aloca um encadeamento JRuby do pool de encadeamentos para manipular cada conexão de cliente recebida. À medida que o número de nós aumenta, o dimensionamento do Puppet pode ser otimizado aumentando o número de encadeamentos JRuby disponíveis no pool. Isso pode ser feito configurando o valor do parâmetro de configuração do Puppet "instâncias máximas ativas" mais alto que o valor padrão, que é 1. Como regra, esse valor é considerado igual ao número de núcleos de processador do seu computador, mas lembre-se de que isso exigirá mais A memória da CPU usou RAM RAM. Como regra geral, você também precisará definir um "tamanho máximo de heap" mais alto para a JVM do seu servidor Puppet para garantirque seus encadeamentos JRuby adicionais podem ser alocados sem um erro de falta de memória do Java. É necessário cuidado ao fazer essa configuração, pois isso pode resultar em perda de desempenho.

Exemplo de Código Ansible CM


Para o trabalho diário de configuração, escrever código Ansible é surpreendentemente simples devido a uma combinação de dois fatores: o uso do formato YAML para PlayBooks e o estilo declarativo de gerenciamento de configuração que corta “cantos cortantes”. Isso é importante para melhorar rapidamente o desempenho dos comandos do DevOps e garantir que seu código seja gerenciável, mesmo para tarefas complexas de configuração.

O código impossível é idempotente. Isso significa que você pode executar com segurança o PlayBook para componentes do sistema repetidamente, sem bagunçar seus servidores. O Ansible alterará apenas a configuração dos recursos de software nos servidores onde estiver fora do estado desejado. Por exemplo, se o seu PlayBook precisar instalar um pacote e criar um arquivo de configuração específico no disco, o Ansible instalará apenas esse pacote e criará o arquivo de configuração especificado quando o PlayBook foi iniciado pela primeira vez no host. Os lançamentos subsequentes do PlayBook deixam automaticamente o pacote intacto até que haja alguma alteração que remova ou modifique a configuração especificada de arquivo ou pacote. Isso mantém seus nós em um estado determinístico e previsível, com muito pouca ou nenhuma chance de desvio de configuração.

A seguir, é apresentado um exemplo do código Ansible PlayBook que instala o servidor da Web Tomcat nos seus sites. Este exemplo é retirado do repositório oficial de exemplos do Ansible, que você deve procurar para se familiarizar melhor com o estilo idiomático do Ansible:

---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present

- name: add group "tomcat"
group: name=tomcat

- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo

- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz

- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61

- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link

- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes

- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755

- name: Start Tomcat
service: name=tomcat state=started enabled=yes

- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables

- name: insert firewalld rule for tomcat http port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: insert firewalld rule for tomcat https port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: wait for tomcat to start
wait_for: port=

Essa tarefa Ansible específica baixa e instala o Apache Tomcat junto com o Java JDK 1.7 dependente e, em seguida, configura, inicia e instala o Tomcat. Como você pode ver neste exemplo, os arquivos controlados por Ansible podem conter modelos Jinja, o que simplifica o cálculo de valores e torna sua configuração mais flexível. O código YAML é fácil de ler e escrever para administradores de sistema e desenvolvedores. Isso leva ao fato de o Ansible estar se tornando um sistema de gerenciamento de configuração acessível para usuários avançados e iniciantes.

Exemplo de código de marionetes CM


A linguagem orientada a assuntos Puppet é baseada em Ruby, mas sua sintaxe está muito mais próxima de linguagens imperativas no estilo C, como Perl, Java e C ++. Essa abordagem é um intermediário entre desenvolvedores familiarizados com Ruby e aqueles que podem não estar familiarizados com esse idioma. Como resultado, talvez você não precise conhecer Ruby para aprender e usar o Puppet DSL de forma produtiva.
Este é um exemplo de um manifesto Puppet do repositório do PuppetLabs MySQL Puppet Module que instala e configura o pacote do cliente MySQL:

# @summary
#     Installs and configures the MySQL client.
#
# @example Install the MySQL client
#     class {'::mysql::client':
#         package_name => 'mysql-client',
#         package_ensure => 'present',
#         bindings_enable => true,
#     }
#
# @param bindings_enable
#     Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`.
# @param install_options
#     Array of install options for managed package resources. You must pass the appropriate options for the package manager.
# @param package_ensure
#     Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'.
# @param package_manage
#     Whether to manage the MySQL client package. Defaults to `true`.
# @param package_name
#     The name of the MySQL client package to install.
#
class mysql::client (
    $bindings_enable = $mysql::params::bindings_enable,
    $install_options = undef,
    $package_ensure = $mysql::params::client_package_ensure,
    $package_manage = $mysql::params::client_package_manage,
    $package_name = $mysql::params::client_package_name,
)  inherits mysql::params {
    
    include '::mysql::client::install'

    if $bindings_enable {
        class { 'mysql::bindings':
            java_enable => true,
            perl_enable => true,
            php_enable => true,
            python_enable => true,
            ruby_enable => true,
        }
    }

# Anchor pattern workaround to avoid resources of mysql::client::install to
# "float off" outside mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}

Uma vantagem importante do Puppet é que, diferentemente das linguagens de programação imperativas listadas acima, o Puppet DSL é declarativo, de certa forma semelhante ao XML, assim como o código YAML do exemplo de código Ansible acima. A abordagem declarativa do Puppet e do Ansible é realmente rastreada nos dois exemplos de código. Em termos de codificação, eles são semelhantes e mais próximos um do outro do que ferramentas como Chef. No entanto, a linguagem declarativa Puppet também fornece construções semelhantes ao Ruby, como expressões condicionais e iterações, o que novamente é um compromisso para os usuários do Ruby e para aqueles que não falam o idioma.

Ansible vs. Puppet: Facilidade de Uso


Para a equipe de desenvolvimento, a facilidade de uso deve ser uma parte importante da avaliação do SCM. Dado que os desenvolvedores da Ansible estão concentrando muito esforço na facilidade de uso do sistema, não há concorrentes nisso. Configurar, programar e gerenciar os nós fornece uma interface muito simples para engenheiros de desenvolvimento e administradores de sistema.

Isso não significa que o Puppet seja difícil de usar, mas esse sistema se comporta com confiança enquanto você segue o método proposto de automação de sua infraestrutura. Nesta área, o Puppet é bastante forte, modelando explicitamente cada recurso e fornecendo aos usuários módulos com comportamento padrão que são eficientemente usados ​​em seus manifestos.

Em termos de aprendizado do usuário, as duas plataformas são fáceis de usar, mas o Ansible tem uma pequena vantagem. É fácil obter um estilo YAML declarativo, portanto, o código Ansible nunca é muito complicado. Enquanto isso, o Puppet passou a reconhecer alguns dos problemas associados à combinação de dados e código nos mesmos arquivos de origem. Isso levou ao advento do Puppet Hiera, uma solução de armazenamento que usa o formato YAML para armazenar pares de valores-chave de dados de configuração. Hiera ajuda bastante na simplificação e otimização da experiência do Puppet DevOps. O formato YAML provou ser bastante popular no gerenciamento de configurações, com o Salt do SaltStack também usando esse formato.
Os dois SCMs têm a capacidade de validar e testar seu CM, desde a verificação de sintaxe até a integração da infraestrutura como código.

Ansible vs. Puppet: custos de licenciamento e implementação





Como ferramentas de código aberto, o Ansible e o Puppet têm muito em comum em suas políticas de licenciamento.

O lançamento de código aberto do Ansible é totalmente gratuito. As empresas que precisam de mais garantias de segurança, estabilidade e confiabilidade são incentivadas a atualizar para o Ansible Engine, o produto de classe empresarial que acompanha o Red Hat Linux. Os custos de licença do Ansible Engine geralmente variam de US $ 47,50 a US $ 70 por ano por nó e dependem da sua configuração preferida.

Se você precisar de suporte técnico com solução rápida de problemas, use a versão corporativa. A Ferramenta de Gerenciamento Ansible Tower para Grandes Empresas está disponível como um pacote de serviços e fornece à sua empresa mais recursos de treinamento, gerenciamento e agendamento de tarefas por meio de um painel de controle gráfico.

Como o Ansible, o lançamento do Puppet de código aberto está disponível gratuitamente. Para recursos corporativos adicionais e suporte técnico, as organizações podem atualizar para o Puppet Enterprise, que custa de US $ 112 a US $ 199 por ano por nó. O Puppet Enterprise oferece um pacote de várias ferramentas, incluindo relatórios e monitoramento do status da infraestrutura da empresa.

Ansible vs Puppet: Comunidade


O Puppet, lançado em 2005, é uma ferramenta antiga do DevOps, por isso teve mais tempo para criar sua própria comunidade e base de usuários. No entanto, o Ansible, lançado em 2012, graças à sua nova abordagem, conseguiu atrair um público ainda maior e criar uma comunidade muito dinâmica de entusiastas e usuários de desenvolvedores. Os usuários do Puppet incluem empresas como Uber, Salesforce e Paypal, enquanto a comunidade Ansible inclui empresas como Digital Ocean, 9GAG e TypeForm.

Se compararmos um indicador tão importante do desenvolvimento de produtos de código aberto como o número de colaboradores que participam do desenvolvimento no GitHub, o Ansible com mais de 4.800 colaboradores é muito superior ao Puppet, com seus 527 colaboradores no desenvolvimento de produtos. O desenvolvimento do Ansible nos últimos anos foi tão rápido que gerou a criação de um repositório "galáctico" separado do Ansible Galaxy . Isso significa que a comunidade Ansible se esforça para compartilhar seu código, contribuindo assim para o desenvolvimento adicional do produto.

Enquanto isso, a comunidade Puppet, que está se desenvolvendo de forma mais lenta e constante, criou uma infraestrutura para facilitar a localização de soluções para atender às suas necessidades de SCM. O Puppet Forge fornece módulos para tarefas comuns de gerenciamento de configuração da comunidade Puppet.

Ambos os sistemas possuem ferramentas de primeira classe para monitorar o ciclo de vida de um projeto de gerenciamento de configuração por meio da linha de comando. O Puppet e o Ansible se integram bem a outros sistemas DevOps amplamente usados, como Docker, Kubernetes e Jenkins, e plataformas de computação em nuvem da AWS e do Azure.

Ansible vs Puppet: qual é o melhor?


Nesta questão, a escolha é sua. O estilo declarativo do Ansible e do Puppet significa que essas ferramentas têm muito mais em comum do que outros sistemas de gerenciamento de configuração. No entanto, para fazer a melhor escolha, você precisa prestar atenção especial em como as necessidades de sua equipe são combinadas com o design e as vantagens de um SCM específico.
O Ansible é mais adequado para aqueles que estão interessados ​​na configuração no estilo YAML e compartilham a filosofia do Ansible de ser o mais simples possível ao gerenciar um grande conjunto de máquinas de forma rápida e simultânea. Além disso, essa filosofia se concentra no uso de funções SSH existentes, em vez de criar agentes do usuário.

O Puppet é mais adequado para equipes que preferem o DSL, que modela os recursos do sistema de maneira consistente e repetitiva. É exatamente isso que o Puppet DSL faz, juntamente com todo um ecossistema de ferramentas para tornar grandes equipes previsíveis e fáceis.

Se você sabe exatamente quais princípios de gerenciamento de configuração melhor atendem às suas necessidades, escolher entre Puppet e Ansible não será um problema para você.

achados


Para facilitar sua escolha, sugerimos que você se familiarize com as principais vantagens e desvantagens de ambos os sistemas.



Um pouco de publicidade :)


Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

All Articles